Hi,
I have a board using the i.MX8M Mini. The software is Yocto-based.
There is an issue with the communication using UART3 (may also happen on other UARTs, not tested) where, with DMA enabled, the serial communication does not work as expected. Data that can be seen to be received using a logic analyser is not always available to an application running on the OS. The issue is seen using Yocto kirkstone branch, Linux kernel 5.15.60.
- The issue does not occur when DMA is disabled in the devicetree.
- The issue does not occur on Warrior or Scarthgap.
This issue was seen when running stm32flash, which updates a connected STM32 MCU over UART using its ROM bootloader. The issue is also reproduced using a small custom test program.
The attached images show the issue:
- Image [warrior_working_logic_analyser.png] shows the logic analyser trace of the UART communication when running a Yocto Warrior-based OS. The communication looks correct and the stm32flash tool works.
- Image [kirkstone_not_working_logic_analyser.png] shows the logic analyser trace of the UART communication when running a Yocto Kirkstone-based OS. The communication looks correct but the stm32flash tool does not work.
- Image [stm32flash_not_working_output.png] shows the output when running stm32flash. The "Failed to read ACK byte" is printed when the tool has sent a command but was unable to read the ACK byte.
- Image [test_program_output.png] shows the output from a custom test program that repeatedly writes to the serial, polls waiting for a response, and reads any response. It shows that:
- After the first write to the serial, no response data is available.
- After the second write to the serial, 6 bytes are available.
- Image [test_program_logic_analyser.png] shows the logic analyser trace of the custom test program. It shows that:
- After the first write, one byte is received.
- After the second write, 5 bytes are received.
The custom test program shows the unexpected behaviour where the first received byte after the write is not available for reading until the second write, where the first received byte then becomes available.
This post describes what seems to be the same issue on UART1, among other issues, also on Kirkstone:
iMX8, enabling SDMA on UART1 causes problems - NXP Community
Is this a known issue with a workaround (other than disabling DMA) or could this issue be investigated by NXP?
Many thanks,
Ben
