I know this question must get asked enough, but i am at my wits end and have not managed to find a solution for this yet.
calling sd_power_system_off returns NRF_INVALID_STATE and causes a reset. I have read that this can be due to the configured wakeup pin is already in the wakeup state. This is not the case, in fact i would rather it never wakeup at all, as i have another MCU which is controlling the nRFs power modes that can just toggle the load switch to wake it back up.
It might sound silly putting it in deep sleep when i can just turn off the load switch, however its a high side switch, and some of the pins on the nRF are pulled to an always present 3V3 line and i get horrible GPIO leakage, not matter what i do before shutdown. Deep sleep solves this and the current consumption when it works is fine.
I have two build targets in one project. One does not use the softdevice and can deep sleep just fine, the BLE enabled target however can't ever sleep. i have tried uninitialising every interrupt and disabling them, stopping the advertising, and setting up a wakeup pin but to no avail.
Is there some way i can clear whatever it is that blocks system off mode?
Device is an nRF51422 QFAC S110.
Thanks in advance, Bill.
Are you in debug mode? See this : devzone.nordicsemi.com/.../
You should also power-cycle the device after you flash the device.
What error number did you get? NRF_ERROR_INVALID_STATE? I do not think that error is possible with the call sd_power_system_off();
the error number was 8, but thinking about it, that could have come from another function, as it was the last log printed before it started resetting.
I do power cycle the devices after programming so the issue lies elsewhere. I was able to get the nRF to go to deep sleep, by performing a soft reset and then going making it go to sleep instantly. I was not able to get a flag stored across the restart via the ram to work though, following an example. Might have to do with my startup files.
Instead of the flag, i decided to make it initialise its bit bash I2C/TWI driver and read the power status, and then set up of a wakeup pin. it just reads this status then goes to sleep if the condition is right. however it still continues to go into a reset loop.
You have to find the condition where it falls into the reset loop trap. Use breakpoints and see the call stack. You will probably find this as an APP_ERROR_CHECK failure which causes default eror handling to be resetting your device.