LPS28DFW FIFO update lock

[SimoCali]

Hello,

I have a couple of devices using LPS28DFW pressure sensors.

The sensors are configured as follows:

• INTERRUPT_CFG = 0x00,
• THS_P_L = 0x00,
• THS_P_H = 0x00,
• IF_CTRL = 0x00,
• CTRL_REG1 = 0x3C,
• CTRL_REG2 = 0x00,
• CTRL_REG3 = 0x01,
• CTRL_REG4 = 0x02,
• FIFO_CTRL = 0x02,
• FIFO_WTM = 0x64,

All other registers are left at their default values.

Usually they work fine, filling the FIFO with new data and generating an interrupt every second. However, I occasionally encounter an issue where the sensors appear to stop filling the FIFO for a period of time. The duration of this stall is not consistent, it can range from a few seconds to a permanent lock-up. During this locked state, I can still successfully read the temperature, and reading back the configuration registers confirms they are set as expected. After a power cycle and reconfiguration, everything returns to working correctly.

Have you ever experienced this issue? Do you have any idea what might be causing it?

[Federica Bossi]

Hi ​@SimoCali ,

I would first check FIFO_STATUS1 / FIFO_STATUS2 / STATUS / INT_SOURCE when the stall happens. If FIFO_FULL_IA, FIFO_OVR_IA, or P_OR is set, it’s likely a FIFO overrun/state issue rather than a sensor failure.

A simple recovery to try is to put the FIFO in bypass (FIFO_CTRL = 0x00), wait a bit, then reconfigure it.

[SimoCali]

Hello Federica,

First of all, thank you for your answer. I reproduced the problem monitoring the status registers you mentioned. In the table below i report the values of the registers in the three events that i log. 

Register	Field	Occ.1	Occ.2	Occ.3
FIFO_STATUS1	FSS	49	5	0
FIFO_STATUS2	FIFO_WTM_IA	0	0	0
FIFO_STATUS2	FIFO_OVR_IA	0	0	0
FIFO_STATUS2	FIFO_FULL_IA	0	0	0
STATUS	T_OR	1	1	0
STATUS	P_OR	1	1	1
STATUS	T_DA	1	1	0
STATUS	P_DA	1	1	1
INT_SOURCE	BOOT_ON	0	0	0
INT_SOURCE	IA	0	0	0
INT_SOURCE	PL	0	0	0
INT_SOURCE	PH	0	0	0

I also tried the recovery you mentioned by putting the FIFO in bypass but it does not seem to have an effect. How long should i wait before reconfiguring the chip after i set the FIFO_CTRL = 0x00?

[Davide TERZI]

Hello ​@SimoCali,

Can you explain a more the data that you shared? For example, are the values taken at the beginning of 3 different stall intervals? Do these values stay constant during the whole stall period? It's odd that on the last example no samples are stored and that none of the FIFO flags are raised. 

Now in general, how are you measuring the duration of the stall? Have you tried reading also the pressure data directly from the output registers PRESS_OUT during the stall? When it stalls, do you no longer get the interrupt signal?

As for the FIFO bypass, you should wait one ODR and reconfigure it. You could try also to reconfigure the sensor.

What setup are you working with? 

 

If you would like to follow an example, you can check this link with how to read from FIFO using the official C drivers:

FIFO Read example

 

Thanks!

[SimoCali]

Hello ​@Davide TERZI,

Thank you for the answer, I will try to give you the clarification you requested.

Regarding the shared data: the values are read about two seconds after the last interrupt (once we declare the sensor stalled), and they stay constant for the whole duration of the stall. As for the case with FIFO level at zero and no flags raised: it's happened only once so far and I don't have an explanation for it — the operating conditions were the same as in the other occurrences.

On stall duration: with the current configuration we expect an interrupt every second. We declare the sensor stalled if at least two seconds have passed since the last interrupt; at that point we read back the status registers, which is where the values I shared came from. The stall duration is not constant.

We now have a recovery logic that checks the status registers every two seconds after the last interrupt; if the sensor is found stalled 6 consecutive times, we trigger a power cycle to recover it. Sometimes it recovers on its own before the power cycle kicks in, other times it stays locked for more than 12 seconds. Before adding this recovery logic, we observed sensors remaining permanently stalled.

We haven't tried reading PRESS_OUT directly during a stall yet, but we will test that. To confirm: yes, during the stall the FIFO level stays locked and no further interrupts are generated.

On the FIFO bypass recovery: our previous attempt only kept the sensor in bypass for a few milliseconds. We'll increase that to a full ODR period as suggested, and also try reconfiguring the sensor as an additional recovery path.

It's also worth noting that these events are quite sporadic: we're running 4 sensors in parallel, and on average we see about 1 or 2 events every 24 hours, not always on the same sensor.

Setup: the sensor is powered at 3.3V and communicates over I2C at 400kHz. Register configuration is as follows —
INTERRUPT_CFG = 0x00, THS_P_L = 0x00, THS_P_H = 0x00, IF_CTRL = 0x00, CTRL_REG1 = 0x3C, CTRL_REG2 = 0x00, CTRL_REG3 = 0x01, CTRL_REG4 = 0x02, FIFO_CTRL = 0x02, FIFO_WTM = 0x64.
Host is an STM32H7 microcontroller reading the sensor over I2C.

 

[Davide TERZI]

Hi ​@SimoCali,

Thanks for your detailed response, that helps a lot and now the whole picture is very clear.

It would be very interesting to check if during the stall the pressure outputs are still updating, to understand whether the issue is related to the FIFO logic or to the whole pressure sensing chain. Also, during the stall, have you tried emptying the FIFO to see if it recovers? Are the read samples valid?

Another possible cause behind the stall could be a communication-side or a power-integrity issue given that the problem is rare and intermittent. Which buses/resources are shared among the sensors? It could also be useful to check the bus integrity in general, by looking for occasional bus anomalies such as missing ACK, timeouts, concurrent access, or similar issues. It may also be worth checking whether the sensor VDD line shows dips or noise during these events.

Now, another option to recover the sensor besides the full power cycle that you are currently using would be to try a Software Reset or a Reboot (not both at the same time). Both procedures are clearly explained in section 6 of Application Note 5758 (LPS28DFW: dual full-scale absolute digital output barometer with water-resistant package - Application note).

 

Let us know how it goes!