Update Net core with netboot through MCUBoot over serial USB.

[anthony32086]

Hello,

The following is for a custom application but I have also tested this with the base peripheral_uart example with the same result.

I have an application which uses a custom firmware on both the application core and network core and have configured the app project with CONFIG_BOOTLOADER_MCUBOOT and CONFIG_PCD, configured the net project with CONFIG_SECURE_BOOT, and added the net as a child image to the app to successfully build and produce app_update.bin and net_core_app_update.bin.

When the DK is placed into DFU mode and connected over USB, I am able to use mcumgr to send app_update.bin to the APP core. The console displays the following:

I: Erasing sector at offset 0x0
I: Writing at 0x0 until 0x124
.....

However, when I try to send  net_core_app_update.bin, I get the same output as above and after reboot the serial console shows that I enter a bootloop from what I assume is mcumgr incorrectly writing the net image to the app flash.

Is there any documentation available on how to instruct mcumgr to write net_core_app_update.bin to netboot over IPC or otherwise update the NET core over MCUBoot's USB connection.

[evanperryg-somewear]

Hello Anthony,

I am working through a problem similar to yours. Regardless of whether I use mcumgr or the nRF Connect app, performing a DFU that includes net_core_app_update.bin causes my firmware to enter a boot loop. After much poking around, I found that b0n (netboot) fails here:

It looks to me like fw_info_find was returning NULL, indicating that it did not find the fw_info block in the uploaded image. I can see a FW_INFO magic number at offset 0x400 in the net_core_app_update.bin file. I will confirm that the magic number in the .bin file matches the one that b0n is looking for.

[evanperryg-somewear]

The magic number matches, including the compatibility info part.

[evanperryg-somewear]

More progress - the fw_src_address passed to bl_validate_firmware is 0x0000be0b. It gets this address from the PCD data supplied by MCUBoot. MCUBoot assumes that b0n knows that this address points to the external flash, but fw_info_bare dereferences the address like a regular pointer. So, instead of reading the external flash, b0n is reading junk.

Seems to me like Nordic's code would work fine for setups where both slots are kept on internal flash, but if your secondary slot is in external flash, b0n will fail.