DFU address conflict

[Fluffy12]

When performing a DFU the 2nd stage increments the expected device BLE address by 1 when the device being updated reboots.  This potentially conflicts with the address of an existing BLE device.  Specifically, the DFU can connect with either device if they are both advertising.  The question is how to best handle this.  Separating device addresses in manufacturing by 2 isn't an option because the BLE address is used as the device serial number.

When a connect occurs, is it possible to get the data from the advertisement that the nRF used for connecting?  Obviously the DFU advertisement is different from the normal device advertising so that would allow at least detecting that the wrong device was connected.  I don't think there's a way to filter actually connecting based on advertising data.  Enumerating characteristics is expensive in terms of time/power.  We are using SDK 15.3.

Regards,

Mike

[Edvin]

Hello,

You shouldn't really set the addresses like this in a series. Using address incrementation for DFU is quite common. Do you need to put the serial number in the BLE address? BLE addresses should be randomly generated, so that the chance of them being two of the same is minimal.

Best regards,

Edvin

[Edvin]

What is your DFU master device? How does it determine what to connect to during a DFU?

[Fluffy12]

It is not realistic to use random addresses.  We use advertising data in a remote sensing application.  We would have no way to map sensors with random MAC addresses.  Instead we use the device serial number, which is the 6 byte BLE MAC address.  Since these are programmed sequentially during manufacturing there is zero chance of them being the same, except during the 2nd part of a DFU

[Fluffy12]

The DFU master is an nRF52840 running SDK 15.3.  A server initiates the OTA.  We'd like to maintain compatibility w/ other Nordic DFU mechanisms like nRF Connect and the nRF Toolbox.  The DFU master software code is basically vanilla SDK 15.3/nRF Connect code but we can alter it if necessary.

The DFU process is that a server sends a command to the nRF52 to update a specific sensor.  The sensors are also nRF52840s running SDK 15.3.  When the nRF52 sees a periodic advertisement from a sensor and that sensor needs to be updated then the nRF52 connects to the sensor and reboots it into the DFU mode.  The nRF52 has a local copy of the normal Nordic update package (SoftDevice/app with manifest).

The issue is when the sensor reboots for DFU it auto-increments the advertising address.  In that case if the sensor with that actual assigned address/serial number advertises in that window then the nRF52 will connect with it instead of the intended sensor.

I'd say this was a low probability event that a customer would have devices with sequential serial numbers and that both devices would advertise in that small window between rebooting for DFU and connecting except that it is happening.  The reason is similar to the Birthday Paradox.

[Edvin]

Fluffy12 said:

The reason is similar to the Birthday Paradox.

 I agree, but the birthday paradox has 365 possible values, while a BLE address has 2^48 = 281,474,976,710,656 possible values, so I would say that the probability is significantly lower, unless you manually hardcoded a serial number as the BLE address.

NB: The default BLE address of an nRF device is randomly assigned (not in serial) during production.

So have you manually changed the BLE address of the devices, or are they using the production address which is generated during production and stored in FICR?

If you have manually changed it, then I guess you are using the same method to change the bootloader's DFU address as well? In that case, I guess adding 3 or 20 to that address wouldn't matter.

You can of course also look at the advertising name (by default "DfuTarg") as well as the address when the DFU master is looking for the correct DFU target. This is used in iOS (nRF Connect for iOS) when performing a DFU, because the OS doesn't give access to BLE addresses. You can look into how the ble_app_buttonless_dfu example sets the advertising name using:

static uint32_t set_adv_name(nrf_dfu_adv_name_t * p_adv_name)

in ble_dfu_unbonded.c, line 78 (name and line number from SDK17.0.2).

Best regards,

Edvin