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.

[KlevioRok]

Thank you for the fast response. It was very helpful.

The error happens here:

    static uint32_t device_manager_evt_handler(dm_handle_t const    * p_handle,
                                               dm_event_t const     * p_event,
                                               ret_code_t        event_result)
    {
        uint32_t err_code = NRF_SUCCESS;
    
        m_dm_handle = *p_handle;
-->    APP_ERROR_CHECK(event_result);

The error is BLE_GAP_SEC_STATUS_CONFIRM_VALUE, which is, as I understand it, as expected.

Can you give me any thoughts on what is usually done to prevent the resets in these cases? Should we expand the APP_ERROR_CHECK macro to support this cases or avoid using it when this error occurs. Thank you very much for your help.

Kind regards, Rok from Klevio

[Jørgen Kvalvaag]

The general idea is that during your product development cycle, you will have the DEBUG flag set, and all errors will cause the app to stop, so you can inspect/debug. But when it's time to make the released product the debug flag is removed. Whenever an assert is encountered in a product at your customer, the only safe thing to do is reset.

[KlevioRok]

So the normal mode of operation is that the device resets everytime any user that is trying to connect enters the wrong key? Or am I missing something? What if other users are connceted and are recieving some data for instance. What to do in these cases?

[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.