• State Not Answered
  • Replies 13 replies
  • Subscribers 25 subscribers
  • Views 464 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? 

Parents
  • 0

    Hi,

    The UUIDs are different, yes. The UUID for the Secure bootloader service is 0xFE59 (see also documentation for the buttonless secure DFU service that is used to trigger DFU mode). Note that it it is not only the UUID that is different between the SDK 11 legacy bootloader and the SDK 15.3 secure bootloader - they are in fact completely different. So you cannot re-use any DFU related code going from the legacy DFU bootloader to the secure DFU bootloader.

  • 0 in reply to user7377

    Thanks for the response! I understand the bootloader code is different between the versions, but I would like to know what does it mean for the DFU function on the application code? When you mention that we can't reuse any DFU related code, do you mean the functions provided in the SDK, or examples or both (on application that is)? In my application code, I only check for the control point characteristic to see if it received the value 0x0001 and set the GPREGRET TO 0XB1 and reset start the device to enter the bootloader code. Has that changed in the new version? Also, I want to make sure if I have understood the updated UUIDs right, so I have attached a table here; If you can verify and confirm, that would be greatly appreciated!

    UUID list UUID number for version 11.0.0 UUID number for version 15.3.0
    DFU OTA primary service 00001530-1212-EFDE-1523-785FEABCD123 FE59
    Control point UUID 00001531-1212-EFDE-1523-785FEABCD123 8EC90001-F315-4F60-9FB8-838830DAEA50
    Packet UUID 00001532-1212-EFDE-1523-785FEABCD123 8EC90002-F315-4F60-9FB8-838830DAEA50
    DFU with bonds n/a 8EC90003-F315-4F60-9FB8-838830DAEA50
    DFU without bonds n/a 8EC90004-F315-4F60-9FB8-838830DAEA51

      

  • 0 in reply to user7377
    user7377 said:
    Do you get any more logs before the application starts or is this it? Also, how long does it take before the application is started?

    Yeah, there are logs on the WDT timer feed and the application starts right after the end of the log. The device gets out of the bootloader two minutes after entering the bootloader. Here is the rest of log:

    <debug> app: Enter main loop
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005994)
<debug> app: timer_fire (0x20005994)
<debug> app: timer_activate (0x20005994)
<info> nrf_bootloader_wdt: Internal feed
<debug> app: timer_stop (0x20005984)
<debug> app: timer_fire (0x20005984)
<info> app: Inactivity timeout.
<debug> app: Resetting bootloader.
<info> nrf_dfu_settings: Backin<info> app: Inside main
<debug> app: In nrf_bootloader_init
<info> app: MAIN: last_reboot_reason = 0
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from

    The RESETREAS seems to be zero as well.

    user7377 said:
    for instance check if this happens if you test without enabling the WDT (just to rule it out)?

    So, I tried disabling the WDT on the application and now the device stays in bootloader but the firmware still doesn't update. But I can update the firmware through OTA once the device is stuck in the bootloader and before the bootloader timeout reset takes place.

    It doesn't seem the WDT being the issue since the bootloader feeds the watchdog properly, and the issue persists even with the WDT turned off.

  • 0 in reply to user101226

    Hi,

    Aashyk said:
    But I can update the firmware through OTA once the device is stuck in the bootloader and before the bootloader timeout reset takes place.

    I see - what exactly is the issue then? Is it that the phone app does not automatically connect to the device after it entered DFU mode and you need to scan for devices and connect to it again, and then do the DFU? Or something else?

  • 0 in reply to user7377

    user7377 said:
    Is it that the phone app does not automatically connect to the device after it entered DFU mode and you need to scan for devices and connect to it again, and then do the DFU? Or something else?

    Yes, the phone app fails to recognize that the device is in the bootloader and therefore the device times out of bootloader and enters the application code after a while. If I abort and restart the DFU process before the device jumps to the application code, OTA DFU works.

    I am wondering if I have missed some key information with implementing the buttonless feature on the application code so that it is compatible with the Nordic DFU app

  • 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()

Reply
  • 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()

Children
  • 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