11-19-2013 12:07 AM
I was wondering if there is a way to tristate the CCLK pin in an Artix-7 device after configuration?
I have the FPGA hooked up to an SPI flash device for configuration, which works fine. To that same SPI interface I have also connected a microcontroller for updating bitfiles via USB and such. This also works fine, as long as I pull the PROB_B-pin while the microcontroller wants to access the SPI flash. This is because the FPGA keeps driving the CCLK pin after configuration; and since CCLK can't be used as a user I/O, I can't force it to 'Z' in my design.
This is all known and documented behaviour, but I was wondering if there still is some way to influence CCLK from the design? It must be possible somehow, or indirect SPI programming via iMPACT wouldn't work. I suppose you can do some JTAG magic to toggle CCLK or something, but can't find any documentation on that.
The situation as it is is OK for my design, but it would be nice to be able to access the SPI flash from the microcontroller while the FPGA is loaded, without having to fuss about with external multiplexers on the board and such.
11-19-2013 01:54 AM
found something. The STARTUPE2 primitive should be able to help with what I want to do. Documentation is sparse, though, still fiddling around with it.
At least that enables you to drive the CCLK pin after configuration, so that looks good.
11-19-2013 08:01 AM
You shouldn't have to do that. Unless you have turned on persist or the SEU detection option (RBCRC) the CCLK in master mode is tri-stated with a weak pullup.
11-20-2013 12:50 AM
I didn't have persist enabled, it should be disabled per default. Disabling it explicitely in the XDC didn't help, though. The way I read the documentation, the persist option only applies to the multi-function pins, but not to the dedicated configuration pins in bank 0.
I would expect CCLK to be tri-stated after configuration (BTW, does it say that in the documentation somewhere?), but what I see is:
- FPGA not configured (i.e. PROG_B held low): flash access from the microcontroller works reliably and every time
- FPGA configured: flash access fails 80% of the time (meaning all I get is all 0s or 1s)
So to me that does not look like a software issue (wrong flash settings or something), but like bus contention or some other hardware issue that is in some way influenced by the FPGA.
I found this at the Spansion site. They state in 4.2 that you must pull PROG_B low or the FPGA will interfere with the SPI pins:
So that's where I got the general idea that CCLK could be the problem (all the other SPI pins I can manually tri-state in my design).
Then I thought maybe the FPGA sets a different flash access mode during configuration (32bit address mode, quad mode, ...), but then the microcontroller shouldn't be able to access at all, not only fail most of the time. Besides, there's a software reset command you can use that should always work, regardless of the mode the flash is in, but I can't even get that through (meaning the shifted data coming back from the device is always garbage).
Any other idea how this could happen?
11-20-2013 11:13 AM
Correct. By default persist is turned off. Both the multi function pins as well as the CCLK are preserved if persist is turned on. I believe the user guide does mention this behaviour. Check the overview section.
You are basically saying your flash access works 20% of the time? The FPGA will behave the same all the time. Perhaps you are trying to access the flash too early? I think there are some extra cycles on the CCLK after configuration is done to ensure the startup sequence is properly excecuted. Perhaps 10 cycles or so.
The Spansion recommendation is probably there so that the user application does not interfere with the multi purpose pins connected to the SPI such as MOSI/FCS.
Check the signals with a scope.
11-22-2013 03:01 AM
Since yesterday, the problem has disappeared. I'm at the moment retracing my steps, trying to figure out what I changed that "fixed" it, and I'm doing testing across a batch of boards now to see if there's a difference.
What I was seeing was that with some bitfiles SPI would work, with others (most of them) it would never work, even though bitfile settings were always identical. Timing should not have been a problem, since it wouldn't work after minutes/hours, either.
I'll do some more digging... even if it does work now, I don't like not knowing for certain what the problem was. Those things tend to re-appear and bite you when you least expect it...
11-08-2017 08:50 AM
There is direct way to solve your problem.
Input port "USRCCLKTS" of STARTUPE2 primitive is controlling state of the CCLK pin.
will set CCLK pin to output mode, when
will set CCLK pin to the tristate mode.