Delay between exiting System OFF and starting main loop

[Mike Austin (LPI)]

I've been playing around with some code that puts my hardware into System OFF mode to save power, and then will exit this mode and start up when one of three different GPIO's trigger it.

I then attempt to establish which GPIO has caused the exit from System OFF by reading the value of the LATCH register.

But I've been having heaps of issues with the LATCH register value being reset if I get more than one GPIO trigger signal in < 200msec of a previous one (it could be the same GPIO, or it could be one of the other ones - these are both likely scenarios in my application)

If I monitor the GPIO signal that is designed to trigger exit from System OFF on my scope, and then set and clear another GPIO as the very first thing I do in my code, and monitor that signal on my scope as well, I am seeing anything from 200msec up to nearly 500msec delay.  So, there is something going on in the background during the "exit from System OFF" process that is adding this 500msec delay into the process.  This means that if I get another GPIO trigger during this process, the value of the LATCH register gets reset, and I can't then determine which GPIO caused the exit.

I recall when I used to code Cypress chips that Cypress stuff a 500msec delay into their compiled code to allow the LFCLK time to settle after a reboot.  Potentially it could be something like this?  Or, it could be something totally different!

Anyway, what I want to find out is:

1.  What's causing this delay

2. Can I shorten it to something < 20msec

3.  If not, is there some way I can grab the value of the LATCH register within the first 10-20msec of the GPIO trigger so I can then run the rest of my code successfully?

Cheers,

Mike

[Simonr]

Let's keep this to your other ticket, as the subject is still the same as in your other ticket: https://devzone.nordicsemi.com/f/nordic-q-a/88311/multiple-gpio-interrupts-from-system_soft_off 

Best regards,

Simon

[Mike Austin (LPI)]

OK, for anyone reading this wondering if there was a resolution, there was:

1. If you are using NCS, then it enables the LFCLK, which means there is a delay of 300-400msec before your main.c code actually starts to run

2. You can get around this by putting time critical start up code in a SYS_INIT() function, and call this in one of the PRE_KERNAL stages.

3. If you are implementing OTA DFU, then the Mcuboot that is needed to do image swaps, etc will be run prior to any of the SYS_INIT() stuff, which sort of re-adds the 300-400msec delay to the start up processes.  It will also impact the registers, which means when you eventually get around to reading them, they'll not reflect what GPIO caused the System_Off exit.  To get around that, you need to follow Step 4 below:

4. Disable CONFIG_GPIO in mcuboot. This can be done by creating the folder my_project/child_image/  And in the child_image catalog, you create the file "mcuboot.conf" holding:

CONFIG_GPIO=n

I was using Retained RAM to store variables when in System Off, and that gets impacted with the above changes.  There is potentially a way around it, but I just ended up writing everything to NVS just prior to going back into System Off, and that achieves the same outcome for me.

Cheers,

Mike