DMA - NDTR - data in memory?

[LCE]

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.html

It 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]

> 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]

[LCE]

@Community member​ Thanks for answering!

>> That a known problem?

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

So that's your article on efton site? Very helpful stuff there!

Last time I checked that link it didn't work, now it does, whatever...

Next try will be the N+1 version.

[waclawek.jan]

> So that's your article on efton site? Very helpful stuff there!

Yes. Thanks!

> Last time I checked that link it didn't work, now it does, whatever...

While efton is my one-man company, that website contains the hobby-part of my work and runs on a cheapo hosting with minimal support. Thanks for the heads-up, I was not aware that it has outages. I'll consider migrating.

> Next try will be the N+1 version.

Please report back with your findings. As you've might have guessed, I don't actively use the 'F7 nor 'H7.

JW

[LCE]

> ... that website contains the hobby-part of my work and runs on a cheapo hosting with minimal support. Thanks for the heads-up, I was not aware that it has outages. I'll consider migrating.

I'm quite sure the problem was on my side: I had some home office internet problems on monday, and then I remember the forum was down the same day, it might have fallen into that time window...