If it can do 48MHz or better and capture enough data then that’s all I need. I’m writing a USB decoder anyways and this would even help with that.
If you do send me a capture, here are some tips:
I’ll see what I can do. Give me a few minutes.
Well here is a mess of probably pretty useless data:
Alrighty, I’ll take a close look at this tomorrow when I’m fresh. Thanks for all the data!
@ssamuelcomeau, @fdgonthier, @Rogdham: Just a quick update for you guys. I’m working on getting a testbench up and running with the bootloader. I already have a testbench built for the USB packet RX path. It’s pretty basic, but I’m learning cocotb as I go. It’s very promising. I’ll be able to build a testbench that uses the actual programmer python script talking to a simulation of the bootloader. That’s awesome, but not an immediate fix for you guys.
I believe the issue is specific to Linux. Windows works very reliably, MacOS is working well since the last few updates made. @Rogdham has been using MacOS and would have more feedback there. Linux is where I have done the least testing. I’m going to be putting together a simple Linux system so I can reproduce the issue and try out workarounds without making you guys work for it. I should have a fix by this weekend.
Quick correction: I’m using Archlinux and not MacOS
However, I erased the bootloader some time ago, so not really possible to try things while you haven’t released the binary
Ask and ye shall receive!
fw.mcs (911.2 KB)
It’s in Intel Hex format: https://en.wikipedia.org/wiki/Intel_HEX
EDIT: this is the default bootloader, not one with any fix. It’s for @Rogdham or anyone else to reflash the standard bootloader onto the board.
I might have a lead on the programmer issue. It turns out that my os was automatically using python3 to open the programmer instead of python2.7. I have installed python2.7 and am forcing it to be used everytime and so far it is much better.
Glad to hear. This sounds like something I need to put in the documentation.
Well…I’ve been working on improving the reliability of the programmer anyways. I have been using my NAS machine which has Linux installed on it. I’ve added some built-in retry mechanisms to help improve stability. Give it a try if you are inclined: https://raw.githubusercontent.com/tinyfpga/TinyFPGA-B-Series/master/programmer/tinyfpgab.py
That is interesting that your OS was using python3, the top of the
#!/usr/bin/env python2 to tell the shell how to execute it. I suppose if it doesn’t already have execute permissions set then you are probably running it with
python and not by executing it. I should add some instructions on using the command-line interface to the user guide as well.
@fdgonthier: try running with python 2.7 like @ssamuelcomeau mentioned and report back if that works better. Also, try out the updated
tinyfpgab.py script to see if it further improves stability for you: https://raw.githubusercontent.com/tinyfpga/TinyFPGA-B-Series/master/programmer/tinyfpgab.py
Ok so that seems to work really well. I just have to keep in mind that the bootloader takes about 22s to fully initiate and be ready to program. Does that sound about right?
Are you talking about the time from pressing the reset button to being able to run the
tinyfpgab.py script to program the board? If that’s the case, 22 seconds is very long. The bootloader itself is ready almost instantly, any lag time is up to the OS you are running. I haven’t noticed such a long time myself. Usually just a couple seconds before I can program the board.
Interesting. Yes from the time the reset button is pressed until the programmer will successfully grab the B2 I have done it about five times now and it is consistently 22s. It easily could be my OS since I use a pretty non-standard distro. It reports the device or resource busy: ‘/dev/ttyACM0’. Either way, I’m happy. The new programmer works very predictably.
So I just checked it myself, on Windows 10 I can run the programmer script within a second of pressing the reset button on the TinyFPGA board. When my little Linux box arrives later today I’ll be able to test the timing for Linux as well.
Actually programming the TinyFPGA board should take 7 seconds or so.
That is very interesting. I’ll be able to verify whether that is generic Linux issue or more dependent on distribution.
The new programmer script has a few different levels of retry in case of failure. Both in picking up the board in the beginning as well as if there are any verification issues.
So testing on my USB3.0 port. I get 0-22s programmer fails with resource busy message and 5s until programmed. (I previously had been using my 2.0 port which is locate more conveniently on my laptop which took over 50s to program.)
FYI: I’ve uploaded the programmer to pypi. If you install it via
sudo pip install tinyfpgab then you should be able to just run
tinyfpgab to execute the programmer. @ssamuelcomeau, would you mind checking to make sure it automatically runs with Python 2.7 on your machine? Then I’ll be updating the documentation.
It’s good to go!! I haven’t had any problems since I actually installed python2.7.