DMA - NDTR - data in memory?

Question

Dear Community,I'm recently having some trouble with STM32F7 DMA (STM32F767 Nucleo, STM32CubeIDE, some HAL stuff, but using more and more direct register writes & reads).I'm using timer input capture with circular DMA from timer peripheral to memory, that works so far.My problem is that I need to read the DMA-asigned memory buffer (internal SRAM) periodically, independent of the timer peripheral or DMA, I cannot use DMA complete interrupts or callbacks (which works reliably with other peripherals).To find out where the DMA is currently writing I check the NDTR register to get the latest result from the DMA buffer.Every now and then I had some strange results that made me doubt the NDTR register, as if data has not yet arrived in the assigned memory buffer, but NDTR had already decremented.Not sure if that still applies (esp. to STM32F7), but my suspicions are supported by this article:http://www.efton.sk/STM32/gotcha/g20.htmlIt basically says that NDTR decrements after data was read from the peripheral, not after data arrived in memory.So I tried turning off the DMA FIFO, then inserting some NOPs after checking NDTR, still I don't get data reliably (although it seems to have improved a little).My questions are:1) That a known problem?2) Is there any way how to make sure data has arrived in the buffer? I couldn't find any DMA status register information. Checking FIFO status - when it was used - caused some long wait times.3) Could the NOPs be optimized out by the compiler?4) Any other ideas? :)Thanks!

waclawek.jan · Answer

> Not sure if that still applies (esp. to STM32F7)

Yes.

> That a known problem?

I wrote about it, and others wrote about it before me (I gave link at the enad of that article) - I guess that makes it to be known?

> Is there any way how to make sure data has arrived in the buffer?

No.

> Could the NOPs be optimized out by the compiler?

Depends on how did you write them, but you can always check in the disasm.

However, AFAIK, the Cortex-M7 core does perform some NOP removal early in the pipeline during execution, and even if not, the dual-issue core messes up timing, too. Generally, Cortex-M7 is less suitable for real-time work than Cortex-M4 is, the perceived "performance increase" is only in computation (number crunching) and comes at the cost of less control and more jitter when it comes to real-time. You've probably have read the "SoC" rant of mine by this time.

Sorry for the bad news, but it is what it is. You may want to step back and rethink the logic of your application, if this is a showstopper for you.

JW

[EDIT]

> Any other ideas?

I thought I've written about it in that article, but now I re-read it and no... so, I do use reading NDTR to determine number of received data through DMA, but only in certain cases. Namely, in receiving continuously arriving streams; and I use NDTR in the way I am certain that given data are already in RAM. For example, in Direct mode i.e. FIFO off, if NDTR indicates that N data has arrived, it means that N-1 data are certainly in the memory. As the incoming data are continuous, I am not worried about the Nth datum as it could be picked up a bit later when NDTR indicates N+1. Similarly if FIFO is on, I ignore NDTR indicating arriving data until it indicates that the next FIFO-threshold amount plus one datum arrived. I understand that this is not a scheme usable in all cases, but again, it is what it is and I try to make the best out of the existing hardware with known limitations.

It may also well be the case that HT and TC flags being set guarantee that data up to half/end of the buffer are already in RAM; ST of course does not comment as they are blissfully ignorant of any hard-timing problems until a well-paying customer slaps it hard enough onto their head; and I did not investigate this as I personally don't find it that much a usable case.

[/EDIT]

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded