ANCS resets after deleting bond on dev board

[Antonio]

Hi,

I have a problem that the ANCS keeps resetting my board, so I was able to reproduce the problem on the PCA 10028 dev board.

Conditions:

• iOS 8.x or 9.x
• No app needed on iOS. This is on settings->bluetooth
• SD 110
• ANCS nordic implementation as is on SDK 9.0
• Check on serial port.

The steps to reproduce the problem are:

• Bond iOS device to ANCS. Leave it connected.
• Reset dev board with button 2 pressed, to erase all bonds
• Watch on the serial term how ANCS keeps resetting.

What I have been able to see on the sniff is that when iOS tries to connect after the board resets, ANCS rejects the ENC request due to the bond not existing (it was erased) After that when the timeout on the ANCS to check if the line is already encrypted asks for Bonding, now it is the turn of iOS to reject the request.

After that ANCS does not responds anymore. It has not reset yet and the connection is still active, but all retries from iOS for Rcvd By Type Request are just acknowledged but not answered.

I am attaching a wireshark file with this. Bonds erased.pcapng and a print of the serial terminal...Screen Shot 2015-12-03 at 3.59.50 PM.png

HELP!!!

[Anders Strand]

Hi.

When the phone has bonding data and the device doesn't, it is not really any easy way out. The phone will try to encrypt the link with the existing encryption keys, and the peripheral device must deny these attempts because it does not have the keys. The only solution to this is to delete the device from the phone bluetooth settings.

You mentioned this potentially being an issue when using DFU. You have the option to keep bond data when doing DFU, so this should not be a problem.

About the board resetting or freezing when an error occurs: This is how the default error handler reacts on errors. It resets by default, and freezes (while(1)), when DEBUG is defined.

From the documentation of app_error_handler:

@warning This handler is an example only and does not fit a final product. You need to analyze * how your product is supposed to react in case of error.

It is up to the developer to decide how the application should react to different errors.

The return code 0x88 comes from

event_result = p_ble_evt->evt.gap_evt.params.auth_status.auth_status;

The status is BLE_GAP_SEC_STATUS_UNSPECIFIED. This status describes that the authorization failed with an unspecified reason. (As we can see on event 1415 in the sniffer log).

[Antonio]

Thank you Anders! In my board I am doing my own implementation of APP_ERROR_CHECK before I actually send it to APP_ERROR_CHECK for reset (after pressing a button that I am looping directly on the IO). The problem I am having is that when I intercept the error for some reason the timers do not work anymore. I have a timer that is constantly driving an LED for status, and that one stops working. Do you know if when an error condition is sent the timers from app_timer stop working? Thanks!

[Anders Strand]

It really depends on the implementation of your error handler. Note that the event that come from the softdevice will run on the same priority as app_timer. If you are for example are doing an infinate while loop somewhere (other than main()), you will block the timer.

[Antonio]

Wow, I feel like a newbie now. I thought that the timer was working through interrupts and that I would get a call if I was on the same priority. Or, now that I think of it, this one error is a callback to the device_manager_evt_handler. What priority would that be?

[Anders Strand]

Most events originate from the softdevice. It will send the event using a software interrupt with priority APP_LOW. Everything called from within that software interrupt is still in APP_LOW priority. See this picture of event flow. Practically speaking; Anything that is not called from main(), will have APP_LOW priority or higher.