FIFO data loss at wake from sleep?

[JRB]

Hi!

Is it possible to keep the FIFO data during a sleep-to-wake transition if aslp_rate and dr are effectively using the same ODR?

Or is it always lost at this transition?

Edit: The reason I am asking is this statement in the datasheet: The FIFO contents are flushed whenever the system ODR changes in order to prevent the mixing of FIFO
data from different ODR periods. Also I would like to use the wake-sleep interrupt as a timing source to power off the external controller without missing an interrupt during the shutdown phase.

Thanks!

JR

[TomasVaverka]

Hi Jean,

I am not sure if I fully understand your use case, but when it comes to the behavior of the FIFO I would refer to the Table 13 of the AN4074.

Best regards,

Tomas

[JRB]

Hi Tomas!

Thanks for your reply! That answers my question!

My use case is that I am using the acc sensor to monitor continuous movement. Also I let the acc sensor handle all of the work regarding detection of type of movement. The main mcu only receives the interrupt to wake up itself, handle the acc sensor event, do its own stuff (quite lengthy) and go back to sleep.

What I am observing is that when the mcu goes back to sleep (full shutdown) there is a small time window during which it cannot handle a received interrupt. Since the edge of the interrupt signal is detected and the interrupt signal stays constant, this is a source of a deadlock between acc sensor and mcu. As tiny as this window may be it occurs too often.

My idea was to use the wake-sleep interrupt to safely put the mcu to sleep. However, while the mcu is handling the results of the first interrupt event, enough time passes (6-9 acc sensor ticks) for another interrupt event from the acc sensor to arrive.

If I use the wake-sleep interrupt I understand I need to flush the FIFO in order to enable the FIFO to accept values at sleep ODR.

Now I have two cases:

A) The second acc interrupt arrives while mcu is still awake - everything is fine. All data is available and interrupt can be detected.

B) The second interrupt arrives 1-2 acc sensor ticks after the mcu went to sleep. In order to go to sleep the FIFO was flushed. When the mcu comes back to handle this second interrupt there will be only data of the the 1-2 acc sensor ticks in the FIFO. This means only part of the data that lead to the interrupt is available.

This actually raises another question:

When the FIFO is flushed, des that also mean that the sensor internal event detection circuitry is also flushed? Say a VECM event is configured with a debounce time of 7 sensor ticks. While the acc is awake 3 of those ticks already happen and 4 would happen after it went to sleep mode. Does the debounce timer also reset to 0 at the wake-sleep transition of the acc sensor?

If not I could at least get the VECM event, though I would still be missing some of its data since the FIFO was flushed in between.

My target is to use a acc sensor interrupt to put the mcu to sleep safely, while preserving as much FIFO data as possible.

Thanks for your input!

Cheers

[JRB]

Edit: I implemented a monitor to check my basic assumptions and option. I noticed that my very basic assumption might already be wrong:
Is it true that the acc sensor generates interrupts always close to its own tick, meaning the ODR? Meaning that if my ODR is resulting in 80ms data point interval, do all kinds interrupts always reliably appear with a 80ms spacing?

I am seeing a pulse interrupt being generated at a half tick (200ms after last interrupt at ODR 12.5Hz = 80ms tick)