DA14683, Custom Board, Custom Software Project, SDK1.0.14
Situation:
I am using ble_gap_address_set() function to configure a PRIVATE_STATIC_ADDRESS type at run time. This code is being run from the BLE_task()
Here is a code snippit:
uint8_t bleMAC[6] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06};
static own_address_t user_bd_address = { .addr_type = PRIVATE_STATIC_ADDRESS, }; memcpy(user_bd_address.addr, bleMAC, 6);
//Then later after the ble_gap_name_set() call I call....
ble_gap_address_set(&user_bd_address, 0x00FF);
This appears to be successfully assigning the correct address. I am able to see the correct BLE address using the phone device (both android and iOS), and I am able to pair/bond with passkey authentication to that address successfully.
Problem:
After disconnecting from that initial pair/bonding connection with the phone devices, I am unable to reconnect to the DA14683. Neither android or iOS can reconnect successfully while they have the pair/bond information for the DA14683 saved. If I "forget" the DA14683 at the OS level then I am able to initiate a new pair/bond connection successfully, but again, once I disconnect I am unable to reconnect until I "forget" the device at the OS level.
More data:
If instead of using the PRIVATE_STATIC_ADDRESS from the ble_gap_address_set() function as described above, and I use the default PUBLIC_STATIC_ADDRESS as set in the custom_config_qspi.h:
#define defaultBLE_STATIC_ADDRESS { 0x07, 0x00, 0x80, 0xCA, 0xEA, 0x80 }
Then both android and iOS can connect/pair/bond and reconnect successfully.
Questions:
1) Do you see any issues with the way I am assigning the BLE Address in the code snippit above?
2) When using PRIVATE_STATIC_ADDRESS from the ble_gap_address_set() function as described above, Why would the phone devices (both android and iOS) be able to connect/pair/bond initially, but fail subsequent connection attempts while the pair/bond information is stored in the OS?
Hi Nathan,
The two MSBs of a random static address shall be equal to 1.
Can you please try to test is with this one ?
uint8_t bleMAC[6] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x80};
or
uint8_t bleMAC[6] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0xC0};
The BD Address will be inverted so in the first case will be : 80 05 04 03 02 01
Best regards,
PM_Renesas
I got the value of ".addr = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06},"
straight from the DA1468x advertising tutorial here: lpccs-docs.renesas.com/.../code_overview.html
0x80 = 0b10000000
0xC0 = 0b11000000
Only 0xC0 sets the two MSB both to 1. Why would 0x80 work?
Is this requirement for the two MSB of the BLE address to both be equal to 1 documented anywhere?
Testing results:
I tested this with both values and I get the same original result (problem). I can connect and pair/bond with passkey, but if I disconnect I am unable to reconnect until I "forget" the device at the OS level.
How do I even go about debugging where this is failing? I am not aware of any documentation describing the ble connection process in this detail.
1) What functions should I set breakpoints in if the DA14683 is the peripheral and is expecting a connection from a mobile device?
ble_mgr_gapm_connect_cmp_evt_handler?
ble_mgr_gap_connect_cmd_exec?
2) What is the first step of the BLE connection process if the DA14683 is the peripheral?
3) Do you have something like a flow chart?
Just as a heads up here about the consequences of this issue:
1) I need to be able to connect/pair/bond AND reconnect to continue software development of the mobile app
2) I need to have devices that have unique (not #define at compile time) BLE Addresses because I have multiple devices operating in the same area.
3) So this is an issue that I need to resolve quickly.
This thread appears to be almost exactly describing the issue I'm having here, but with mbed platform: https://github.com/ARMmbed/mbed-os/issues/13499#issuecomment-681864797
Is this an issue here with the DA14683 as well? From that thread:
"after pairing, it is not possible with the latest iOS to authenticate again if the initiation/advertising address isn't the Identity address exchanged during pairing or a resolvable private address derived from the identity address. This change is specific to iOS 13 if I'm not mistaken.It might be implemented by other Android vendors like Samsung too but it isn't by all on the latest Android version (Google, Huawei, ...).On Cordio, the identity address used by the device is always the public address, so to reconnect after bonding you must use the public address at the moment."
If I used the public_static_address (#define in custom_config) everything works. If I set a private_static_address (ble_gap_address_set) I can't reconnect after initial pair/bond/disconnect.
Instead of spending more time working on this issue as described above, I am changing the way the the DA14683 handles addresses to use "Private Random Resolvable address using LE privacy v1.2" as described in this thread:
https://renesasrulz.com/wireles-connectivity/f/bluetooth-low-energy/21031/example-wanted-for-private-random-resolvable-addresses
There are still issues to sort out with that process as described in this thread:
renesasrulz.com/.../da14683-private-random-resolvable-address-using-le-privacy-v1-2-issues
So while I never got the original issue here working correctly, this is essentially closed because of the change of direction.
Nathan.L.Cook said:Instead of spending more time working on this issue as described above, I am changing the way the the DA14683 handles addresses to use "Private Random Resolvable address using LE privacy v1.2" as described in this thread: https://renesasrulz.com/wireles-connectivity/f/bluetooth-low-energy/21031/example-wanted-for-private-random-resolvable-addresses
Let's follow up on the new forum thread. I am working on the new one.
Regards,