sd_ble_gap_authenticate causes HardFault

[Ron]

Hi

I am using nRF51822, S130, SDK12, Working on adding static key security to my application

So far I have change the GLS (glucose) example to static passkey and connected successfully using nRF Connect and NRF DK51

Since than I have tried to migrate that code into a thin version of my existing application and encountered a Hardfault after the sd_ble_gap_authenticate command,

A problem I didn't see on the the project I worked on based on the SDK example version - this is the call stack 

I have not changed anything in those functions, only, as I said, as far as I know I only changed to Static passkey with the following code after ble_stack_init() in main()

			uint8_t passkey[] = STATIC_PASSKEY;
			//m_static_pin_option.gap.passkey.p_passkey = passkey; //gap_opt
			m_static_pin_option.gap_opt.passkey.p_passkey = passkey; //gap_opt
			err_code =  sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &m_static_pin_option);
			APP_ERROR_CHECK(err_code);		

the routine from which the HardFault is invoked -

static ret_code_t link_secure_peripheral(uint16_t conn_handle, ble_gap_sec_params_t * p_sec_params)
{
    // This should never happen for a peripheral.
    NRF_PM_DEBUG_CHECK(p_sec_params != NULL);

    // VERIFY_PARAM_NOT_NULL(p_sec_params);

    ret_code_t err_code = sd_ble_gap_authenticate(conn_handle, p_sec_params);

    return err_code;
}

Would greatly appreciate any inputs and insights on this issue, since I have no idea what causes it

Thanks!

[Fredrik]

Wild guess: from your call stack it appears everything is handled in the context of an RTC IRQ handler. As a general rule, interrupt handlers should be short and perform only simple operations. Calling into the softdevice from an interrupt handler can give unexpected results. Try to perform the authentication from main context (thread mode) insead. These are all valid options:

• Use app timer with scheduling (set APP_TIMER_CONFIG_USE_SCHEDULER and call app_sched_execute in the main loop)
• Set a flag in your timer interrupt handler and check the flag in the main loop and trigger authentication from there
• Use the application scheduler inside the timer interrupt handler to schedule a call to link_secure_peripheral

If the hardfault disappears when authenticating from main context you'll know that the interrupt context was the issue.

[Ron]

Hey Fredrik,

Interesting, I will definitely try that, but to clarify the GLS example did the exact same thing, this wasn't my addition, and when doing the same thing on the GLS based project no such problem occurred. anyway I will try you method

Thank you very much for your help

[Vidar Berg]

Hi, 

It's ok to make Softdevice calls from an interrupt context as long as its int priority is lower than the SVC handler's (is '3' for the 51 series). Have you kept the default setting for RTC1_IRQ_PRI and SWI_IRQ_PRI in app_timer.c? It should be APP_IRQ_PRIORITY_LOWEST for both.

[Ron]

Hey Vidar!

I will do that and compare my RTC1 interrupt configuration to that of the original GLS project

Thanks :)

[Ron]

Hi, 

It was a different implementation of the RTC1 interrupt,

Thank you! 

[Nicholas_Nuti]

Hi Ron, may I ask how you solved this issue?

Thank you.

[Ron]

Hey Nicholas,

Yes, I was using a project in which I have previously changed the implementation of RTC1 (I used it for PPI) and specifically the compare channel that is used for security request, the solution was to bring it back to legacy implementation and than to move my previous PPI implementation to new compare channel.