DFU over BLE using external Flash TESTING

[Sankton]

Hello Engineer
Greetings Of the Day 


We performed DFU over BLE with secondary slot in External flash that operates using SPI .

I needed some clarification on the outcomes .

-> My running application of Primary Slot was of 256KB 
-> To perform DFU I did minor tweaks in my running application , say , added a printing Line that says "NEW FIRMWARE"
-> Then executed Build and took out the app_update.bin file that is binary that I will flash thru my BLE DFU process , it was obviously around 256KB , as changes were minor 
-> I undo'ed all tweaks and build it and flashed to my custom board (nrf 52833) 
->Then I did dfu using nordic app on my phone 

-> DFU was successful and I observed new application running in my custom board , successfully .





To Verify that DFU took place according to my External flash settings 

-> I made a special application that reads my external flash (this application was tested before with spi_flash example and it worked perfectly fine)
-> to be precise with my testing I made sure that flash was all erased prior to my DFU testing sequence
-> when I went to read , start of my flash (area partitioned for McuBoot_Secondary slot )
-> I observed only some odd 30 bytes were written 

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  ?


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 ) .



This image represents my Partition table 


Also if you insuniate with possible tasks that can verify my DFU BLE using external slots , would be really helpful . 




Thanks & Regards 
S 

[AHaug]

Hi S,

Good questions, I'll clarify them for you

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  ?

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:

1. First you run your original image on MCUboot Primary
2. Then you enter the DFU procedure mode and upload the new image to MCUboot secondary
3. 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,
4. 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.

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 ) .

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

[Sankton]

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 

[AHaug]

Sankton said:

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

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?

Sankton said:

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

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

Kind regards,
Andreas

[Sankton]

AHaug said:

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?

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

[AHaug]

Sankton said:

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 .

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:

1. 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).
   
   
2. 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).
   
   
3. 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).
   
   
4. 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).
   
   
5. 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

[Sankton]

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.

AHaug said:

The commands for building and loading MCUboot and the firmware images may vary depending on the specific use case.

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