Attachments (0)
Nordic Case Info
  • Case ID: 281137
Options

Shell/UART (Jlink CDC ADM) RX Issue

zoob

Hi All,

I have a project which uses the zephyr shell, but I can reproduce the issue with zephyr/samples/subsys/shell/shell_module or any other sample making use of the UART input functionality sample. The sample appears to run correctly but when I input a character into the serial port (using minicom) it does not register it until the next one is input at which point it will echo the first character. This is only happening on 1 out of my 2 dev kits (nrf52840dk) despite flashing the exact same image. 

This seems to have happened after upgrading the project to Zephyr 2.7.0 which had some USB changes, I had to fumble a bit with the settings (switching between UART & USB CDC) to get it building and running again.  But even when I downgrade to a previous version of nRF Connect SDK ( with Zephyr 2.6.99 which worked) it does not recover.

I have tried multiple PCs, and cables but I am unable to track down the configuration option but it seems like there is something persistent on one of the devices (perhaps in the Jlink driver?). I have tried to do `nrfjprog -e` on the affected device, even flashed the RSSI FW before switching back but still unable to fix this. I've gone into the SEGGER J-flash interface and erased everything also. Does any one have advice on what I can do to remedy this issue?

  • 0

    I was able to reproduce this issue on my other nrf52840dk board by simply flashing the zephyr/samples/subsys/shell/shell_module sample from the main branch of nrf connect sdk which uses zephyr from about tag v2.7.0-ncs1-rc2. So it looks like its unrelated to my project but simply using the latest ncs. Going back to an older version of the ncs does not fix this behavior so I'm guessing some settings persist (in the softdevice?). 

  • 0

    I checked with a logic analyzer, using an FTDI -> uart1 it works perfectly fine. The jlink ACM (uart0), however, fails to send the first character correctly. Seems the issue is with Jlink? I am sending the data using the exact same command to both interfaces python -c "import serial; s = serial.Serial('/dev/ttyACM0', baudrate=115200); s.write(b'help\r')"

    FTDI -> uart1

    Jlink ACM -> uart0

  • +1

    With the help of the Zephyr community I figured out that the issue is with the latest FW bundled with J-Link Software and Documentation Pack. This FW gets updated automatically (did not realize this) and that is why the issue persisted. 

    The fix for me is to use the Jlink FW bundled with J-Link Software and Documentation 7.58d which include FW J-Link OB-SAM3U128-V2-NordicSemi compiled Feb  2 2021 16:47:20. 

    J-link 7.58e & 7.60 contain FW J-Link OB-SAM3U128-V2-NordicSemi compiled DEC  3 2021 15:41:28 which was broken for me.

  • 0 in reply to zoob

     I came across the same issue with the Segger FW. The UART through USB CDC ACM somewhat works...but not perfectly enough. Sometimes characters get stuck or lost in the internal buffer of Segger, it seems.

     Part of my issues with the SMP Srv sample was caused by this buggy JLINK FW. I program the SMP SRV sample with serial support overlays - 

    as per instructions:

    west build \ -b frdm_k64f \ samples/subsys/mgmt/mcumgr/smp_svr \ -- \ -DOVERLAY_CONFIG='overlay-serial.conf;overlay-fs.conf;overlay-shell-mgmt.conf'



    Then if I update my Segger to the version provided in Segger software package 7.60d using the configurator, I can't get MCUMGR responses for echo or "image list" command.
    If I downgrade Segger FW to version provided in 7.58d everything works.

    Frustrating because I spent hours trying to figure out why SMP wasn't working on my custom FW - changing stacks and KCONFIG settings.. then realized it is the Segger FW.

    Does Nordic release this FW or Segger? Are they informed of this bug?

  • 0 in reply to Farhang

    Hi ,

    Glad this helped you out! I understand your frustration as I myself faced this issue for a few days before I was able to figure out what happened. 

    Does Nordic release this FW or Segger?

    I believe this FW is released by Segger, it is bundled with https://www.segger.com/downloads/jlink/. Looking at the release notes I think this is the offending change

     

    I've been keeping an eye out on the release notes but haven't seen any further updates to this particular firmware so I can only assume it has not been fixed.

    Are they informed of this bug?

    I personally did not inform them, I replied with my solution/answer in this thread because it was the first place I started looking incase others experienced this before me. Perhaps I wrongly assumed that this issue would have been reported by others and promptly fixed by Segger.

1 2
Terms of service