Unerstanding of DFU OTA on legacy bootloder

[Ankit_chauhan]

Hello,

I have an application running on legacy NRF SDK and using the nRF5 bootloader, which has below flash sectors,
0x00000 - 0x026000 - Soft-device section
0x26000 - 0x0D9000 - Application section
0xD9000 - 0x0F8000 - Reserved section
0xF8000 - 0x100000 - Bootloader/settings/mrb

Now I want to perform a DFU OTA over this with my new application called the intermediate application. This shall have,
- two large byte arrays, of 50KB and 320KB
- A function that copies the above array to flash into a specific address(in 0x00000 to 0x062000); this function is a RAM function that loads into RAM.
- And a main function that calls this RAM function.

The flash sections of this intermediate application are as below,
0x00000 - 0x062000 - Space to paste two byte array data
0x62000 - 0x0BF000 - dedicates sectors to hold byte array in flash memory
0xBF000 - 0x100000 - Application section

What I want is to perform a DFU OTA of the intermediate application over the legacy application. Now the legacy application has a bootloader, softdevice, and application in the dedicated flash regions, while the intermediate application has a different flash layout compared to the legacy application.

So the question here is, is it possible for the legacy application bootloader to accept the intermediate application and perform DFU? Because the intermediate application does not have a softdevice, a bootloader, and the same flash layout that the legacy application expects.

If not, then can you suggest a way I can follow to achieve my goal?

[Hung Bui]

Hi Ankit, 

Could you explain what exactly you want to achieve by swapping the original application with the intermediate application ? Does the intermediate application has a softdevice ? What exactly the intermediate application does  ? Is it flashed just to perform some operation before being swapped with another application ? Does it have a softdevice ? 

How familiar you are with the secure bootloader in nRF5 SDK. What you asking for is quite advanced and not something our bootloader support originally. 

[Ankit_chauhan]

Hello,

Thank you for the response.

My goal is to switch the nrf bootloader to MCUboot. I have multiple devices running on a legacy nRF application + bootloader. I ported this application to Zephyr + MCUBoot, and now I want to update the Zephyr application over the legacy nRF application. Due to hardware limitations, I am not able to access the SWD pins, so I cannot flash the Zephyr application straight away. 

So, I have created an intermediate firmware that has two byte arrays. One array contains the raw bytes of the mcuboot binary zephyr.bin, and another array contains the raw bytes of the application binary zephyr_signed.bin.

Along with this, I have created a RAM function that copies these raw byte arrays to a specific flash location as mentioned above.

This approach is working as expected. I have tested this on devkits. After flashing the intermediate firmware over the legacy nRF application, it erases the required flash sectors, write new byte array data of the MCUboot and Zephyr application, and reboots the device. After this reboot, it starts with the MCUboot and zephyr application.

Now, I need to perform the same thing through DFU OTA. The legacy nRF application supports BLE OTA DFU, and I have created a DFU package of intermediate firmware that can be transferred to the nRF application. But this part is not working, and the reason I suspect is my initial comment.

I hope this will provide you with the required information that you are looking for. Let me know if you have doubts about any of the explanations.

Thank you,
Ankit.

[Hung Bui]

Hi Ankit, 
Thanks for the info. 
There actually some discussion regarding what you want to achieve. 
I would suggest to take a look here: Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application 

https://devzone.nordicsemi.com/f/nordic-q-a/76529/nrf5-sdk-possible-to-ota-update-to-nrf-connect-sdk?pifragment-684=2

And another solution here which is closer to what you are doing: https://www.embeddedrelated.com/showarticle/1573.php

There are a few things: 

- You image must replace the softdevice. Inside the softdevice there is a MBR that doesn't get replaced , so you need to customize your application to start after the MBR. 

- You need to trick the bootloader to think that your application is a valid softdevice image. 

- The plan to run an application from RAM to do the copying expose a risk that if there is a reset for example power reset, when the process is on going , you may brick the device. 

[Ankit_chauhan]

Thank you for sharing the links for reference. Actually, I have been working on this for a couple of weeks and I almost gone through all possible approaches defined in the links that you shared.

Basically, the concept they suggest is to create a DFU package that can update the softdevice and bootloader with the Zephyr application and MCUBOOT. And they made it work as well. However, the sector defined in the nRF5 application for the bootloader is now 24KB, and the size of MCUboot is approximately 45-50KB. So it will not fit into that region. 

I tried the suggested approach, and during DFU through the nRF Connect app, I am getting a pop-up of insufficient space, and it stops file transfer. I believe that is due to the insufficient flash sector of MCUboot, as I mentioned above.

Also, the softdevice region is from 0x100 to 0x26000, which means the Zephyr application that is going to be updated over the Softdevice region is limited to that size.

[Hung Bui]

Hi Ankit, 

I believe you can have minimum size MCUboot that can fit to the bootloader. Have you looked at the example provided by Vidar ? 

Ankit_chauhan said:

Also, the softdevice region is from 0x100 to 0x26000, which means the Zephyr application that is going to be updated over the Softdevice region is limited to that size.

As far as I know it's ok for a new softdevice to increase in size. You have to provide the softdevice size (and info) at a special location inside the softdevice hex file for that. 

Of course you can continue to do what you plan. But it would be easier if you follow what discussed in the embeddedrelated link. Instead of overwriting the softdevice , you simply replace the bootloader and remove the protection in the bootloader, after that run in RAM and overwrite softdevice to write your application there.