How to capture NDTR of ADC DMA on timer event

[Kolja Waschk]

Hi,

on H723... I'm trying to configure a DMA on TIM5 CC3 event (DMA1 Stream 0 P2M) to capture the current NDTR value of another stream (DMA1 Stream 1 P2M) (to record where that DMA just put data from ADC into a ring buffer at the time of the CC3 event).

On the previous platform where I tried it (a F427), it was impossible, due to the fact that DMA1 can't access the NDTR of DMA2 stream as a peripheral register.

But on H723, the system architecture/bus matrix looks like it could be possible, both streams are controlled by the same DMA (DMA1) (maybe that's the problem)

Or did I miss something? I ended up getting data into the buffer synchronous to TIM5 CC3 but it doesn't look like the expected NDTR values at all.

Thanks for your thoughts,

Kolja

[Kolja Waschk]

Maybe there is a flaw in the actual code, so I'll cite it here. TIM5 CC3 DMA is started like in the following excerpt:

uint32_t par = (uint32_t) &(((DMA_Stream_TypeDef*) (hdma_adc1.Instance))->NDTR); /* 0x4002002C */

uint32_t m0ar = (uint32_t) ndtrbuffer; /* ndtrbuffer[8]: at 0x30003000 in RAM_D2 */

HAL_DMA_Start_IT(htim5.hdma[TIM_DMA_ID_CC3], par, m0ar, 😎 /* ... */

[waclawek.jan]

What are the symptoms and how do they differ from expetations?

What is the content of relevant TIM, DMAMUX, DMA registers?

JW

[Kolja Waschk]

The NDTR of the (circular) DMA1 Stream 1 (for ADC) counts down from 6144. I therefore expect varying values within range 0..6144 in ndtrbuffer, the destination for the (also circular) DMA1 Stream 0 that shall read NDTR and store it in that memory. However, the content, when viewed using an "expression" in STM32CubeIDE connected to the H723 on Nucleo via its ST-Link v3, shows quite other values e.g. 0xf6a0ff9 or 0x10160f2b.

Now after I had the idea to initialize the destination memory content to 0 in the beginning, I see it doesn't change at all after starting DMA. But the DMA Stream 0 (for TIM5 events) NDTR does visibly count down from 8 to 1 etc, so it definitely is doing something. Maybe my method of looking at the memory is flawed? I'm new to H7 with its caches etc..

To start with, a snapshot of the TIM5-CC3-driven DMA1 Stream 0 registers at 0x40020010 shows

• CR: 0x551F
• NDTR: 2
• PAR: 0x4002002c (that's IMHO the address of NDTR of DMA1 Stream 1)
• M0AR: 0x30003000
• M1AR: 0
• FCR: 0x20

[waclawek.jan]

> it doesn't change at all

That could be because of

> H7 with its caches etc..

---

> 0xf6a0ff9 or 0x10160f2b.

That looks like words of two halfwords, each of them being below 6144=0x1800.

Was this result achieved with some different setting of DMA1 Stream0 CR than what you've shown?

JW

[Kolja Waschk]

> That could be because of

>> H7 with its caches etc..

I read somewhere that RAM_D2 at 0x30000000 would be accessed without caching. But indeed with D-Cache off (for this experiment) I can now get reasonable values regularly updated. So the DMA/ADC/TIM setup itself was okay and I rather have to learn more about the caching.

> words of two halfwords, each of them being below 6144=0x1800.

It turned out to be the (cached) result of the previous run where the ADC DMA (2x halfword) overwrote the buffer for NDTR because I started it with a count too large for its own buffer. After looking more closely, sometimes one reasonable NDTR value showed up there (just to be overwritten soon), and only to be seen after restart (due to caching), not while running.

Thanks especially for pointing me towards looking for the actual source of the memory contents 🙂