Image upload over MCUBoot serial recovery not bootable

[Adrian Eggenberger]

Hi

I've an application running on nRF Conenct SDK 3.0.2 on an nRF52840DK. Now I tried to enable update support over serial recovery of MCUBoot using the USB ACM.

First I've setup sysbuild to use MCUboot in sysbuild.conf file:

# Enable bootloader with dedicated bootloader image
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=y

In the configuration for the mcuboot image (sysbuild/mcuboot/prj.conf) the following configuration was added:

CONFIG_PM=n

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x20000

CONFIG_MAIN_STACK_SIZE=10240

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n

CONFIG_BOOT_ENCRYPT_IMAGE=n

CONFIG_BOOT_UPGRADE_ONLY=n

CONFIG_BOOT_BOOTSTRAP=n

### mbedTLS has its own heap

# CONFIG_HEAP_MEM_POOL_SIZE is not set

### We never want Zephyr's copy of tinycrypt.  If tinycrypt is needed,

### MCUboot has its own copy in tree.

# CONFIG_TINYCRYPT is not set

# CONFIG_TINYCRYPT_ECC_DSA is not set

# CONFIG_TINYCRYPT_SHA256 is not set

CONFIG_FLASH=y

CONFIG_FPROTECT=y

### Various Zephyr boards enable features that we don't want.

# CONFIG_BT is not set

# CONFIG_BT_CTLR is not set

# CONFIG_I2C is not set

CONFIG_LOG=y

CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL

### Ensure Zephyr logging changes don't use more resources

CONFIG_LOG_DEFAULT_LEVEL=0

### Use info log level by default

CONFIG_MCUBOOT_LOG_LEVEL_INF=y

### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y

CONFIG_CBPRINTF_NANO=y

### Use the minimal C library to reduce flash usage

CONFIG_MINIMAL_LIBC=y

CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0

# NCS boot banner

CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="MCUboot"

# Partition table set by pm_static.yml

# CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x20000

CONFIG_GPIO=y

CONFIG_SINGLE_APPLICATION_SLOT=y

# CONFIG_BOOT_SWAP_USING_MOVE=y

# Enable MCUboot Serial Recovery

CONFIG_MCUBOOT_SERIAL=y

CONFIG_BOOT_SERIAL_UART=y

CONFIG_UART_CONSOLE=n

# Point Serial Recovery to CDC_ACM

CONFIG_BOOT_SERIAL_CDC_ACM=y

# Enable Serial Recovery by Button

CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=n

CONFIG_BOOT_SERIAL_ENTRANCE_GPIO=y

# USB configuration

CONFIG_USB_DEVICE_VID=0x1915

CONFIG_USB_DEVICE_PID=0x5300

 

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.

Anyone had success with getting serial recovery with MCUBoot working? What could be wrong?

[Håkon Alseth]

Hi,

 

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.

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

[Adrian Eggenberger]

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

[Håkon Alseth]

Hi Adrian,

Adrian Eggenberger said:

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.

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.

Adrian Eggenberger said:

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)

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.

Adrian Eggenberger said:

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

What is the current speed that you're seeing?

 

Kind regards,

Håkon

[Adrian Eggenberger]

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.

[Håkon Alseth]

Hi,

 

Adrian Eggenberger said:

Currently we get 3.5kB/s with the newtmgr client.

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 

Adrian Eggenberger said:

Is there something that can be configured around the MTU size?

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

[Adrian Eggenberger]

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?