Issues with shell not echoing / buffering input characters

RE: Issues with shell not echoing / buffering input characters

Isaia F — Tue, 31 May 2022 12:40:47 GMT

Hi.

We did as told and all that happened is that now we cannot send commands via gtkterm. We only see uart:~$ and nothing more, pressing keys on the keyboard doesn't seem to send or echo anything

EDIT: after flashing and then inserting the JLink interface MCU firmware it now behaves as expected.
Thank you.

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Tue, 31 May 2022 09:10:01 GMT

Hi,

Make sure you have v7.58b of JLink, then try to flash the Zigbee shell sample to your DK again.

Best regards,

Marte

RE: Issues with shell not echoing / buffering input characters

Isaia F — Tue, 31 May 2022 06:49:48 GMT

Hi.

Apologies for the late answer, we've just tried what you suggested. Now the DK prints to UART the following string when we press the reset button:
*** Booting Zephyr OS build v2.7.99-ncs1-1 ***
Though it doesn't print anything else. Where do we go from here exactly?

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Tue, 24 May 2022 08:08:58 GMT

Hi,

I have asked my colleagues, but besides the one I mentioned previously no one else has seen this error or are able to reproduce it.

Since the issue does not present itself when using nRF USB it might be an issue with the firmware on the interface MCU, so you can try uploading new firmware.

Download the JLink interface MCU firmware from nRF52833 DK > Downloads.
Unplug the DK from the computer.
Hold in the IF BOOT/RESET button on the DK while plugging it in, and keep it pressed until LED5 starts to blink to make the device enter bootloader mode.
The device should show up as BOOTLOADER.
Drag and drop the firmware image into the DK.

Best regards,

Marte

RE: Issues with shell not echoing / buffering input characters

Isaia F — Mon, 16 May 2022 09:46:04 GMT

Hi.

We had not tried to program the DK with another computer.
Furthermore, after updating nrfjprog, downgrading jlink and trying on the DK's USB with the project you've given us, the problem does not appear to present itself (although it took a couple presses of the reset button before gtkterm stopped appending garbage characters (like "[1;32m" and "^[") after uart:~$, characters that were intepreted by the shell as (obviously incorrect) commands)

We will try with the updated nrfjprog / downgraded jlink to see if our normal build of the shell sample keeps manifesting such problems, as well with our normal build modified to route the shell output to USB

Addendum/update: trying to use the shell sample in the nrf SDK with the updated nrfjprog/downgraded jlink still caused the same issue on gtkterm (to note: this is the same sample that originally displayed the problem, i suppose this excludes the possibility of nrfjprog/jlink being the source of the issue?)

I am attaching a zip file with our shell sample, even though it should be the same as the one in the SDK
devzone.nordicsemi.com/.../shell.zip

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Mon, 16 May 2022 09:06:36 GMT

Hi,

Please try updating to the latest version of nRF Command Line Tools (nrfjprog), v10.15.4. You can find the download here: https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools/download#infotabs. Also try downgrading to v7.58b of JLink, since that is the version bundled with this version of nRF Command Line tools, and thus the version it has been tested with.

Have you tried programming the DKs with another computer?

Can you also try using the nRF USB on the DK instead of using the USB for the onboard debugger, to see if the issue might be because of the interface MCU? For this you will need to make changes to the sample so that the shell uses USB instead of UART. I have already done this, so you can simply program the file zephyr_usb.hex to your DK, but I will also upload the project as a zip-folder. After programming the device, move the USB cable from the interface MCU USB to nRF USB on the side of the DK. The device should show up as a USB serial device or Zephyr Zigbee shell, and you can connect to it using GTKTerm as normal.

Best regards,

Marte

devzone.nordicsemi.com/.../zephyr_5F00_usb.hex

devzone.nordicsemi.com/.../shell_5F00_usb.zip

RE: Issues with shell not echoing / buffering input characters

Isaia F — Fri, 13 May 2022 14:33:55 GMT

Hi.

I have rebuilt the shell project removing the additions to the proj.conf file for RTT, and also cleaned the build directory when opening the project (so to return to the "pre-rtt" state for lack of better terminology).

Opening gtkterm and running the command i see the following

speed 115200 baud; line = 0;
min = 1; time = 0;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

without gtkterm running i see

speed 9600 baud; line = 0;
-brkint -imaxbel

running miniterm i see a similar problem where the latest character is not properly displayed, stty gives this info

speed 115200 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

The issue presented itself even on another computer running the same version of Ubuntu

I already tried different cables but the issue persisted even there

nrfjprog -v gives the following

nrfjprog version: 10.15.1 external
JLinkARM.dll version: 7.60c

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Fri, 13 May 2022 14:13:19 GMT

Hi,

I have discussed this with a colleague who have seen a similar issue on Linux in the past. However, in their case the problem was with the computer, as they saw the same issue with different devices (from other producers) and only on their computer. I do have some suggestions for things to try and test out, so hopefully one of them will help, or will at least narrow down the issue.

First, I have seen reports of similar behavior with other devices on Linux. In one of those cases using miniterm solved the issue. It seemed to be related to stty settings, so running stty on the port when you have the port open in different terminal emulators might give you some information, e.g:

stty -F /dev/ttyACM0

The settings used by miniterm and not by the terminal emulators causing issues were the following:

-echoke -echoctl -ignbrk brkint -onlcr

I see all of these settings when I check on my side. So please check with miniterm, and check the stty settings.

To further narrow it down if the above does not work, can you try the following things?

Test the DK on another computer
Test with another device on your computer if you see the same lag there
Test with different cables

Please also check what version of nrfjprog and JLink you have installed. You can find this by running

nrfjprog -v

Best regards,

Marte

RE: Issues with shell not echoing / buffering input characters

Isaia F — Thu, 12 May 2022 09:03:47 GMT

Hi.

I have done the following:

-open Programmer
-erase all
-write the .hex you have provided
-pressed "erase & write" (as for some reason, Write was not enabled)
-tried connecting with gtkterm and tried typing -> saw the same issue
-closed gtkterm
-swapped usb cable
-reopened gtkterm
-pressed reset button on board
-tried typing -> same issue again
-closed gtkterm, swapped usb port on my pc, pressed reset button on the board->same exact issue

Then i tried with the shell sample with the modifications to the proj.conf file (attached below)

#
# Copyright (c) 2021 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Options enabled by CONFIG_NCS_SAMPLES_DEFAULTS,
# put this way to get rid of LOG_MODE_MINIMAL
CONFIG_LOG=y
CONFIG_ASSERT=y
CONFIG_ASSERT_NO_COND_INFO=y
CONFIG_ASSERT_NO_MSG_INFO=y
CONFIG_HW_STACK_PROTECTION=y
CONFIG_LOG_DEFAULT_LEVEL=1

# Configure serial
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_SERIAL=y
CONFIG_GPIO=y

# Make sure printk is not printing to the UART console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n

CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_MAIN_THREAD_PRIORITY=7

CONFIG_ZIGBEE=y
CONFIG_ZIGBEE_APP_UTILS=y
CONFIG_ZIGBEE_ROLE_ROUTER=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# This example requires more workqueue stack
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Enable nRF ECB driver
CONFIG_CRYPTO=y
CONFIG_CRYPTO_NRF_ECB=y
CONFIG_CRYPTO_INIT_PRIORITY=80

# Networking
CONFIG_NET_IPV6_MLD=n
CONFIG_NET_IPV6_NBR_CACHE=n
CONFIG_NET_IPV6_RA_RDNSS=n
CONFIG_NET_IP_ADDR_CHECK=n
CONFIG_NET_UDP=n

# Zigbee shell
CONFIG_ZIGBEE_SHELL=y
CONFIG_ZIGBEE_SHELL_DEBUG_CMD=y
CONFIG_ZIGBEE_SHELL_ENDPOINT=64

CONFIG_LOG_CMDS=y
CONFIG_LOG_STRDUP_MAX_STRING=370
CONFIG_LOG_STRDUP_BUF_COUNT=24

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_SHELL_BACKEND_RTT=y

-Opened SES, selected shell project, cleaned build dir
-Checked .config file, i see that:

# CONFIG_UART_CONSOLE is not set
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_SHELL_BACKEND_RTT=y

-Pressed Target > connect J-Link in SES
-Target > Erase all
-Project > Run CMake
-Build > Rebuild Solution
-Target > Connect J-Link
-Target > Download zephyr/merged.hex
-Opened JLinkRTTViewerExe
-Used default options (USB, NRF52833_XXAA, SWD 4000kHz, Auto-Detection)
-Connected and received this log

LOG: J-Link RTT Viewer V7.60c: Logging started.
LOG: Terminal 0 added.
LOG: Connecting to J-Link via USB...
LOG: Device "NRF52833_XXAA" selected.
LOG: InitTarget() start
LOG: InitTarget() end
LOG: Found SW-DP with ID 0x2BA01477
LOG: DPIDR: 0x2BA01477
LOG: CoreSight SoC-400 or earlier
LOG: Scanning AP map to find all available APs
LOG: AP[2]: Stopped AP scan as end of AP map has been reached
LOG: AP[0]: AHB-AP (IDR: 0x24770011)
LOG: AP[1]: JTAG-AP (IDR: 0x02880000)
LOG: Iterating through AP map to find AHB-AP to use
LOG: AP[0]: Core found
LOG: AP[0]: AHB-AP ROM base: 0xE00FF000
LOG: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
LOG: Found Cortex-M4 r0p1, Little endian.
LOG: FPUnit: 6 code (BP) slots and 2 literal slots
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: [0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
LOG: [0][1]: E0001000 CID B105E00D PID 003BB002 DWT
LOG: [0][2]: E0002000 CID B105E00D PID 002BB003 FPB
LOG: [0][3]: E0000000 CID B105E00D PID 003BB001 ITM
LOG: [0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
LOG: [0][5]: E0041000 CID B105900D PID 000BB925 ETM
LOG: RTT Viewer connected.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 7 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 7 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 7 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 7 not supported.

-Other options: Input > Sending > Send on enter, Block FIFO if full not checked, EOL Windows format
-sent "bdb", now for some reason the device responded as it should have (no dropped bytes or weird sendings), log below

LOG: Sent 5 bytes.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.
WARNING: <Terminal 0>: ANSI CSI SGR parameter 18 not supported.

-tried sending "bdb" a few more times, no issues with FIFO being full, response (both on terminal and on log) same as above

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Thu, 12 May 2022 08:34:15 GMT

Hi,

[quote user="Isaia F"]I flashed the .hex via the nrf Programmer v3.0.0 but once again the issue presented itself, [/quote]

Then the issue does not seem to be with the SDK. It would also be strange if the issue is with the DK, as you are seeing the same on two different DKs. Did you make any other changes between when it was working as expected and when the issue appeared? Anything with your set up that might be causing this. Have you also tried with different USB cables? Do you perform an eraseall on the DKs before programming?

[quote user="Isaia F"]we have attempted to use RTT by changing the options via ninja guiconfig, however while RTTViewer seems to be able to send the message [/quote]

I am testing using RTT Viewer myself, and I do not see the issue you are seeing with this either. If you look in the .config file generated when building (<build_dir>/zephyr/.config), you can see configurations that are set and not. Please check there and verify whether the configurations I mention in my last reply are set or not.

Best regards,

Marte

RE: Issues with shell not echoing / buffering input characters

Isaia F — Wed, 11 May 2022 12:31:35 GMT

Hi.

I flashed the .hex via the nrf Programmer v3.0.0 but once again the issue presented itself, our operative system is Ubuntu 20.04.4 LTS

We have not yet tried with RTT and we'll get back to you as soon as we try that option

EDIT: we have attempted to use RTT by changing the options via ninja guiconfig, however while RTTViewer seems to be able to send the message (we tried all EOL options), it does not however seem to receive any response message with the sole exception of the opening message on system reset. That or the commands are simply not sent in the first place (likely the case as after a few sending the RTT warns us that it has sent 0 bytes)

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Wed, 11 May 2022 12:18:16 GMT

Hi,

What operative system are you using?

I have done some more tests using GTKTerm in Ubuntu 20.04 LTS, but I am still unable to reproduce your issue. Can you test with the zephyr.hex file I have attached? This is built for nrf52833dk_nrf52833 in v1.9.1, and it worked as expected when I tested it.

You can also check if using RTT instead of UART as backend helps. To switch to RTT instead you must modify prj.conf to have the following settings:

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_SHELL_BACKEND_RTT=y

Connect to RTT as described in Connecting using RTT.

Best regards,

Marte

devzone.nordicsemi.com/.../5584.zephyr.hex

RE: Issues with shell not echoing / buffering input characters

Isaia F — Tue, 10 May 2022 14:19:02 GMT

Hi.
I have made no changes to the source code of the sample itself, the only thing that i did was to reinstall the nrf Connect SDK in the way indicated in the Getting Started Assistant. (We're currently using the tag v1.9.1 but the problem appeared even by switching previous tags as mentioned in the opening post)

We have two nrf52833dk_nrf52833 but they behave the same (as in, both display this anomaly regarding the shell sample/terminal)

As for terminal we also tried cutecom but there the issue was somehow even worse, with the first character always being lost.
es: sending "bdb" resulted in the device responding "db: command not found", sending "bbdb" instead returned the correct response message

Minicom instead displayed the same issue as Gtkterm, same for PuTTY

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Tue, 10 May 2022 08:54:12 GMT

Hi,

I have tried to reproduce your issue, but I have not been able to so far. Have you made any changes to the sample or any library or driver files used by the sample? Have you tested using a different DK and/or different terminal, i.e. PuTTY?

Best regards,

Marte

RE: Issues with shell not echoing / buffering input characters

Marte Myrvold — Mon, 09 May 2022 16:46:21 GMT

Hi,

I have started looking into your issue and will come back to you tomorrow.

Best regards,

Marte