ice40 Hx8K project not configuring from external flash

[Nasdrasil]

Bare with me... I am merely a tinkerer who likes to hobby around electronics in her spare time.

So I have been toying a bit with an icefun board and icestudio to produce a prototype for a project I'm working on. I have everything working on the breadboard as it should, so I designed a pcb exactly according to the schematics of the icefun board (which are publicly available), soldered everything in (I'm using thesame CB132 bga package), programmed the pic to handle usb communication and was able to upload my bin file using iceFUNprog as well as icestudio. My hopes were high.... but...

Unfortunately no code is being executed by the fpga. I can see data moving on SPI_SI of the flash memory on my scope when I program it. However... I see no activity at all in SPI_SO towards the fpga. ISP_SS is set high for master ISP configuration, which I measured is also the case on the original icefun board. I'm kinda wondering what could be causing this.

I checked all the fpga connections with the internal protection diode test method when I had just soldered it in (no other components were on the board during this test). Every measurement on O/I was good, so I was quite confident that the soldering went well. There are no shorts on 3.3V nor on 1.2V.

I'm wondering whether a reflow (or maybe even replacement) of the fpga is needed, or if I'm missing something else. Could it be the flash chip perhaps? This is an AT25SF081 like the original icefun board has. Maybe something obvious that I am completely oblivious about?

Hopefully someone with more knowledge can provide some insight in the workflow of troubleshooting :-)

[woofy]

How are you controlling the fpga reset. On the icefun its controlled by the on board pic.

[iMo]

..ISP_SS is set high for master ISP configuration, which I measured is also the case on the original icefun board. I'm kinda wondering what could be causing this..

After the CRESET_B goes from low to high the ice40 samples the SPI_SS.
If the SPI_SS is sampled low, the ice40 waits to be configured off an external master..

iCE40 Programming and Configuration Technical Note, p.10

[Nasdrasil]

How are you controlling the fpga reset. On the icefun its controlled by the on board pic.

I copied the design, so in thesame way as the icefun board does. The pic also has thesame code loaded on to it as the original icefun has.

[Nasdrasil]

..ISP_SS is set high for master ISP configuration, which I measured is also the case on the original icefun board. I'm kinda wondering what could be causing this..

After the CRESET_B goes from low to high the ice40 samples the SPI_SS.
If the SPI_SS is sampled low, the ice40 waits to be configured off an external master..

iCE40 Programming and Configuration Technical Note, p.10

Are you suggesting the fpga is in fact not set to master SPI, but instead slave while the microcontroller handles the configuration from flash memory as master SPI?

[SiliconWizard]

..ISP_SS is set high for master ISP configuration, which I measured is also the case on the original icefun board. I'm kinda wondering what could be causing this..

After the CRESET_B goes from low to high the ice40 samples the SPI_SS.
If the SPI_SS is sampled low, the ice40 waits to be configured off an external master..

iCE40 Programming and Configuration Technical Note, p.10

Are you suggesting the fpga is in fact not set to master SPI, but instead slave while the microcontroller handles the configuration from flash memory as master SPI?

I'm not sure, but something to check.
If you copied the design from this: https://www.robot-electronics.co.uk/icefun.html
The flash chip is connected to both the PIC MCU and the FPGA. I'm supposing that the MCU does at least program the flash chip, but i don't know how the FPGA configuration itself is handled.

There's a programming tool for this: https://github.com/devantech/iceFUNprog , but haven't found the firmware of the MCU itself so far. How do you program your board?

[Nasdrasil]

I'm not sure, but something to check.
If you copied the design from this: https://www.robot-electronics.co.uk/icefun.html
The flash chip is connected to both the PIC MCU and the FPGA. I'm supposing that the MCU does at least program the flash chip, but i don't know how the FPGA configuration itself is handled.

There's a programming tool for this: https://github.com/devantech/iceFUNprog , but haven't found the firmware of the MCU itself so far. How do you program your board?

I'll check this in the weekend when I have a bit more time. I could compare the scope readouts on powerup of the original icefun board with my design. Perhaps that will tell me something?

I extracted the hex file frome the original icefun pic and loaded that into the pic on my board. Since windows detects the board when I plug it in, and data is being written to the flash memory I assumed this part of the design is doing its jobs as it is supposed to.

I program the original icefun board with icestudio. To program my design I have tried both icestudio as wel as iceFunprog. Both pieces of software appear to be moving data into the flash memory.

[SiliconWizard]

If you could post your schematic, maybe something would pop up that you haven't caught.
Other than a potential hardware issue, having access to the source code of the firmware for the PIC would definitely help understanding what exactly it does and how, and thus probably help figuring out your issue. Haven't found this source code, but haven't looked hard and maybe it's available.

[Nasdrasil]

If you could post your schematic, maybe something would pop up that you haven't caught.
Other than a potential hardware issue, having access to the source code of the firmware for the PIC would definitely help understanding what exactly it does and how, and thus probably help figuring out your issue. Haven't found this source code, but haven't looked hard and maybe it's available.

I added a screencap of the part of the schematics that cover the SPI interfaces of all three components. It's not the neatest but it'll do the job. I believe I have connected everything as it is in the datasheet of the icefun board. As for the source code to the pic firmware... I haven't found that. I guess the hex code (maybe in Mplab?) could be disassembled but I don't know how much use that would be.

Edit:

Upon comparing the original icefun board to my design I can see that CDONE on the icefun board is set to high. On my board this keeps low on powerup, which I guess is no surprise.

[woofy]

I program the original icefun board with icestudio. To program my design I have tried both icestudio as wel as iceFunprog. Both pieces of software appear to be moving data into the flash memory.

How does icestudio program the icefun flash? icefun uses a custom command set to acquire the flash and send the data. Do you have verify switched on to confirm the flash is programmed?

[Nasdrasil]

How does icestudio program the icefun flash? icefun uses a custom command set to acquire the flash and send the data. Do you have verify switched on to confirm the flash is programmed?

I am not aware of an option to turn verify on in Icestudio, but that could be because of my ignorance ;-) Is there such an option?

Output command gives me this after flashing to my pcb.

Info: Program finished normally.
icefunprog COM3 hardware.bin
Flash ID 0x1f 0x85 0x1
Program length 135100
Erase pages 3
Erasing sector 0x00000
Erase sector response 0xb0
Erasing sector 0x10000
Erase sector response 0xb0
Erasing sector 0x20000
Erase sector response 0xb0
################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

Flash ok
Release response 0x0
========================= [SUCCESS] Took 9.06 seconds =========================

[woofy]

Not really sure whats going on there, try using iceFUNprog as stand alone programmer which defaults to verify, like:

iceFUNprog blinky.bin
iceFUN v1, Flash ID 1F 85 01
Erasing sector 000000
Erasing sector 010000
Erasing sector 020000
file size: 135100
Programming ....................................................
Verifying ....................................................
Done.
 
The -v switch inhibits the verify:
iceFUNprog -v blinky.bin

Do you have CRESET connected to the FPGA?
This does sound like a hardware fault, you could show all the schematic not just the bit you think matters.

[Nasdrasil]

iceFUNprog gives me this as output

FPGA reset.
Flash ID = 1F 85 01
Program length 0x020FBC
Erasing sector 0x000000
Erasing sector 0x010000
Erasing sector 0x020000
Programming ....................................................
Verifying ....................................................
Done.

CRESET is connected to the fpga in my design. I didn't bother with the full schematics because the design is 100% a copy of what the original looks like. I just removed the parts I didn't need (buttons, led's, piezo etc.) I used thesame components (LDO's, PIC and Flash chip).

My reasoning now is that it is either

- the PIC. I highly doubt this though since it has thesame firmware as the original board and it connects, passes data and generates a 12 Mhz clock.
- the flash memory. Could the chip be corrupt in such a way that it receives and stores data, but the fpga can't read it? Then again... If that was the case I guess iceFUNprog wouldn't be able to verify it either? Fact is on the icefun board I can see SPI_SO data on the flash memory chip during bootup. On my board there is just a constant high signal there. Nothing moving between the fpga and flash memory.
- the fpga. It was the first thing to be soldered onto the pcb, so I could check every input and output. I was careful to really take my time and measure every I/O I use. They all checked out.

I'm wondering if replacing the flash memory would be an option to start with. Really don't feel like going through the process of reballing that hx8k to be honost... ;-)

[woofy]

I really don't see this being the flash chip, but it is the easiest to replace. I'd bet its a connection problem under the fpga. It might be easier to simply build another one up.
Just out of curiosity, what PCB are you using, I've never been able to track the Hx8k CB132 in less than 6 layers.

[julian1]

I can see data moving on SPI_SI of the flash memory on my scope when I program it. However... I see no activity at all in SPI_SO towards the fpga. ISP_SS is set high for master ISP configuration, which I measured is also the case on the original icefun board. I'm kinda wondering what could be causing this.

For bitstream configuration with ice40 as master, SS needs to be pulled high with a light pull-up resistor. But after the ice40 has sampled SS for the configuration direction, then (if master) it will drive SS low, to select the spi flash mem device for the spi transfer.

If SS is not driven low by the ice40 - then the flash mem device is never selected/made active, and it will not drive MISO, and you won't see data on MISO.
So scoping SS that may be something to check.
If SS is correctly configured with the pull-up on SS, but the ice40 is not driving it low, then it's more likely the on-chip power-supply supervisor is holding up the advance to the bitstream load sequence.   

[SiliconWizard]

Upon comparing the original icefun board to my design I can see that CDONE on the icefun board is set to high. On my board this keeps low on powerup, which I guess is no surprise.

The CDONE pin should be pulled low by the iCE40 until it's fully configured, then CDONE will be released and become high (it's an open-drain output). There's an internal pull-up on CDONE in the iCE40, so even without any external pull-up, you should normally still see a high level if it's configured. What it shows here is that the FPGA never gets to the configured state, which makes sense as you have noticed that it doesn't "run" as expected.

The reason it's not configured is that it it can't, or doesn't read the bitstream from the Flash chip.
The reason why is still unknown as it is. Sorry if I missed it, have you checked that CRESET is not permanently held low?

[Nasdrasil]

Just out of curiosity, what PCB are you using, I've never been able to track the Hx8k CB132 in less than 6 layers.

I am using a 4 layer pcb since I don't need to fan out all the connections. I think all in all (including SPI configuration pins) 36 pins are used. It made it very possible on 4 layers using 0.2mm via's. Board was made by jlcpcb.

For bitstream configuration with ice40 as master, SS needs to be pulled high with a light pull-up resistor. But after the ice40 has sampled SS for the configuration direction, then (if master) it will drive SS low, to select the spi flash mem device for the spi transfer.

If SS is not driven low by the ice40 - then the flash mem device is never selected/made active, and it will not drive MISO, and you won't see data on MISO.
So scoping SS that may be something to check.
If SS is correctly configured with the pull-up on SS, but the ice40 is not driving it low, then it's more likely the on-chip power-supply supervisor is holding up the advance to the bitstream load sequence.   

I measure on both the original icefun board and on my board SS stays high. Both the original design as well as my design (since it's a copy) have no pull up resistor on it, yet on the original design I can see data moving. On my pcb I can not.

The CDONE pin should be pulled low by the iCE40 until it's fully configured, then CDONE will be released and become high (it's an open-drain output). There's an internal pull-up on CDONE in the iCE40, so even without any external pull-up, you should normally still see a high level if it's configured. What it shows here is that the FPGA never gets to the configured state, which makes sense as you have noticed that it doesn't "run" as expected.

The reason it's not configured is that it can't, or doesn't read the bitstream from the Flash chip.
The reason why is still unknown as it is. Sorry if I missed it, have you checked that CRESET is not permanently held low?

I measure CRESET as high on my scope.

I feel like all the SPI configuration pins are showing everything right, which leads me back to the only thing of notice, which is CDONE not telling me configuration took place. If that is the case, maybe a reflow of the fpga could help? I could look in a thousand places but if there is a chance that SPI_SO or SPI_SI is not connected... that would be an explanation I guess? (even though I am still absolutely positive that the SPI interface pins all passed the protection diode check on inspection after soldering). If there other suggestions I'll gladly try them, but at this point I don't have a clue.

[woofy]

I feel like all the SPI configuration pins are showing everything right, which leads me back to the only thing of notice, which is CDONE not telling me configuration took place. If that is the case, maybe a reflow of the fpga could help? I could look in a thousand places but if there is a chance that SPI_SO or SPI_SI is not connected... that would be an explanation I guess? (even though I am still absolutely positive that the SPI interface pins all passed the protection diode check on inspection after soldering). If there other suggestions I'll gladly try them, but at this point I don't have a clue.

The Hx8k doesn't have diode protection to 3.3v, just to gnd. I had a thread about it here:
https://www.eevblog.com/forum/fpga/ice40-hx-a-5v-tolerant-fpga/msg3580451/#msg3580451
Are you sure it wasn't the pic protection diodes you were measuring?

Reflowing the board has to be a good next step. If that fails I still think you should post the full schematic, or better, the kicad (I'm making an assumption here) files. New eyes can often see issues you miss over and over.

[Nasdrasil]

I diy soldered 20 small bgas in my home lab, the best way I could, and the yield was 16, with 4 trashed..
Also mind the ice40 SPI pins go tristate (ie. disconnected from the internal SPI boot engine, such get usable from the userland) after XX clocks from CDONE=1..
What is you master SPI clock?
PS: I have to reread your posts as I got lost what you are doing
You have pic and flash and ice40 there. You flash the flash off the pic, and then you want the ice40 reads the flash upon power on in SPI master mode, right?

Basically what I am doing is "simply" (appearently not haha) rebuilding the icefun board in a bit of a different formfactor without the things I don't need. To accomplish this I copied the original schematics exactly.

The Hx8k doesn't have diode protection to 3.3v, just to gnd. I had a thread about it here:
https://www.eevblog.com/forum/fpga/ice40-hx-a-5v-tolerant-fpga/msg3580451/#msg3580451
Are you sure it wasn't the pic protection diodes you were measuring?

Reflowing the board has to be a good next step. If that fails I still think you should post the full schematic, or better, the kicad (I'm making an assumption here) files. New eyes can often see issues you miss over and over.

hmmmm... there could be something there then. I did this test about half a year ago (project was on hold for a bit) with guidance from someone on a Facebook group. The guy walked me through the process. It never occured to me to second guess his method! I'll try the reflow and go from there. My schematics are made in Eagle. If needed after the reflow I'll post them here :-)

[Nasdrasil]

Walk of shame incoming I guess...

Upon cleaning up my schematics to post them here for you I found a mistake. Pin Vpp-2V5 was not connected in the schematics. I assume (looking into the data sheet) that this has as a consequence that power on reset is never released and the fpga logic stays inactive. Could anyone confirm this?

I bet this is a rookie mistake. I traced it down to the way I was drawing the schematic. Never worked with so many pins before and it requires me to take a different approach in laying things out in a schematic.

[woofy]

 
Sounds like jlcpcb will be getting a bit more business, good luck.

[SiliconWizard]

Walk of shame incoming I guess...

No shame in making mistakes. Who doesn't.

Upon cleaning up my schematics to post them here for you I found a mistake. Pin Vpp-2V5 was not connected in the schematics. I assume (looking into the data sheet) that this has as a consequence that power on reset is never released and the fpga logic stays inactive. Could anyone confirm this?

Had you posted the full schematic, maybe we would have spotted this earlier.
Yes, the POR circuitry monitors VPP_2V5 as well, so if it's not connected, I think it will be held in reset.
The doc says: "The Non-
volatile Configuration Memory (NVCM) requires that the VPP_2V5 supply be connected, even if the application
does not use the NVCM."

[Nasdrasil]

Had you posted the full schematic, maybe we would have spotted this earlier.
Yes, the POR circuitry monitors VPP_2V5 as well, so if it's not connected, I think it will be held in reset.
The doc says: "The Non-
volatile Configuration Memory (NVCM) requires that the VPP_2V5 supply be connected, even if the application
does not use the NVCM."

I probably should have indeed. To be fair... I was on my way of making it "presentable" and that's when I discovered the mistake. Note to self is to always make schematics presentable and clear. The symbol in Eagle for the fpga did not make this easier. It is one block with connections left and right. It would have been more clear if it had seperated groups of connections. Power, I/O etc. I know I can draw a new symbol but oh well... live and learn I guess.

I'd like to thank you all for the time you took to help me. Bit sorry it turned out to be such a basic mistake. On the other hand it is nice to know what the culprit was. Revised pcb's have been ordered. When I get this resoldered I'll get back to this thread with the results

Hopefully better news than in round 1

[SiliconWizard]

For a first prototype, I would have suggested to use a more friendly package than BGA - you would have been able to test the fix before respinning a new board.

[Nasdrasil]

For a first prototype, I would have suggested to use a more friendly package than BGA - you would have been able to test the fix before respinning a new board.

I don't believe the hx8k is available in another package besides bga unfortunately.