Issues with tinyprog -u on BX


#1

I am uploading picosoc programs a lot as part of the developmemt of my Pacman game for tiny-fpga-game-soc.

So I am doing:

tinyprog -p hardware.bin -u firmware.bin

After what looks like a sucessful upload, after getting:

Success!

there is a long wait until tinyprog returns, and when it does, all the USB devices on my Linux machine have stopped working and I have to reboot it with the power button. (This is not a modemmanager problem as I removed that a long time ago). I am running on a small Gigabyte box, which is a bit like an Intel NUC, and I am running Ubuntu 16.04. This problem does not seem to be related to the the files I am uploading as I can successfully upload hardware.bin and firmware.bin, then press the reset button on the TinyFPGA BX and do it again and the machine freezes.

Another problem that I get is tinyprog is:

Success!

Traceback (most recent call last):
File β€œ/home/lawrie/.local/bin/tinyprog”, line 11, in
sys.exit(main())
File β€œ/home/lawrie/.local/lib/python2.7/site-packages/tinyprog/main.py”, line 334, in main fpga.boot()
File β€œ/home/lawrie/.local/lib/python2.7/site-packages/tinyprog/init.py”, line 389, in boot self.ser.flush()
File β€œ/home/lawrie/.local/lib/python2.7/site-packages/tinyprog/init.py”, line 69, in flush self.ser.flush()
File β€œ/usr/lib/python2.7/dist-packages/serial/serialposix.py”, line 560, in flush termios.tcdrain(self.fd)
termios.error: (5, β€˜Input/output error’)

However, despite the track trace the upload os OK in that case.

The third problem is that I get a similar track trace but with a β€œFailure!” message, and the upload of the firmware (picosoc C program) fails. I will post the stack trace when I next get it. When this problem occurs, it is repeatable: every attempt to upload the same firmware.bin fails the same way. However, when I make a minor change to the C program, the upload works. So it seems to be related to the size (or possibly contents) of firmware.bin.

These errors slow down my development a bit, particularly the one that freezes the machine, although the Linux box reboots very quickly from its SSD.


#2

I’ve seen the I/O error and β€œfailure!” tracebacks here too… Sometimes retrying works. Other times I seem to have similar issues to you, and a modify/rebuild cycle seems to get things back on track.

I had pondered whether maybe I was reaching the wear limits of the flash given how much it’s been used, but I checked the flash datasheet and they’re rated for 100,000 cycles - even at 50 program cycles/day that’s 6 years worth of abuse :). I shouldn’t be anywhere near those sort of limits yet.

Something I’ve noticed is that I seem to be having more problems since using PicoSoC, so I wonder whether maybe something the SoC is doing to the flash (config registers etc), or to the USB pins, is interfering with the programming.

Thankfully I’ve never had the machine freeze on me yet. I’m using a macbook pro (with the usb-c ports and an Apple USB-C -> USB-A adaptor), and I’m doing the FPGA development in a VMWare Fusion VM (Ubuntu 16.04).

I’ll keep an eye out for future occurrences too, and if I can find a bitstream that consistently fails I’ll make a backup of it.


#3

This is the failure message I get:

> Programming /dev/ttyACM0 with firmware.bin
Programming at addr 050000
Waking up SPI flash
60276 bytes to program
Erasing: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 60.3k/60.3k [00:00<00:00, 98.1kB/s]
Writing: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 60.3k/60.3k [00:00<00:00, 165kB/s]
Reading: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 60.3k/60.3k [00:01<00:00, 56.0kB/s]
Failure!

…/…/hdl/tiny_soc.mk:2: recipe for target β€˜upload’ failed


#4

I just got the message:

Failure!

…/…/hdl/tiny_soc.mk:2: recipe for target β€˜upload’ failed

and no amount of retring seems to make that work again.

I switch and off some debugging (or make some other change) and that changes the size and makes things work again.


#5

The third problem is that I get a similar track trace but with a β€œFailure!” message, and the upload of the firmware (picosoc C program) fails

I’ve had this problem, too. I filed a issue on github about this.

In my experience, appending a few bytes to the firmware binary is a work-around when you hit the bug – no C code changes necessary. Like so:

echo "xxx" >>firmware.bin


#6

@mkimball, @gundy, @lawrie.griffiths: Try updating to the latest tinyprog. I modified the programming algorithm a bit to avoid the β€œFailure!” issue. Let me know if that helps.


#7

I get a new error message with the new version:

Programming /dev/ttyACM0 with firmware.bin
Programming at addr 050000
Waking up SPI flash
61408 bytes to program
Programming and Verifying:  99%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰| 60.7k/61.4k [00:01<00:00, 46.9kB/s]

Offset: 388864
Readback Data:
78 b3 01 00 5c cd 01 00 cc e8 01 00 dc 05 02 00
a8 24 02 00 47 45 02 00 d8 67 02 00 77 8c 02 00
43 b3 02 00 5e dc 02 00 ea 07 03 00 30 31 32 33
34 35 36 37 38 39 41 42 43 44 45 46 00 00 00 00
06 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 e2 04 00 06 05 01 02 0b 65 05 06
67 80 00 00 0b 65 05 0a 67 80 00 00 10 00 00 00
00 ff ff 80 20 10 08 04 02 01 00 00 00 00 00 00
10 00 00 00 10 b0 b4 a0 80 60 40 30 20 10 08 04
03 02 01 00 10 00 00 00 80 60 40 20 10 08 02 02

Write Data:
78 b3 01 00 5c cd 01 00 cc e8 01 00 dc 05 02 00
a8 24 02 00 47 45 02 00 d8 67 02 00 77 8c 02 00
43 b3 02 00 5e dc 02 00 ea 07 03 00 30 31 32 33
34 35 36 37 38 39 41 42 43 44 45 46 00 00 00 00
06 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 e2 04 00 06 05 01 02 0b 65 05 06
67 80 00 00 0b 65 05 0a 67 80 00 00 10 00 00 00
00 ff ff 80 20 10 08 04 02 01 00 00 00 00 00 00
10 00 00 00 10 b0 b4 a0 80 60 40 30 20 10 08 04
03 02 01 00 10 00 00 00 80 60 40 20 10 08 02 02
01 01 00 00 00 00 00 00 10 00 00 00 ff ff c0 80
40 20 10 00 00 00 00 00 00 00 00 00 00 00 00 00

FAILED!
Programming and Verifying: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 61.4k/61.4k [00:02<00:00, 25.3kB/s]

#8

Can you post the bitstream(s) and command line?


#9

Sorry I don’t have firmware.bin any more as the code has moved on. I could post hardware.bin as that is the standard one for the game Soc, but I don’t think that is the problem. The command lines is:

tinyprog -p hardware.bin -u firmware.bin

I will save firmware.bin and post it if the failure happens again.


#10

Here is another failure:

Programming at addr 050000
Waking up SPI flash
63392 bytes to program
Programming and Verifying: 98%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–Š| 62.2k/63.4k [00:01<00:00, 40.9kB/s]
Offset: 390912
Readback Data:
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 e2 04 00 06 05 01 02 0b 65 05 06
67 80 00 00 0b 65 05 0a 67 80 00 00 10 00 00 00
00 ff ff 80 20 10 08 04 02 01 00 00 00 00 00 00
10 00 00 00 10 b0 b4 a0 80 60 40 30 20 10 08 04
03 02 01 00 10 00 00 00 80 60 40 20 10 08 02 02

Write Data:
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 e2 04 00 06 05 01 02 0b 65 05 06
67 80 00 00 0b 65 05 0a 67 80 00 00 10 00 00 00
00 ff ff 80 20 10 08 04 02 01 00 00 00 00 00 00
10 00 00 00 10 b0 b4 a0 80 60 40 30 20 10 08 04
03 02 01 00 10 00 00 00 80 60 40 20 10 08 02 02
01 01 00 00 00 00 00 00 10 00 00 00 ff ff c0 80
40 20 10 00 00 00 00 00 00 00 00 00 00 00 00 00

FAILED!
Programming and Verifying: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 63.4k/63.4k [00:02<00:00, 25.1kB/s]

This size of firmware.bin is 63392 bytes and I have attached it. I renamed it as firmware.bit so that I was allowed to upload it.

firmware.bit (61.9 KB)

Doing what @mkimball suggested and added 3 bytes to the end of firmware.bin allowed me to upload it.


#11

Interesting - I’m not sure if it’s a coincidence or not, but in each of your traces there appear to be 32 bytes missing from the read-back data, and the USB endpoint in the bootloader appears to be using 32-byte buffers… potentially a buffer worth of data being lost somewhere?


#12

@mkimball, @lawrie.griffiths: thanks for your debug info! I have a much better idea of what’s going on and I think I’ll have a fix published later this evening.


#13

Will there be a Py3 wheel for the current or about-to-be-published version of tinyprog?


#14

There’s supposed to be a py3 wheel. The build was not behaving for some reason…I think it was a tools issue. I’ll make sure there’s a py3 wheel for the next release.


#15

Sounds great, thanks!