Thingy91X UART Shell drops characters at 921600

[Neal Riedel]

We have noticed an issue with received characters being dropped on the UART shell interface.  Originally, we found the issue using our own application, but subsequently we duplicated it using the modem shell sample application.

1.  The problem only occurs with baud rate 921600.  It does not happen using 115200.

2.  The problem only occurs on the Thingy91x.  It does not happen when using the nRF9151DK.

3.  The problem is not present using v2.8-branch version of the modem_shell application.  It is present using the v3.1.0 version of this application.

4.  The problem does not occur if we set `CONFIG_LOG=n` in the `prj.conf` file.  This is similar to the problem reported here:  UARTE1 at 921600 baud rate doesn't receive more than 5 bytes if CONFIG_LOG is enabled. However, in our case we can receive more than just 5 characters, we just have occasional lost characters.

To duplicate the problem, I built the nrf/samples/cellular/modem_shell application with the v3.1.0 tag of NCS:

# Checkout the NCS repo:
cd <ncs folder>
git checkout v3.1.0
HEAD is now at 6c6e5b3249 manifest: Tag v3.1.0

west update
    <completes successfully>

source ../zephyr/zephyr-env.sh

# Build the modem_shell application
cd samples/cellular/modem_shell/
west build -p -b "thingy91x/nrf9151/ns"

# program the thingy91x (we have an external debugger connected to it)
west flash --erase

Using a terminal emulator connected to the thingy91x (we use minicom on /dev/ttyACM0 at 115200), we can observe the problem by setting the UART to 921600 and copy/paste a long command into the shell:

*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***

Reset reason: PIN reset

MOSH version: v3.1.0-6c6e5b32496e
MOSH build id: custom
MOSH build variant: dev
Modem FW version: mfw_nrf91x1_2.0.2
Modem FW UUID: 320176d5-9f40-45fc-923b-2661ec18d547


Network registration status: searching

    <extra prints deleted>

IPv4 MTU: 1428
IPv4 address: 100.75.70.88
IPv6 address: ::
IPv4 DNS address: 198.224.182.135, 198.224.183.135
IPv6 DNS address: ::, ::
RRC mode: Idle
mosh:~$

We can see the problem does not occur with the default 115200 baud rate by pasting a long command into the shell:

mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delete

Each command appears normally in the shell.

Now we set the UART to 921600 baud and try again:

mosh:~$ uart baudrate 921600

    <reconnect minicom with 921600 baud>

mosh:~$ shell backspace_mode delete
mosh:~$ shell backspace_mode delee
backspace_mode - Toggle backspace key mode.
Some terminals are not sending separate escape code for backspace and delete button. This command forces shell to interpret delete key as
backspace.
Subcommands:
backspace : Set different escape code for backspace and delete key.
delete : Set the same escape code for backspace and delete key.

In the above, we see that the second time the shell backspace_mode delete is pasted into the window, it drops the t character in delete.

[Hakon]

Also, if not already disabled, can you disable this?

CONFIG_UART_NRFX_UARTE_LEGACY_SHIM=n

[Neal Riedel]

Hi Hakon,

Thank you for your response.  I checked and HW flow control is not enabled in the DTS.  The CONFIG_UART_NRFX_UARTE_LEGACY_SHIM config is enabled.  I will try disabling it.  Unfortunately, I am out of the office for the rest of this week.  So I will post the results here early next week.

Thanks,

Neal

[Neal Riedel]

Hi Hakon,

I tried disabling CONFIG_UART_NRFX_UARTE_LEGACY_SHIM.  Unfortunately, the results were the same.  The console still drops characters at 921600.  I did notice that with this config disabled, the console sometimes became unresponsive for several seconds after dropping characters. That is, typing on the keyboard gave no update on the console.  This did not happen with CONFIG_UART_NRFX_UARTE_LEGACY_SHIM=y.

I also tried updating to the v3.2.0-preview3 tag in NCS.  I found that this tag would not work at all, even at 115200 baud. I could not enter characters on the modem shell.  I could see the output logs, but there was no response to the input characters.  I reverted the code to the revision I was previously using (81daeb705c4cfadfd8c890c802a9d30ce15323b7) and it worked OK at 115200.  Of course, I did the usual west update after checking out a different tag/revision.

I repeated the experiment, and found the behavior was consistent.  That is, the v3.2.0-preview3 tag would not respond to characters on the input console, while the 81daeb705c4cfadfd8c890c802a9d30ce15323b7 revision would.  I did notice that when switching back to the 81daeb705 revision, I had to use west flash --recover to get the device to program.  Perhaps this is a clue to this issue.

Thanks,

Neal

[Hakon]

Neal Riedel said:

I checked and HW flow control is not enabled in the DTS.

Can you try with flow control enabled?

[Neal Riedel]

I tried enabling the HW flow control and the problem remained.  I expected this because I do not believe the HW flow control signals are connected between the nrf9151 and the board controller on the thingy91x.

For the record, here is the DTS overlay I used:

/*
    Thingy91X board DTS Overlay
*/

/ {
    aliases {
                uart0 = &uart0;
                uart1 = &uart1;
    };
};

&uart0 {
        status = "okay";
        hw-flow-control;
};

[Hakon]

Can you try testing with 1M baud instead? That has been tested to work with the thingy91x, and is also an exact value. In the case of 921600 baud, what is actually being used is 2 % higher, which could lead to errors when going through the connectivity bridge.