Best way to locate a buttonless device in DFU mode

[Rob]

I'm using the experimental buttonless DFU app in SDK v13 to automatically change a device without buttons to run in DFU mode for an update.

I'd like to automatically reconnect o the device after the mode switch in the same way as the nRF connect app dues during DFU.

However, once the mode has been switched, the device appears with a different UUID. What is the best way of automatically finding the device again once in this mode?

Ways I can think of (none of which seem guaranteed):

• The new device UUID seems to always be one more then the initila device, can this be relied on and use a "guessed" UUID
• Select a device with the name "DFUTarg". Perhaps the first one found or the ose with the strongest RSSI

Any help appreciated.

Cheers,

Rob

[atune]

Indeed, the default Nordic implementation changes the device MAC address (you speak of UUID) by incrementing the last octet by 1.

nrf_ble_dfu.c:

static uint32_t gap_address_change(void)
{
...
    sd_ble_gap_addr_get(&addr);
...
// Increase the BLE address by one when advertising openly.
    addr.addr[0] += 1;
...
    sd_ble_gap_addr_set(&addr);
...
}

So yeah, you can trust that the MAC is always +1 to the original and use that to connect to the right device.

---

The implementation also uses the device name "DfuTarg" by default, which is advertised and Nordic tools may also use this name to connect to the device.

nrf_ble_dfu.c:

#define DEVICE_NAME "DfuTarg" /**< Name of device. Will be included in the advertising data. */

and

 err_code = sd_ble_gap_device_name_set(&sec_mode,
                                      (const uint8_t *)DEVICE_NAME,
                                      strlen(DEVICE_NAME));

What I have personally done for now - since I needed to take the reference DFU into use ASAP with as little changes as possible - is changing the device name to "DfuAB:CD" where AB:CD are the last two octets of the MAC address. This way you can use the device name itself to more easily connect to the right device (e.g. using nrfutil without any modifications).

So for example

• Original MAC address (FICR): 12:34:56:78:9A:BC
• DFU MAC address: 12:34:56:78:9A:BD
• DFU Device Name: Dfu9A:BD

Best way? Don't know. But it works predictably. At least it's a step to the right direction. I'll probably be branching from the reference implementation quite a bit in the future, but for now this has been a good first step for me.

[dingari]

This snippet is taken from nrf_ble_dfu.c in the SDK:

static uint32_t gap_address_change(void)
{
    uint32_t            err_code;
    ble_gap_addr_t      addr;

#ifdef NRF51
    err_code = sd_ble_gap_address_get(&addr);
#elif NRF52
    err_code = sd_ble_gap_addr_get(&addr);
#else

#endif

    VERIFY_SUCCESS(err_code);

    // Increase the BLE address by one when advertising openly.
    addr.addr[0] += 1;

#ifdef NRF51
    err_code = sd_ble_gap_address_set(BLE_GAP_ADDR_CYCLE_MODE_NONE, &addr);
#elif NRF52
    err_code = sd_ble_gap_addr_set(&addr);
#else

#endif

    VERIFY_SUCCESS(err_code);

    return NRF_SUCCESS;
}

so I think it's safe to assume that the address will always be one more than the address of your peripheral.

Edit: Didn't see the above answer before posting this.

[bjorn-spockeli]

You could also add an additional characteristic to both the DFU service of the app and the bootloader that contains a unique ID of some sorts and use it to determine if you've connected to the correct "DFUTarg". As far as I know the nRF Connect app simply uses the address, i.e. device address +1, to identify the device.

[atune]

Heh I've been so hasty that I've completely omitted the address-based option in your tools. :) In that case it's even more straightforward even without changing the device name.

[Rob]

Hi all,

Thanks for the feedback and confirming the possibilities!