Linux VF50 UART broken (BSP2.6.1)


after switching from BSP 2.5 to 2.6.1 the UARTs on the vf50 module don’t work as expected anymore.

One problem has something in common with issues I had before:

After receiving invalid data, the following received bytes are delayed and prepended to the next received message The last bytes of the new mesage are prepended to the following message and so on.
This leads to unusable communication with timeouts and CRC errors.

It’s easy to reproduce it on the command line:

On the device:

root@colibri-vf:~# stty -F /dev/ttyLP2 19200
root@colibri-vf:~# cat /dev/ttyLP2 

On the PC:

stty -F /dev/ttyUSB1 19200
echo "111" > /dev/ttyUSB1
# Result on the device: 111
stty -F /dev/ttyUSB1 9600
echo "222" > /dev/ttyUSB1
# Result on the device: nothing
stty -F /dev/ttyUSB1 19200
echo "333" > /dev/ttyUSB1
# Result on the device: 111 (wtf?) or some invalid characters
echo "444" > /dev/ttyUSB1
# Result on the device: empty line
echo "555" > /dev/ttyUSB1
# Result on the device: 333
echo "666" > /dev/ttyUSB1
# Result on the device: 444

As a workaround I switched back to kernel 4.1.15 (used in BSP 2.5), but I would like to stay in sync with the toradex BSP,

The other problem with the UART is, that I’m not able to use a TTY line discipline driver (based on the common slcan but for LIN protocol) anymore. There are problems with receiving replies from another device after sending a request (I get a timeout) It works fine on all devices and kernels I tried so far, but with BSP 2.6.1 on vf50 I get receive timeouts.
I’m not sure if it has something to do with the issue above and I think, more research is needed, but maybe you have an idea on what happened.

Thank you for your help,


Please note that due to the reason lpuart not having hardware timeout for Rx in DMA mode we do use a software timer which has a fixed timeout, to keep latency below ~10ms we calculate the length of the DMA buffer on the fly according to the baud rate the tty port is configured to. May be due to this fixed timeout in DMA mode, low latency protocol communications might not work reliably.

Thank you, disabling DMA helps for both problems.
Currently we don’t have high CPU load and I can live with that.

The timeout for the protocol is 24 characters @ 19200 Baud (1.25ms) With DMA disabled, it works.

With the BSP V2.6.1 we re-enabled DMA by default, I guess it is related to that. Can you try with kernel boot parameter fsl-lpuart.nodma=1?

I guess the wrong UART leads to a framing error or similar, quite likely that this case is not properly handled with DMA. We need to further investigate this.