Facing issue while using multiple USART in parallel on OSD32MP153C

[pratik.manvar]

Hi Octavo-Team,

We are facing problem while using multiple USART in parallel on OSD32MP153C running Linux kernel v5.4.

Our application contains two separate threads communicating on two separate RS485 ports in parallel at every ~10ms. After further debugging, we were able to narrow down the use-case to writes happening in parallel. The write on one of the RS485 is stuck and it never finishes and the thread is blocked forever.

Simplified way of reproducing the issue using Linux script is as follows (2 instances of this running on two separate RS485 (ttySTM3 and ttySTM7) in parallel):

——————————————-

#!/bin/bash

while true

do

echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07’ > /dev/ttySTM3

# echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07’ > /dev/ttySTM7

done

———————————————————

With this script, we can see write on one of RS485 is blocked after few seconds. Only way of recovering from this is to reboot the device. For debugging, when the application was modified to write on only one RS485 at a time, it works ok and never gets stuck.

Can you please suggest what could be wrong here?

Thanks & Regards,

Pratik Manvar

[Aedan Cullen]

This is a fascinating problem. However, I tried three kernels (5.10.10, 5.4.31, and 4.19.49) and wasn’t able to reproduce this with your script on an OSD32MP1-BRK using either Octavo’s Debian images or ST’s OpenSTLinux. Writes to both TTYs always succeed. This makes me think that it is not an exciting stm32-usart.c driver bug. Maybe there’s some additional detail about your device tree configuration of the USART modules that causes an issue, or a specific way that you’re building your overall Linux system that isn’t replicated in my testing. More information about your specific system might be needed to troubleshoot this problem.

Things that come to mind:

What board are you reproducing this issue on? If you’re only reproducing it with a custom board, have you tried it on one of the standard Octavo boards with nothing connected to the USART pins at all? Are you sure that the issue is not related to hardware flow control (CTS/RTS pins?)

[Neeraj Dantu]

Thanks Aedan!

Pratik,

As it is clear that the behavior you are seeing cannot be reproduced independently, I would suggest looking at your board configuration. In addition to Aedan’s inputs, here are a few things to check:

1. Probe signals and see if you can actually see the traffic you are generating on each interface and narrow down where during the transmission you are running into issues.

2. Check the pinmux configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L268) and peripheral configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L1063) in the device tree as compared to the BRK on your custom board.

Best,

Neeraj

[pratik.manvar]

Hello @Aedan and @Niraj,

Thank you for your support.

Yes, we have a custom board with Octavo BRK SIP module (STM32MP157C) with kernel v5.4.31.

As per your suggestion, I tried on OSD32MP1-BRK board with couple of kernel releases (v5.4.31 and v5.10.10) and able to reproduce the same issue on kernel v5.4.31!

It works fine with kernel v5.10.10 release.

I have added more data in echo command with a print of each transmission (PFA the updated scripts com-1.txt & com-2.txt).

#!/bin/bash while true do echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM1 echo -n "1" done

1 2 3 4 5 6

#!/bin/bash while true do         echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM1         echo -n "1" done

Please see the attached test logs (kernel-v5.4.31-serial-test-logs.txt & kernel-v5.10.10-serial-test-logs.txt).

Thanks & Regards,

Pratik Manvar

• This reply was modified 2 years ago by pratik.manvar.
• This reply was modified 2 years ago by pratik.manvar.

Attachments:

1. kernel-v5.4.31-serial-test-logs.txt
2. kernel-v5.10.10-serial-test-logs.txt
3. kernel-v5.4.31-serial-test-logs-1.txt
4. kernel-v5.10.10-serial-test-logs-1.txt

[pratik.manvar]

Hello

I could not upload the script files (com1.sh and com2.sh).

==> com1.sh

#!/bin/bash while true do echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM1 echo -n "1" done

1 2 3 4 5 6 7

#!/bin/bash   while true do echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM1 echo -n "1" done

==> com2.sh

#!/bin/bash while true do echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM2 echo -n "2" done

1 2 3 4 5 6 7

#!/bin/bash   while true do echo -n -e ‘\x00\x01\x02\x03\x04\x05\x06\x07\x10\x07\x23\x60\x61\x86\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xC4\x3A\x35\x7C\x56\x78’ > /dev/ttySTM2 echo -n "2" done

Thanks & Regards,

Pratik Manvar

[Neeraj Dantu]

Pratik,

Thanks for the logs. This is interesting. From the logs it looks like the driver was unable to shutdown the peripheral successfully: https://github.com/torvalds/linux/blob/v5.4/drivers/tty/serial/stm32-usart.c#L644. Given that you are not seeing this on kernel 5.10, the bug must be fixed in the updates to the driver. Upgrading the kernel seems to be the easiest way to resolve this issue.

Best,

Neeraj

[pratik.manvar]

Hello @Niraj,

Yes, we want to upgrade to the kernel-v5.10.

For that, I have posted the query in the other OSD32MP1-BRK latest patches – Octavo Systems thread. Seems like it is still not published and pending for approval.

Can you please confirm that the Octavo patches for kernel-5.10 available at GitHub – octavosystems/meta-octavo-osd32mp1: Yocto layer for OSD32MP1 Family of devices from Octavo Systems can be used to migrate to updated kernel-v5.10 provided by STM?

 

Thanks & Regards,

Pratik Manvar

[Neeraj Dantu]

Answered in another thread. You can use the patches in meta-octavo-osd32mp1 layer.

Best,

Neeraj

[pratik.manvar]

Yes. Thanks Neeraj.

Regards,

Pratik Manvar

 

[Author]

Posts