LIS2DH12 Occasionally Sends Duplicate Samples in FIFO Streaming Mode

[David Abdallah]

Posted on June 08, 2018 at 20:20

With the part in FIFO streaming mode and a watermark set to 15, I poll for the watermark interrupt on INT1 and then burst 16 entries from the FIFO. I repeat this until I’ve acquired 2048 samples. When I do this, I occasionally see duplicate samples values in the stream.

With the device on a shaker table driving a 100 Hz sinusoid, the captured waveform looks as expected. However, I occasionally see duplicate samples as shown circled in red on the accompanying plot. I’ve verified that the SPI bursts from the FIFO are completed much faster than the watermark interrupt fires. Attached is a SPI trace showing multiple transfers initiated by the watermark interrupt (WTM) to demonstrate that timing. I’ve also verified that duplicates can occur within a single burst which seems to rule out issues between bursts (e.g. the beginning of a burst reading the last sample from the previous burst). Interrupts to the CPU are disabled so nothing interrupts the process while acquiring the 2048 samples.

Has anyone in the community seen this behavior or is there an erratum for the part that indicates duplicate data is a possibility? Some additional observations:

This seems to happen only at sample numbers that are a multiple of 8 (i.e. 968 as shown in the plot of the captured waveform)

When it happens, not all axes are affected; sometimes, only the Z axis is affected, or only the Y and Z axes are affected.

It happens infrequently without an obvious pattern. When capturing 2048 samples, I may see the issue two or three times.

Here are my register settings:

CTRL_REG1                         0x77

CTRL_REG2                         DEFAULT VALUE

CTRL_REG3                         0x04

CTRL_REG4                         0x80

CTRL_REG5                         0x40

CTRL_REG6                         DEFAULT VALUE

FIFO_CTRL_REG                0xCF

Additional note for clarity: The SPI interface is not running fast enough to burst all 16 FIFO locations in less than 1/ODR so there is some overlap between reading old samples and acquiring new ones. However, the interface is fast enough to burst out 16 entries in about the time it takes to fill 2 new ones so there should always be plenty of space in the FIFO for new data (which should rule out an overrun).

Update: I've confirmed with a logic analyzer that the duplicate data is coming out of the sensor and isn't an error somewhere else in the system.

Thanks