• State Verified Answer
  • Locked Locked
  • Replies 15 replies
  • Subscribers 25 subscribers
  • Views 387 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.

  • 0

    Hi,

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

    Best regards,

    Marte

  • 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

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

Related
Terms of service