• State Verified Answer
  • Locked Locked
  • Replies 15 replies
  • Subscribers 25 subscribers
  • Views 389 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 288757
Options
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

user111592

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 Reply
  • 0 in reply to user92402

    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

Children
  • 0 in reply to user92402

    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

  • 0 in reply to user111592

    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


  • 0 in reply to user92402

    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)

  • 0 in reply to user111592

    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

  • 0 in reply to user92402

    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

Related
Terms of service