ice40 Hx8K project not configuring from external flash - Page 1
Forum section: electronics / general

author: Nasdrasil
author_rank: Contributor
timestamp: February 15, 2024, 07:55:33 pm
content: 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 :-)

author: woofy
author_rank: Frequent Contributor
timestamp: February 15, 2024, 09:09:44 pm
content: How are you controlling the fpga reset. On the icefun its controlled by the on board pic.

author: iMo
author_rank: Super Contributor
timestamp: February 15, 2024, 09:25:09 pm
content: Quote from: Nasdrasil on February 15, 2024, 07:55:33 pmQuoteiCE40 Programming and Configuration Technical Note, p.10

author: Nasdrasil
author_rank: Contributor
timestamp: February 15, 2024, 09:27:12 pm
content: Quote from: woofy on February 15, 2024, 09:09:44 pmI 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.

author: Nasdrasil
author_rank: Contributor
timestamp: February 15, 2024, 09:41:29 pm
content: Quote from: iMo on February 15, 2024, 09:25:09 pmAre 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2024, 09:53:32 pm
content: Quote from: Nasdrasil on February 15, 2024, 09:41:29 pmI'm not sure, but something to check.If you copied the design from this:https://www.robot-electronics.co.uk/icefun.htmlThe 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?

author: Nasdrasil
author_rank: Contributor
timestamp: February 16, 2024, 06:35:30 am
content: Quote from: SiliconWizard on February 15, 2024, 09:53:32 pmI'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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2024, 07:00:01 am
content: 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.

author: Nasdrasil
author_rank: Contributor
timestamp: February 16, 2024, 07:46:55 am
content: Quote from: SiliconWizard on February 16, 2024, 07:00:01 amI 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.

author: woofy
author_rank: Frequent Contributor
timestamp: February 16, 2024, 08:57:54 am
content: Quote from: Nasdrasil on February 16, 2024, 06:35:30 amHow 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?

author: Nasdrasil
author_rank: Contributor
timestamp: February 16, 2024, 10:32:04 am
content: Quote from: woofy on February 16, 2024, 08:57:54 amI 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.Quote

author: woofy
author_rank: Frequent Contributor
timestamp: February 16, 2024, 02:44:30 pm
content: Not really sure whats going on there, try using iceFUNprog as stand alone programmer which defaults to verify, like:iceFUNprog blinky.biniceFUN v1, Flash ID 1F 85 01Erasing sector 000000Erasing sector 010000Erasing sector 020000file size: 135100Programming ....................................................Verifying ....................................................Done.The -v switch inhibits the verify:iceFUNprog -v blinky.binDo 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.

author: Nasdrasil
author_rank: Contributor
timestamp: February 16, 2024, 03:24:51 pm
content: iceFUNprog gives me this as outputQuoteCRESET 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... ;-)

author: woofy
author_rank: Frequent Contributor
timestamp: February 16, 2024, 05:55:20 pm
content: 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.

author: julian1
author_rank: Frequent Contributor
timestamp: February 16, 2024, 08:04:47 pm
content: Quote from: Nasdrasil on February 15, 2024, 07:55:33 pmFor 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2024, 09:17:08 pm
content: Quote from: Nasdrasil on February 16, 2024, 07:46:55 amThe 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?

author: Nasdrasil
author_rank: Contributor
timestamp: February 17, 2024, 09:45:36 am
content: Quote from: woofy on February 16, 2024, 05:55:20 pmI 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.Quote from: julian1 on February 16, 2024, 08:04:47 pmI 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.Quote from: SiliconWizard on February 16, 2024, 09:17:08 pmI 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.

author: woofy
author_rank: Frequent Contributor
timestamp: February 17, 2024, 11:05:18 am
content: Quote from: Nasdrasil on February 17, 2024, 09:45:36 amThe 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/#msg3580451Are 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.

author: Nasdrasil
author_rank: Contributor
timestamp: February 17, 2024, 11:26:16 am
content: Quote from: iMo on February 17, 2024, 10:50:39 amBasically 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.Quote from: woofy on February 17, 2024, 11:05:18 amhmmmm... 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 :-)

author: Nasdrasil
author_rank: Contributor
timestamp: February 17, 2024, 03:18:57 pm
content: 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.

author: woofy
author_rank: Frequent Contributor
timestamp: February 17, 2024, 04:35:33 pm
content: Sounds like jlcpcb will be getting a bit more business, good luck.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 18, 2024, 12:22:42 am
content: Quote from: Nasdrasil on February 17, 2024, 03:18:57 pmNo shame in making mistakes. Who doesn't.Quote from: Nasdrasil on February 17, 2024, 03:18:57 pmHad 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 applicationdoes not use the NVCM."

author: Nasdrasil
author_rank: Contributor
timestamp: February 18, 2024, 10:14:03 am
content: Quote from: SiliconWizard on February 18, 2024, 12:22:42 amI 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 resultsHopefully better news than in round 1

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 18, 2024, 10:08:10 pm
content: 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.

author: Nasdrasil
author_rank: Contributor
timestamp: February 19, 2024, 12:21:53 pm
content: Quote from: SiliconWizard on February 18, 2024, 10:08:10 pmI don't believe the hx8k is available in another package besides bga unfortunately.

author: woofy
author_rank: Frequent Contributor
timestamp: February 19, 2024, 01:46:59 pm
content: The hx4k is available in a TQ144. I've heard it's an hx8k inside, but never used it and no idea if it's true or not.

author: julian1
author_rank: Frequent Contributor
timestamp: February 19, 2024, 09:58:37 pm
content: Quote from: woofy on February 19, 2024, 01:46:59 pmThat's interesting.I noticed in documentation, that the bitstream sizes (generated by icestorm) are the same size.A quick grep through the nextpnr code on the arch flags for ArchArgs::HX8K and ArchArgs::HX4K doesn't show obvious handling differences.For hx8k packages, the 256 pin bga is 0.8mm pitch versus 0.5mm pitch for cb132 and would be more tolerant of a home reflow process.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 19, 2024, 10:22:32 pm
content: If it's the same, then yes the only way of using it as such will be with yosys/nextpnr. I wouldn't be surprised - this is relatively common.Another example of this with Lattice is with the ECP5. The -12 and -25 are the exact same die. The only difference is the internal chip ID - so if you use Lattice tools, they won't let you use a-12 as a -25, but with yosys/nextpnr, no problem!(And it's about half the price.)

author: woofy
author_rank: Frequent Contributor
timestamp: February 19, 2024, 10:27:51 pm
content: I think it was David Shah (nxtpnr) who first discovered this but I can't find a reference now. Lattice tools will not generate hx8k code for the hx4k but nxtpnr could, though not recommended.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 19, 2024, 10:34:20 pm
content: Can't speak for the hx4k, but for the ECP5, it *is* the exact same and there's no difference. So, if it "not recommended", that would be by Lattice for obvious reasons.

author: julian1
author_rank: Frequent Contributor
timestamp: February 19, 2024, 11:05:19 pm
content: With the tq144 package - a combined eda symbol can support both hx1k or hx4 parts (some 1.2V supply pins get managed with jumpers).This may be useful if the firmware complexity is not known upfront, or else for product scope changes, without having to change the pcb.If the hx4k actually has the same dff+logic resources as the hx8k, this brings more flexibility.Although the dependency on the open-source toolchain, will be a limitation for some.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 20, 2024, 08:38:17 pm
content: Yes, yosys/nextpnr isn't for everyone and still has limitations for sure. (Just for the record, for those who use VHDL, you can use it with yosys and a ghdl plugin. Works fine. So it's not limited to Verilog either.)Now of course, while (at least for the ECP5, maybe same for the hx4k) it *appears* to be identical dies to the more expensive models, there's of course no guarantee that it will work reliably. Even if it's indeed the very same dies, for all we know, the manufacturer may sort the dies during production and sell the ones that pass tests for the lower number of logic blocks but don't pass tests for the nominal number. Something that *some* manufacturers do with *some* chips. OTOH, they may not do any sorting at production and just distribute the dies according to marketing figures. We just don't know, unless someone works at Lattice and can tell us, but I doubt they'd be allowed to.