BUG: MCUBoot network core update sometimes fails to update

[anthony32086]

When uploading a network core image though MCUBoot and confirming the image, sometimes it fails to accept and on other builds it accepts the update.

I have narrowed this down to the check in zephyr flash simulator flash_sim_write which checks if the offset and length are multiples of the flash sim prog unit.

https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/flash/flash_simulator.c#L227

My build environment generates ipc_radio.bin images that vary in length anywhere from 132236, 132235, to 132234 bytes. Only the 132236 confirms as it is a multiple of 4.

My understanding is the nrf5340 uses the flash simulator as a zephyr built in way to map the shared memory to a fake flash api so the built in loader.c code copies the data over to shared memory automatically, then nrf53_hooks.c takes over and performs a network core update.

This value of 4 comes from the flash_sim.overlay write-block-size property which is set to 4.

https://github.com/nrfconnect/sdk-nrf/blob/main/modules/mcuboot/flash_sim.overlay#L36

Since the flash simulator is mapped to sram, it does not need word aligned writes. Setting this value to 1 allows byte level writes to memory and the problem is resolved.

[Hung Bui]

Hi Anthony, 
I got the ticket from Håkon. 
I think you have a point here. What I'm concerning is that the ipc_radio.bin would first have to be written in flash (on the app core/external flash) then copy to RAM then writing to flash (on the net core) so we will have to check if 4-byte alignment is required or not. My understanding is that it's not as the last byte(s) would be written as a 4 bytes write. 

I have forwarded your question internally and will keep you update. 

[anthony32086]

Correct, the last bytes are attempted to be written as 4 bytes but because of the size check it returns -EINVAL instead and I never see the message "turning on network core" which means the hooks aren't running.

Looking at the implementation and the comments in flash_sim.overlay it looks like the intent was for flash sim in sram to be an easy way to get data from the zephyr api's on app core to the netcore.

From zephyr's perspective, it updates image 1 slot 1 in external flash to image 1 slot 0 in the flash simulator and the update is done.

But in actuality, the nrf hooks takes that flash sim sram buffer and copies its data to the net core to do the actual update.

Since flash sim's purpose is to "simulate flash" normally you would use an alignment parameter to actually simulate a flash specification. However nordic's use case is to simply get data from image 1 slot 1 to a sram buffer the alignment emulation is not needed.

The actual code that writes the input data to the flash sim sram buffer does byte level copies anyways so the alignment check is purely an api simulation.

github.com/.../flash_simulator.c

[Hung Bui]

Hi Anthony, 

I think you have a point here. I have forwarded your finding internally. I will get back to you if the bootloader team confirms.