App timer hard fault when running without debugger

[Keith V]

NRF52 on custom hardware

SDK 17.0.1

SoftDevice 7.2

I have a timer running, one shot or repeated, that blinks an LED.

It works just fine when run from the debugger but if I hit stop, or try to run disconnected from the Segger it hard faults. The LED may blink 1-3 times then stops.

If I attach the debugger and pause it is in the hard fault handler.

If I run the ble beacon app, modified for my hardware, it runs just fine.

Why am I getting a hard fault?!?

Thanks

Keith Vasilakes

int main(void)
{
   // Initialize.
   log_init();
   timer_init();
   power_management_init();
   MainStart();
   ButtonsLedsInit();

    ble_stack_init();
     
      for (;;)
   {
      idle_state_handle();
   }

void ButtonsLedsInit(void) 
{
    APP_ERROR_CHECK(nrf_drv_gpiote_init());

   LEDState = LEDStMtbNormal;

   nrf_gpio_cfg_output(SysLED);
   nrf_gpio_cfg_output(LoRaLED);
   nrf_gpio_cfg_output(BLELED);
   nrf_gpio_cfg_output(BattLED);

   nrf_gpio_cfg_input(BUTTON,GPIO_PIN_CNF_PULL_Disabled);

   nrf_gpio_pin_set(SysLED);
   nrf_gpio_pin_set(LoRaLED);
   nrf_gpio_pin_set(BLELED);
   nrf_gpio_pin_set(BattLED);

   ButtonPressed = ButtonPressedNot;

   //Enable button event
   nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);
   in_config.pull = NRF_GPIO_PIN_NOPULL;

   APP_ERROR_CHECK( nrfx_gpiote_in_init(BUTTON, &in_config, ButtonsLedsButtonEvent));

    nrf_drv_gpiote_in_event_enable(BUTTON, true);

    APP_ERROR_CHECK(app_timer_create(&SysLEDTimerID, APP_TIMER_MODE_REPEATED, SysLEDTimeOutHandler));
    APP_ERROR_CHECK(app_timer_start(SysLEDTimerID,  1000/*GetFlashLEDOnTime(LED_SYSTEM_SLOW)*/, NULL));

     nrf_gpio_pin_clear(SysLED); //LED ON
}

static void SysLEDTimeOutHandler(void * p_context)
{
   UNUSED_PARAMETER(p_context);

   if(SysLEDOn)
     nrf_gpio_pin_set(SysLED);
   else
     nrf_gpio_pin_clear(SysLED);

   SysLEDOn = !SysLEDOn;
}

[Vidar Berg]

Hi,

As a test to help narrow down the problem, can you please try to enable the constant latency power mode (Sub power modes) at the beginning of main() to see if it has the same effect as running the chip in debug interface mode? 

Constant latency mode can be enabled by writing the following register (Note: must be done prior to softdevice enable):

 int main(void)
 {
        NRF_POWER->TASKS_CONSTLAT = 1;
        ...

I wonder if what you are seeing could be related to wrong decoupling capacitors on your board, same as discussed in this thread:  RE: Wierd hardfault . This could explain why you are not experiencing the issue in debug interface mode, as this mode will prevent the chip from entering its lowest power saving modes. 

Best regards,

Vidar 

[Keith V]

Adding NRF_POWER->TASKS_CONSTLAT = 1; does fix the hard fault, the decoupling caps are correct.

But, the real problem is I had all that BLE code commented out When I turn it back on I don't get hard faults either.

I had turn all that off trying to get lower power to work, I'm seeing 500ua average with no advertising. So I'm back to that issue

[Vidar Berg]

When you get a hardfault, does the program end up in the HardFault_Handler() function? I do not understand what it could be that causes a hardfault when don't have BLE or constant latency mode enabled. 

Keith V said:

I had turn all that off trying to get lower power to work, I'm seeing 500ua average with no advertising. So I'm back to that issue

500 uA indicates that a peripheral is requesting the HF clock source in idle. You will also get this if you still have constant latency enabled. Do you have any peripherals apart from RTC enabled in this test?