• State Verified Answer
  • Replies 1 reply
  • Subscribers 74 subscribers
  • Views 908 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 213796
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Reverting DFU using dual bank

Pawel Niedbala

Hi!

I use SD 6.0.0 and SDK 15.0.

I am developing an application and I want it to include service of buttonless OTA firmware updating. So far I have managed to zip my application and send it over bluetooth to my chip. Nothing special.

I am still overwhelmed by the amount of the information on the topic of bootloader, DFU and so on but I want to do the following:

Let say my device is run by a firmware v1.0. I use dual-bank DFU, so when I send new firmware v1.1 the old one isn't immediately erased. The documentations says that if the new firmware is received, not corrupted it's validated and the old one is removed. My aim is to preserve the old one, so when I find out that v1.1 is working but somehow bugged I can quickly revert the changes and activate old program v1.0 (for example by using a certain characteristic). 

I have read this topic but I don't want it like this, I mean having two already finished programs and merging them. I want a program to be present in the chip memory, update it by sending another one via bluetooth, and optionally if it's needed to revert the changes.

Is it possible? How? Where to get more knowledge to make it possible?

Thanks

Parents
  • +1

    Hi Pawel, 

    This is possible, however, this will require major changes to the bootloader as well as in the application code. 

    The first think you would need to address is the SoftDevice interrupt forwarding scheme, i.e. the SoftDevice expects the application to be located directly after the SoftDevice. 

    Hence, if you want to have multiple applications in the application space you will need to create a small application, placed directly on top of the SoftDevice, that forwards the SoftDevice interrupts/events to the correct application. This is similar to what we do in our MBR when jumping to the bootloader if it is present and directly to the application if not, see Master boot record and bootloader in the Softdevice specification for more information. 

    The second hurdle you would have to pass is modifying the bootloader so that the DFU banks starts after this application MBR and find a way to tell the application MBR where the new and old application starts. We use the UICR registers for this with the bootloader, but in our case the bootloader start address is fixed, in your case i would imagine that the application may grow in size. It is possible to modify the UICR registers from runtime, but if a power failure occurs during the update you might end up with a bricked device if the jump address(es) are only partially written. 

    The third hurdle is the actual DFU process, you will have to modify the bootloader so that the old application is not erased after the new image has been received and validated and then update only one of the two merged applications. 

    With our implementation you can always perform a new DFU there is an issue with the application and the bootloader is the fallback should anything happen to the app. 

    Best regards

    Bjørn 

Reply
  • +1

    Hi Pawel, 

    This is possible, however, this will require major changes to the bootloader as well as in the application code. 

    The first think you would need to address is the SoftDevice interrupt forwarding scheme, i.e. the SoftDevice expects the application to be located directly after the SoftDevice. 

    Hence, if you want to have multiple applications in the application space you will need to create a small application, placed directly on top of the SoftDevice, that forwards the SoftDevice interrupts/events to the correct application. This is similar to what we do in our MBR when jumping to the bootloader if it is present and directly to the application if not, see Master boot record and bootloader in the Softdevice specification for more information. 

    The second hurdle you would have to pass is modifying the bootloader so that the DFU banks starts after this application MBR and find a way to tell the application MBR where the new and old application starts. We use the UICR registers for this with the bootloader, but in our case the bootloader start address is fixed, in your case i would imagine that the application may grow in size. It is possible to modify the UICR registers from runtime, but if a power failure occurs during the update you might end up with a bricked device if the jump address(es) are only partially written. 

    The third hurdle is the actual DFU process, you will have to modify the bootloader so that the old application is not erased after the new image has been received and validated and then update only one of the two merged applications. 

    With our implementation you can always perform a new DFU there is an issue with the application and the bootloader is the fallback should anything happen to the app. 

    Best regards

    Bjørn 

Children
No Data
Related
Terms of service