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