01-26-2019 10:53 AM
I have an Artix XC7A35T target that has an AES key programmed. I need to reflash the boot SPI via JTAG (indirect programming.)
SPI is functional. The flash was previously programmed, and the FPGA is booting from it. JTAG is functional. I have the correct AES key and can load an encrypted bitstream.
However, I cant seem to do is access the SPI device at all: I get the [Labtools 27-3165] End of startup status: LOW message no matter what kind of programming operaion I try (read, erase, blank check, etc.)
FUSE_CNTL state is 0xC9: CFG_AES_Only and R_EN_B_Key are set.
Previously I was able to reprogram using an encrypted bitstream with CFG_AES_Only set. The trouble seems to have come about once R_EN_B_Key is set.
01-29-2019 09:55 PM
I think the issue is due to CRF_AES_Only rather than R_EN_B_Key. Are you sure you have CFG_AES_Only programmed previously?
If CFG_AES_Only is set, FPGA no longer takes an unencrypted bitstream; as you may know, indirectly programming flash is first to download a bitstream into FPGA, and then this design works in FPGA to get access the SPI interface. With the bit set, this indirect programming core( or bit) could not configure your FPGA any longer.
01-30-2019 11:12 AM
1. "Indirect Mode" means programming SPI over JTAG, not via logic. Check the Configuration guide.
2. As I developed this plaform, I first checked reprogammability with CFG_AES_Only set. This worked. It's only after I had set R_EN_B_Key set that I no longer could access SPI over JTAG.
That's a good suggestion for a workaround though (using a SPI perpheral instanced in my logic to reflash the device.) I may try it if I have time.
02-05-2019 05:11 PM
In thinking on this, I don't know of a method to co-opt the CCLK pin for external control. Do you?
02-05-2019 07:45 PM
Please try programming flash without enabling option of verify.
02-06-2019 10:09 AM
I've done that. Doesn't work. Also, tried only to erase - doesn't work. Basically, I cannot access the SPI flash over JTAG at all.
03-08-2019 03:46 PM
Was wondering @iguo if this problem had been replicated in Xilinx. As I said, my experience with this issue is that it didn't come up until I programmed the RD_EN_B_Key bit.
I have posted elsewhere about a request for an FPGA-resident SPI peripheral to program the device instead of JTAG. I figured out STARTUPE2 to get control of CCLK, and of course there's an AXI SPI controller IP peripheral. The challenge comes in coming up with the SPI+flash driver stack to manage programming the device itself. I found references on Github for some open-source stuff, but I wanted to see if someone had successfully built it from beginning to end.
03-22-2019 10:35 AM
As I learn more about this process, I've come to realize that Vivado actually downloads a bitstream to connect JTAG to the SPI (or BPI, etc.) device to perform indirect programming, as @iguo noted. This is the 'spi_xc7a35t_pullnone.bit' file in my case, found in <path>/Xilinx/Vivado/2018.2/data/xicom/cfgmem.
If the target is encryption enabled, and obliges an encrypted bitstream based on e-fuse key (as I have here), I conclude that the indirect programming code must *also* be encrypted, yes? Otherwise it won't load.
Seems like Vivado should be able to re-make this bitstream with my key and I'd be back in business, SPI-programming wise. @iguo , what do you think?