LPS22DF first FIFO element corruption?

[KWine]

I am using an LPS22DF over I2C with an STM32WB5MMG. The sensor is configured for continuous 1 Hz operation, AVG = 64, LPF1 = ODR/4, and continuous dynamic-stream FIFO mode. FIFO samples are retrieved as separate three-byte reads from registers 0x78–0x7A.

The first FIFO read after every watermark interrupt is consistently corrupted by approximately +32 hPa. For example, the first value may be raw 4130956 (1008.534 hPa), while the following values are approximately raw 3999700 (976.49 hPa) and agree closely with the standard PRESS_OUT registers. The difference is close to 131072 counts, corresponding to bit 17 of the 24-bit pressure value. This occurs repeatedly for every FIFO batch, not only during startup or LPF settling.  

Our operational workaround is to set the FIFO watermark to 11, read eleven three-byte data sets individually, discard the first result, and average the remaining ten. Is this first-read corruption a known LPS22DF behavior or erratum? Is there a required FIFO read sequence or recommended workaround that avoids losing the first entry?

[Federica Bossi]

Hi ​@KWine ,

Thank you for the detailed description.

The application note recommends reading FIFO data as a 3-byte multi-read starting from 0x78 (with IF_ADD_INC = 1), and for a full FIFO it even recommends a single 384-byte burst read. This suggests that the FIFO data should be accessed as an atomic 3-byte dataset, rather than as separate single-byte transactions.

For this reason, I would first verify the read sequence on the I²C bus. If the three bytes are currently being read as separate transactions, the FIFO contents may advance between accesses and the reconstructed 24-bit value could be corrupted.

So, the recommended workaround would be:

• keep IF_ADD_INC enabled
• read each FIFO entry with a single 3-byte burst
• if possible, drain the FIFO with a single multi-read of the entire watermark block

 

Let me know!

[KWine]

Thank you. Each FIFO entry is already read as one atomic three-byte I2C transaction. The host writes subaddress 0x78, issues a repeated START, requests three bytes in one operation, and reconstructs the 24-bit pressure only after all three bytes have been received. The three pressure bytes are not read as separate I2C transactions.

The same three-byte function is called repeatedly to drain the FIFO. Only the first three-byte dataset after every watermark event is approximately 32 hPa high; all subsequent datasets read with the identical function agree closely with PRESS_OUT. The raw error is close to 0x020000, suggesting that bit 17 is set in the first returned dataset.

We also attempted one 30-byte read from 0x78 with IF_ADD_INC enabled. In that test, the first three bytes contained the same anomalous pressure, while the remaining bytes were 0xFF rather than wrapping through 0x78–0x7A. We are repeating that test after correcting an unrelated interface-register initialization issue.

Is any configuration beyond CTRL_REG3.IF_ADD_INC = 1 required for FIFO register wrapping? Does ST’s lps22df_fifo_data_get() perform one 3 × sample_count register read starting at 0x78, or does it internally issue one three-byte transaction per dataset?

[KWine]

Well, somewhat embarrassingly, we cannot reproduce this behavior even using the same Arduino sketch we originally discovered it with. This seems to indicate an anomalous hardware glitch that somehow resolved. We can now successfully read the FIFO either in three-byte bursts or in 32-sample (96 byte) bursts without any corruption of the first FIFO sample and with the correct and expected results. Sorry for the false alarm.