On Fri, Jun 6, 2025 at 2:55 AM Jacob Dahl <dahl.jakeja...@gmail.com> wrote: > > Hi, this is my first time posting in the mailing list. I'm an embedded > software engineer and I primarily work on the PX4-Autopilot project. I > recently implemented Bidirectional DShot in PX4 which uses Timer Burst with > DMA to simultaneously update channels 1 - 4 to send data to the ESCs > (electronic speed controllers) to control the RPM of the motors. The > Bidirectional DShot protocol uses a single wire for both RX and TX. So > after the Timer Burst is complete I am reusing the same DMA stream to then > perform a Capture Compare on one timer channel at a time in a round-robin > fashion (to receive ESC telemetry). When I implemented and tested the > feature it worked and we merged it in. Fast forward to now, a user reported > that one of their serial devices wasn't working when Bidirectional Dshot > was enabled. Upon investigation I confirmed this, one of the serial devices > also using DMA on DMA1 stopped receiving data when bidirectional dshot was > enabled. I instrumented the NuttX driver code and verified that I was using > the exact number of DMA streams as I was expecting, none of the streams > were in conflict. In total I am using 7 streams -- 2 for SPI, 4 for two > UARTs, and 1 for the Timer. The SPI and first UART devices work properly, > only the second UART is affected. > > My working theory is that the high frequency allocation/freeing of the DMA > stream (re-assinging from Burst to CaptureCompare at 800Hz) is > interfering with the other streams on that DMA controller. I looked through > the NuttX code and saw that most drivers use stm32_dmachannel() during > initialization and stm32_dmafree() during cleanup, so my use case seems > unique. Can anyone shed some light on this and help me determine the best > path forward? For now I've moved the Timer DMA stream to DMA2 to avoid > conflicts with my other peripherals, but I would like to solve this issue > so that I am not limiting my available DMA streams. The code is here, I've > highlighted the relevant sections: > https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/px4/stm/stm32_common/dshot/dshot.c#L330-L537 > The flow is as such: > up_dshot_trigger --> dma_burst_finished_callback > --> capture_complete_callback > > Thank you for your time, > Jake
Hardware bug? There are several known issues with STM32H7's USART/LPUART + DMA and some workarounds :-P https://www.st.com/resource/en/errata_sheet/dm00530531-stm32h745-747xi-g-and-stm32h755-757xi-device-limitations-stmicroelectronics.pdf -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
