• State Not Answered
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 3022 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 120427
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Latest status of Buttonless secure DFU in SDK 13.0

sam wagner

Hi,

I just got the email about SDK13.0 official release. The list of changes in this release include "Secure DFU improvements". What does it mean? Is Buttonless Secure DFU completely supported in this release?

Regards, Sam

  • 0

    Hi Sam,

    Compare to SDK v13 alpha, the buttonless example in the SDK v13 official doesn't change much.

    • It is still in experimental mode

    • Some issues on SDK v12 and 13 alpha were fixed such as the characteristic's write property missing, the bootloader_setting section missing were fixed.

    • Now we use RAM retention register GPREGRET to set the flag to enter bootloader mode instead of writing to flash.

    • Change the service's UUID to the Secure-DFU UUID

    • Change from the DFU control point property from notification to indication

    • Requires nRFutil v2.2.0

  • 0 in reply to Hung Bui

    Hi Hung,

    Thanks for the information. As far as I know, SDK12 does not support the sharing of BLE link encryption key between the bootloader and the firmware application.

    Does SDK13 support a case where [1] Central and Device are bonded using BLE encryption (say JUST WORKS) and [2] Phone App triggers DFU by writing into the DFU endpoint, thereby making the Device switch to bootloader mode, [3] then the phone App transfers signed DFU image over the air to the device, and [4] the Device jumps to the new image after that?

    We need to support the above scenario ASAP for our production code.

    Regards, Sam

  • 0 in reply to Hung Bui

    We don't support bond forwarding yet. But is it a firm requirement that the link has to be re-encrypted when you do DFU ?

    If it's OK to do DFU with an open link ( still secure DFU, just no bond) you can think of changing the address of the device when it switches to bootloader.

    This also require you to modify the DFU app on the phone to look for the new address after it write the command to tell the application to switch to the bootloader.

    If encryption is the requirement, you may have to think of writing some code to forward bond information and re-use it after you switch to bootloader. You can refer to what we have in the bootloader in SDK v11 to know how to do it.

  • 0 in reply to Hung Bui

    Thanks Hung!

    Is there plan to include support for sharing Bond Info between Application and Bootloader during DFU? If yes, when would it be available?

    Is there any example that shows how to change the address of the device when switching from Application to Bootloader?

    Regards, Sam

  • 0 in reply to Hung Bui

    @Sam: To change the address, it's pretty simple and already done in our DFU bootloader inside gap_params_init() , see gap_address_change() function.

    Regarding bond forwarding, I don't know when it will be officially included. But we tech support will try to come up with an example. I hope to have something ready by the end of this month or first week April.

Related

core_v2_widget.Hide()