• State Verified Answer
  • Replies 6 replies
  • Subscribers 74 subscribers
  • Views 848 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

    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.

  • 0 in reply to Anthony Ambuehl

    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

Reply
  • 0 in reply to Anthony Ambuehl

    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

Children
No Data
Related
Terms of service