mcumgr image confirm returns error 3 while following the "Add DFU support to your application" walk-through (serial DFU)

[laurentc]

Add DFU support to your application walk-through
devzone.nordicsemi.com/.../ncs-dfu
Serial DFU chapter
Fails on a nRF52840 DK (with one HW change)
With error 3 on image confirm using mcumgr

All the previous steps seem fine.

nrf connect sdk 2.1.0

I tried increasing stack sizes with no success.

I ensured that the flash is fully erased before the first flash in case
Like in the walk-through, I did just rebuild the hello world sample to change the signature

The change I did to the nRF52840 DK, in case this could be of any effect
HW : disconnect the 32.768Khz quartz, reroute the wires so that P0.00 and P0.01 are the new USART0, pass through USB CDC
FW :
create an overlay to set the uart0 on P0.00 and P0.01
add to the prj.conf to run without the quartz 32.768Khz
# No 32.768Khz Quartz
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

I was able to run several other samples with this config with no problems.

Looking at the mcumgr source code
Error 3 seems to be LOG_MGMT_ERR_EINVAL in the mcumgr source code. May have to do with cbor_read_object or cbor_write_attr

Here are the logs

D:\ndapp\serial_dfu\build\zephyr>mcumgr --conntype serial --connstring "COM7,baud=115200" image test 636ec254a624a4dd554ea46c4f04a7bda19b8f1fa88f374b701d9421b8712b96
Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 74ec5b3cb343075a73fe5f179e94c80cd2c8bf886a8687ac32828fbb23e6906e
image=0 slot=1
version: 0.0.0
bootable: true
flags: pending
hash: 636ec254a624a4dd554ea46c4f04a7bda19b8f1fa88f374b701d9421b8712b96
Split status: N/A (0)

D:\ndapp\serial_dfu\build\zephyr>mcumgr --conntype serial --connstring "COM7,baud=115200" reset
Done

// NRF Connect RTT properly logs the Hello World, with a new compilation time, confirming that the active slot is the one we wanted

D:\ndapp\serial_dfu\build\zephyr>mcumgr --conntype serial --connstring "COM7,baud=115200" image list
Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active
hash: 636ec254a624a4dd554ea46c4f04a7bda19b8f1fa88f374b701d9421b8712b96
image=0 slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: 74ec5b3cb343075a73fe5f179e94c80cd2c8bf886a8687ac32828fbb23e6906e
Split status: N/A (0)

D:\ndapp\serial_dfu\build\zephyr>mcumgr --conntype serial --connstring "COM7,baud=115200" image confirm
Error: 3

// NRF Connect VSCode or no NRF connect connected, same problem.

D:\ndapp\serial_dfu\build\zephyr>mcumgr --conntype serial --connstring "COM7,baud=115200" image list
Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active
hash: 636ec254a624a4dd554ea46c4f04a7bda19b8f1fa88f374b701d9421b8712b96
image=0 slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: 74ec5b3cb343075a73fe5f179e94c80cd2c8bf886a8687ac32828fbb23e6906e
Split status: N/A (0)

// yep, no change

I am stuck.

[Jørgen Holmefjord]

Hi,

Did you create an overlay for the MCUboot child image, or just for the application? The configs in the prj.conf file will only be applied to the application, and not to child images. You can specify Kconfig and devicetree overlays for child images as described in Image-specific variables and Child image devicetree overlays.

Best regards,
Jørgen

[laurentc]

I have found that 

mcumgr --loglevel "debug" --conntype serial --connstring "COM7,baud=115200" image confirm   fbb1f392f9fb758f1b28662833d200cc781088c3cb6610e55c47ab3cc7983a5c

does work

that is, it works only if I put the hash in the command.

Still wondering why it does not work without. Maybe mcumgr spec has changed ? 

[Jørgen Holmefjord]

Hi,

Can you try this simple sample on your custom board, to see if the command works with this? 

In general, I would recommend you to not modify the source files in nRF Connect SDK, outside of your project. The overlay configs should be put in project_folder/child_image/mcuboot.conf, not in D:/ncs/v2.1.0/bootloader/mcuboot/boot/zephyr/mcuboot.overlay.

You can check the changes you have made to the repositories by running git status or git diff inside each of the repositories (e.g. bootloader, nrf, zephyr, etc).

Best regards,
Jørgen

[laurentc]

I would like to point out 2 differences in your simple sample : 
1) the confirm is done before the reset

2) the confirm is done with the hash of the image
So, I expect that this will also work on my target. Should I change the sample to confirm after the reset and without the hash ?