[Cryptech Tech] STM32 FMC problem

[Pavel Shatov]

Hello!

I've been trying to make Fredrik's board talk to Spartan-6 in Novena for 
quite some time. I'm facing some strange issue however. First of all, 
FMC arbiter in Novena runs at its own system frequency, while FMC in 
STM32 is clocked by another frequency derived from HCLK. This requires 
clock domain crossing logic in FPGA. Because the two frequencies are not 
related in any way, CDC inherently has variable latency, that's why FPGA 
uses NWAIT signal to tell STM32, that it has processed the request. With 
iMX6Q this all worked like a charm, and I thought, that I would easily 
port it to STM32. First part of the problem with STM32 is that, if it 
tries to read or write from an unprogrammed FPGA, it hangs. As far as I 
understand, it locks up waiting for NWAIT. I don't see any configurable 
FMC timeout in STM32. iMX6Q was better in that sense, because it had 
configurable bus timeout, and your app at least crashed with "bus i/o 
error" or something like that, when it was trying to read from an 
unprogrammed FPGA.

Another strange issue is that STM32 still occasionally hangs while 
reading from programmed FPGA. STM32 has built-in "random" number 
generator, I used it to create very simple demo program, that generates 
some "random" number, writes it to FPGA, then reads it back and compares 
with original value. This way all the data bus lines are tested. If I 
comment out the readback part, the program runs for as long as I want 
(hours), if I enable readback, the programs locks up within a minute. I 
don't understand, how come read and write are different? Writing has 
variable latency too, so it uses NWAIT signal, why doesn't it cause 
STM32 to hang? If I configure FMC to have fixed latency and ignore 
NWAIT, reading doesn't hang the processor anymore, but returns garbage, 
because STM32 samples the data bus at wrong time.

The only possible explanation for this behaviuor I found, is item 2.9.4 
in STM32F429 errata 
(http://www.st.com/web/en/resource/technical/document/errata_sheet/DM00068628.pdf) 
This seems possible, since we have SysTick interrupt, but on the other 
hand, that issue is said to only affect revision "A" devices, while I 
have "3" next to ST logo on my processor. Very strange.

Anyways, so far I ended up configuring DMA to do the transfer, as it is 
recommended in errata. This doesn't cause freezing when reading from 
empty FPGA anymore, and returns DMA timeout error, as it should. I 
haven't checked, whether it fixes spontaneous freezes when reading back yet.

Using DMA to transfer 32 bits at a time is not very efficient, but I was 
unable to find a better solution. Does anyone else have any ideas? I can 
provide compiled FPGA bitstream with FMC arbiter, in case anyone wants 
to try debugging the issue.

--
With best regards,
Pavel Shatov