• State Not Answered
  • Replies 13 replies
  • Subscribers 25 subscribers
  • Views 478 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287804
Options

Characteristic UUID for buttonless bootloader changes between nrf SDK v.11.0.0 and SDK v15.3.0

user101226

Hello, 

I have been working with a BLE custom board project for a few months and the product requires buttonless DFU feature. The bootloader that I initially used was derived from SDK v.11.0.0 but I realized it didn't have all the features required for secure bootloading though buttonless DFU. Currently, I have successfully updated the bootloader to v.15.3.0 but the realized the buttonless DFU feature no longer works. Reading the documentation for both versions, I couldn't find the UUIDs for control point to which the designated value is written to initiate the DFU process. Has the value of NORDIC_VENDOR_BASE_UUID from v.15.3.0 example change from the base UUID represented in v.11.0.0? 

  • 0 in reply to user101226

    Hi,

    I can think of a few reasons that is worth checking out.

    First of all, are you using the buttonless DFU service from later SDKs now, or are you using the old (legacy) buttonless DFU service? If there is a mismatch between the buttonless DFU service (secure or legacy) and the DFU service in the bootloader, the app may filter on wrong parameters when scanning for the device again after it has reset into DFU mode.

    Secondly, is the BLE address incremented by 1 while in bootloader mode? That should always be done when using DFU without bonding in the bootloader, also in the legacy bootloader, but it is worth double-checking.

  • 0 in reply to user7377
    user7377 said:
    First of all, are you using the buttonless DFU service from later SDKs now, or are you using the old (legacy) buttonless DFU service? If there is a mismatch between the buttonless DFU service (secure or legacy) and the DFU service in the bootloader, the app may filter on wrong parameters when scanning for the device again after it has reset into DFU mode.

    By buttonless DFU service, do you mean the BLE service set with the UUID 0xFE59. If so yes, and the corresponding characteristics (control, packet and without bonding) from the table above.

    user7377 said:
    Secondly, is the BLE address incremented by 1 while in bootloader mode? That should always be done when using DFU without bonding in the bootloader, also in the legacy bootloader, but it is worth double-checking.

    Yeah, it is present in the bootloader under the function gap_address_change() which is called by gap_params_init(), which in turn is called by the function, ble_dfu_transport_init()

  • 0 in reply to user101226

    So you are using the buttonless service (with the correct "new" UUIDs from SDK 15.3 (or other "new" SDK with the secure bootloader? And you are using the secure bootloader. If so, then that should be good. Then I do not immediately have any other ideas.

    Perhaps to get more info you could test with nRF Connect for Android instead - does it fail to connect after entering DFU mode as well? If so, can you upload the full debug log from the app here? You could also make a sniffer trace of the communication both when entering DFU mode and of the nRF advertising afterwards. That way we would know both what happens on air, what the nRF is advertising after entering DFU mode and what the Android log says. Looking at that together could hopefully give some pointers.

Related
Terms of service