Just got mine BX. Going with the guide I tried updating bootloader. Few times it crashed while waiting for response after first stage. Next time it got to second stage, crashed, now tinyprog can’t see it and the boot diode stopped flashing. I’ve got old Raspberry Pi B+ if I need to reprogram it this way.
Has anyone ever done that and has tips? Or maybe a guide?
There seem to be several people with a bricked BX that need to reprogram it.
All ways to reprogram it require soldering wires to the SPI pins on the underside of the BX, unless you have a test rig like @lukevalenty has to connect to the pads using pogo pins or you have a device such as https://www.tindie.com/products/loglow/tinyfpga-bx-breakout-revision-a/.
They all use the multiboot bootloader binary - https://github.com/tinyfpga/TinyFPGA-Bootloader/releases/download/1.0.1/tinyfpga_bx_fw.bin
These are the ways that I have seen people succeed with:
Reprogramming using an Arduino
This is described in Arduino programmer (B series)
It makes an Arduino emulate the USB to SPI protocol that the TinyFPGA bootloaders use. For the BX you would use tinyprog as the programmer, and solder wires to the SPI pads on the underside of the BX.
You could use other cheaper version of the Arduino for this such as an Arduino Nano clone, or an STM32 device like the Blue Pill. If you use a 3.3v device you would not need the resistor voltage dividers.
Using an FTDI JTAG/SPI programmer
This is described in BX board received, BX bootloader wiped! [Solved]
It uses iceprog (one of the icestorm tools) rather than tinyprog.
Using another BX
I have successfully done this as described in Experiments with BX programmer and bootloader
Using an SPIDriver
I have not seen anyone use James Bowman’s SPIDriver, but I am pretty sure that could be made to work - https://www.crowdsupply.com/excamera/spidriver
It has a python version of iceprog - https://github.com/jamesbowman/spidriver/blob/master/python/samples/iceprog.py
I have not seen anyone use a Raspberry Pi to program a BX, but it should be possible.
One way would be to make a Raspberry Pi Zero work like an Arduino as a serial USB device that bridges to SPI, but this would be quite complex, and it is much easier to use an Arduino for that.
Another way would be to write a version of iceprog for the Raspberry Pi that drives SPI directly rather than via a USB FTDI device. I wrote something similar for the BlackIce icestorm FPGA, but that works rather differently from the BX. Such a utility would not be hard, but it would need someone to write it.
If anyone has knows any other ways to reprogram the BX, or spots any errors in my list of methods, please add to this thread.
Error while updating bootloader: invalid literal for int() with base 10
RE: Using an SPIDriver
Just a note as I happened to brick my BX this evening when an running
tinyprog --update-bootloader hit a
writeTimeoutError while 44% into the stage two erase.
I tried the Arduino method with a Deumillanova (5v needing the resistor dividers) and a Due (3.3v) and both methods failed. The RX light on the arduino flashed once a second for around a minute before it failed. Frustrated with having set it up twice and it failed I thought I’d the the SPIDriver I had laying around instead as it seemed like the right tool for the job.
I tried using a clip on the chip directly but the small passive component by pin 17’s silk screen made getting decent contact unreliable.
I ended up soldering to the pads on the underside of the BX and connecting the the SPIDriver and after powering on with the BX reset button held, and keeping it held, the SPIDriver could read the device ID.
I had to modify the flash.py from the SPIDriver samples folder to expect the correct JDEC ID and hardcode the size: https://gist.github.com/Palmr/cd458e6ba28f9bc60799c3514049c88a
But that worked just fine for me and it’s no longer bricked.
So I can confirm that the SPIDriver is a valid method of un-bricking a TinyFPGA BX.
@palmr, Just to clarify - when you tried the Arduino did you connect it to the SPI pins on
J4 on the BX board or did you use the connection diagram on github?
I think the latter doesn’t work for the BX - in fact I think it has the potential to kill your BX (depending on what the current code does with pins
BTW, the moment you connect anything to the SPI pins on
J4 it is probably a good idea to always keep the reset button pressed while programming.
@mlampert I initially tried the connections on the diagram before realising the pins it showed weren’t the SPI pins… Then I attempted to use the ones on the underside but I still could not get it to work. It could have been my bad soldering to the SPI pins or my general impatience.
Fortunately my BX survived my initial attempts with the incorrect pins on it and the SPIDriver resurrected it.
Knowing what I know now the next time this happens I’ll continue to use the SPIDriver as it was simple and quick to run. I’d also use thinner gauge wires and solder a wire to the reset pad so the SPIDriver could keep it in reset mode instead of me holding it.
How do I know if my bootloader is bricked? I’ve just recevied my TInyFPGA BX and while following the guide to check/upgrade the bootloader (on windows mind you), it stays in “Only one board with active bootloader, using it.” And does not do anything else at all. The bootloader LED fades in and out, but I don’t see any progress on the command.
What are you running SPIDriver on?
Just had my brand new BX brick after carefully following the user guide. Second part of the update. Why isn’t there an official unbricking guide? Seems to happen a lot.
I just unbricked a TinyFPGA BX with a bus pirate and flashrom.
I soldered wires from the pads under the BX to the bus pirate connector like this :
BusPirate — BX
GND G of course
5V Vin (it’s not a pad)
I had to expand the firmware binfile to the flash size but adding zeros :
dd if=/dev/zero of=tinyfpga_bx_fw_1Mb.bin oflag=append conv=notrunc bs=1 count=749636
then flashrom was happy :
flashrom --programmer buspirate_spi:dev=/dev/ttyUSB0 -f -w ../tinyfpga_bx_fw_1Mb.bin
(flashrom compiled from source, packaged version on debian systems is usually too old)