Issues with MCUmgr over serial with nRF52 devkit/J-Link

I am currently experiencing an issue using MCUmgr CLI over a serial connection provided by the on-board J-Link debuggers on nRF52 devkits.

When using MCUmgr CLI to send smaller simpler commands like echo and image list to the devkit, the first one succeeds but all subsequent commands result in an NMP timeout. I will need to disconnect and reconnect the nRF52 devkit for the first command to succeed again. When attempting to actually update an image, it will never pass 0%.

There are no issues when I try this same process using our production board with direct access to the UART interface through a CP2105 USB-to-UART bridge.

I suspect it has something to do with the serial comms being routed through the J-Link. Some timing/buffer limitation issues? I have tried different variations of the mtu=xxx parameter but no success unfortunately. I have also tested on Linux and macOS, but not Windows.

I appreciate this is likely more of an MCUmgr issue, but I guessed since it involved the onboard J-Link on the nRF52 devkits perhaps you have some previous experience. 

Parents Reply Children
  • Hi,

     

    If you have issues with the usb-serial bridge in the debugger, it might be beneficial to disable the mass storage device in the debugger itself.

    This is done by opening J-Link Commander (JLinkExe on mac/linux) and writing:

    msddisable

    Remember to power cycle the board afterwards before testing again.

     

    Kind regards,

    Håkon

  • Yes, I have done this already. This is one of the first things I do with a new devkit.

    I have also tried different MTU sizes in the mcumgr connection parameters, but no luck.

    I saw your post on this similar issue, I will try your suggestion here and see if it works.

  • Hi,

     

    FARLY7 said:
    I saw your post on this similar issue, I will try your suggestion here and see if it works.

    That is specifically for the nrf9160dk_nrf9160_ns target.

    I have seen similar issues in the past myself and disabling the MSD has usually been the fix.

    I just tested ncs v1.8.0 and ncs v1.9.0, with board nrf52dk_nrf52832, stock smp_svr (w/overlay-serial.conf):

    $ mcumgr --conntype serial --connstring /dev/ttyACM0 image upload zephyr/app_update.bin
     48.14 KiB / 48.14 KiB [====================================================================================] 100.00% 3.46 KiB/s 13s
    Done
    

    image list shows: 

    Images:
     image=0 slot=0
        version: 0.0.0
        bootable: true
        flags: active confirmed
        hash: ed10f5869785d67af2fa7d416016a6836c78c6254cd330b4446ba21b316ac2e4
     image=0 slot=1
        version: 0.0.0
        bootable: true
        flags: 
        hash: 1ffb1291735140f39b1ba1f920b14e07e26136abde2d92109ddacbd047d509a7
    Split status: N/A (0)
    

      

    Do you see the same behavior on other PCs as well?

     

    Kind regards,

    Håkon

  • Hi Hakon,

    I just tried the suggestion from your answer in the other issue thread, and this worked.

    I will also test the smp_svr example again like you did. A little bit more investigation is required on my side to clarify where the issue is and how it is fixed.

    Thanks,

    Sean

  • Hi,

     

    FARLY7 said:
    I just tried the suggestion from your answer in the other issue thread, and this worked.

    This is interesting!

    Was the CONFIG_HEAP_MEM_POOL_SIZE set to non-zero value prior to adjusting it?

     

    Kind regards,

    Håkon

Related