Exit from System OFF via GPIO and MCUBoot

maustin-redant

I’m having some challenges with some firmware I’m writing that requires the following functionality:

Spends most of its time in System OFF to save power
Exits System OFF when one of three GPIOs change to the active state (these will be normally low, and will trigger the exit when they go high)
Checks RESETREAS and LATCH to determine which GPIO has triggered an exit from System OFF
Update some variables that are stored in retained RAM, then go back into System OFF

I’ve got the basics of it working, but I’m having problems when I get multiple GPIO triggers within the time period it takes for my code to fire up and switch off the .SENSE on the relevant GPIOs.

What I’ve established is that:

There is 300 - 400msec delay between the GPIO trigger, and the code in my main.c starting up. I’m led to believe this is due to the settling time of the LFCLK, which is enabled with NCS, regardless of whether you are using the BLE Stack or not.
I get around this delay by reading RESETREAS and LATCH in a SYS_INIT call in PRE_KERNEL_1. This enables me to get the info I need in around the first 200usec of the GPIO trigger
I want to be able to do OTA DFU, so have enabled the MCUBoot via CONFIG_BOOTLOADER_MCUBOOT=y in my proj.conf. What happens when I do that, is that there seems to be a 300 - 400msec delay before my SYS_INIT code gets called, presumably due to the MCU Bootloader starting up. So, what happens is the GPIO triggers the device out of System OFF, the bootloader does its checks and balances, the SYS_INIT code gets called and by that time the delay due to the LFCLK is over and the main.c code starts almost immediately after the SYS_INIT code.
If I get any more GPIO triggers during the time the MCU Bootloader is running, it seems to reset the value in the LATCH register, or over-write it, or something. And then when I eventually read the LATCH register, I get a zero result and I can’t determine which GPIO caused the exit from System OFF.

So, I’m trying to work out what’s upsetting the LATCH register and how I can fix this. Note that the RESETREAS register is not affected.

Anyone able to help?

Cheers,
Mike

jaredwolff

Hey maustin-redant

You may want to post this on Devzone. They’d most likely be able to point you in a better direction.

I’ll add a few things here though:

One thing to remember though with MCUBoot vs your app code: depending on how you have things configured, they may be reconfigured later on. You may have to write the LATCH register result to NVM (yea I know bigger bootloader 😅) or in a place in memory where you know it won’t get clobbered.

You also may want to check if there is a Zephyr specific API/functionality that may be reading these values out. I’ve been guilty of overlooking that possibility in the past as well.