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

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.

  • 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

  • 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 ? 

  • Hello Jorgen,

    I would like to have a clean SDK before going further.

    I am trying to not to have to change the DSK and have all my modifications inside my project/api folder

    I have tried my best to follow the documentation for properly setting overlays for the mcuboot child image, but all my tests fail with my overlay and conf files being ignored wherever I put them. The only way to make it work is if I edit dts.overlay and prj.conf in D:\ncs\v2.1.0\bootloader\mcuboot\boot\zephyr

    To know if my overlay and conf are taken into account, I look at the log of the compilation.

    In my case, the child_image is mcuboot ? right ? 

    and ACI_NAME is mcuboot ? right ? 

    So, I created a mcuboot subdirectory to my api (serial_dfu is my api dir. My project dir is ndapp, see logs)

    I created a  ndapp/serial_dfu/mcuboot/mcuboot.overlay but it is ignored

    same problem with my .conf file for the child image.

    also, i tried to change the mapping of the flash to allocate more room for the API and less for the scratch, but the only way to do it that I found working was to edit nrf52840dk_nrf52840.dts in the sdk.  If I make an overlay, the maping (in dts.overlay...),  is rejected because of a redefinition of the start address of slot1 (and all examples I have seen using static mapping wit h.yml files are not for the 52840 and I can't make sense of the addresses computations, so that I am not sure how to edit it)  Looong way to go.

    laurent

  • laurentc said:
    In my case, the child_image is mcuboot ? right ? 

    The directory should be named "child_image", not the name of the child image. See for instance the Matter light bulb sample directory structure. For more details, see Multi-image builds.

    laurentc said:
    and all examples I have seen using static mapping wit h.yml files are not for the 52840 and I can't make sense of the addresses computations, so that I am not sure how to edit it

    What do you mean by "not for the 52840"? There is a pm_static file for nRF52840DK here, but this also includes external flash. It may help you with creating your file as well.

  • Well, the child_image thing was funny. But only for 5 minutes.

    The child_image/mcuboot.conf works it seems. (appears now in the log)

    But the child_image/mcuboot.overlay is still not taken into account. Damn.

    I know it by checking the zephyr.dts  (correct only if I modify dts.overlay) and the compilation log

    Nota : the  light bulb sample does not contain .overlay files.

Related