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]

What is your DFU master device? How does it determine what to connect to during 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

[Fluffy12]

Yes, as mentioned, we set the serial number during manufacturing  to sequential BLE addresses and store the serial number in non-volatile memory.  That makes the address pool much smaller than all possible BLE addresses and the probability of adjacent addresses higher at sites with more than a handful of sensors.  And yes, the advertising address is adjusted during the DFU reboot to be the normal S/N + 1 in the lower byte.

Maybe I'm missing something, but while we advertise with the DfuTarg name after the reboot, there doesn't seem to be a parameter to sd_ble_gap_connect() in SDK 15.3 that would filter by advertising name instead of BLE address.  That's why I asked about the possibility of accessing the advertisement that the nRF saw when it connected to the sensor.  Is this filtering functionality available in a more recent SDK version?

If it matters, both the nRF and the sensors are S140.

I think our current approach is going to be to enumerate the characteristics with discovery to distinguish if the device is in DFU mode instead of normal operating mode.  It will nominally take more battery power but shouldn't occur very often.

Regards,

Mike 

[Edvin]

I see.

Fluffy12 said:

Maybe I'm missing something, but while we advertise with the DfuTarg name after the reboot, there doesn't seem to be a parameter to sd_ble_gap_connect() in SDK 15.3 that would filter by advertising name instead of BLE address

 Just to be clear, the advertiser (DfuTarg) is not the device that initiates the connection. It is always the scanner/central that sends the connection request via sd_ble_gap_connect(), and this takes the address as an input. The way to find the address is to start scanning and monitoring the advertising reports. When you see an advertising with a matching service or name, you can take the advertising address from there, and use it in sd_ble_gap_connect().

I understand your point now. Even if you scan and find the correct device, and then call sd_ble_gap_connect() with that address, you may actually connect to the other device with the same address in the same area. Yes. That is a possibility. That is the reason why you shouldn't serialize your addresses like this. 

However, should this happen, you should quickly discover, because you wouldn't see the services that you would expect the peripheral to have. If that happens, disconnect and try to connect again.

Best regards,

Edvin