STM32L4 TIM+ADC+DMA overrun

[Alekseus]

Hello!

I have a custom board with NAND flash connected. One of the DMA channels is used during write operations to move data from RAM to FMC buffer (mem-to-mem mode). The channel has low priority so theoretically it shouldn't interfere with other channels. Second DMA channel (same DMA controller) with high priority is intended to receive ADC data (two ADC channels with x8 oversampling). DMA channel works in circular mode non-stop, ADC is triggered by timer (1kHz, single conversion, discontinuous mode disabled, ADC_REG_OVR_DATA_OVERWRITTEN mode, 92.5 cycles per conversion).

The issue is an ADC overrun during NAND write operation (mostly not every operation but with certain periodicity) what results in missing value as if ADC channels were swapped. Besides these DMA channels, two more DMA channels are used on same DMA controller but the latter ones aren't active at the moment of ADC overrun. If you simply move NAND DMA channel to another DMA controller, the overrun disappears.

This looks weird to me, as if priority levels don't work properly. The data streams don't look so dense to produce such effect. Any suggestions?

Regards

[TDK]

Looks weird to me, too. At 1 kHz sample rate, DMA throughput can't be the issue here. The priority mechanism is robust. Do you see error flags in the ADC (OVR) or the DMA? Can you show relevant ADC and DMA register values when the issue occurrs?

[Alekseus]

Yes, I added the ADC interrupt handler for OVR event and the channel data omission occurs right after that flag appears. I didn't monitor DMA flags but it is possible to check TE event in its handler (however it seems there is no TE as conversion continues normally). Also I can capture DMA state after OVR event but I am not sure if it would be helpful.

[waclawek.jan]

> NAND write operation

I am not familiar with this. How is it accomplished, is there any WAIT signal from NAND to FMC, to take into account the physical write time?

JW

[Alekseus]

Yes, NWAIT signal is used. It can halt the core but not sure if it is the case (as I mentioned before, simple change of DMA controller removes overrun). Also there is a RDY bit (#6 in Read Status command answer) to check if an operation is finished. Interestingly, I just added single read (not even polling) of this bit before writing, and the overrun doesn't occur anymore (no any changes regarding DMA controller or channel numbers). This is also weird as RDY is checked after every write operation.

[waclawek.jan]

> Yes, NWAIT signal is used. It can halt the core

It does not halt the *core*, whatever that means, in some direct way. Instead, it *may* be propagated(*) to the transaction initiator - here, the DMA unit which attempts to write to the NAND through FMC. As that DMA can't finish its operation for this Channel, that then prevents that DMA to handle other Channels, regardless of their priority. But that WAIT does not impact other bus-masters on the matrix, i.e. other DMAs and the processor continue to work (as long as they don't attempt to access the same AHB slave bus where FMC is located, although probably in all STM32 FMC is the sole slave on its slave AHB bus).

(*) as I've said, I don't know how the NAND portion of FMC exactly works (and also there are several incarnations of FSMC/FMC which do differ in small but important details). And, much depends on the exact circumstances, too. For example, a single write to some sort of memories in FMC may be stored in a buffer/cache inside FMC, for FMC to be handled autonomously later, even if the write takes longer, and the WAIT may not be propagated back for that single write.

Reading RDY by the processor may mean that the WAIT - which was not propagated yet as data have been buffered until FMC autonomously writes them - starts to be propagated towards the master reading that RDY (the processor), which is then stalled until the physical write is actually accomplished by FMC. This again is a speculation (an example of what may happen, without really knowing what actually does happen), as I don't know the details.

Placing strategically GPIO toggles and observing them together with the NAND signals may shed more light.

JW

[Alekseus]

---

@waclawek.jan wrote:

It does not halt the *core*, whatever that means, in some direct way.

---

Actually it does. It doesn't look like just halt under debugger but the core definitely goes crazy if NWAIT is low and at the same time you try to do something (read or write) with NAND area. You can easily do such experiment with any MCU even if it has no NAND connected (only FMC/NAND support required). Just initialize corresponding pins and FMC/NAND itself with the next option enabled:

hnand1.Init.Waitfeature = FMC_NAND_WAIT_FEATURE_ENABLE;

Then any operation with NAND leaves you with hanging core. Only hardware reset reenables normal working mode. For example, under debugging if you try to pause the core, debugging session will be abnormally finished.

Regarding my issue, I have found that there was 'erase block operation' right before ADC overrun. That is the only operation without RDY flag checking so next write operation likely causes its DMA channel stuck (apparently, until erase operation has finished) and at the same time ADC DMA channel slows down (or hangs) too. But it looks more complicated as I mentioned before that the reading NAND status operation right before write operation is able to cure the overrun. MCU still waits until erase is done (i.e. all timings are the same) but ADC overrun gone. I can't find an explanation for this.