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

Migrate from SDK15 without bond sharing to SDK15 with bond sharing via DFU

Cyril Praz

Hello,

We have started to develop a software on SDK15 and have noticed later than it's now possible to deal with service changed indication to invalidate the device cache instead of increasing the bluetooth address by 1.  

We have then modified the firmware as follow:

  • set define NRF_SDH_BLE_SERVICE_CHANGED  to 1 for the application
  • set define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS to 1 for the application
  • set define NRF_DFU_BLE_REQUIRES_BONDS to 1 for the bootloader

If we flash this firmware and perform a DFU everything is working

As some devices can't be flashed directly we are wondering if it's possible to do a DFU to migrate from a firmware without bond sharing to a firmware with bond sharing.

We have tried to do it but apparently there is an hardfault where the watch try to find the peer data.

Some help will be great :)

Parents
  • +1

    Hello,

    What SDK version do you use? SDK15.0.0?

    This is a bit tricky, because if the bootloader and the application shares bonding information then this setting has to be included in the bootloader. The only way to change this over DFU is to update the bootloader via DFU. This is possible, but if you do this, the bootloader will advertise as DFU_Targ, but it will only accept images from bonded devices, and it doesn't have any bonding information. 

    I have a recommendation for you, which I will take in the end of this reply, but first, my colleague, Vidar explains this issue in the following DevZone ticket. It is sort of a chicken/egg problem. You can't update the bonding information (that is shared with the bootloader) without a bootloader that supports bonding, but you can't start this application without having a bootloader that supports it (the vector table will return an error). Vidar explains this in this ticket:

    https://devzone.nordicsemi.com/f/nordic-q-a/46927/update-app-bootloader-without-bonds-to-with-bond-by-dfu-in-single-shoot

    So, it is an option to adjust the bootloader to accept a packet from any device e.g. in a certain application-version, and then require the bonding information for any application-version larger than this. 

    You should be aware that there are some risks when you have a bootloader that requires bonding information. The issue is that if you are in DFU mode, and one of the devices for some reason loses the bonding information, then the device is bricked. Of course, it depends on the product, but if it is intended for customers, and you have 10 000 devices out in the field, then the probability that the DFU doesn't go through successfully the first time is not that low. In that case, if the init packet was accepted, and the bootloader deletes the old application, then the device only has the bootloader and bonding information. So far so good. 

    The issue is that if 500 of the 10 000 devices ends up in this case, maybe because of some user mistake, or the battery runs out during this process, it is quite likely that someone tries to "forget device" in the phone settings to get a fresh start. If they do, then the device is bricked, because they will not be able to connect because they lack the bonding information, and in reality, noone can update this device. 

    An alternative is to protect the buttonless_dfu service with bonding requirements. This way, only a known device can put the device in DFU mode. At this point anyone can try to update the device, but the bootloader will still only accept valid, signed images. The only risk er is Denial of Service attacks (someone that keeps connecting to it), but in reality, the correct user/owner will be able to connect eventually. 

    I hope this clears things up a bit. Let me know if something was unclear. 

    BR,

    Edvin

Reply
  • +1

    Hello,

    What SDK version do you use? SDK15.0.0?

    This is a bit tricky, because if the bootloader and the application shares bonding information then this setting has to be included in the bootloader. The only way to change this over DFU is to update the bootloader via DFU. This is possible, but if you do this, the bootloader will advertise as DFU_Targ, but it will only accept images from bonded devices, and it doesn't have any bonding information. 

    I have a recommendation for you, which I will take in the end of this reply, but first, my colleague, Vidar explains this issue in the following DevZone ticket. It is sort of a chicken/egg problem. You can't update the bonding information (that is shared with the bootloader) without a bootloader that supports bonding, but you can't start this application without having a bootloader that supports it (the vector table will return an error). Vidar explains this in this ticket:

    https://devzone.nordicsemi.com/f/nordic-q-a/46927/update-app-bootloader-without-bonds-to-with-bond-by-dfu-in-single-shoot

    So, it is an option to adjust the bootloader to accept a packet from any device e.g. in a certain application-version, and then require the bonding information for any application-version larger than this. 

    You should be aware that there are some risks when you have a bootloader that requires bonding information. The issue is that if you are in DFU mode, and one of the devices for some reason loses the bonding information, then the device is bricked. Of course, it depends on the product, but if it is intended for customers, and you have 10 000 devices out in the field, then the probability that the DFU doesn't go through successfully the first time is not that low. In that case, if the init packet was accepted, and the bootloader deletes the old application, then the device only has the bootloader and bonding information. So far so good. 

    The issue is that if 500 of the 10 000 devices ends up in this case, maybe because of some user mistake, or the battery runs out during this process, it is quite likely that someone tries to "forget device" in the phone settings to get a fresh start. If they do, then the device is bricked, because they will not be able to connect because they lack the bonding information, and in reality, noone can update this device. 

    An alternative is to protect the buttonless_dfu service with bonding requirements. This way, only a known device can put the device in DFU mode. At this point anyone can try to update the device, but the bootloader will still only accept valid, signed images. The only risk er is Denial of Service attacks (someone that keeps connecting to it), but in reality, the correct user/owner will be able to connect eventually. 

    I hope this clears things up a bit. Let me know if something was unclear. 

    BR,

    Edvin

Children
Related