I'm using the imx6ul eval kit with the 4.9-1.0.x-imx Linux kernel:
Commits · Freescale/linux-fslc · GitHub
I have a user-space application running on the imx6ul reading from /dev/ttymxc1 with the TTY configured in raw mode at 115200 baud. The TTY is configured for DMA (not interrupt) via the device tree.
When the imx6ul receives small chunks of bytes (< 32 bytes) with delays between those bursts (> 1ms), the imx6ul UART receive seems to function properly. However, when I send larger chunks (256 to 512 bytes) in a more continuous fashion, I'm seeing periodic drops or corruption. I'm running a logic analyzer on the UART signals and at the physical layer (decoding the signals) the expected bytes are transferred. Hence I think there might be a UART driver problem.
Based on this post:when use uart with DMA, why its DMA callback function invoked so slowly? I tried changing DMA burst size relative to FIFO, but no luck. There are still periodic errors.
By "periodic error" I mean a single byte dropped and/or a single byte corrupted every few minutes. I don't suspect HW issues, but it could be...
Questions:
Can anyone recommend if I should be using a newer/different Linux kernel/BSP?
Other posts refer to using flow control (RTS/CTS) for UART with DMA. issue about imx6 uart dma Is this absolutely necessary? Or just a recommendation? In my case, I don't think flow control is an option.
Any other recommendations for debugging this would be appreciated.
Hello,
Using flow control (RTS/CTS) for UART with DMA is absolutely necessary to avoid
data lost.
Regards,
Yuri.
Hi Yuri,
Would it be a valid assumption that with the smaller messages, I'm probably just getting lucky in "never" seeing byte errors? I'm curious why sending more bytes more often seems to trigger an issue, or at least trigger it faster.
Thanks
-Nick
Hello,
UART FIFO helps to avoid bytes lost.
Regards,
Yuri.