hexfile release for SDK 7.0.1+ for softdevice update testing?

[Anthony Ambuehl]

I have developed an bootloader operating with external flash for image storage.  For the use case it is not acceptable to put the device into an inoperable (no-application) state while receiving an application over BLE, therefore during a softdevice update both the softdevice+bootloader and application are stored in external flash before the DFU procedure begins transferring data.

I ran into quite a few unexpected issues around the sd_req check, that I believe I have worked around.  I now need to perform tests that demonstrate the softdevice/bootloader/application update without breaking.  Since I built my code based on the latest SDK, my test is already starting with the latest version of the SDK.  Is there someplace I can download an SDK with version greater than 7.0.1?

[Karl Ylvisaker]

Hello,

Since I built my code based on the latest SDK, my test is already starting with the latest version of the SDK.  Is there someplace I can download an SDK with version greater than 7.0.1?

The latest version of the nRF5 SDK is v.16.0.0, and the latest SoftDevice versions is currently v.7.0.1 - For the time being, these are the latest versions available for download.

I ran into quite a few unexpected issues around the sd_req check, that I believe I have worked around.

What unexpected issues did you encounter, and what workarounds did you implement to resolve them?
When generating the DFU package the --sd-req argument shall be the SoftDevice ID currently operating on the device, and the --sd-id argument shall be the SoftDevice ID of the new SoftDevice.

If you need to demonstrate that the SoftDevice can update without breaking, you could perhaps downgrade a SoftDevice version, and then upgrade it again to v.7.0.1?

Just keep in mind that if the SoftDevice is updated, then the application must be updates as well, since it is dependent on the SoftDevice. When updating between major SoftDevice releases, you will also have to update the bootloader. Also, when updating between major SoftDevice releases(v.6.* to v.7.*, as an example) you need to be mindful of API changes made between releases.

Best regards,
Karl

[Anthony Ambuehl]

Hi Karl,  

  You touched on the big issue that I had to workaround.  The sd_req checking just doesn't make sense.  I'm curious how softdevice updates work at all with the existing SDK, I cannot see how the sd_req can be met.  In nrf_dfu_ver_validation, the sd_req_check function always checks the sd_req against the currently active softdevice.  This check cannot be correct when performing a softdevice+bootloader with application update with a new softdevice since the same sd_req is present on both the softdevice+bootloader image and the application.

If I do as you recommend, making the sd_req match the existing softdevice, then after the softdevice is updated, the application will not load since the sd_req does not match the new softdevice version.  If I make the sd_req match the upgraded softdevice, then the softdevice+bootloader will fail since the sd_req does not match the existing softdevice.  If I include both the old and new softdevice in the sd_req then it fails to enforce the requirement to update the softdevice for the new application.  (the application might be loaded without the updating the softdevice)

To workaround this issue, I disable the sd_req_check when the type is DFU_FW_TYPE_SOFTDEVICE_BOOTLOADER.  This seems reasonable to me, since a softdevice update doesn't need to check the type of the existing softdevice  which will be replaced.

To avoid issues with softdevice API changes, I only allow 2 types of update:

Full system update: application sd_req must match sdid of provided softdevice+bootloader

Application only update: sd_req must match sdid of existing softdevice

Theoretically, it might be possible to support application+bootloader update, however IIRC the nrfutil tool does not supports generating this combination, therefore it cannot be verified.

[Karl Ylvisaker]

Hello,

Anthony Ambuehl said:

The sd_req checking just doesn't make sense.

I would beg to differ, since both the bootloader and application depends on SoftDevice verison, it is paramount that these match.
For instance, if you were to update your device with a new SoftDevice only, then the device would be bricked when the bootloader no longer works. 
The bootloader is made to be very versatile while still preventing users from bricking their devices - thus the need for the --sd-req check.
However, if you are ok with limiting yourself to the two types of updates your describe, then your disabling of the sd_req_check is fine.

Anthony Ambuehl said:

This check cannot be correct when performing a softdevice+bootloader with application update with a new softdevice since the same sd_req is present on both the softdevice+bootloader image and the application.

Anthony Ambuehl said:

If I include both the old and new softdevice in the sd_req then it fails to enforce the requirement to update the softdevice for the new application.  (the application might be loaded without the updating the softdevice)

Yes, this part is sadly not that intuitive. When you are updating both SoftDevice + Bootloader and application, there are really two updates happening in series, therefore you will need to provide two arguments to the --sd-req check. First, the SoftDevice + Bootloader update happens, which requires the current SoftDevice ID. Then, the application updates, which requires the new SoftDevice ID.

In essence, since SD+Bootloader and application updates essentially are two updates, you will need to provide the sd-req argument twice, separated by a comma.

Looking into this now I do agree that this is not elaborated on as much as it should be, and I will speak to one of my colleagues about how we may improve on this. Apologies for the confusion this has caused.

Best regards,
Karl

[Anthony Ambuehl]

I agree softdevice must match the bootloader, however the sd_req on a softdevice update doesn't tell us much about the sd_req of the bootloader that is already present.  

Regarding bricking the device, many end-users I have dealt with decided the device was bricked when it was sitting in bootloader waiting for DFU.  The primary application was not runnable and until the companion/mobile phone app completed the update process they would never be able to use it again.  This is my 5th product using nordic BLE bootloader, this has an been an issue with all of them. 

For products that require a high degree of reliability. (e.g. medical/therapeutic devices), I am no longer recommending the bluetooth dfu transport in bootloader, unless there is a method to indicate the update is in progress to the user.  This would usually require integrating a driver for a screen into the bootloader which would significantly increase the bootloader size.  

Also, please correct me if I'm wrong... there is a major advantage of using the softdevice+bootloader update in a single step, the new bootloader (and eventually the application) will never run with the currently installed softdevice.  Therefore in the case of p_init->type == DFU_FW_TYPE_SOFTDEVICE_BOOTLOADER there is no need to perform sd_req checking at all.  There are no requirements of the existing softdevice, since the softdevice and bootloader will be replaced.

Furthermore as I explained, I don't see listing both the old and new softdevice in the sd_req as a safe approach.  If the new bootloader or application are NOT compatible with the old softdevice then its important not to allow them to be updated without a softdevice update.  In my situation where both images (softdevice+bootloader and application) are downloaded and saved before any update begins, I believe it is safest to disable the sd_req check for the softdevice+bootloader and add a pre-validation step to confirm the soft_device+bootloader matches the sd_req of the stored application.  Please advice if you see any reason this would be problematic.

Actually it would be really appreciated if in the future Nordic could provide an example bootloader with external storage capability.  I have been adding it on to the existing bootloader as an additional dfu transport, but its not a perfect fit.  Certain assumption like this sd_req checking should work differently in this use case.

[Karl Ylvisaker]

Hello,

Sorry for my late reply.

Anthony Ambuehl said:

Regarding bricking the device, many end-users I have dealt with decided the device was bricked when it was sitting in bootloader waiting for DFU.

 Yes, I agree that a device sitting in DFU mode is likely to be indistinguishable from a bricked device for an end user. However, I personally have not heard back about this from customers before. I will mention this to a colleague and see if she has heard anything about it.

Anthony Ambuehl said:

This would usually require integrating a driver for a screen into the bootloader which would significantly increase the bootloader size.

I suppose any kind of feedback to the user might fulfill the same purpose here, for example a rapidly blinking/changing LED - to avoid having to include a screen driver. Of course, this is dependent on the application/device, and what peripherals it has available.

Anthony Ambuehl said:

Furthermore as I explained, I don't see listing both the old and new softdevice in the sd_req as a safe approach.  If the new bootloader or application are NOT compatible with the old softdevice then its important not to allow them to be updated without a softdevice update.  In my situation where both images (softdevice+bootloader and application) are downloaded and saved before any update begins, I believe it is safest to disable the sd_req check for the softdevice+bootloader and add a pre-validation step to confirm the soft_device+bootloader matches the sd_req of the stored application.  Please advice if you see any reason this would be problematic.

The only time you would need to include both the old and new SoftDevice is when both SoftDevice and Bootloader is updated in the same package, which makes it safe since they are being updated at the same time.

Apart from limiting your options for the DFU as I mentioned earlier, I do not see any reason why your approach should be problematic.

Anthony Ambuehl said:

Actually it would be really appreciated if in the future Nordic could provide an example bootloader with external storage capability.  I have been adding it on to the existing bootloader as an additional dfu transport, but its not a perfect fit.  Certain assumption like this sd_req checking should work differently in this use case.

I have noted your request for an example bootloader with external storage capabilities, and I have created an internal request with the SDK team to create such an example, thank you for your suggestion - we appreciate the feedback!

As for the last part, it is of utmost importance to us to disable customers from bricking their devices when performing a bootloader DFU, while we still would like to offer a highly versatile DFU framework to develop with. This comes with some extra overhead, but with the benefit of making it virtually impossible to accidentally bricking the device. I will confer with some colleagues to hear their thoughts on this.

Thank you for bringing up your concerns and thoughts on this!

Best regards,
Karl