'F40x FSMC asynchronous WAIT clarification

[waclawek.jan]

1. RM0090 Rev.18 states in many places in the narrative that WAITPOL is used in the asynchronous modes (in the FSMC_BCRx bit fields tables for the various asynchronous modes, in WAIT management in asynchronous accesses subchapter, and elsewhere). Yet, the description of WAITPOL field in SRAM/NOR-Flash chip-select control registers 1..4 (FSMC_BCR1..4) subchapter says: Valid only when accessing the memory in burst mode. "Burst mode" is undoubtedly synchronous mode. So please clarify.
2. WAIT management in asynchronous accesses subchapter says, in a rather clumsy way, that the WAIT signal is ignored in the last 4 cycles of any given memory access (and it's ignored in any other than the data setup phase). From that, it follows, that for read accesses, DATAST must be at least 4; for write accesses, DATAST must be at least 3 (there may be more stringent requirements for special cases and RM recognizes them). Figure 449 and Figure 450 confirm this assertion. However, the narrative fails to recognize the latter case, write with DATAST=3, depicted in Figure 450 (which may be relevant both for write-only memory-like peripherals, and for the split-timing case i.e. when EXTMOD = 1), and requires DATAST strictly be >= 4. This results in suboptimal settings for the mentioned cases. ST, please clarify.

This is probably pertinent to other RMs with FSMC and FMC chapters (and FMC chapter in the very same RM0090 too); but that's ST's task to check/correct/whatever all of them.

JW

[waclawek.jan]

The asynchronous waitstate works sligthly different than described above, and maybe different than one would probably expect.

Following waveform was taken using a LA sampling at 5ns (vertical tick-lines), 'F407 running at 168MHz (i.e. HCLK period cca 6ns), DATST=3, ADDSET - I don't remember exactly, probably around 8-10:

So, while /WAIT's trailing (upgoing) edge is far enough from the /WR, /WR lasts the expected 3 cycles. As soon as /WAIT gets closer (that's third write and on, here), /WR starts to stretch so that the distance between the trailing edge of /WAIT and trailing edge of /WR is kept at a constant distance, cca 30-35ns. That might quite well correspond to the mentioned 4HCLK (even if 30-35ns is 5-6 clocks at the 1/168MHz rate) - note, that /WAIT is *input* from memory to FSMC and is asynchronous to FSMC/STM32, so there's some lag between the observed /WAIT edge and the moment when the internal logic of FSMC detects it (and the LA is not that perfect at those rates, either).

Note that this stretching occured even before /WAIT overlapped /WR. I tried DATAST=2 and the results are similar.

When DATAST is set to a larger value, this behaviour may result in an unpleasant surprise:

(there I wrote 30ns corresponds to 5(maybe 6) HCLK cycles, but I did not realize what I wrote above, i.e. that /WAIT is asynchronous to FSMC; so it again corresponds probably more to 4 HCLK).

The unpleasant surprise is in that after memory (or memory-like external peripheral) signals end of /WAIT, until end of /WR, there's not the expected time set by DATAST (which can be set up to 255 cycles), but only the fixed 4 HCLK. That behaviour ought to be documented.

JW