mcumgr image upload fails

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

  • Hello,

    Correct me if I’m wrong in what I understood. Your mcumgr_cli was built using NCS v2.3.0, but your current project uses v2.5.0. Is that right? If so, I suspect the issue might be related to signing and versioning. As far as I remember, v2.5.0 introduced a version file, see this documentation. Try rebuilding mcumgr_cli with v2.5.0.

    Kind Regards,

    Abhijith

  • I don't think that's the problem.  I am using that VERSION Zephyr API and understand it wasn't available in v2.3.0.  But neither that nor your sdk are involved when building an SMP client as far as I can tell:

    root@710-002-hub3008:~/mcumgr-cli/mcumgr# go build
    <br>go: downloading mynewt.apache.org/newt v0.0.0-20201028015609-b57111dbd19f
    <br>go: downloading mynewt.apache.org/newtmgr v0.0.0-20201028150837-60b2da78788c
    <br>go: downloading github.com/sirupsen/logrus v1.5.0
    <br>go: downloading github.com/runtimeco/go-coap v0.0.0-20190911184520-8e5532820fc0
    <br>go: downloading github.com/spf13/cast v1.3.0
    <br>go: downloading github.com/spf13/cobra v0.0.5
    <br>go: downloading gopkg.in/abiosoft/ishell.v2 v2.0.0
    <br>go: downloading gopkg.in/cheggaaa/pb.v1 v1.0.28
    <br>go: downloading github.com/JuulLabs-OSS/ble v0.0.0-20200716215611-d4fcc9d598bb
    <br>go: downloading github.com/mitchellh/go-homedir v1.1.0
    <br>go: downloading github.com/pkg/errors v0.8.1
    <br>go: downloading github.com/joaojeronimo/go-crc16 v0.0.0-20140729130949-59bd0194935e
    <br>go: downloading github.com/tarm/serial v0.0.0-20180830185346-98f6abe2eb07
    <br>go: downloading golang.org/x/sys v0.0.0-20220608164250-635b8c9b7f68
    <br>go: downloading github.com/spf13/pflag v1.0.5
    <br>go: downloading github.com/abiosoft/readline v0.0.0-20180607040430-155bce2042db
    <br>go: downloading github.com/fatih/color v1.7.0
    <br>go: downloading github.com/flynn-archive/go-shlex v0.0.0-20150515145356-3f9db97f8568
    <br>go: downloading github.com/mattn/go-runewidth v0.0.6
    <br>go: downloading golang.org/x/net v0.0.0-20191119073136-fc4aabc6c914
    <br>go: downloading github.com/ugorji/go/codec v1.1.7
    <br>go: downloading github.com/ugorji/go v1.1.7
    <br>go: downloading github.com/fatih/structs v1.1.0
    <br>go: downloading github.com/mattn/go-colorable v0.1.6
    <br>go: downloading github.com/mattn/go-isatty v0.0.12
    <br>go: downloading github.com/mgutz/logxi v0.0.0-20161027140823-aebf8a7d67ab
    <br>go: downloading github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b
    <br>root@710-002-hub3008:~/mcumgr-cli/mcumgr#
    Like I said, once a working MCUboot app (v2.3.0) is flashed, all v2.5.0 projects, built with MCUboot, continue to bootload over and over. But if I first flash a 2.5.0 project with J-Link, it fails???
    What I do see when it doesn't work is the partition manager message.  I'm researching that, I appreciate any input.

    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. ---
    ---------------------------------------------------------------------

    Thanks,
    Bob
  • Hello,

    From the warning message you shared:
    Since the pm_static.yml file is not present, partitions may be dynamically assigned, leading to differences in bootloader expectations. You could try creating a static partition (pm_static.yml) and see if that resolves the issue.

    Kind Regards,
    Abhijith

  • I already tried that per Sigurds post.  It doesnt work.

  • Hello,

    Are you still receiving this warning even after adding the pm_static file? The warning should not appear if the pm_static file is present and configured correctly. Have you checked if the pm_static file is being reflected during the build process?

    Kind regards,
    Abhijith

Related