Which seems to solve the issue, except when it locks my application. When digging into why it would lock my application, I’ve found that the Electron is communicating with the cloud between when the PMIC wakes the Electron and when it goes back to sleep. When in debug mode, I can see messages, such as:
AWAKE
ASLEEP
AWAKE
0000040035 [comm] INFO: Waiting for Confirmed messages to be sent.
0000051767 [comm] INFO: All Confirmed messages sent: client(yes) server(
ASLEEP
I’m not sure this is the root cause of the lock, but I am sure I don’t want the Electron to be communicating with Particle in this loop. I don’t care whether Particle received confirmable messages, etc.
So my question is – what is the right way to prevent this? It seems that this is what SINGLE_THREADED_BLOCK is for, but I am not sure how its intended to work with sleeping and whatnot.
// The following pins are only defined for easy access during development.
// Will be removed later as they are internal I/O and users
// should not have too easy of access or bad code could do harm.
I cannot get my Electron to sleep in SINGLE_THREADED_BLOCK() {}. I imagine it has something to do with some calls not making it to the other parts of the RTOS when in single threaded mode.
It seems like in order to avoid communication with the Particle cloud when waking in this loop, I am going to have to disconnect from the Particle cloud before going to sleep. New code looks like:
This seems to fix my issue, but comes with two new questions:
I’m using the undocumented function Particle.disconnected. This is a little worrying, but it seems to work.
What penalty do I incur by issuing a Particle.disconnect() when later reconnecting after waking up? It seems, per the logs below, the device is restoring its status without going through the full 5k handshake. Is that correct?