TinyFPGA based on iCE40-UP5K-SG48



Yesterday I did my third attempt at assembling the board. The OSHPARK PCB never arrived so I had to do it with ones from aisler. of the 9 boards I endded up ordering 3 did not pass electric check and are marked with x-out.

On the image you see some pads on the top board don’t shine. I think I might have been unlucky(aisler offered reduction on my next order).

This is after applying the solder

A assembled the board (got 3v3 and 1v2) and the power led is working.

The oscillator also produces the expected 16 Mhz

and I can see a 12.5 MHz signal on the SPI data line. I therefore think the FPGA is most likely working.

I created programming jig (to program the SPI flash) using one of the broken boards and some test pins(different from what I ordered before).

Soldered wires where the SPI flash should have been (as they are connected to the programming pins)

The finished programming jig looks like this.

I can now mount my soldered board on top of the programming jig and attach a bus pirate for the programming part:

I also have an option to keep the reset button pressed (to keep the FPGA in reset ?)

The next step is to program the SPI with a blinky using the bus pirate and flashrom. So far flashrom was not able to detect my chip.


Great progress! I’m on the edge of my seat over here.



Today I finally spent some time on the project and thinking about the next step.

As state the problem is that I can not program the flash currently because the FPGA itself is trying to boot from the flash and is generating the clock.

I investigated the possibility to boot the FPGA into slave mode. This can be done by pulling down the CS line (compared to pullup) when booting into FPGA master mode. The good news is that this pin is the slave select line that was exported to the programming header anyway.

With a 1k5 pulldown (the 10K pullup is still present on the board) I can indeed see that the board no longer pollutes the SPI clock line.

The bad news is that to program the SPI I will need the SS line low. I have a few options

  1. Power the FPGA into slave mode and use flashrom afterwards to flash the SPI (This currently does not work as flashrom is also controlling the power to the FPGA)… hope that the SPI flash programming won’t get the FPGA into a working state

  2. Well. keep the FPGA in slave mode and use a TinyFPGA-BX(or similar) to push the data into the my fpga over SPI. The SPI protocol itself is ratter simple (described in http://www.latticesemi.com/dynamic/view_document.cfm?document_id=46502 ) . This can be nice while developing the the bootloader.

bootloader “development” probably means gettingthe code from the fomu project https://www.crowdsupply.com/sutajio-kosagi/fomu


Phew… my ass had gone to sleep with all my edge of the seat sitting.

How is this different from the TinyFPGA BX? How is that device initially programmed?


Just hold the CRESET_B pin Low, and you can do with the SPI pins what you want. The FPGA holds all the IO pins in tristate while the reset is low.


Hi @mnemonix

Indeed! when holding in reset (and forcing SS low) I am now getting my flash detected!

flashrom p1.0-22-g0bfa819-dirty on Linux 4.18.0-17-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found SST flash chip “SST25VF016B” (2048 kB, SPI) on buspirate_spi.
No operations were specified.


I was able to flash the bit file to flash but it ain’t blinking yet… I do see some difference in the board compared to when it was not programed (the user led is no longer on by default) hence getting close

I copied code from upduino but perhaps I need to change the makefile to account for a different package or similar. At first I suspected something to be wrong with the clocks but also combinatorial logic does not apply

code here

Flashing using flashrom does take 7 minutes…


In my opinion you need to swap the SDI and SDO connections to the Flash chip. Otherwise the FPGA can not access the Flash in Master mode, and maybe also programming of the Flash will go faster.



Hi @mnemonix

That would be very bad news. I swapped the pins after reviewing the work from @glanzi in rev 0x03. I now just compared TinyFPGA-BX and my board and the pins look similar at this point so I am crossing fingers that things are alright. I played with the upduino yesterday. Today I think I will try programming using iceprog

BX     SI (5)        SDO          IOB_105_SDO
       SO (2)        SDI          IOB_106_SDI

      MOSI (5)       SDO          IOB_32a_SPI_SO
      MISO (2)       SDI          IOB_33b_SPI_SI



We have blinky!



These is correct, but your schematic shows it otherwise.
Anyway it seems to work now - congratulations.
Is it because you used iceprog, or what was wrong before?


I See, thank you so much for looking into the schematics. I have updated the pdf. Keeping track of the revisions, components ordered and keeping the pdf, schematics, bom in sync remains quite a challenge.

I am still flashing using flashrom but this takes 7 minutes to flash hence not really useful for further development. My FTDI chip laying around do not work with iceprog (they are FT232 based and somehow don’t work).

I am investigating different options to continue development and faster flashing but the board, as is, is not a great development platform yet.


Again, seems very quiet…

how is progress?




Indeed not much progress here. I have still just assembled one board and was able to blink. I need to flash the bootloader (possibly using the one from FOMU) but that did not happen. It have been over a year since I started working on this.


I few days ago I saw some changes also happening here https://github.com/glanzi/TinyFPGA-UP


sent you email, do you have spare boards?
ie to be soldered by me…

found https://github.com/keesj/TinyFPGA-BX
is this up to date?

ie it is over a year old…
so perhaps needs update?




if you are interested in helping out (getting the bootloader working) I can certainly consider sending a board !


ok! have emailed you postal address.

let me know if you have not received it: jay at peepo.com


re: FTDI

these can be a hassle.
on linux in terminal type lsusb, after plugging in device
ID 0403:6014
is found on my box
another possibility is ID 0403:6010
iirc the later versions of iceprog cater for these two possibilities
earlier versions did not.
find iceprog.c and search

lsusb means list usb devices connected
windows etc. will have alternatives



Time flies and I have not sent the board. It is still going to take a couple of week before I will be ready for it.
my kid (15) is sailing out to discover the world during a 6 month trip ( https://www.gofundme.com/f/pvhwza-sem-at-sea-15-jarige-scholier-en-avonturier | https://www.sem-at-sea.nl/ ) and I have bought a new house that will provide more room for my hobbies.

One of the challenges was packaging the components. The small SMD components do not have a clear marking and the KiCad bom tools are not great for printing a label. Best case would be to print the ibom http://www.keesj.dds.nl/bom/ibom.html and tape the components on the paper.