2020-11-10 12:13 PM
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:
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:
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?
2020-11-18 12:07 AM
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 ?
2020-11-18 07:26 AM
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