Best way to locate a buttonless device in DFU mode

RE: Best way to locate a buttonless device in DFU mode

Rob — Mon, 15 May 2017 14:18:00 GMT

Hi all,

Thanks for the feedback and confirming the possibilities!

RE: Best way to locate a buttonless device in DFU mode

atune — Mon, 15 May 2017 11:30:31 GMT

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.

RE: Best way to locate a buttonless device in DFU mode

bjorn-spockeli — Mon, 15 May 2017 11:18:16 GMT

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.

RE: Best way to locate a buttonless device in DFU mode

dingari — Mon, 15 May 2017 11:16:59 GMT

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.

RE: Best way to locate a buttonless device in DFU mode

atune — Mon, 15 May 2017 11:09:44 GMT

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.