nrf51822 restarting after wrong passkey from an iOS device

RE: nrf51822 restarting after wrong passkey from an iOS device

Jørgen Kvalvaag — Fri, 19 Aug 2016 12:53:55 GMT

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.

RE: nrf51822 restarting after wrong passkey from an iOS device

KlevioRok — Fri, 19 Aug 2016 12:08:29 GMT

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?

RE: nrf51822 restarting after wrong passkey from an iOS device

Jørgen Kvalvaag — Fri, 19 Aug 2016 11:56:31 GMT

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.

RE: nrf51822 restarting after wrong passkey from an iOS device

KlevioRok — Fri, 19 Aug 2016 10:54:13 GMT

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

RE: nrf51822 restarting after wrong passkey from an iOS device

Jørgen Kvalvaag — Fri, 19 Aug 2016 09:36:05 GMT

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.