Pulse outputs for wake are frequently going to be a problem. For your IMU situation, it’s a common issue, but it can happen for any asynchronous pulse-based interrupt output, both rising and falling. Some situations are worse than others.
The reason as you pointed out, is that there’s a window of time from the time you’ve checked/cleared the interrupt and the time the device is actually asleep.
The two situations that come into play that are problematic are:
- If the interrupt source will only generate another interrupt after clearing the old. In this case, the first interrupt will be lost because it occurred before the device was asleep. The interrupt will never be cleared and the device won’t wake up on the next movement. The only solution is to periodically wake, check the interrupt status, and go immediately back to sleep. This can be done really quickly if cellular is off.
- If you’re using a rising WKP to wake from hibernate mode on the Gen 2 devices (STM32F205) you’re super stuck. If WKP is high at the moment the device goes to sleep, even if it falls and rises again, the device will not wake up, even based on time. This was an issue with the LIS3DH on the old Electron AssetTracker 2. The solution is to use ultra low power mode instead of SLEEP_MODE_DEEP, combined with the solution for #1.
If the device sends another interrupt always, you’re usually OK, but if you’re trying to count interrupts (for example, rain gauge), you will miss one click.
One solution is to insert an even smaller microcontroller (like a small PIC) as the interrupt handler. If you go a little larger like a PIC18 you can even make a dedicated I2C device to pre-filter interrupts. This works well with things like anemometers that interrupt too frequently to wake a sleeping Particle device safely. You just use the PIC to count the anemometer clicks and periodically get min/max/average from it by I2C.