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

[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