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

[Susheel Nuguru]

The  System OFF mode does not work in debug mode. It is just emulated as mentioned here.

So it is recommended that if have an infinite while loop just after calling the SYSTEM_OFF mode in your application. That way when you start your program in debug mode, the instructions after the SYSTEM_OFF call are also executed. Most likely in your application the main function is exited causing the CPU to execute illegal instructions causing hardfault. Address 0x00000A80 seems to be the hardfault handler address inside the MBR in the softdevice.

but in non debug mode, the instructions after the SYSTEM_OFF call are never reached.

[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.