I’m using UARTB and UARTC on my board, UARTB works properly but I noticed an issue on UARTC, when it receives more than 16 bytes I lost bytes in the middle of the buffer, for example I send a buffer with sequential numbers
1 2 3 4 5…65 66 67 and I receive the begin and the end of the buffer but I lost some bytes in the middle generally 16 or more all together.
I tried in blocking mode and no blocking mode. I’m using in both uarts an isolated RS485 the circuit is the same the only difference is that I’m using UARTB with RTS and UARTC with an Output pin (because I’ve not a RTS pin).
Do you know if there is some issue with this port?
This issue is not expected. The test for the UART on our Linux BSP 6.5.0, which Torizon OS 6.5.0 is based on, has passed.
This test includes the UARTC port and RS485.
What software and hardware versions are you using?
Most of the relevant information can be obtained by running tdx-info or sudo tdx-info on Torizon OS.
This could be the cause of the problem, when using the PREEMPT_RT patch, the interrupts are turned into tasks which are scheduled by the real time scheduler.
Do you need the RT capabilities for your application?
If yes, so we can narrow down the problem, would it be possible for you to test on a non-PREEMPT_RT image?
You might want to include the relevant device tree pieces for UARTB and UARTC, along with a description on how your hardware is exactly connected to the module.
To exclude the circuit I set the driver direction of 485 to 0 (always input), but is always the same
here my circuit but it works properly on uart B, the only difference is that with uartb i use RTS instead in
uart c I use an output (now I excluded direction and put the driver always in input).
The strange thing is that the gap is in the middle.
I could try the same hardware with jumpers with uarta or uartd, but uarta is used from another process, and uartd is not inlcuded in torizon image, how can I enable it.
I executed a simple test on my Colibri iMX8X on the Colibri Evaluation Board. I connected a serial-to-USB converter directly to pins X11:A2 and X11:A3. The software image I used was the Multimedia Reference Image version 6.6.0 (TDX Wayland with XWayland 6.6.0+build.12).
With the USB converter connected to my PC, I started microcom on the target:
$ microcom -s 115200 /dev/colibri-uartc
Then, on my PC side, I set the baud rate on the serial port:
$ stty -F /dev/ttyUSB0 115200
After, I sent some data on the serial port from my PC to the Colibri with:
I tested with TTL uart and usb/TTL converter and is the same uartc lost packets as with RS485 in the middle. (The serial is connected directly to SODIMM 19 RXC without any kind of circuit)
I tried also with echo commands and other kind of host
i send 1234567890abcdefghilmnopqrstuvzABCDEGFGHILMNOPQRSTUVZ
on the target board
$microcom -s 9600 /dev/colibri-uartc
1234567890abcdefghiVZ
sometimes it recevices all and sometimes not.
I deactivated also the container. Maybe some problem on the SOM? Is it possible add to the image uartd to do some test on another port?
I reproduced the issue at 9600, and it seems related to a certain buffer size. Sending a 160-character buffer like I was sending before works, but sending a 50-character buffer fails.
Sending the following sequence of characters only works sometimes:
echo "1234567890abcdefghijklmnopqrstuvxyz"
At 19200 this issue didn’t occur. Is it a requirement to use 9600 in your application, or can this be changed?
Yes 9600 is important because is the standard baud rate for Modbus protocol. There is some workaround, or possibility to change the port (uartd)? Do you know if IMX6 has the same issue?
It should be possible to enable UART D, but currently, we don’t have ready-made examples of that.
In the end, it’s a matter of enabling the correct lpuart instance on the device tree and set the pinmux of the desired pins, taking care to not use any pin that’s already mapped to another necessary function.
Do you know if IMX6 has the same issue?
I’m not aware of a similar issue on the iMX6, but we were also not aware of this one on the iMX8X. We captured this one as a bug but I can’t provide a timeline for the fix at the moment.
