Circular DMA seems to "doublebuffer" (STM32F427)

[turboscrew]

What is it that I've been missing...

I set a timer to trig 7-channel ADC with DMA. The DMA is set to make 7 16-bit to 16-bit transfers circularly. It seemed to work fine, but some data started to corrupt. So I made the 7x16-bit buffer 4-fold (28 16-bit numbers) and it got half-written. It looks like the data is stored in two 7x16-bit blocks.

The actual doublebuffering was not used and the DMA_S0M1AR was zero.

(Checked in the Atollic debugger special register view.)

[waclawek.jan]

So, as checked reading back the registers in debugger at a breakpoint just before enabling DMA, is the initial value of NDTR=28?

JW

[Tesla DeLorean]

DMA here normally has HT (Half Transfer) and TC (Transfer Complete) interrupts to manage a ping-pong arrangement with a singular buffer description.

[RMcCa]

Double check the dma stream CR. Both transfer sizes should be half words. The NDTR should be 7. If you have properly set circular mode the NDTR will get reloaded to 7 after each complete block. I use this with 8 half words with spi and it works fine. Setting up the dma without HAL is pretty easy, just a few lines of code.​

[turboscrew]

I always see 7 in the NDTR. And the both transfer sizes are 1s (half word).

Checked from the special registers in the middle of run. Several times.

The timer triggers the reading every 10 ms, so it's very hard to hit a stop in the middle of transfer.

[turboscrew]

Only complete-interrupt is used. The idea is that the ADC -reading happens "automatically", and the interrupt routine quickly copies the data for the application use. The reading happens every 10 milliseconds.

[turboscrew]

Yes. NDTR is always 7 and both transfer sizes are '1' (half words). If they were words, every second half word should have been zero. Now that's not the case.

There are 7 16-bit numbers that seem to be about right, then another group of 7 16-bit numbers differing their first group counterparts by less than 10. And the values are quite, what could be expected. I think the differences are just normal small "fluctuations".

[turboscrew]

BTW, what are the "bursts" and "beats" the reference manual talks about? Are those for, like, burst-writing to SDRAM?

[edit]

Ah, never mind, I already found out...

[waclawek.jan]

Ah, so you increased the buffer size without changing NDTR, and found part of buffer unexpectedly being written? I though you increased NDTR to 28 and complain about founding only half of the transfer to happen... =) Misunderstanding.

Strip down the program to absolute minimum but complete compilable example exhibiting the problem, and post.

JW

[turboscrew]

Yes.

Getting the code here is not easy, because it's not my personal stuff. I can only access the code at work, and I don't have much time for extra activity at the moment.

I was hoping to hear about some ideas about what I should check.