What could explain a HardFault when entering in critical region?

RE: What could explain a HardFault when entering in critical region?

Susheel Nuguru — Mon, 27 Apr 2015 06:45:45 GMT

good observation sebastien, there is a limitation on how you use CRITICAL_REGION_xx macro. You cannot use it when softdevice is disabled and have the macro SOFTDEVICE_PRESENT defined in your project. you can just use below when you are not using softdevice

static uint32_t m_in_critical_region = 0;

void critical_region_enter(void)
{
    __disable_irq();    
    m_in_critical_region++;    
}

void critical_region_exit(void)
{
    m_in_critical_region--;    
    if (m_in_critical_region == 0)
    {
        __enable_irq();
    }
}

This code is also available in components\libraries\util\app_util_platform.c

RE: What could explain a HardFault when entering in critical region?

Sebastien — Fri, 24 Apr 2015 15:25:47 GMT

Important note : two nested CRITICAL_REGION_ENTER generate an hardfault only if the softdevice is not enabled !

RE: What could explain a HardFault when entering in critical region?

Susheel Nuguru — Fri, 24 Apr 2015 09:53:25 GMT

good to know, can you please accept the right answer so that we can close this case.

RE: What could explain a HardFault when entering in critical region?

Sebastien — Fri, 24 Apr 2015 09:31:55 GMT

Hello Aryan,

Thanks for your comment.

Yes we are using the app_timer and the RTC1 IRQ is always set to LOW.

But, actually, we have modify the app_timer in order to save RAM consumption, and I found the issue: In our RTC1_IRQHandler, we add CRITICAL_REGION_ENTER when calling "timer_timeouts_check()", so when there is a task to execute, we will perform another CRITICAL_REGION_ENTER in the app_scheduler.

You routed me to the issue ;) Thx!

RE: What could explain a HardFault when entering in critical region?

Susheel Nuguru — Fri, 24 Apr 2015 08:32:06 GMT

Check if you are using APP_TIMER and if you have set RTC1 interrupt handler priority to APP_HIGH, then like RK said it will cause an hardfault in app_scheculer

below m_evt_schedule_func = app_timer_evt_schedule (set in APP_TIMER_INIT macro)

RTC1_IRQHandler->timer_timeouts_check()->timeout_handler_exec->m_evt_schedule_func->app_sched_event_put->CRITICAL_REGION_ENTER

RE: What could explain a HardFault when entering in critical region?

Sebastien — Fri, 24 Apr 2015 08:10:00 GMT

Hello RK,

Thanks a lot for your quick answer!

About the first reason, I think this is handled by the CRITICAL_REGION_ENTER() macro because we won't disable IRQs when the current interrupt priority is HIGH =1. I don't see any app irq priority equal to 0, is it possible?

I did a simple test, consisting to call two CRITICAL_REGION_ENTER, and I got the same panic trace. So it looks like we try to disable irq whereas it's already done. I will double check in our SW where it could happen.

Thx again.

RE: What could explain a HardFault when entering in critical region?

RK — Fri, 24 Apr 2015 01:55:30 GMT

Since it looks from what you've posted that the hardfault is happening at the critical region enter (not inside the softdevice ie not a softdevice bug) then it seems it's happening at the svc() call. The only two reasons I know of that an svc() call will go to hardfault are if it's executed

from a higher interrupt state, SVC() in the softdevice is a level 2 interrupt, so if it's called from a level 0 or 1 interrupt it will hardfault
It's called when interrupts are disabled, ie PRIMASK is 1.

Don't know how you are getting into one or other of those states, if you have the registers on the panic you should be able to figure out whether it's in thread or handler mode, what the current interrupt priority is if in handler mode and whether PRIMASK is or is not 1 and confirm that.

I can't think of anything else.