Firmware updates via the serial port without loosing half the code space

[dwalton65]

SDK Environment: nRF Connect SDK v1.8.0
Target: Decawave DWM1001-DEV. This uses the nRF52832

My application uses more than half the flash size of the nRF52832.

Using mcuboot and smp it appears you need to have a working slot and a download slot for the firmware. I believe smp can not update the working slot. This means the firmware can only be a little less than half the size of the flash.

The only solution I have come up with so far, is to use mcuboot in serial recovery mode with CONFIG_SINGLE_APPLICATION_SLOT=y. The issue with this is that mcuboot in serial recovery mode only supports a subset of commands. mcumgr.exe" --conntype=serial --connstring=COM8 image list does not give the hash value, and so far I can't get version to display as anything other than "0.0.0.0".

Are there any better ways of implementing a serial boot loader for the nRF52832?

I have attached my current complete test project:

5165.hello-world.zip

Note the file "CMakeLists.txt" contains a file link with an absolute path that includes the ncs version. See my other post here about that issue.

Key created using

python \ncs\v1.8.0\nrf\scripts\bootloader\keygen.py --private -o test-key.pem

Built using

west build -b decawave_dwm1001_dev2 --pristine -d build2 /ncs/myapps/bootloader/hello-world -- -DBOARD_ROOT=/ncs/myapps/bootloader/hello-world

Programmed to the device using

west flash --runner nrfjprog --bin-file build/zephyr/app_update.bin -d build2

Firmware updates via the serial port using

mcumgr.exe --conntype=serial --connstring=COM8 image upload build2\zephyr\app_update.bin

[Elfving]

Hello David!

Unfortunately we don't provide any other alternative to what you mentioned.

If you need support for more commands those needs to be ported from the generic mgmt subsystem, but that is not trivial since mcuboots port is mostly written from scratch. However, setting the application version should work, see here for info on how.

It doesn't seem like you have set CONFIG_MCUBOOT_IMAGE_VERSION anywhere in your test project.

Best regards,

Elfving

[dwalton65]

It now turns out that one of the devices I am working on does not have any buttons, so unfortunately that counts out serial recovery mode.

I had a similar problem with a project using the esp32. With this device the two image slots do not have to be equal size. The first smaller slot contained a small image that used the equivalent of SMP. The main project went into the second larger slot. When a request to upgrade firmware was detected, the main image in the second slot would mark its image as invalid and then reboot. The processor would then run the only valid image left which was the smaller image that had the equivalent of SMP available.

[Elfving]

Hello David,

dwalton65 said:

The version is displaying correctly in serial recovery mode, but not the flags or the hash.

I believe flags and hash should be supported on serial recovery as well, but it probably hasn't been implemented in order for the code to be minimal. When you use serial recovery you probably wouldn't care what the version was anyway. This is recovery, so you are in a bad state and want out of it, and will upload the latest, or upload it from another device (in which you would manage the versions anyway, so why duplicate this effort). In the case of dev-to-dev upload the version is allready overkill. SHA is mainly useful for tests because the user should use some versioning, rather than relying on the SHA, which is read from a header and not calculated on the device.

You could implement all of this, SHA reading etc., using KConfig options, but it will take more space. The new use for recovery, where you are actually using it for direct DFU, from PC, rather than other dev, and manage software that way should work fine with versions, and does not seem to require hash; the hash will not fix user's configuration management where same app versions have different hashes.

dwalton65 said:

It now turns out that one of the devices I am working on does not have any buttons, so unfortunately that counts out serial recovery mode.

I see. Considering flash size issues I should also mention that there are some updates that are coming with NCS 1.9 that might shrink the Soft Device Controller, depending on your application.

Best regards,

Elfving