STM32H7, MDMA IRQ double hit... and working only with debugger attached.

[tarzan]

Hello,

I configured the following ADC flow:

ADC3 => DMA2 => SRAM => MDMA => DTCM

Everything was working well using the MDMA in single buffer transfer mode. In each MDMA interrupt I was reconfiguring the MDMA channel to get ready for the next DMA2 transfer complete IRQ.

Next step was to configure the MDMA in linked mode. The idea is to use a single node pointing on itself, to reconfigure the MDMA automatically at the end of each buffer transfert.

• Program compiled in debug mode, started with a debug session: it looks to work, but every MDMA IRQ is immediately followed by a second entrance in the interrupt routine (with all IRQ flags = 0). I was thinking about something like that link but the MDMA shares the core clock (?) and the problem persists even using 10 nops after the flag clear.
• The same program, started by itself: I don't have any MDMA interrupt. I'm sure the problem is the MDMA because everything was ok before using it.

I/D caches disabled. Optimization level don't change the behavior.

I've spent hours on this problem, I didn't found any relevant information on the web.

Any ideas will be strongly appreciated 🙂

[Piranha]

http://efton.sk/STM32/gotcha/g7.html

[Tesla DeLorean]

Double Interrupts, HT & TC ?

The Cortex-M has a long standing race condition with the NVIC / Peripherals, the processor is pipelined, and the tail-chaining decisions are made quite rapidly.

Reading back the register you've written acts as fencing instruction for the write-buffers. Clear the interrupt early in the handler, not the instant before you exit.

Debugger only? Check BOOT0 is pulled low. Instrument with a UART so you don't need to single step everything. Confirm it is running. Check that you've enabled all required clocks and peripherals, and not reliant on the debugger to do it. Dump RCC registers in the working and non-working states, compare and contrast. Look at other peripheral registers