Reset in nRF51 SDK v10 BLE Keyboard HIDS Example

Question

Hi, 
 We are using the BLE keyboard example as a basis for a design and notice strange behavior. 
 Only change was to create a custom_board.h header for a button press on my board to loop through the "hello" string and everything works great, until the central disconnects. Using an iPad, when I turn off Bluetooth the firmware resets with error code 0x8005, no line number and no file name. 
 I traced the reset down to this function call: 
 // Only Give peer address if we have a handle to the bonded peer.
 if(m_bonded_peer_handle.appl_id != DM_INVALID_ID)
 { 
 err_code = dm_peer_addr_get(&m_bonded_peer_handle, &peer_address);
 APP_ERROR_CHECK(err_code); // RESETS HERE

 err_code = ble_advertising_peer_addr_reply(&peer_address);
 APP_ERROR_CHECK(err_code); 
 }
 
 Digging a little further, it seems like m_bonded_peer_handle still points to the central but the central's ID is not in the internal peer table. The workaround for now is to remove the APP_ERROR_CHECK() that causes the reset and then not execute ble_advertising_peer_addr_reply() if there was an error, but that is not ideal. The workaround does however stop the reset from occurring and the device successfully repairs with the central (iPad) after it enables Bluetooth again. Using the 51822_xxAC 
 I've attached the code that is being used. Please help resolve this issue. Thanks! 
 main.zip 
 UPDATE 
 Attached is the complete project. I took the BLE example and ported it to our hardware via a custom_board.h via the documentation to give BSP a button to press for cycling 'hello' on our iPad. Using SDK v10.0.0, and the S110 SoftDevice v8.0.0. 
 BLE Keyboard on Custom Board.zip 
 The above modification to avoid the reset isn't present in the attached, the only changes are the addition of the SDK configuration headers per the documentation, namely custom_board.h for the BSP. So the code diff between the BLE keyboard example should show no differences. 
 The example code resets whenever the central disconnects (doing this via disabling Bluetooth in system settings). We are using an iPad with the latest iOS for testing. We are also noticing that if Bluetooth is turned off (same method) for about 15 minutes then enabled again, the peripheral connects but the HIDS doesn't work. Lastly, if the iPad forgets the peripheral and then I try to connect to it using another central device, it fails to connect. 
 UPDATE #2 
 In diff'ing the example in v10 SDK and in v11, there was this change that I backported. Seems like the error code I was seeing isn't a cause to reset and that was fixed in v11. 
 v10 v11 Diff 1 of 2.png 
 However, there are still the connection problems noted above and copied here: 
 
 
 if Bluetooth is turned off (same method) for about 15 minutes then enabled again, the peripheral connects but the HIDS doesn't work 
 
 
 if the iPad forgets the peripheral and then I try to connect to it using another central device, it fails to connect

Petter Myhre · Accepted Answer

Good that you found the fix in SDK 11, I wasn't aware of this bug. The function will return an error if the peer device uses random resolvable address, like iOS does. 
 
 if Bluetooth is turned off (same
method) for about 15 minutes then
enabled again, the peripheral connects
but the HIDS doesn't work 
 
 I tried to reproduce this, but I couldn't. I connected and bonded, then turned off Bluetooth on iOS. Then I waited for 17 minutes. Turned on Bluetooth on iOS, it connected, and the HID keyboard worked fine. Does this happen every time? Do you have access to a sniffer so we can see what is happening on air? 
 
 if the iPad forgets the peripheral and
then I try to connect to it using
another central device, it fails to
connect 
 
 The unmodified example will limit the number of bonds to 1. See #define DEVICE_MANAGER_MAX_APPLICATIONS 1 in device_manager_cnfg.h. Even though you delete the bond on iOS it will still exist in the nRF51, so you need to either allow more devices to bond to the nRF51, or delete the bond before another central is allowed to bond.