RS485 send too much data

Hi
I’m using the uart2 on my custom board to run RS485.
In general, it works fine, but if I run longtime test after ever 5’000 to 50’000 request/response the transmitted data is much too long.
I always send 8 Byte and receive 11 Byte from the connected device.
In the case of failure, the transmitted data is 513 times longer than the expected data. I recorded the data with the scope and saw that the RTS-Line stays active (high) during the full time.
The transmitted pattern is an exact repetition of 513 times my sent pattern. This is reproducible.

The tty is configured as follows

  B57600, bit8, no parity, one stop
  delay_rts_before_send =0
  delay_rts_after_send=0
  SER_RS485_RTS_ON_SEND
  SER_RS485_RX_DURING_TX

Furthermore I tried to understand how multiples the transmitted data. Is it the tty-framwork or is it a uart driver problem. Therefore I added some printing in the drivers/tty/serial/imx.c imx_transmit_buffer() and counted the character written into the xmit->buf

   while (!uart_circ_empty(xmit) &&
       !(readl(sport->port.membase + uts_reg(sport)) & UTS_TXFULL)) {
          writel(xmit->buf[xmit->tail], sport->port.membase + URTX0);
          xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
          sport->port.icount.tx++;
   }

Here I was not able to see that I receive more than 8 Bytes. So I expect that the problem is in the lower layer of the uart driver.
Does someone see similar problems?
Regards Stefan

PS: I tried to reproduce the problem with the mainline kernel 4.19.7 but here it worked for millions of transmits.

Hi @StefanB

Bsp 2.8b3 is not supported anymore. Could you update to 2.8b4 and do the tests again?

Concerning your issue, could you share the schematic of the rs485 output? What did you connect at the output of rs485 ports?
Could you share an example code you are using to do your tests?

Thanks and best regards, Jaski

Hi Jaski
I ported the kernel to BSP 2.8b4 tag. Looking that the patches between 2.8b3 and 2.8b4 there is no fix in this area. Anyway, I run the test and it failed again.

Here you see the schematics of RS485.

The connected device is a own rs485 device running in other applications as well. The cable is 30cm.

You asked for the code, it is attached as a zip and can easily rebuild with cmake.

Regards Stefan

Thanks for the schematic and the example code. We will look next week into this Issue. Just a question? Is it OK for you to use mainline (4.19.7) kernel or do you need the 4.9 kernel?

Hi Jaski
We have 2 projects both using RS485.
One project already use 4.19.y so with his we have no problem.
But there is a second project running 4.9 using qt-web-view…
With 4.19.y we are not there to run qt-web-view with the open-source graphic stack.
Probably we could discuss in a other thread if tx has experience there.
Regards Stefan

Thanks for the Information. We will try to reproduce the error this week. Concerning your questions with open-source graphic stack, you should ask a new question? Thanks.

Hi @StefanB

In the meantime, we changed to the kernel 4.9.2.3 and we released Bsp 2.8b5. Could you try, if you still see the issue with the new Bsp? Thanks and best regards, Jaski

Hi @jaski.tx
Thank you for updating us. I already saw the announcement and requested our team to repeat the test with the updated kernel. We will comment as soon as we have the results.

Perfect, thanks for your Input. We will wait for your results.

Hi @jaski.tx
I repeated the test with Bsp 2.8b5. I encountered the same problem.
It fails always after 9’000 to 91’000 sends (4 out of 4 tests)

Hi @StefanB

Thanks for letting us know. We will look into this Issue and come back soon to you.

Hi @StefanB

Thanks for your Input.

Best regards,
Jaski

Hi @jaski.tx
Our second and last team is now migrating to mainline-kernel 4.19.y
So there is no need from our side to fix this problem
Regards Stefan

We had the exact same bug with kernel linux-toradex-4.9-2.3.x.
Going with mainline was not an option for us. Thus we did find a fix for this problem.

We backported manually the fix that was done on mainline kernel, and it hopefully worked.
The explanation of the fix can be found here: https://lore.kernel.org/patchwork/patch/801925/
The fix contains 2 patches that needs to be applied:
0012-PATCH-serial-imx-Prevent-TX-buffer-PIO-write-when-a-.patch
0013-Backport-DMA-patches.patch

The first one fixes corruption of the tx buffer. This improves the reliability of data transmit and the second patch (based on http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/516845.html but backported to linux-toradex) fixes DMA when stopping rx/tx transmission. Together we don’t see the bug anymore.

Hope this can help someone else using imx6qdl with RS485.

Patch files

HI @emcp

Thanks for your valuable Input.

Best regards,
Jaski