DFU over BLE using external Flash TESTING

RE: DFU over BLE using external Flash TESTING

AHaug — Tue, 27 Aug 2024 11:56:40 GMT

Aha, thank for enlightening me

[quote user="Sanket Rao"]But Andreas there is reason i dont want MCUboot to do things on its own , therefore having control on MCUboot or knowing MCUboot better is neccessary. [/quote]

You're of course free to modify MCUboot and create your own custom solution that fits your project. What I meant with my explanation is what MCUboot does out of the box in our SDK

[quote user="Sanket Rao"]Discussion 1:

Listed as follows [/quote]

This makes sense to me w.r.t why you would want to do this.

[quote user="Sanket Rao"]is there is any way or any example API calls that can decrypt my OTA file/image before writing to the secondary slot partition for further DFU process . Please let us know .[/quote]

Unfortunately there are no existing samples that showcases encrypted DFU, and w.r.t the API that which exists is mentioned in the documentation I sent regarding encrypted DFU + the MCUboot documentation

[quote user="Sanket Rao"]I believe during DFU OTA thru GSM that data will be recieved in chunks and written to some memory portion in the external flash defined by us , is it possible for MCUboot to handle these chunks directly or even indirectly & write them to MCUBoot Seconadry slot for further stages of DFU . [/quote]

Atleast for indireclty you can do something similar to what is done in this lwm2m evaluation or in this variation and modify where you write the encrypted chunks for temporary storage, for instance in your own secure partition. Then when you've done whatever you need to do to the chunks and/or full image, you can move it to mcuboot_secondary and start the DFU process from there.

Kind regards,
Andreas

RE: DFU over BLE using external Flash TESTING

Sankton — Tue, 27 Aug 2024 10:15:45 GMT

Hello Andreas

I would like to thank for your prudent opinions on my doubt

But Andreas there is reason i dont want MCUboot to do things on its own , therefore having control on MCUboot or knowing MCUboot better is neccessary.

I had like to discuss two issues pertaining to it .

Discussion 1:

Listed as follows

Suppose , i am giving my client an OTA file that they will have to perform OTA manually over BLE , but we will be using our local encryption technique before handing the OTA file to the client .
This may require decryption of the OTA file before MCUboot can write this to secondary partition , or else MCUboot will fail this process and resorces be wasted as signature tests will fail.

[quote userid="107683" url="~/f/nordic-q-a/114216/dfu-over-ble-using-external-flash-testing/499902"]The commands for building and loading MCUboot and the firmware images may vary depending on the specific use case.[/quote]

I can see you wrote , there are different ways how MCUboot is loading and how firmware images are handled , is there is any way or any example API calls that can decrypt my OTA file/image before writing to the secondary slot partition for further DFU process . Please let us know .

Discussion 2:

Andreas we are looking for further possibilities on our products with GSM capabilities that can perform DFU OTA thru cellular networks .

I believe during DFU OTA thru GSM that data will be recieved in chunks and written to some memory portion in the external flash defined by us , is it possible for MCUboot to handle these chunks directly or even indirectly & write them to MCUBoot Seconadry slot for further stages of DFU .
And i believe there will be no scope of encryption or decryption in this method of DFU .

Nordic SDK has very limited ambit on MCUboot , a sample/example regarding discussion 2, if it ever passed by you, please let us know , it be really helpful .

Regards
S

RE: DFU over BLE using external Flash TESTING

AHaug — Tue, 27 Aug 2024 07:50:15 GMT

[quote user="Sanket Rao"]This is because we have our encrypted OTA file to be tested now , so direct jump to step of confirmation and swap shouldnt take place .[/quote]

Ah, my bad. I see I mighte caused some confusion with the ordering of things. Let me know if the explanation under removes your desire to want to stop the erase:

Here's the general process of how MCUboot testing, confirming, and swapping work:

Building and Loading Images: First, you need to build and load MCUboot and the firmware images for the primary and secondary slots. The commands for building and loading MCUboot and the firmware images may vary depending on the specific use case. For example, you might use the newt tool to build and load MCUboot and the firmware images (source).
Testing the Image: After uploading the firmware image to the secondary slot, you can test the image by obtaining its SHA and ensuring it boots. This can be done using the imgtool verify and mcumgr image test commands (source, source).
Confirming the Image: If the image in the secondary slot is tagged as "confirm", MCUboot will swap it into the primary slot permanently. If the image is tagged as "test", MCUboot will swap it into the primary slot for one reset cycle. Unless the image is then confirmed while running, MCUboot will swap back the old application to the primary slot on its next reset (source).
Swapping the Images: If everything works as expected, you can proceed with requests for permanent swap to the image in the secondary slot and do random swaps. When the swap finishes, the previous secondary image should now be in the primary slot and vice-versa (source).
Reverting the Images: If the device crashes immediately upon booting a new (bad) image, MCUboot will revert to the old (working) image at the next device reset, rather than booting the bad image again. This allows device firmware to make test swaps permanent only after performing a self-test routine (source).

Kind regards,
Andreas

RE: DFU over BLE using external Flash TESTING

Sankton — Mon, 26 Aug 2024 13:34:27 GMT

[quote userid="107683" url="~/f/nordic-q-a/114216/dfu-over-ble-using-external-flash-testing/499776"]You can modify the MCUboot code for your project and create your own custom procedure where you can manually delete the contents on the secondary partition, but I'm not 100% sure why you would want to do this. Could you expand upon why so that I might see differently?[/quote]

This is because we have our encrypted OTA file to be tested now , so direct jump to step of confirmation and swap shouldnt take place .

Also thanks for the link regarding encrypted images , that will be for my personal educational pursuits ,

Thanks & Regards
S

RE: DFU over BLE using external Flash TESTING

AHaug — Mon, 26 Aug 2024 13:19:03 GMT

[quote user="Sanket Rao"]1) that i can stop the erase of secondary slot after swap procedure .[/quote]

You can modify the MCUboot code for your project and create your own custom procedure where you can manually delete the contents on the secondary partition, but I'm not 100% sure why you would want to do this. Could you expand upon why so that I might see differently?

[quote user="Sanket Rao"]2) this is bit off topic , is there any way i can encrypt my app_update.bin file , for better security of our product .[/quote]

Yes, this should be possible according to https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/encrypted_images.html.

Kind regards,
Andreas

RE: DFU over BLE using external Flash TESTING

Sankton — Mon, 26 Aug 2024 12:53:18 GMT

Hi Andreas
Thank you for your valuable input , i will go thru the link you provided , also is there any way -

1) that i can stop the erase of secondary slot after swap procedure .

2) this is bit off topic , is there any way i can encrypt my app_update.bin file , for better security of our product .

Regards

S

RE: DFU over BLE using external Flash TESTING

AHaug — Mon, 26 Aug 2024 12:28:17 GMT

Hi S,

Good questions, I'll clarify them for you

[quote user=""]My First question is , why only 30Bytes were written on my external flash when my new image was of around 256KB ?
Is MCUboot that intelligent that I can see the changes and only write the update that I have made in my application ?[/quote]

I assume that you read and observe this after you've powercycled/restarted the device after performing DFU. If this is the case, then the reason for why you only see some arbitrary 30 byte on MCUboot secondary is due to how the DFU procedure works:

First you run your original image on MCUboot Primary
Then you enter the DFU procedure mode and upload the new image to MCUboot secondary
When the new image in MCUboot secondary has been uploaded it starts the swapping procedure, i.e it swaps around the images in Primary and secondary so that the new image is now in MCUboot primary and the original is in MCUboot secondary,
If the new image (which is now in MCUboot primary) is tested and approved (i.e that it seems to be a valid firmware), it approves the swap and deletes the original image which is in MCUboot secondary, making room for future images to be uploaded to the MCUboot secondary slot.

[quote user=""]My second question is , how I can verify that my DFU over BLE is done using External Flash only , not inbuilt SOC flash (this haunts me ) .[/quote]

If you're using MCUboot, then the procedure is simply that MCUboot is programmed to use MCUboot primary application and MCUboot secondary application slots for DFU. Primary is used for the running image, and secondary is used to temporarily store the update image, and to hold the image that is swapped.

As you can see in your image, the secondary MCUboot application partition resides in your external flash from 0x0 to 0x71000, meaning that it has to be done through external flash. If you place your secondary partition on the internal flash area, it will only use your internal flash for DFU.

I recommend that you also have a look at https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/ for some more information regarding how this works!

Kind regards,
Andreas