sd_ble_gap_authenticate causes HardFault

RE: sd_ble_gap_authenticate causes HardFault

Ron — Mon, 13 Apr 2020 07:36:08 GMT

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.

RE: sd_ble_gap_authenticate causes HardFault

Nicholas_Nuti — Fri, 28 Feb 2020 10:34:54 GMT

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

Thank you.

RE: sd_ble_gap_authenticate causes HardFault

Ron — Sun, 12 Jan 2020 12:13:33 GMT

Hi,

It was a different implementation of the RTC1 interrupt,

Thank you!

RE: sd_ble_gap_authenticate causes HardFault

Ron — Mon, 16 Dec 2019 16:48:04 GMT

Hey Vidar!

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

Thanks :)

RE: sd_ble_gap_authenticate causes HardFault

Vidar Berg — Mon, 16 Dec 2019 12:37:54 GMT

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.

RE: sd_ble_gap_authenticate causes HardFault

Ron — Mon, 16 Dec 2019 11:22:29 GMT

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

RE: sd_ble_gap_authenticate causes HardFault

Fredrik — Mon, 16 Dec 2019 10:53:10 GMT

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.