mcumgr image upload fails

[BobS]

Hi Sigurd,

I'm finally using the mcuboot and mcumgr_cli I worked on in summer of 2023. I generated the mcumgr_cli for debian with go lang back then.  I'm building my app for a Fanstel BT840F/E/XE (52840) with mcuboot in VScode.  The mcumgr commands work and flashes ok only if the "image list" shows "hash: Unavailable".  The upload command fails when the hash shows a value.

I've also noticed it seams to fail if the bootloader code is first loaded with J-Link (VScode or Connect Desktop Programmer).  Then it fails to load another app.  So I can load an older simple bootloader app with J-Link then it will boot-load my latest app and keep working.  But if I load it with VScode, it fails???  Please respond with a possible cause and what configuration might be missing? 

WORKS:

Feb 6 15:35:25 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli conn add acm0 type="serial" connstring="dev=/dev/ttymxc2,baud=1000000,mtu=512"
Feb 6 15:35:25 710-200-9992023 hub3-ble: Connection profile acm0 successfully added
Feb 6 15:35:25 710-200-9992023 hub3-ble:
Feb 6 15:35:25 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli -c acm0 image list
Feb 6 15:35:25 710-200-9992023 hub3-ble: Images:
Feb 6 15:35:25 710-200-9992023 hub3-ble: image=0 slot=0
Feb 6 15:35:25 710-200-9992023 hub3-ble: version: 0.0.0.0
Feb 6 15:35:25 710-200-9992023 hub3-ble: bootable: false
Feb 6 15:35:25 710-200-9992023 hub3-ble: flags:
Feb 6 15:35:25 710-200-9992023 hub3-ble: hash: Unavailable
Feb 6 15:35:25 710-200-9992023 hub3-ble: Split status: N/A (0)
Feb 6 15:35:25 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli -c acm0 image upload /data/fw_dnld/module/module_fw_3.0.2-90.bin
27.18 KiB / 244.32 KiB [===>-----------------------] 9.90% 10.74 KiB/s 00m20s
57.39 KiB / 244.32 KiB [=====>---------------------] 22.13% 11.03 KiB/s 00m16s
71.58 KiB / 244.32 KiB [========>-------------------] 29.30% 9.48 KiB/s 00m18s49% 11.25 KiB/s 00m16s
81.43 KiB / 244.32 KiB [=========>------------------] 32.93% 8.05 KiB/s 00m20s
91.60 KiB / 244.32 KiB [==========>-----------------] 37.22% 7.18 KiB/s 00m21ss
101.11 KiB / 244.32 KiB [===========>---------------] 41.39% 6.62 KiB/s 00m21s----] 37.49% 7.12 KiB/s 00m21s
110.30 KiB / 244.32 KiB [============>--------------] 44.88% 6.17 KiB/s 00m21s
119.49 KiB / 244.32 KiB [=============>-------------] 48.91% 5.85 KiB/s 00m21sB/s 00m21s
129.00 KiB / 244.32 KiB [==============>------------] 52.53% 5.61 KiB/s 00m20s-------------] 49.18% 5.83 KiB/s 00m21s
139.18 KiB / 244.32 KiB [===============>-----------] 56.56% 5.41 KiB/s 00m19s
148.04 KiB / 244.32 KiB [================>----------] 60.59% 5.26 KiB/s 00m18s% 5.41 KiB/s 00m19s
158.21 KiB / 244.32 KiB [=================>---------] 64.35% 5.13 KiB/s 00m16s
167.72 KiB / 244.32 KiB [==================>--------] 68.25% 5.01 KiB/s 00m15s
175.93 KiB / 244.32 KiB [===================>-------] 72.01% 4.90 KiB/s 00m14s-] 68.65% 5.01 KiB/s 00m15s
185.11 KiB / 244.32 KiB [====================>------] 75.37% 4.80 KiB/s 00m12s
194.32 KiB / 244.32 KiB [=====================>-----] 79.13% 4.71 KiB/s 00m10s 00m12s
202.50 KiB / 244.32 KiB [======================>----] 82.62% 4.64 KiB/s 00m09s====>-----] 79.53% 4.71 KiB/s 00m10s
212.35 KiB / 244.32 KiB [=======================>---] 86.65% 4.58 KiB/s 00m07s
221.21 KiB / 244.32 KiB [========================>--] 90.54% 4.53 KiB/s 00m05s.58 KiB/s 00m06s
230.39 KiB / 244.32 KiB [=========================>-] 94.03% 4.48 KiB/s 00m03s
240.24 KiB / 244.32 KiB [==================================] 98.20% 4.44 KiB/s
244.32 KiB / 244.32 KiB [==============================] 100.00% 4.42 KiB/s 55s=====] 98.33% 4.43 KiB/s
Feb 6 15:36:20 710-200-9992023 hub3-ble: Done
Feb 6 15:36:20 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli -c acm0 reset
Feb 6 15:36:20 710-200-9992023 hub3-ble: Done

FAILS:

Feb 7 16:29:37 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli conn add acm0 type="serial" connstring="dev=/dev/ttymxc2,baud=1000000,mtu=512"
Feb 7 16:29:37 710-200-9992023 hub3-ble: Connection profile acm0 successfully added
Feb 7 16:29:37 710-200-9992023 hub3-ble:
Feb 7 16:29:37 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli -c acm0 image list
Feb 7 16:29:37 710-200-9992023 hub3-ble: Images:
Feb 7 16:29:37 710-200-9992023 hub3-ble: image=0 slot=0
Feb 7 16:29:37 710-200-9992023 hub3-ble: version: 3.0.2
Feb 7 16:29:37 710-200-9992023 hub3-ble: bootable: false
Feb 7 16:29:37 710-200-9992023 hub3-ble: flags:
Feb 7 16:29:37 710-200-9992023 hub3-ble: hash: 560e0f34b1ac87683cae52d7e6ba2f872a5ff09273df2b15517d1e4407d810e9
Feb 7 16:29:37 710-200-9992023 hub3-ble: Split status: N/A (0)
Feb 7 16:29:37 710-200-9992023 hub3-ble: RUNNING ./mcumgr_cli -c acm0 image upload /data/fw_dnld/module/module_fw_3.0.2-90.bin
0 B / 244.31 KiB [----------------------------------------------------] 0.00%
0 B / 244.31 KiB [----------------------------------------------------] 0.00%
0 B / 244.31 KiB [----------------------------------------------------] 0.00%
0 B / 244.31 KiB [----------------------------------------------------] 0.00%
0 B / 244.31 KiB [----------------------------------------------------] 0.00%

I thought it might be an SDK incompatibility thing since I was using v2.3.0 when I generated the mcumgr_cli with go and now use v2.5.0.  I plan to bump that up when I get everything working. I also noticed this:

CMake Warning at C:/Hub3.0/BLE/module-ble/external/nrf/cmake/partition_manager.cmake:79 (message):

---------------------------------------------------------------------
--- WARNING: Using a bootloader without pm_static.yml. ---
--- There are cases where a deployed product can consist of ---
--- multiple images, and only a subset of these images can be ---
--- upgraded through a firmware update mechanism. In such cases, ---
--- the upgradable images must have partitions that are static ---
--- and are matching the partition map used by the bootloader ---
--- programmed onto the device. ---
---------------------------------------------------------------------

Bob

[Menon]

Hello,

I received an email from Wes Cherry stating that there is an issue responding to this thread. If the issue persists, I recommend opening a new case, attaching this case link, and I can take it from there to continue the discussion.

Coming back to the issue, what application are you using here? Have you tried any sample applications and were you able to reproduce the same issue? If you are working with Sigurd's sample, were you able to reproduce the issue with that sample as well?

I also recommend performing a full flash erase before flashing new firmware to avoid problems caused by leftover data.

Regarding the logs you shared, are you building a desktop app on Linux using GoLang?

Kind Regards,

Abhijith

[BobS]

I tried creating another issue, that failed also.

I'm using the same app that I started with: 

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery/mcuboot_serial_recovery_uart.

I'm building it with VScode.  If I configure it for sdk 2.3.0 it works, If I configure it for sdk 2.5.0, it fails.

But again: THE 2.5.0 IMAGE WILL BOOTLOAD OTHER IMAGES ONCE A GOOD 2.3.0 IMAGE IS FIRST FLASHED.

Can u replicate this problem?

[BobS]

This probably explains why a bootloader built with >SDK v2.3.0 fails with my mcumgr_cli built two years ago.

From the nRF Connect SDK v2.4.0 Release Notes...

Updated:

• The Device Firmware Upgrade MCUmgr module is used instead of the Simple Management Protocol module in MCUboot SMP configuration (prj_mcuboot_smp.conf) for the nRF52840 DK.

And VSCode says the referenced kconfig options are undefined symbols?

CONFIG_DESKTOP_DFU_LOCK=n

CONFIG_DESKTOP_DFU_MCUMGR_ENABLE=n

So is there a way to turn all this crap off or do I have rebuild the mcumgr.  It was quit involved and as far as I know, it uses SMP.  I could really use some help understanding all this.

[BobS]

I found another clue/solution.  I've been using an mcumgr_cli I thought I built, for Debian, with this change to boost the baud rate:

 MCUBOOT slow with nRF52840 / Zephyr / USB CDC_ACM protocol 

So with two mcumgr-cli utilities, (cant remember which is which, and havent rebuilt them) one works with a sdk 2.3.0 mcuboot but fails with a 2.5.0 mcuboot..  This sdk difference was very misleading and I still know why.  And to further complicate things, the mtu setting for the mcumgr-cli serial conn setup also determines whether it works, even for the 2.3.0 bootloader. 

Bottom line is I can use the "working" mcumgr_cli utility with a 2.5.0 mcuboot and mtu=1024 to dfu my 244kB in only about 1m 10s.  Instead of 5m 2s for mtu=512.

I plan to use a different smp client and upgrade the sdk, just wanted everything working before any changes.  Can u recommend an SMP client for a small Debian board and point me to any relevant changes with mcuboot for a higher sdk?  Thanks.

Bob

[Menon]

Hello,

Apologies for the delayed response.

Unfortunately, I do not have experience working with Debian boards, and I do not have any specific references for using smp_client with them. I hope you’ve been able to make some progress in the meantime.

If you're planning to update the SDK version and are looking for the relevant changes introduced, I would recommend reviewing the Release Notes . Additionally, the Migration Guide can provide valuable insights into configuration changes and help you better understand what adjustments may be needed.

Kind Regards,

Abhijith