GPIO wakeup from system OFF under FreeRTOS restarts at address 0x00000A80

[bfriedk1]

Hello -

We are using SDK 15.3.0, FreeRTOS and the nRF52840-DK board with SES. We implemented wakeup from System Off sleep using the nrf_gpio_cfg_sense_input() API, which seems to work:

nrf_gpio_cfg_sense_input(pin, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);

When we run our debug build and wakeup from System Off sleep by pressing the button, the debugger breaks at address 0x00000A80, the third line of assembly below:

BF20        wfe
E7FD        b 0x00000A7C
4B06        ldr r3, [pc, #24]

Pressing the continue button in SES also works as expected. The app restarts and the reset cause is correct.

But when I run the same basic flow using the SDK ram_retention app, which isn't running FreeRTOS, the app breaks at the Reset_Handler after pressing the button. Our .emProject file is configured for the Reset_Handler entry point:

gcc_entry_point="Reset_Handler"

Is there another configuration option to make a FreeRTOS app break in the Reset_Handler under these circumstances? It seems that the reset handler gets invoked before main().

Regards,

Brian

[bfriedk1]

Susheel -

Thank you for the quick reply and additional details. Much appreciated. I wasn't aware that system OFF mode was emulated in debug mode, though that does make sense.

I also now see that the ram_retention example enters an infinite loop after calling SYSTEM_OFF mode. I did the same in my application, but unfortunately I am still ending up in the hard fault handler after pressing the sense button. After some experimentation I found that if I press the reset button instead of the sense button the first time I run the app, I can then press the sense button after the next SYSTEM_OFF and I don't end up in the hard fault handler. Our test app repeatedly enters SYSTEM_OFF after a delay.

Because the ram_retention app doesn't have this behavior, I suspect the failure is due to our app running under FreeRTOS. The SYSTEM_OFF is called from a FreeRTOS task. Are there additional calls required to achieve the same behavior as the ram_retention app from debug builds running FreeRTOS?

I do understand that release builds should behave properly. We are working towards getting our release build up and running. Just a little concerned that the behavior we are experiencing is different under FreeRTOS.

Regards,

Brian

[Susheel Nuguru]

Brian,

The emulated SYSTEM_OFF mode and the emulated wakeup from RAM_RETENTION memory might not go well together. 

 

bfriedk1 said:

I found that if I press the reset button instead of the sense button the first time I run the app, I can then press the sense button after the next SYSTEM_OFF and I don't end up in the hard fault handler.

 This makes sense. The pin reset or the reset button should bring the device out out of debug mode. And hence the SYSTEM_OFF mode will not be emulated there after. And that explains why there are no hardfaults after pressing the reset button.

Like you already figured out, I do not think this is going to affect your actual release version of your product. It is just that the SYSTEM_OFF + RAM_RETENTION (emulation) are not designed to work together with the debugger.