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

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?

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
  • +1 in reply to Anthony Ambuehl

    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

Related
Terms of service