NMP timeout error with SMP sample / mcumgr on nrf52840dk

SUMMARY

Attempting to OTA the nrf52840dk over BLE.

I was able to perform most of the steps in this sample: https://docs.nordicsemi.com/bundle/ncs-2.1.4/page/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html

However, when running the image upload command
mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image upload /Users/username/project/Code/SW/build/zephyr/zephyr.signed.bin -lDEBUG
I get an NMP timeout error approximately 15% of the way through the upload: HandleError off 38159 error NMP timeout
I assume this means the DK did not respond in time, but I'm not sure what would cause this error.

STEPS

Most of the steps in the sample were followed, however
The sign command required a header and padding to be specified. The command was edited to:
west sign -t imgtool -- --key /opt/nordic/ncs/v2.6.1/bootloader/mcuboot/root-rsa-2048.pem --header-size 32 --pad-header
This command appears to complete successfully and generates a new zephyr.signed.bin

Initially, running the command 

mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image upload /Users/username/project/Code/SW/build/zephyr/zephyr.signed.bin -lDEBUG

gave errors as in this post:  Solution: mcumgr not working in MacOs  (which by the way will NOT appear in search if you paste the error). Following the steps in this post resolved the issue.

Running the mcumgr echo command or image list commands both work.

However, running the image upload command as above gives the NMP error:
DEBU[2024-09-06 03:23:04.42] {remove-nmp-listener} [.:0] seq=47           
DEBU[2024-09-06 03:23:04.42] HandleError off 76071 error NMP timeout 

ATTEMPTS:
- Tried changing the clock source as described in mcumgr communication times out with NMP when nRF5340 supports DFU.although AFAIK the DK has an external crystal. No change. 
- Tried increasing stack sizes in prj.conf, no change:

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4608
CONFIG_MAIN_STACK_SIZE=4096

- Tried increasing global log level to 4 in prj.conf, this I assume used too much memory and would just boot loop. Using 3 gave no insight into the issue.

CONFIG_LOG_OVERRIDE_LEVEL=3

- Any number of pristine builds / reflashes / board recoveries or clears etc.

- Increasing timeout and retries: mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image upload /Users/username/project/Code/SW/build/zephyr/zephyr.signed.bin -lDEBUG -t 20 -r 3

None of the above changed the behavior.

SETUP

- I'm using an nrf52840 devkit.

- ncs was newly updated to 2.6.1, build command is therefore

- west build \                                                                                                                                        
   -b nrf52840dk_nrf52840 \
   /opt/nordic/ncs/v2.6.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr \
   -- \
   -DOVERLAY_CONFIG=overlay-bt.conf

-Attached are the build/zephyr/zephyr.dts, build/zephyr/.config, and /opt/nordic/ncs/v2.6.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/prj.conf, which I modified.
- Also attached are snips from the output of the mcumgr image upload command and a snip from connecting to the DK over USB with the vscode extension.

5852.nordic_help.zip

Parents Reply Children
  • Hello,

    Thanks for the pointers. I will go through them in detail this week and report back.

    Glancing at the "FOTA over Bluetooth Low Energy" section of the course, it appears that either the Device Manager mobile app or the mcumgr tool is recommended. I'm using mac currently and we must be able to use BLE - I can try AuTerm and the mcumgr-web to see if that changes behavior, if you believe the issue lies on the desktop side rather than the device side. At one point in the past I was able to FOTA with some example using device manager (I cannot recall the specifics).

    The eventual goal is to provide our customers with an NRF52840 device, along with a mobile app and desktop which should be able to execute a BLE FOTA with the device.

    For the mobile app, it appears we can use the nRF connect device manager (library). Is this correct? Do you have any guidance for a universal desktop solution? The mcumgr page mentions a "universal replacement" - is there any notion when this would be released?

  • frankenboom said:
    if you believe the issue lies on the desktop side rather than the device side.

    I think it is more likely that it is device side.

    Our mobile app is very stable, so if it fails with this, it is likely the device.

    frankenboom said:
    For the mobile app, it appears we can use the nRF connect device manager (library). Is this correct?

    Yes

    frankenboom said:
    Do you have any guidance for a universal desktop solution? The mcumgr page mentions a "universal replacement" - is there any notion when this would be released?

    In fact, this mention was removed in Upstream documentation lately: https://github.com/zephyrproject-rtos/zephyr/commit/1906ab33da8970f4098bcacba11cd5f35e572754

    I think the note refers to the list of new tools now available, and that you can choose which of them fits your use-case best.

Related