Bond Manager Issue

Question

Although there are some posts dealing with bond manager issues, I have not been able to find a similar issue. I am using part of the BLE code from nRFready Desktop 2 v1.0.4. I've found an issue with how the master GAP Address type are stored by the bond manager. 
 At a disconnection event the master bond is stored as follows: 
 
 case BLE_GAP_EVT_DISCONNECTED:
 s_conn_handle = BLE_CONN_HANDLE_INVALID;
 
 err_code=ble_bondmngr_bonded_masters_store();
 
 s_direct_adv_cnt = APP_DIRECTED_ADV_TIMEOUT;
 s_advertising_mode = BLE_DIRECTED_ADV; 
 break;

 
 If the device start advertising again, the following code is use to decided between direct or whitelist advertising: 
 
 if (s_advertising_mode == BLE_DIRECTED_ADV)
 {
 err_code = ble_bondmngr_master_addr_get(s_last_connected_master, &peer_address);
 if (err_code != NRF_SUCCESS)
 {
 s_advertising_mode = BLE_FAST_ADV_WHITELIST;
 }
 }

 
 The problem is that the function ble_bondmngr_master_addr_get is always returning and err_code = NRF_ERROR_INVALID_PARAM, looking at the definition of this function: 
 uint32_t ble_bondmngr_master_addr_get(int8_t master_handle, ble_gap_addr_t * p_master_addr)
{
 if (
 (master_handle == INVALID_MASTER_HANDLE) ||
 (master_handle >= m_masters_in_db_count) ||
 (p_master_addr == NULL) ||
 (
 m_masters_db[master_handle].bond.master_addr.addr_type
 ==
 BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE
 )
 )
 {
 return NRF_ERROR_INVALID_PARAM;
 }

 *p_master_addr = m_masters_db[master_handle].bond.master_addr;
 return NRF_SUCCESS;
}
 
 The last condition is true ( m_masters_db[master_handle].bond.master_addr.addr_type == BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE). And here is the issue, the address type is not stored or configured in the bond manager at all. I may have missed a function call or any SVC but I dunno where this variable is inizialited and where is stored in the bond manager. 
 Thanks for your help.

Audun · Accepted Answer

Hi, 
 there are several issues that can cause this behavior. First of all, I suggest upgrading to the bondmanager found in SDK 4.4.2. Compared to Desktop 2 v1.0.4, this bondmanager release fixes many issues, several of which are related to resolvable addresses (used most notably by iOS). 
 First off, is the condition ( m_masters_db[master_handle].bond.master_addr.addr_type == BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE ) true regardless of which Master you are connected to? When connected to for example the Nordic Master Emulator it should be false.
Let's assume that you are connecting to an iOS device, in which case it's expected that this is the correct address type. 
 Resolvable addresses can be changed at any time, and thus it doesn't make sense to use that address for directed advertising. Instead undirected advertising with a whitelist should be used. The Identity Resolve Key (IRK) is put in the whitelist, which makes it possible to recognize the Master even though it has changed its address. The bondmanager will handle IRKs and can be used to generate a whitelist for you ( ble_bondmngr_whitelist_get() ). Several bugs related to address types and IRK storage has been fixed lately, so again I suggest upgrading to SDK 4.4.2 bondmanager. 
 The address type can be found in ble_bondmngr.c, m_masters_db[x].bond.master_addr.addr_type. m_masters_db is a RAM struct. The contents of this struct is loaded from flash during bondmanager initialization. You can take a look at the flash storage area to see if there is any data there at all:
Open address FLASH_PAGE_BOND (default value 255 in DT2 v1.0.4) * 1024 in the debugger. If this area is all F's (flash erase value), then the data is invalid. If it's not just F's there is probably valid data there, and you can take a closer look at the m_masters_db array during bondmanager initialization. 
 Hope this helps!