mcumgr image upload fails

RE: mcumgr image upload fails

Menon — Tue, 01 Apr 2025 14:33:42 GMT

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

RE: mcumgr image upload fails

BobS — Wed, 26 Feb 2025 16:34:54 GMT

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

RE: mcumgr image upload fails

BobS — Thu, 20 Feb 2025 16:24:00 GMT

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.

RE: mcumgr image upload fails

BobS — Wed, 19 Feb 2025 20:09:25 GMT

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?

RE: mcumgr image upload fails

Menon — Wed, 19 Feb 2025 15:13:15 GMT

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

RE: mcumgr image upload fails

Menon — Mon, 17 Feb 2025 13:04:45 GMT

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

RE: mcumgr image upload fails

BobS — Wed, 12 Feb 2025 17:21:42 GMT

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

RE: mcumgr image upload fails

Menon — Wed, 12 Feb 2025 14:28:52 GMT

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

RE: mcumgr image upload fails

BobS — Tue, 11 Feb 2025 14:59:55 GMT

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

go: downloading mynewt.apache.org/newt v0.0.0-20201028015609-b57111dbd19f

go: downloading mynewt.apache.org/newtmgr v0.0.0-20201028150837-60b2da78788c

go: downloading github.com/sirupsen/logrus v1.5.0

go: downloading github.com/runtimeco/go-coap v0.0.0-20190911184520-8e5532820fc0

go: downloading github.com/spf13/cast v1.3.0

go: downloading github.com/spf13/cobra v0.0.5

go: downloading gopkg.in/abiosoft/ishell.v2 v2.0.0

go: downloading gopkg.in/cheggaaa/pb.v1 v1.0.28

go: downloading github.com/JuulLabs-OSS/ble v0.0.0-20200716215611-d4fcc9d598bb

go: downloading github.com/mitchellh/go-homedir v1.1.0

go: downloading github.com/pkg/errors v0.8.1

go: downloading github.com/joaojeronimo/go-crc16 v0.0.0-20140729130949-59bd0194935e

go: downloading github.com/tarm/serial v0.0.0-20180830185346-98f6abe2eb07

go: downloading golang.org/x/sys v0.0.0-20220608164250-635b8c9b7f68

go: downloading github.com/spf13/pflag v1.0.5

go: downloading github.com/abiosoft/readline v0.0.0-20180607040430-155bce2042db

go: downloading github.com/fatih/color v1.7.0

go: downloading github.com/flynn-archive/go-shlex v0.0.0-20150515145356-3f9db97f8568

go: downloading github.com/mattn/go-runewidth v0.0.6

go: downloading golang.org/x/net v0.0.0-20191119073136-fc4aabc6c914

go: downloading github.com/ugorji/go/codec v1.1.7

go: downloading github.com/ugorji/go v1.1.7

go: downloading github.com/fatih/structs v1.1.0

go: downloading github.com/mattn/go-colorable v0.1.6

go: downloading github.com/mattn/go-isatty v0.0.12

go: downloading github.com/mgutz/logxi v0.0.0-20161027140823-aebf8a7d67ab

go: downloading github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b

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

RE: mcumgr image upload fails

Menon — Tue, 11 Feb 2025 08:03:12 GMT

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