nRF5340 Upgrade of App and Net core firmware

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Fri, 02 Dec 2022 15:55:41 GMT

Hi Sigurd,

thanks for the update.

RE: nRF5340 Upgrade of App and Net core firmware

Sigurd Hellesvik — Thu, 01 Dec 2022 15:51:10 GMT

Hi,

Our developers have this feature on their TODO-list, but I am not able to tell you anything about the timeline for this.

As we generally tell customers: If you want insight into our timeline on different things, ask your local sales representative, and they will know how much they can say.

Regards,
Sigurd Hellesvik

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Mon, 28 Nov 2022 16:04:33 GMT

Hi Sigurd,

thanks for the prompt reply.

The bug i mentioned is the one i linked above called link1 and link2.

I report them here again:

https://github.com/nrfconnect/sdk-mcuboot/pull/197

https://github.com/nrfconnect/sdk-mcuboot/pull/210

RE: nRF5340 Upgrade of App and Net core firmware

Sigurd Hellesvik — Mon, 28 Nov 2022 11:45:11 GMT

Hi,

Simon is out of office, so I will continue handling this case.

I will poll our developers to see if there are anything new here.

But first: Can you link to the 7 months old bug your are referencing here?

Regards,
Sigurd Hellesvik

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Fri, 25 Nov 2022 17:08:21 GMT

Thansk so much ! Any news ? Because the problem i see is that even the actual SDK 2.1.2 does not support the upgrade when both the new image are located in the external flash, due to a know bug since 7 months.

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Tue, 25 Oct 2022 15:05:55 GMT

Hello, I have created a ticket internally about single image netcore update using external flash.

I will keep you updated on the progress

Best regards,

Simon

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Tue, 18 Oct 2022 16:32:47 GMT

Hi Simon,

but according the documentation:

The reversion is not available in simultaneous multi image. Instead i would like to preserve this possibility.

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Tue, 18 Oct 2022 12:46:03 GMT

[quote user="Riccardo Gaiati"]Hi Simon, actually what i would like to do is exactly a multi image upgrade - App and Net Core - preserving the possibility of reversion for the App Core firmware. But if i understand correctly is not possible (Simultaneous multi-image DFU). Is that correct ? [/quote]

Multi image upgrade should be supported You could take a look at the Machine Learning application and the Thingy:53 configuration, it demonstrates how to do multi image DFU. Use the file dfu_application.zip to do multi image DFU.

What is not supported is single netcore update using external flash.

Best regards,

Simon

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Tue, 11 Oct 2022 11:48:45 GMT

I will create a new ticket as soon as i finished to test some scenarios.

Thanks in advance !

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Tue, 11 Oct 2022 09:05:27 GMT

Hi Simon, actually what i would like to do is exactly a multi image upgrade - App and Net Core - preserving the possibility of reversion for the App Core firmware. But if i understand correctly is not possible (Simultaneous multi-image DFU). Is that correct ?

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Tue, 11 Oct 2022 08:55:14 GMT

Sure. And sorry again for the big delay.

I am interested in having the possiblity to revert to the old image of the firmware if the new one does not work (so it does not set itself as confirmed). As far as i have read this feature is:

- available only for the App Core and not for the Net Core;

- not available in the simultaneous upgrade;

Could you kindly give me your feedback about this please ?

Thanks in advance.

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Wed, 05 Oct 2022 14:01:30 GMT

Sorry for the delay. Have you made any progress on this?

[quote user="Riccardo Gaiati"]sure i will. thanks ![/quote]

Nice, sounds good. Let me know when you have created the new ticket.

[quote user="Riccardo Gaiati"]In which condition the rollback of the image IS NOT possible ? Multi image and simultaneous upgrade ?[/quote]

I'm not sure what you're asking about here, can you elaborate?

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Thu, 22 Sep 2022 13:39:10 GMT

Hi Simon,

sure i will. thanks !

In which condition the rollback of the image IS NOT possible ? Multi image and simultaneous upgrade ? Thanks in advance

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Thu, 22 Sep 2022 12:02:31 GMT

Would you be able to create a new ticket about this? This is because you don't mention non-simultaneous (not multi image DFU) netcore update using external flash in the initial post. You do ask about multi image DFU.

If you create a new ticket, where the header and content is related to this specific issue, it will be easier for other developers to find it.

Of course I will continue to work with this, just link to the new ticket in this ticket once created and I will assign it to myself.

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Wed, 21 Sep 2022 12:06:16 GMT

Hi Simon, thanks again. Yes, i saw that he does not use them.

Thanks for digging into it !

Kind regards

Riccardo

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Wed, 21 Sep 2022 11:10:52 GMT

In that reply he modified loader.c directly, he didn't use any hooks. So that could be a temporary workaround. But you are correct, currently the nrf53_hooks.c file is only working with multi-image simultaneous DFU. I will look into creating a hook file for your case.

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Wed, 21 Sep 2022 09:01:00 GMT

Good morning Simon,

thanks for the feedback.

Yes, I saw his proposal but - if i am not mistaken - the hook approach works only in multi image approach where the rolling back of the app image is not possible. Is that correct ?

Anyway, thanks for investing time to dig in this issue.

Looking forward to hearing from you.

Kind regards

Riccardo

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Wed, 21 Sep 2022 08:40:02 GMT

As a temporary fix, could you try to modify loader.c as the customer did in this reply: RE: nRF5340 non-simultaneous netcore updates with external QSPI ,it seems like he was able to perform a netcore update with the secondary slot in external flash with that modifications:

" I can now perform net and app core updates one at a time from a single secondary slot on the external qspi in a way that still allows for reversion of the application core."

Based on that, I will see if I can create a hooks file that achieves the same, which is a better approach than modifying mcuboot and the loader.c file.

Best regards,

Simon

RE: nRF5340 Upgrade of App and Net core firmware

Riccardo Gaiati — Sun, 18 Sep 2022 13:45:31 GMT

Hi Simon,

thanks for the detailed information and sorry for my late feedback.

Regarding the code, what it was missing was the allocation for the mcuboot buffer: unfortunately dfu_target_mcuboot_set_buf is not part of the single image DFU library so i noticed that i had to add it only when the fw crashed and the assert told me to invoke this function.

My configuration place the mcuboot_secondary in the EXTERNAL FLASH, for both the app and net core.

In order to have it properly executed, i had to introduce the patch in the loader.c for the MCUboot reported in these links: link1 and link2.

Neverteless, the patched MCUBoot works ONLY FOR THE APP CORE: having the netcore new image in the external flash causes a bus fault:

#if defined(CONFIG_SOC_NRF5340_CPUAPP) && defined(PM_CPUNET_B0N_ADDRESS)
        /* If the update is valid, and it targets the network core: perform the
         * update and indicate to the caller of this function that no update is
         * available
         */
        if (upgrade_valid && reset_addr > PM_CPUNET_B0N_ADDRESS) {
            struct image_header *hdr = (struct image_header *)secondary_fa->fa_off;
            uint32_t vtable_addr = (uint32_t)hdr + hdr->ih_hdr_size;
            uint32_t *net_core_fw_addr = (uint32_t *)(vtable_addr); /*!!! BUS FAULT !!! */
            uint32_t fw_size = hdr->ih_img_size;
            BOOT_LOG_INF("Starting network core update");
            rc = pcd_network_core_update(net_core_fw_addr, fw_size);

I saw that the same thing was reported in this ticket

Is a solution planned for the netcore with this configuration (that is one only mcuboot seconday in the external flash) ? Or are there any configuration parameters that i am missing to enable such of management ?

Thanks in advance !

Kind regards

Riccardo

RE: nRF5340 Upgrade of App and Net core firmware

Simon — Tue, 06 Sep 2022 10:23:39 GMT

[quote user=""]is the reported approach correct ? If not, could you kindly indicate an example that suites my scenario ?[/quote]

It seems good. As long as you put the app_update.bin or the net_core_app_update.bin into the secondary flash partition, mcuboot will handle the rest. Based on the reset addr it will decide whether it is a netcore update or an appcore update and take the appropriate action.

[quote user=""]Can it work also for the network core ? How do i specify the core to be updated ? Basically, doing the same thing that nRF Connect Device Manager does.[/quote]

Actually, all you need to do is to put net_core_app_update.bin into secondary flash, and mcuboot will handle the rest.

[quote user=""]Is there a function that perform the validation of the bin files before being copy in the DFU target ?[/quote]

I did provide a similar answer in another private ticket. In that case mcumgr was used, and I explained how to do some verification of the .bin file from the computer as well as from the chip. I'll copy it in here. Let me know if this is not what you asked about:

"The mcumgr tool does not have this functionality. If you would like to do some verification from the computer, you could use Image tool (located in <ncs>/bootloader/mcuboot/scripts) to verify the binary file. Use imgtool verify:"

@$ imgtool verify -h
Usage: imgtool verify [OPTIONS] IMGFILE

  Check that signed image can be verified by given key

Options:
  -k, --key filename
  -h, --help          Show this message and exit.

"As said the mcumgr is quite dumb and pretty much only writes the image to the secondary slot (with one exception), with no checks on it. The verification is done by mcuboot, when mcuboot tries to swap images. The exception is when checking for image address is enabled, so that an image with an incorrect boot adress would not get uploaded, because the image may be still be verified by mcuboot and brick the device - but this needs to be enabled and special TLV needs to be added with the start image address using the imgtool.

Also topic of image verification is quite broad and may mean anything from signature, version, CPU, board revision, device purpose, nearly anything - and mcuboot currently only supports signatures, versions and some other basic checks that are rather related to correctness of an image than it's purpose.

If you have some additional conditions the img needs to fulfill, you can try providing an own callback img_mgmt_upload_cb that allows to do some additional checks on received image chunk, after mcumgr has already accepted it as valid but not yet written."

[quote user=""]I saw that there is DFU multi-image library. is there any example using that ? is the zip file produced during the compilation that need to be sent to the DFU target?[/quote]

I'm not too familiar with simultaneous multi image DFU, however it makes sense to update both the netcore and appcore simultaneously if Bluetooth is affected, for changes that is related to the Bluetooth communication between the chips. You could take a look at the Machine Learning application and the Thingy:53 configuration, it demonstrates how to do multi image DFU. Use the file dfu_application.zip to do multi image DFU.

Let me know if anything is unclear, and I will try to clarify or investigate further.

Best regards,

Simon