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 

[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

[AHaug]

Aha, thank for enlightening me

Sankton said:

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. 

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

Sankton said:

Discussion 1:

Listed as follows  

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

Sankton said:

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 .

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

Sankton said:

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 . 

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