[DFU] Is the peripheral doing direct advertisement at bootloader?

RE: [DFU] Is the peripheral doing direct advertisement at bootloader?

Vidar Berg — Wed, 09 Mar 2016 08:28:09 GMT

In dfu_app_handler.c you can see that the address is being set with the dfu_ble_svc_peer_data_set function (SV instruction - SV call is located in bootloader). The restriction in CoreBluetooth is that the IRK is only distributed during bonding. This means you can do directed advertisement when not bonded, and whitelist or normal advertisement when bonded (privacy enabled).

RE: [DFU] Is the peripheral doing direct advertisement at bootloader?

MANGO — Wed, 09 Mar 2016 07:22:36 GMT

Do you mean after disconnecting at the main program (like NUS example) and

jumping to the bootloader, the board also knows the address of the central

(in this case, my iPhone's resolvable address or static address) ?

This is a part about share a static address.

As far as I know, I thought iOS CoreBluetooth has many restrictions about giving the phone's address.

If so, can you tell which function / method / delegate makes it share the address?

(From the DFU functions and the DFU library)

RE: [DFU] Is the peripheral doing direct advertisement at bootloader?

Vidar Berg — Mon, 07 Mar 2016 10:28:52 GMT

correct, it won't do bond sharing if only paired, but it the application can still share a static address so the bootloader can do directed advertising.

RE: [DFU] Is the peripheral doing direct advertisement at bootloader?

MANGO — Mon, 07 Mar 2016 05:20:47 GMT

Thanks, what about if the peripheral uses a service that uses pairing, not bonding (like NUS)?

In this case, I think the bootloader won't use the bond sharing.

RE: [DFU] Is the peripheral doing direct advertisement at bootloader?

Vidar Berg — Thu, 03 Mar 2016 12:46:08 GMT

Hi, the bootloader uses the dfu_ble_peer_data_t (bond sharing) received from the application to either start direct or whitelist advertising, and whitelist advertising will be used when the address type is private resovable (resolved with IRK). Note that it is the iphone app that attempts to re-connect.