ttyMSM1 and data loss in Debian

[simozz]

Hello,

I am using a Debian with both serial consoles disabled using the suggestions obtained here:

Dragonboard410c Debian #283 - disabling kernel messages to /dev/ttyMSM0 (/dev/console)

Hi all, I need to use both UART0 and UART1 for communication with an MCU. However, UART1 is attached to the Linux system console /dev/console. I already disabled the login commenting the line: ExecStart=-/sbin/agetty --noclear %I $TERM --keep-baud 115200,38400,9600 which disables root autologin via sytem console (root login is enabled by default). However, I would like to disable all messages which are forwarded to /dev/ttyMSM0 by default, including boot messages and kernel messages. Foll…

We have noticed a (big) problem with serial ttyMSM1, which basically consists in loss of data.
Some bytes are lost, both in transmission as in reception.

Basic test: connecting TX and RX togheter, using screen to echoing what is being typed on keyboard, after a randon number of characters the serial device starts to miss some data.
I also tried disabling the RTS and CTS lines using:

sudo stty -F /dev/ttyMSM1 -crtscts

I did not notice this problem only using screen (this was the last test), but also with interfaced boards.

The problem has been noticed on Debian 359, also with 283 version.

Please provide some suggestion because we have developed a product using your board and our client is waiting for it, and we are delaying it also due to the AP problem I recently discussed on this board.

Thank you in advance.
Regards,
Simon

[Loic]

@simozz

We have noticed a (big) problem with serial ttyMSM1, which basically consists in loss of data.
Some bytes are lost, both in transmission as in reception.

Which speed ? I don’t think UART can be considered as a reliable media, especially without flow control.

Do you observe same behavior with ttyMSM0 (LS UART0)? If I’m not wrong, You can use hardware flow control with UART0 since its hardware flow control pins are exposed on the Low Speed Connector (RTS/CTS), this is not the case for ttyMSM1 (dedicated to debug/console output).

If you need to use both UARTs, maybe you should enable software flow control (xon/xoff) on ttyMSM0.

[simozz]

Hello @Loic,

Which speed ? I don’t think UART can be considered as a reliable media, especially without flow control.

We tried 9600, 115200.

Do you observe same behavior with ttyMSM0 ?

No, ttyMSM0 seems to works fine.

From the pin table yes, RTS and CTS can be used, but it’s also true that these can be disabled.
In this case shouldn’t be any problem, especially with TX/RX shortcircuited. Do you agree ?

Regards,
Simon

[danielt]

Echo tests are rather notorious for unexpected failures often because
they often convert /r to /r/n (or make other transformations which
cause a data out to be larger than data in). Eventually that will
overflow somewhere since both TX and RX are running at max speed.

Easier tests (perhaps with clearer output) are things like:

• Do uni-directional tests fail?

• Do bi-directional but uncorrelated tests (i.e. two simulatenous
  uni-directional tests) fail?

[simozz]

Hello @danielt,

I never had problems with echo tests but I keep in mind this detail. Thank your for sharing.

Regarding tests, uni-directional test is where we noticed the problems.
Looking at ttyMSM1 TX line with an oscilloscope we noticed that ttyMSM1 doesn’t transmit anything when this happens.

Regards.
Simon

[simozz]

Hello @danielt and @Loic

I have to say sorry for this thread, I was a little bit stressed at the moment.
We noticed that the errors came up from an hardware problem of the interfaced board.

This board actually seems that broke the serial port of the Dragonboard we were using.
We replaced the Dragonboard and the interfacing board and it’s working fine.

Thank you for your help and interest.
Regards,
Simon

[danielt]

No worries… and sorry you broke a board. I had this on my TODO list but hadn’t got round to running any tests yet (I wasn’t at my desk much of yesterday).