cancel
Showing results for 
Search instead for 
Did you mean: 

STM32MP151 Transmit DMA stopping unexpectedly

BNieb.1
Associate

I am using UART5 on an STM32MP151 to communicate with an external processor. The Cortex-A7 is running Linux and DMA is in use for both receive and transmit. Hardware flow control is also enabled and the transfer rate is 6 Mbps. Currently we are running test code to repeatedly send messages between the processors in both directions simultaneously. During this test, eventually the MP151 will send part of a message, and then the transmission will stop and never complete. I have verified this both by examining what is received on the other processor, as well as by using an oscilloscope. Here is the data that I have about the problem:

  1. Hardware flow control is not activating in this scenario, as verified by the oscilloscope
  2. The DMA transfer is still active. This has been verified by noting that the EN bit of the SCR register is still set and the SNDTR register still has the correct count of the remaining bytes that haven't yet been sent.
  3. The serial port is still active. This has been verified by noting that the DMAT bit of CR3 is still set , the ISR register shows the TXFIFO is empty, the TC bit of the ISR register is set, and the ISR register has no errors indicated.

By examining the DMA and UART registers, it appears that for some reason the DMA has stopped loading bytes into the UART. Nothing looks out of the ordinary except one thing: the FEIF bit of HISR indicates that a FIFO error event occurred. This is strange because the DMA is operating in direct mode. I came across this statement in the reference manual:

In direct mode, the FIFO error flag can also be set under the following conditions:
• In the peripheral-to-memory mode, the FIFO can be saturated (overrun) if the memory bus is not granted for several peripheral requests.
• In the memory-to-peripheral mode, an underrun condition may occur if the memory bus has not been granted before a peripheral request occurs.

I'm wondering if this FIFO error flag could be why the transmit DMA transfer stopped. My questions are:

  1. Does it seem reasonable that this would be why the DMA transfer stopped?
  2. What exactly does "if the memory bus has not been granted before a peripheral request occurs" mean?
  3. What can I do to address this problem?

Thank you for your help,

Brian

EDIT: It seems there are FIFO errors asserted in direct mode when the transfer is successful too, so I'm guessing that maybe the FIFO error doesn't have anything to do with it. To clarify, the DMA transfer is in progress when it just stops in the middle of the transfer for no apparent reason. I have done a test where after the transfer stops I clear the UART DMAT bit and then set the UART DMAT bit. If I do that then the DMA transfer resumes. This suggests to me that the DMA is stuck. What could possibly cause this?

2 REPLIES 2
Bernard PUEL
ST Employee

Hi Brian,

many work were done on UART/DMA use case on V2.0.0 then on V2.1.0. Could you please clarify Which SW version you are using ?

Linux framework is as far as I know limited to 4 Mbps, did you patch it to extend to 6 ? Or your test SW is not using it ?

Bernard -

Thanks for the response. Our kernel is currently based on v5.4-stm32mp-r1. I did look through all the commits on the v5.4-stm32mp branch, both for DMA, DMAMUX, and for the UART. I didn't see anything that looked remotely related to this problem, but of course I don't know that for sure. Are there any particular fixes that you think might be worth trying out?

We modified the TF-A to set PLL4 to 96 MHz, which allows us to get 6Mbps with 16x oversampling. It appears to transmit and receive correctly at 6Mbps, that is until eventually the DMA error above occurs.

Brian