UART interface problem in iMX8MQ/MM

[borisberman]

Hello,

I'd appreciate it if you could open up an issue at NXP support about the  UART interface problem in iMX8MQ/MM reported by our customer.

Please see the following two messages from our customer:

------------------------------------------------------------------

Message #1:

Dear CompuLab,

I am experiencing really strange behavior right now. We have used UART1 on previous HW revision for RS-485 communication and we have changed the circuitry to use UART2 instead as that could use HW RTS pin for RS-485 transceiver control (DE pin). However the code that worked just fine on UART1 no longer works on UART2 and instead behaves very strangely.

I have simple Python code that increments number and send it over UART2 every 100 ms. From time to time I observe that there is more data being sent over Tx pin, and based on my testing it seems that it sends data that have been sent previously (sometimes from same run of my program, sometimes even from previous run, that depends on how long I keep it running). It seems like there is some rather large buffer (DMA?) as approximately 5kB are being transmitted repeatedly.

My code (minimal working example) is in file mwe.py. It opens the serial port, sets baud rate and enables RS-485. Then it randomly selects number to start from, so we can distinguish it from other runs, and sends incrementing number over UART in loop.
mwe.py

Here you can see example of one run. In file 4300-strace.txt is output from strace showing what has been written to serial port. In file 4300-received.txt are data actually received over RS-485. As you can see, it worked just fine from 4300 to 4346 (so far so good), but then it repeats 4346 followed by lot of data from previous runs.
4300-strace.txt
4300-received.txt

I am not sure if this can be somehow connected to the fact that UART2 is connected to BT on SOM module rev1.0 which I am trying it on (I do not have access to rev1.1 at this moment), but it seems rather unlikely. Even if there would be something connected, how could it explain observed behavior?

There is also some issue with received data as it tends to corrupt them from time to time. Right now I am not sure if this is separate issue of if the issues are connected, and I am trying to focus on issue described above for now. It makes absolutely no sense to us, therefore I am asking you for help.

Do you have any idea why we are experiencing this issue? I have thought that all UARTs shall be equal, but something is clearly wrong...

Message #2:

So it appears that i.MX8 UART driver have some imperfections, am I right? Does NXP know about this issue and is there something being done about this situation? I find it rather strange that there are some hacks/quirks/patches required just to get UART with RTS/CTS working without issues...

-----------------------------------------------------------------------------------------------

Best Regards,

Boris

[Yuri]

Hello,

   Are hardware  flow control (CTS\RTS) signals used in the case? 

Generally it is recommended to use it  to avoid issues.

Have a great day,

Yuri

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

[borisberman]

Hello Yuri,

Thank you for the fast answer.

According to our customer, and our software team checked it, problems

begin when we start working with flow control signals (CTS \ RTS).

In generally (by default), the UART uses one of  DMA  channels in the

iMX8, while the flow control is turned on, the UART does not work

properly, to fix this we need to disable the use of the DMA channel.

Best Regards,

Boris

[Yuri]

Hello,

  from "Driver Features" section of "i.MX Linux Reference Manual, Rev. L4.14.98-2.0.0"
The UART driver recognizes frame and parity errors only in interrupt-driven mode; does not recognize
these errors in DMA-driven mode. Perhaps it makes sense to decrease baud rate in Your case.

Regards,

Yuri.