nrf51822 restarting after wrong passkey from an iOS device

[KlevioRok]

Hi!

We are having problems with pairing & bonding procedures with iOS devices.

On the peripheral side we are using a nrf51822 BLE module on which we are testing pairing/bonding with the ble_app_gls example. We are using the example from the 8.0.0 SDK and the s110 softdevice. On the central side we are using a Lenovo T450s notebook with Windows 10, an iPhone 6 and an iPad Air 2, both with the latest iOS.

When trying to pair with the correct passkey, everything works as expected. However, when typing in the wrong password we are experiencing restarts on the nrf51 device. The only occasion in which the device does not restart is when we enter a passkey with 7 digits or more (the correct one has 6) on the notebook. In that case the application processes the BLE_GAP_EVT_DISCONNECTED BLE event.

In all other cases, the device restarts. The device manager in the application starts to process the next event, but not even the trace log is printed for this event.

We wanted to try the same example from the 11.0.0 SDK, but the project exceeds the 32K code limit for the free license.

Can you give us any advice how to prevent the device from restarting in these cases.

Kind regards, Rok from Klevio

[Jørgen Kvalvaag]

On SDK 8, I believe the default behaviour on any error/assert is to perform a reset.

If you add the compile flag DEBUG it should halt in the assert handler, where you can see file&line number where the assert occurred. You could also set a breakpoint in the assert handler and see if it hits.

There should not, to my knowledge, be any other reason for going into reset in this case.

SDK 11 will halt in the reset handler by default. If you want to try SDK11 there is also gcc makefiles included.

[Jørgen Kvalvaag]

No, that would not be a good solution. I was answering for the use of the DEBUG flag on a general basis. As for the application in question, I am not sure if the wrong_key_entered->assert->reset is intentional or not, as this is a single-link example i guess it could be a working but not-very-clean solution. A working solution for your case could be to handle this case in some way, eg check the event_result for BLE_GAP_SEC_STATUS_CONFIRM_VALUE and perform a disconnect in this case.