Hash not found (8) attempting to DFU ipc_radio image (nRF5340, NCS 2.9.2)

[JakeM]

I’m working on an nRF5340 project (NCS 2.9.2) with simultaneous multi-image DFU using MCUboot, MCUmgr (SMP over BLE), and external flash (MX25R64, like the DK).

App-core DFU works correctly. Net-core DFU (ipc_radio) uploads successfully, is reported as bootable and pending, but after reboot it disappears from the image list and Device Manager reports “Hash not found (8)”.

I tracked this down to the net-core image not being signed / versioned correctly:

• DFU ZIP contains peripheral_uart.signed.bin (app core) but only a raw ipc_radio.bin (net core).

• After enabling CONFIG_BOOTLOADER_MCUBOOT=y for ipc_radio, the build fails during signing:

imgtool sign … --header-size 0 … Error: Invalid value for -H/--header-size: Minimum value is 32

I attempted to set CONFIG_ROM_START_OFFSET=0x200 (and searched for MCUBOOT_HEADER_SIZE / related options), but the value is still resolved as 0 in .config, likely due to sysbuild/partition manager overrides.

Partition Manager layout appears correct for nRF5340 simultaneous DFU:

• app-core secondary in external flash

• net-core secondary in external flash

• net-core primary via ram/flash simulator

The core question is:
What is the correct way in NCS 2.9.x to produce a properly signed/versioned net-core DFU image (with non-zero MCUboot header) so that b0n/MCUboot will accept the hash and it persists after reboot?

Is this expected to be handled via:

• child-image config,

• sysbuild config,

• partition padding for cpunet,

• or explicit imgtool args for the net-core image?

I can’t easily capture UART boot logs, but I can share partition reports, .config snippets, and the exact imgtool command line if needed.

[Vidar Berg]

Hello,

Signing of the netcore image should happen automatically during the build when you have enabled the network core bootloader (SB_CONFIG_SECURE_BOOT_NETCORE=y). The MCUBoot bootloader should not be enabled on the network core.

Please compare you configurations to the sample attached below, particularly the sybuild configurations in sysbuild.conf.

4572.peripheral_lbs_dfu_test_nrf5340_v290.zip 

Best regards,

Vidar

[JakeM]

Vidar,

When I built peripheral_lbs_dfu_test_nrf5340_v290, I observed a dfu_application.zip similar to the one our project generates. I verified that ipc_radio.bin in the zip file matches the signed_by_mcuboot_and_b0_ipc_radio.bin build artifact, for both peripheral_lbs_dfu_test_nrf5340_v290 and our project (before attempting to change configs to resolve the "Hash not found (8)" error).

When I perform a "basic" mode Firmware Upgrade from nRF Connect Device Manager 2.4.0 for Android using the dfu_application.zip built built from the peripheral_lbs_dfu_test_nrf5340_v290 source you provided, I get same "Hash not found (8)" error I'm struggling with from our project. I tested peripheral_lbs_dfu_test_nrf5340_v290 with DK hardware, not our custom hardware.

Note that I can't get peripheral_lbs_dfu_test_nrf5340_v290 to build with the nrf5340dk/nrf5340/cpuapp/ns target (build log). I had to use nrf5340dk/nrf5340/cpuapp. My understanding is the /ns target is preferred. We've been building our project with /ns.

Is "Hash not found (8)" the expected result of a successful dual-image FOTA?

Should peripheral_lbs_dfu_test_nrf5340_v290 build with /ns?

If this project is supposed to work, do you have a pre-built image I can test?

Thanks,
Jake

[Vidar Berg]

Hi Jake,

JakeM said:

When I perform a "basic" mode Firmware Upgrade from nRF Connect Device Manager 2.4.0 for Android

Please upgrade to the latest (v3.1.0 at time of writing) to see if that changes anything. I only found one report of this error, and it was fixed by updating the app.

Also, when updating from one version to the next it is critical that the memory layout is kept unchanged (size and addresses of the primary and secondary slots are hardcoded in the bootloader - https://docs.nordicsemi.com/bundle/ncs-3.2.2/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.html#static_partition_requirement_for_dfu).

My project was not tested or configured for the /ns target, but it should work if you rename the kconfig fragment and overlay in the board directory from nrf5340dk_nrf5340_cpuapp to nrf5340dk_nrf5340_cpuapp_ns.

Best regards,

Vidar

[JakeM]

Vidar,

I get the same "Hash not found (8)" error when the peripheral_lbs_dfu_test_nrf5340_v290 app is built with 3.1.0.

I'm aware of the static partitioning requirement. We also have a project on 2.5.3 that doesn't have external flash. We're doing an app core DFU with that project, and we have a pm_static defined for it. I don't think it's the issue I'm facing now, though. I can't even get peripheral_lbs_dfu_test_nrf5340_v290 to DFU over itself.

Have you actually tested peripheral_lbs_dfu_test_nrf5340_v290 built against 3.1.0 (without /ns is fine) and had it DFU successfully to an nRF5340 DK without a "Hash not found (8)" error?

Regards,

Jake

[Vidar Berg]

Hi Jake, 

I meant to ask if you could update the nRF connect device manager app on your phone. 

Regards,

Vidar

[JakeM]

Vidar,

That makes sense. For some reason the Play Store wasn't offering me the update, but I uninstalled and reinstalled, and now I have 3.1.0. Unfortunately, that version gives the same error.

Is there any combination of project, recent NCS version, and mobile app that you've seen perform a dual image DFU to an nRF5340 DK successfully, with test and confirm?

Regards,
Jake

[Aleksander Nowakowski]

Hello! Apps developer here!

Could you please share the logs from nRF Connect Device Manager app? One way to do this is by installing nRF Logger app (available on Play Store) and tapping the magnifying glass icon in top-right corner of nRF C.D.M. after you get this error. This would help up a lot finding when the error happens.

Thank you!

[JakeM]

Aleksander,

I reproduced the "Hash not found (8)" error with the LBS app, nRF5340 DK, and Device Manager 3.1.0 app.

Log file: https://pastebin.com/raw/1ddwnUWz

Are you able to reproduce the error? I can't get a successful Test and Confirm with dual-image FOTA, even with 100% Nordic FW, HW, and mobile app.

Regards,
Jake

[Aleksander Nowakowski]

Mind, that with nRF53 the only working mode is "Confirm only". This is because the netcore cannot restore its original image after the new was set to "pending" and swapped.

When the TEST command is sent, the netcore permanently changes its image to the new one. When using "Test and Confirm", after reconnection the library (and app) tries to send CONFIRM command using the same hash, but the device no longer has access to the hash as it cannot access the netcore image, thus returning "Hash not found".

Change mode to "Confirm only" and you should see the result as success. Note, that in this mode the phone won't reconnect to the device, and the success will eb returned "estimated swap time" after the reset command was sent. Please measure the actual swap time (time until your device starts advertising again) and set the correct value. This is to prevent a timeout on reconnection in case you try to reconnect to your device after getting success (Android has a ~30 sec timeout).

[Aleksander Nowakowski]

Check out the first Note in this section:
https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/?tab=readme-ov-file#firmware-upgrade-mode 

[JakeM]

Aleksander,

This makes complete sense. I was getting hints of Test and Confirm not being supported and should have looked into that sooner.

We were previously getting away with Test and Confirm on a 5340 because we weren't supporting multi-image due to not having flash. After introducing updated hardware that includes flash, we assumed the mobile apps wouldn't need to change (aside from identifying the new hardware for features unrelated to FOTA).

I verified that Confirm Only works for both the LBS FW on the nRF5340 DK and our custom FW on our custom HW. I'll take heed of the swap/reconnect time when implementing the mobile app support.

Thanks,
Jake