Can a SoftDevice + UART bootloader + application system support future SDK updates?

[alnordic]

Hello DevZone,

I am developing a system that has a SoftDevice, UART bootloader, and application. The SoftDevice is S132 SoftDevice v6.1.1. The UART bootloader and application are based on the examples from the nRF5 SDK v15.3.0. The application depends on the SoftDevice.

Will anything prevent this system from supporting future SDK updates?

Through reading the documentation and code, I've found that this system should be able to support future SDK updates.

• Bootloader:
  
  • The bootloader cannot be erased.
  • Because the UART bootloader does not depend on the SoftDevice, the SoftDevice can be upgraded to another major or minor version without compromising the bootloader.
  • The bootloader can be freely upgraded without affecting the SoftDevice or application.
• SoftDevice:
  
  • As long as DFU packages are generated using the --sd-req option, and the option matches the SoftDevice ID present on the system, the SoftDevice cannot be erased.
    • All DFU packages for this system can use the sd-req option, where the option matches the SoftDevice ID present on the system (I do not plan on performing any DFU where the application overwrites the SoftDevice).
  • The SoftDevice can be upgraded to another major version, but this will automatically compromise the application. This is not an issue, as the application can be replaced in the following DFU.
  • The SoftDevice can be upgraded to another minor version, and this will not affect the application.
• Application:
  
  • The application can be safely upgraded as long as the new application and current SoftDevice are from the same SDK.

Please confirm whether my findings are correct, and please let me know of any details that I've missed.

Thank you DevZone!

[tesc]

Hi,

Your findings are correct for nRF5 SDK v15.3.0. For earlier nRF5 SDK versions than 15.3.0, there has been restrictions such as Bootloader depending on SoftDevice also for serial transport, or any SoftDevice update (including minor updates) invalidating the application. Some of the remaining restrictions may be lifted or changed in the future, but there will be an upgrade path into future SDKs and SoftDevices. (After all, being able to upgrade is the key functionality of DFU.)

The requirement of SoftDevice compatibility is not strictly tied to SDK, as a project based on one SDK can be ported to use a different SoftDevice, most commonly a new minor version or bugfix version of a SoftDevice. So the application can be safely upgraded as long as the new application is built for the current SoftDevice.

The statement that "the bootloader cannot be erased" is a bit ambiguous. The bootloader will not erase itself, but it can update itself if given a correctly signed bootloader update. (Technically it would be possible to update the bootloader into a bootloader without DFU capabilities, for instance, or with other transport than UART.) You also have flash access from the application. But yes, as long as you do not do anything weird, either with bootloader or application, where you deliberately erase or overwrite parts of the bootloader, then the bootloader is safe, yes.

Regards,
Terje

[alnordic]

Thank you Terje!

Could I safely replace the UART bootloader with an OTA bootloader using the DFU, as long as the OTA bootloader is built for the current SoftDevice?

[tesc]

Hi,

That should work, yes, as long as the new bootloader is not bigger than the old one.

(Changing bootloader size as part of an update is theoretically possible, with some modifications to the bootloader, but it does involve a critical phase where if power is lost you will brick the device.)

Regards,
Terje

[alnordic]

tesc said:

That should work, yes, as long as the new bootloader is not bigger than the old one.

Hi Terje, will this still work if the new bootloader is bigger than the old one, but still within the Bootloader segment (0x0007 8000 - 0x0007 E000 as of nRF5 SDK v15.3.0)?

[Vidar Berg]

Yes, it will work as long as the new bootloader has the same start address and that it fits into the allocated memory range.