This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless DFU Example broken

Hi there,

I know you guys are very busy and I appreciate your quick response on Devzone.

I'd like to make a request for a more polished example of Buttonless DFU using SDK 12.1 with nRF52.

We are nearing production and if there's anything I'd like to get in concrete, it's a reliable way to upgrade firmware in the field.

The current example is not working out of the box, and the documentation doesn't offer a complete start to finish of how to upgrade. For example, what should we do after we send a 0x01 to the characteristic?

Thanks, Paul

Parents
  • I'm interested by the topic and I guess I'm not the only one! Can you please share the developments with the community..?

  • Hi, The out come from the discussion on support portal was to not do bond forwarding and only do address change when switching to bootloader. Here is some quote explaining:

    The main reason why bonding does not provide a benefit is that the upgrade image is signed, so the upgrade can only be performed with a valid image. The real issue when it comes to security for buttonless DFU is to prevent an attacker to put the device in DFU mode, as we discussed, which is independent of bonding used for DFU or not.

    If bonding information is shared between bootloader and application there are some cases that could lead to problems. For example, if the application deletes the bond after the bootloader has started, the bonding information will be invalid. In that case, the bootloader need a way to delete the bonding information. Another situation is where the upgrade is aborted for some reason, and the device is reset into the bootloader (possibly with an invalid application if the application is so large that single bank DFU is needed). In that case, the application cannot be run in order to transfer bonding information to the bootloader. There are other corner cases as well.

    The conclusion from our DFU team is that with the current solution, the only benefit of sharing bonding information is that there is no need to change the device address, and that this does not outweigh the disadvantages. That is why we have not implemented sharing of bonding information at the moment, and does not have immediate plans to do not. Nor do we recommend modifying the application and bootloader for sharing bonding information.

Reply
  • Hi, The out come from the discussion on support portal was to not do bond forwarding and only do address change when switching to bootloader. Here is some quote explaining:

    The main reason why bonding does not provide a benefit is that the upgrade image is signed, so the upgrade can only be performed with a valid image. The real issue when it comes to security for buttonless DFU is to prevent an attacker to put the device in DFU mode, as we discussed, which is independent of bonding used for DFU or not.

    If bonding information is shared between bootloader and application there are some cases that could lead to problems. For example, if the application deletes the bond after the bootloader has started, the bonding information will be invalid. In that case, the bootloader need a way to delete the bonding information. Another situation is where the upgrade is aborted for some reason, and the device is reset into the bootloader (possibly with an invalid application if the application is so large that single bank DFU is needed). In that case, the application cannot be run in order to transfer bonding information to the bootloader. There are other corner cases as well.

    The conclusion from our DFU team is that with the current solution, the only benefit of sharing bonding information is that there is no need to change the device address, and that this does not outweigh the disadvantages. That is why we have not implemented sharing of bonding information at the moment, and does not have immediate plans to do not. Nor do we recommend modifying the application and bootloader for sharing bonding information.

Children
No Data
Related