This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issues with shell not echoing / buffering input characters

Greetings.

We are using the zigbee/shell sample in order to verify the connectivity of some other devices running the zigbee stack. While the shell sample had no issues in the past (circa tag v1.8.0) now we see a odd behavior in which the characters inputted in the terminal emulator (gtkterm) appear "delayed" by one character. We tried rolling back to v1.8.0 as were using the 1.9.1 tag in case that was the issue but the problem persisted. As such we do not fully know if the problem resides in the sdk, zephyr or our machine

As an example:


-checkout v1.8.0


-download shell sample


-open gtkterm and connnect to tty/ACM0


-press reset button on the board, board sends the opening message (*** Booting Zephyr OS build v2.7.99-ncs1-1  *** followed by  uart:~$ )


-press the "a" key, the character "a" appears on the screen


-press the "b" key, the character "a" appears on the screen


-press the "c" key, the character "b" appears on the screen


-press the "enter" key, the character "c" appears on the screen


-press the "d" key, the "enter" is parsed and the device replies with "aabc: command not found"

-press the "e" key, the character "d" appears on the screen

And so on and so forth, this makes it very difficult to employ the shell sample for verifying our devices.

Parents
  • Hi,

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

    Best regards,

    Marte

  • 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

  • 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)

  • Hi,

    Isaia F said:
    I flashed the .hex via the nrf Programmer v3.0.0 but once again the issue presented itself,

    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?

    Isaia F said:
    we have attempted to use RTT by changing the options via ninja guiconfig, however while RTTViewer seems to be able to send the message

    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

  • 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

  • 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

  • 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

Reply
  • 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

Children
  • 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

  • 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

  • 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.

    1. Download the JLink interface MCU firmware from nRF52833 DK > Downloads.
    2. Unplug the DK from the computer.
    3. 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.
    4. The device should show up as BOOTLOADER.
    5. Drag and drop the firmware image into the DK.

    Best regards,

    Marte

  • 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?

  • Hi,

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

    Best regards,

    Marte

Related