Just a notice about a silicon errata from ST for STM32F410 and 411 (and maybe others): using DMA2 and GPIO as done in this project can cause glitches in the generated pulses. Errata says "DMA2 data corruption occurs when managing AHB and APB2 peripherals in a concurrent way", specifically with GPIO when doing memory-to-peripheral transfers (exactly what we need...).
The workaround given in the errata is not suitable: memory-to-memory transfers doesn't support requests, so it can't be used.
And DMA1 cannot write to the GPIO peripheral, so can't avoid it.
It's tricky to know when you're "managing AHB and APB2 peripherals in a concurrent way", but I managed to avoid glitch issues (for now) by compiling in "-Ofast". Not very robust, I'm afraid this "workaround" can break easily.
We'll see, I'll report if I find something else.
Hello,
Just a notice about a silicon errata from ST for STM32F410 and 411 (and maybe others): using DMA2 and GPIO as done in this project can cause glitches in the generated pulses. Errata says "DMA2 data corruption occurs when managing AHB and APB2 peripherals in a concurrent way", specifically with GPIO when doing memory-to-peripheral transfers (exactly what we need...).
The workaround given in the errata is not suitable: memory-to-memory transfers doesn't support requests, so it can't be used. And DMA1 cannot write to the GPIO peripheral, so can't avoid it.
It's tricky to know when you're "managing AHB and APB2 peripherals in a concurrent way", but I managed to avoid glitch issues (for now) by compiling in "-Ofast". Not very robust, I'm afraid this "workaround" can break easily. We'll see, I'll report if I find something else.