Debugging when DMA is active...

[Harvey White]

When debugging, and when stopped at a breakpoint, does DMA or any interrupt driven process continue? 

If no, then debugging an incoming serial data stream (for example), can only be done after the stream is completed, otherwise you will miss characters....

Opinions?

[turboscrew]

Well, a breakpoint can't stop the external world - like the sender...

[Jeroen3]

It is possible to halt certain peripherals during a breakpoint. Such as timers.

Serial is more difficult, but perhaps things keep working if you use hardware flow control.

[S.Ma]

Even if the DMA was still operating, you can watch DMA's register like CNTR and look into the RAM buffer. Think like UART incoming data stream: DMA receives incoming bytes in cyclic buffer. Instead of having interrupt on every received byte, you could check the DMA and the buffer every 1 msec. Lower interrupt frequency at longer reaction time without any data loss.

[Harvey White]

Exact problem, RS232 input without any flow control. If the DMA continues, then that's one thing, it can be debugged inside the loop. If not, then only outside the loop.

[Harvey White]

Hardware flow control is not possible on this peripheral (ESP8266). If it were, I'd have some different solutions.

[Harvey White]

Already do that with a slightly different implementation, using a software FIFO and comparing successive stages of put pointers. Doesn't work well with an operating system that's controlling interrupts, so it needs to be in a separate processor that does not run an operating system. HAL drivers don't necessarily work well with operating systems. Hence, the problem.

If DMA works during breakpoints, that's one thing. However, the DMA destination register is shadowed, and is not available (I think) until the DMA action is finished, which doesn't help...