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 1M baud on the Thingy.  Unfortunately, it still does not work.  The result was the same if flow control was on or off in the DTS.

I also went back to the v3.2.0-preview3 tag in NCS.  I found that it still does not work at all, I cannot send chars to the Thingy91X shell, even at 115200.  Can you try that experiment?  If it works for you, maybe you could send me your HEX file and I can try it to possibly eliminate any possible HW problems.

Thanks,

Neal

[Hakon]

Neal Riedel said:

Can you try that experiment?

Yes, I will try to replicate and report back.

[Hakon]

I tried with v3.2.0-rc1 and yes, it seems very bugged. At least on 1M baud. At 115200 baud it worked fine. I will do some more testing tomorrow.

[Hakon]

I did some more testing, this time using picocom. And using that I was not able to send anything. Could be that you need to change some settings with minicom to make it work. With the Nordic Serial Terminal it worked  with 115200.

[Neal Riedel]

Hi Hakon,

I tried the Nordic Serial Terminal (v1.6.0) with the Thingy91X and I was not able to get it to work.  It has the same problem as with minicom and picocom, I cannot send characters to the Thingy shell.  I confirmed that the same software build for the `nrf9151DK` works correctly with all three terminal emulation programs (minicom, picocom and Nordic Serial Terminal).

We have changed our development configuration to only use 115200 baud to work around the dropped characters.  I think the lack of flow control on this port causes the problem at 921600 baud, but I do not know why we did not observer it with earlier releases of NCS.

Today I tried NCS v3.2.1 and found that the Thingy91X problem no longer occurs with any of the three terminal emulation programs.