Image upload over MCUBoot serial recovery not bootable

RE: Image upload over MCUBoot serial recovery not bootable

Adrian Eggenberger — Mon, 23 Jun 2025 13:56:34 GMT

:-) That was a nice trick. It works when aplied as you said. As soon as I moved the folder to a subdirectory and renamed it it didn't work somehow. Anyway I use it as proposed by now.

Thanks for your support.

RE: Image upload over MCUBoot serial recovery not bootable

Håkon Alseth — Mon, 23 Jun 2025 13:02:58 GMT

Hi,

Glad to hear that this has improved the scenario.

The USB transport has a 64 byte EP, which means that increasing the MTU size will effectively send 'n' amount of packets of 64 bytes.

As you shared, there's two methods of improving speed:

1. increase mtu

2. decrease dwell-time between each requested MTU.

[quote user="Adrian"]I've one thing that is not working. We have own implementaiton for the serial number over USB. In the MCUboot at the moment we have the default USB serial number. How can I override weak methods (e.g. "usb_update_sn_string_descriptor" in my mcuboot image? All attempts I've made did not work.[/quote]

The default behavior is that the function reads out the FICR.DEVICEID and applies this as the serial number:

https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/usb/device/usb_descriptor.c#L328-L355

I checked around with colleagues, and there is no straight-forward way to add a .c file to mcuboot without forking the repo.

So, I did an exercise to bend sysbuild a bit.

What you can do is to workaround this by treating your .c file as a out-of-tree driver specific to mcuboot.

Create sysbuild.cmake file containing:

set(mcuboot_EXTRA_ZEPHYR_MODULES "${CMAKE_CURRENT_LIST_DIR}/test_usb_sn_override" CACHE INTERNAL "test_module directory")

Then handle "test_usb_sn_override" as a out-of-tree directory by specifying test_usb_sn_override/zephyr/module.yml:

build:
  cmake: .
  kconfig: Kconfig

Then add a small conditional in test_usb_sn_override/CMakeLists.txt:

if(DEFINED CONFIG_BOOT_SERIAL_CDC_ACM)
    message("Adding override function for USB serial number")
    zephyr_library_sources(test.c)
endif()

Where test.c holds:

#include <zephyr/sys/byteorder.h>
#include <zephyr/sys/__assert.h>
#include <zephyr/usb/usb_device.h>

uint8_t *usb_update_sn_string_descriptor(void)
{
	/* SN is 16 bytes */
	static char hex[] = "CAFECAFECAFECAFE";
	return (uint8_t*)hex;
}

lsusb -d 2fe3:0100 -v

Bus 001 Device 042: ID 2fe3:0100 NordicSemiconductor MCUBOOT
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x2fe3 NordicSemiconductor
  idProduct          0x0100 MCUBOOT
  bcdDevice            4.00
  iManufacturer           1 ZEPHYR
  iProduct                2 MCUBOOT
  iSerial                 3 CAFECAFECAFECAFE
  ...

Here's a hello_world that does this:

devzone.nordicsemi.com/.../hello_5F00_world_5F00_sysbuild_5F00_mcuboot_5F00_override_5F00_usb_5F00_sn2.zip

I used the nrf7002dk board for this exercise, so the board files in sysbuild/mcuboot/boards must be altered to match your chosen one.

PS: remove sysbuild.conf "SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=y" if testing on nRF5340.

Kind regards,

Håkon

RE: Image upload over MCUBoot serial recovery not bootable

Adrian Eggenberger — Sun, 22 Jun 2025 20:17:59 GMT

Increasing the MTU did have also a hugh impact. That's fine for now. We will probably go with an MTU of 512. It works now almost as expected.

I've one thing that is not working. We have own implementaiton for the serial number over USB. In the MCUboot at the moment we have the default USB serial number. How can I override weak methods (e.g. "usb_update_sn_string_descriptor" in my mcuboot image? All attempts I've made did not work.

RE: Image upload over MCUBoot serial recovery not bootable

Håkon Alseth — Fri, 20 Jun 2025 10:00:44 GMT

Hi,

[quote user="Adrian"]Somehow only MTU sizes up to ~130 work.[/quote]

I believe this can be changed via mcuboot's CONFIG_BOOT_MAX_LINE_INPUT_LEN.

[quote user="Adrian"]The baudrate seems to be irrelevant. [/quote]

Yes, you're right. With CDC, this has no effect on the overall transmission. Sorry for the confusion.

[quote user="Adrian"]What MTU size does the nRF Connect Programmer use?[/quote]

it uses nrfutil to write the image:

https://github.com/NordicSemiconductor/pc-nrfconnect-programmer/blob/main/src/actions/mcubootTargetActions.ts#L71-L81

I believe that the mtu does not have much of an effect here, it is more related to timing between each packet.

Did you try the fix proposed in the former linked thread? ie. reduce the wait-time between each payload?

Kind regards,

Håkon

RE: Image upload over MCUBoot serial recovery not bootable

Adrian Eggenberger — Thu, 19 Jun 2025 19:19:48 GMT

Somehow only MTU sizes up to ~130 work. With higher values it doesn't work. What MTU size does the nRF Connect Programmer use? The baudrate seems to be irrelevant. That could be because it is a virtual Uart device?

RE: Image upload over MCUBoot serial recovery not bootable

Håkon Alseth — Thu, 19 Jun 2025 16:39:03 GMT

Hi,

[quote user="Adrian"]Currently we get 3.5kB/s with the newtmgr client.[/quote]

This might be a "feature" of the newtmgr CLI tool, as it seems to have a larger sleep between each payload:

RE: MCUBOOT slow with nRF52840 / Zephyr / USB CDC_ACM protocol

[quote user="Adrian"]Is there something that can be configured around the MTU size? [/quote]

You could adjust the mtu via the connstring:

--connstring=COMx,baud=115200,mtu=512

Another option would also be to adjust the baudrate.

Kind regards,

Håkon

RE: Image upload over MCUBoot serial recovery not bootable

Adrian Eggenberger — Thu, 19 Jun 2025 15:46:23 GMT

1) I think it's ok. As it is only a single image setup the mechanisms that are used over BLE with MCUBoot (Pending,Confirm,Hash, etc.) are not necessairy.

2) Currently we get 3.5kB/s with the newtmgr client. With the nRF Connect Programmer App it the throughput is around 10kB/s. It's ok, but a bit more would be nice.
Is there something that can be configured around the MTU size? With the newtmgr tool a MTU can be selected, but I don't know what the max supported value would be.

RE: Image upload over MCUBoot serial recovery not bootable

Håkon Alseth — Thu, 19 Jun 2025 12:40:43 GMT

Hi Adrian,

[quote user="Adrian"]Thanks for the input. That was the problem. After using the "build-folder/application-name/zephyr/zephyt.signed.bin" file it worked as expected. It also works with nRF Connect Desktop Programmer MCUBoot Support, but then the "build-folder/application-name/zephyr/zephyt.signed.hex" file needs to be used.[/quote]

Yes, it is true that the mcumgr/newtmgr takes in a binary file, while our nRF tools primarily favors .hex files. In this case, a dfu_application.zip file can also be used for the nRF Programmer application.

[quote user="Adrian"]
1) What isn't there a hash or bootable flag in the MCUboot image? I see this info with the "image list" command.
The output then is:
Images:
image=0 slot=0
version: 2.1.2
bootable: false
flags:
hash: Unavailable
Split status: N/A (0)[/quote]

mcuboot serial recovery is a function that does not provide boot flags or similar options, and it also does not provide you with a hash of the img.

This is typically aimed towards a failsafe, where you want to overwrite the whole of the application with a new one, either for recovery purposes or upgrade purposes. This will check the signature, and apply if verified.

[quote user="Adrian"]2) Are there any options to increase the speed for the download?[/quote]

What is the current speed that you're seeing?

Kind regards,

Håkon

RE: Image upload over MCUBoot serial recovery not bootable

Adrian Eggenberger — Thu, 19 Jun 2025 04:54:02 GMT

Hi Hakon

Thanks for the input. That was the problem. After using the "build-folder/application-name/zephyr/zephyt.signed.bin" file it worked as expected. It also works with nRF Connect Desktop Programmer MCUBoot Support, but then the "build-folder/application-name/zephyr/zephyt.signed.hex" file needs to be used.

Why does the nRF Connect App need a different file? I assume it uses the same SMP protocol "image upload" commands to download the application to the device in MCUboot.

Maybe you can give me a short info about theses related questions:

1) What isn't there a hash or bootable flag in the MCUboot image? I see this info with the "image list" command.
The output then is:
Images:
image=0 slot=0
version: 2.1.2
bootable: false
flags:
hash: Unavailable
Split status: N/A (0)

2) Are there any options to increase the speed for the download?

Regards Adrian

RE: Image upload over MCUBoot serial recovery not bootable

Håkon Alseth — Wed, 18 Jun 2025 10:36:35 GMT

Hi,

[quote user=""]By pressing the Button 1 on startup I'm able to enter the MCUBOOT serial revovery now. Also reading the image status work properly. But if I download the created "dfu_application.zip" file by using the newtmgr CLI client the system shows me on RTT log the there is no startable image found. Somehow the downloaded image is not startable.[/quote]

I haven't used the mynewt CLI tool, but I believe mcumgr requires that you give in a .bin file.

Could you try to transfer the build-folder/application-name/zephyr/zephyt.signed.bin file and see if this runs as expected afterwards?

Kind regards,

Håkon