Programming SPI Flash In-Situ - Page 1
Forum section: electronics / general

author: Graz
author_rank: Contributor
timestamp: December 13, 2015, 02:33:26 pm
content: Hi,I'm bringing up a project using a Spartan II, PIC16F18325 to control boot and various other system stuff and a 1MB external SPI flash. So far, so good - test FPGA bitstreams over JTAG work, PicKit3 can talk to the PIC and the PIC can talk to the flash. So far, only one green wire. My plan is to put the FPGA bitstream (potentially compressed) into the flash, use the PIC to boot the FPGA using slave serial, then turn the programming interface around and use it to allow the FPGA to talk to the PIC at runtime. I'm going to store additional data in the unused flash past the end of the bitstream.Now I'm stuck at getting the initial bitstreams into the flash. I was hoping that I'd be able to get a simple bootloader into the PIC then use the ICSP interface or PicKit to tunnel data into the flash, but I can't figure out if that's even possible. With a script of some kind, it would be. For example, I could download the bootstrap program to the pic, and enter a loop with a breakpoint at the top. In each iteration of the loop, it'd hit the breakpoint, the debugger would write a page of data (256 bytes) to PIC's RAM, and when the breakpoint was released, the PIC would program the data into flash from RAM.Does anyone have any tips for writing such a thing? Anyone got a better idea? Adding more programming headers or programming the flash before assembly aren't really options, unfortunately.

author: andersm
author_rank: Super Contributor
timestamp: December 13, 2015, 03:09:46 pm
content: Could you use the FPGA's JTAG interface to program the flash? Alternatively,test clipsor pogo pins.

author: KE5FX
author_rank: Super Contributor
timestamp: December 14, 2015, 02:13:34 am
content: Usual approach is to make sure the microcontroller can configure the FPGA by itself (without any external JTAG hardware), then have the micro send a "utility" bitstream to the FPGA that allows it to program the flash with a bitstream sent by the microcontroller. Example for Opal Kelly XEM3005 with Spartan3Ehere, see utils/verilog/xem3005_util.v.If your microcontroller can't configure the FPGA, you may have painted yourself into a corner.

author: Graz
author_rank: Contributor
timestamp: December 14, 2015, 02:47:55 am
content: Quote from: andersm on December 13, 2015, 03:09:46 pmYeah, I'd considered that. It would mean programming an initial bitstream into the FPGA, writing a bootloader for the PIC which takes inputs from the FPGA and stuffs it in the SPI flash. I can't see how I'd stream the final bitstream over JTAG, but there's plenty of available and accessible IO on the FPGA.Quote from: KE5FX on December 14, 2015, 02:13:34 amYes, the PIC can configure the FPGA (at least all the relevant connections are there). The issue is that an uncompressed bitstream for the FPGA is ~97KiB and the PIC has ~14KiB of onboard storage. The SPI flash is there primarily to serve as storage for the bitstream. The conundrum is getting that 97KiB bitstream into the flash in the first place. Once configured, I can reverse the stream and send information from the FPGA to the PIC for writing into the flash - that is the plan for field upgrades.For now, I have a two pronged plan - first, grab a bus pirate and brute force program the device with pogo pins in a jig. That'll get the thing running. But, I'm going to work on a monitor program for the PIC that double-duties the ICSP pins as a UART to allow programming and debug over serial without the PicKit (once initially programmed, of course). That's a better solution and shouldn't require board modifications.

author: Graz
author_rank: Contributor
timestamp: December 19, 2015, 10:02:28 pm
content: I made some progress. I got the programming pins set up as a UART. When the debugger is connected, they work as debug pins. When the debugger is not connected, they're a serial port. That way, I can program the PIC with the debugger, then disconnect the debugger, connect a serial cable and talk to the monitor program. I've also written the monitor. I can't debug it, really, but it's simple enough that it's not a big loss.Now the next problem; SPI isn't working when the serial adapter is connected. It works fine in test functions provoked by the debugger. When the serial adapter is connected, however, I see MISO (SO from the SPI EEPROM) floating at around 1.7V. I can see CLK and MOSI from the PIC wiggling around, but the EEPROM never responds. I tried replacing the EEPROM - no dice. Given that SO is supposed to be HiZ when not driven by the EEPROM, I have to assume the the 1.7V is coming from the PIC, but that's rather disturbing for an input to do that.Enabling the PIC's "weak pull up" on the MISO input brings the voltage to 3.3V as expected.Coincidentally, the serial adapter is 5V and 5 - 3.3 = 1.7. Not sure if that has anything to do with the float.I have no idea what's going on here. Any help would be appreciated.