FIFO Corruption on LSM6DSM

[JBarr.12]

There appears to be a hardware bug on the LSM6DSM where if a sample is acquired while reading from the FIFO, then the pattern # becomes incorrect. I can consistently replicate this issue by reading at random intervals. Additionally, data on the FIFO may be corrupted.

I'm taking my measurements while the custom PCB is sitting still, so consecutive samples should not vary significantly.

I have attached a hardware I2C logger to confirm the data on the I2C bus, see attached spreadsheet with annotations.

I have also attached my .c file showing the configuration settings that are used.

FIFO continuous mode at 26hz, stop on threshold full, block data update = 1, interface increment = 1.

Is there a workaround for this issue? Different settings that I need to use?

[GRagh]

Joseph

Were you able to solve this problem ? I seem to have the same problem and it seems to be related to how fast you read from the fifo. Please let me know if you have a solution.

[e-mail]

[Tesla DeLorean]

Not sure I've seen any mention of an errata. It might be a good plan to find an FAE with expertise on sensor via the local sales office.

[Tesla DeLorean]

@Eleon BORLINI​ 

Even if there is not a chip level issue, an effective demonstration of the FIFO use case would fill in some holes.

[Eleon BORLINI]

There are some C examples regarding the use of the FIFO ​in the LSM6DSM Github driver repository (continuous-to-FIFO, multi read FIFO, and also sensor hub FIFO in case using the sensorhub feature of the device). @JBarr.12 for my better understanding, which is your FIFO mode selection? And which the configuration of FIFO_CTRL3 (08h) (gyro/axl in FIFO)? Which FIFO threshold did you set and which is the configuration of FIFO_CTRL4 (09h) bit STOP_ ON_FTH? Did you tried to disable the BDU and check if the issue is still there? Regards

[Wpeng.3]

Hello, friends. How is status about this issue ? I also ran into this problem.

LSM6DSM run in stream mode after about some minutes , PATTERN(3Ch-3Dh) was not corresponding to fifo data(3Eh-3Fh). the time of issue appearing is random(some minutes to one hour).

[JGarc.5]

I've also run into problems reading the LSM6DSM FIFO.

My problem (I'm only reading accelerations at fast ODR) is that I get interleaved X Y Z readings.

I always read in 6·N bytes batches to get always XYZ, but I get XYZ the first batch, then YZX, then ZXY, then XYZ all the time. (I have the sensor tile quiet over the table and I see 1G values changing of axis)

This is not happening at low ODR. The same code runs smooth at low ODR, and fails if ODR goes high

[JGarc.5]

Hi,

I've been doing a batch of tests running the same code with different configurations of the size of the block that I read from the FIFO.

In all the cases, if the time of getting the bytes from the FIFO is bigger that the sampling time (calculated just with ODR), the information on the FIFO gets corrupted (order of the axis gets mixed in the FIFO), so I can conclude that you can't read from the FIFO while the sensor is writing it.

I can't get fine enough to know the actual time that leads the FIFO to get corrupted.

I'm working on interrupts and DMA, so as soon as the INT pin goes high, I launch a DMA reading of the FIFO (SPI block read). When the reading time (teoretical) is 51% of the actual ODR Period or less, the data is consistent. Maybe there is more margin but my code works on power of 2 sizes and getting better resolution between 50% and 100% would require modifications that I can't afford right now (would post here if possible).