01-29-2014 01:01 PM
I have a virtex 5 xc5vlx30t. I am using it with an Atmel AT45DB161E flash prom. I cannot flash the prom with an MCS file via direct SPI. I can, however, configure the FPGA using JTAG with a bitfile. However, the tool cannot program the attached flash prom in this mode.
Symptoms: Flash prom not yet programmed. Circuit is as in p58 of the Configuration user guide (SPI) Upon power up, with platform cable not yet attached, the FPGA is holding FCS_B low, CCLK is running continuously. DI is high, MOSI is low. The FPGA will not release the FCS_B line.
When trying to program the flash, the tool cannot obtain device verification and fails immediately. FPGA will not release the FCS line.CCLK continues to run. The platform cable cannot take over the bus.
In another experiment, I successfully programmed a flash prom on a different board (different design) with the intended MCS file and then transplanted it onto the problem PCB. Again, the FPGA would not configure even tho the prom was now programmed. Same symptoms appeared.
I am using ISE v11.3. All service packs installed. I installed the patch for using the Atmel AT45DB161E prom..
My theory: FPGA is not getting valid data on DI so it keeps trying to grab it off the prom. It looks like it keeps trying to get stuff from the prom and is never giving up. Is it supposed to give up after a while, or is the continuous CCLK and refusal to relinquish the bus normal behaviour if it cannot see valid DI data? I am assuming the FPGA is seeing the correct SPI variant bits.
Any suggestions on how to fix this? What would make the FPGA behave this way?
02-03-2014 06:03 PM
@brian0: "CCLK is running continuously. DI is high, MOSI is low. The FPGA will not release the FCS_B line."
To further diagnose the issue, first change the FPGA mode configuration pins to a non-master mode such as JTAG.
This MODE change should prevent the on-a-blank-or-broken-PROM-you-can-sync-forever V5 symptoms you are seeing.
Once the CCLK/FCS problem is gone, you should be able to catch the initial SPI clock/data signals on a scope to sort out exactly what's going on.
After changing the MODE pins, I first would try verifying your pre-programmed prom using Indirect (or Direct) SPI.
Some random thoughts on Indirect SPI failures:
- make sure DONE has a pullup, and that nothing else on the board is pulling DONE low
( e.g., DONE LED's without a buffer, clamping the DONE pin low-ish, will kill Indirect SPI )
- double check the schematic and PCB layout against the UG again
- check the physical board connections to the PROM ( shorts/opens/resistor values/etc. )
- make sure CCLK is clean right at the SPI PROM clock pin
- if this is a multi-fpga Master -> Slave configuration chain with paralleled DONE, note that Indirect requires you to first configure all the slaves via JTAG so that they have already released DONE when IMPACT downloads the Indirect SPI programming core to the master.