LSM6DS3 FIFO data corruption on random basis.

[oversc0re]

Hi everyone!

I am using LSM6DS3 in a very simple setup: For the debugging purposes I am only using accelerometer, ODR is set at 416Hz, fifo is enabled in continuous mode and set at the same freq, no decimation. Only XL data is set to be stored in fifo.

I am reading data from fifo every second while buffer is constantly being filled. In random intervals the data I am reading gets corrupt in different ways:

• One axis data is simply missing (even reading the pattern confirms that there is an entry missing)
• Value from one axis is read out at another axis (pattern) (e.g. if device is standing still on the table, and normal reading is 10,10,-990, one of the readings can be -990,10,-990 or 10,10,10, while pattern values are always 0,1 and 2.
• Sometimes it even happens that the pattern is an invalid value (>2).

I have tried reading values in a numerous ways (reading fifo_status 1,2,3,4 and then fifo L and fifo H) and all possible combination of those. I have also tried reading whole fifo in a single shot, but regardless of the reading method the same problems are appearing. The errors appear randomly, sometimes a every few seconds, sometimes I have to wait for a few minutes. I have tried changing clock (from 100kHz to 300kHz), adding delays between reads, but nothing helps.

I have confirmed readings on a scope with I2C decoder so I am pretty sure that everything I read is actually sent from the LSM6DS3. Signals are clean, scope is not detecting any I2C errors at all.

My config (read from the chip):

CTRL9_XL = 0x38
CTRL1_XL = 0x60
FIFO_CTRL1 = 0x00
FIFO_CTRL2 = 0x00
FIFO_CTRL3 = 0x01
FIFO_CTRL4 = 0x00
FIFO_CTRL5 = 0x36

I am aware that my case is somehow similar to this one: https://community.st.com/s/question/0D50X00009hmIZiSAM/lsm6dsl-fifo-data-set-corrupted

I have spent a whole week on this problem but I am not making any progress. I would really appreciate any hint that would bring me closer to the solution of this problem.

Best regards,

Matic

[Eleon BORLINI]

Hi @oversc0re​ , do you think you are missing some sensor data in a random way? I suggest you to try enabling the STOP_ON_FTH bit of CTRL4_C (13h) register and set the FTH_[11:0] FIFO threshold to the maximum value also in Continuous mode. It is intended to stop the data collection and simplify the data synchronization during the acquisition. As described in the AN4650 (check also p.110, LINK:(

If the STOP_ON_FTH bit of the CTRL4_C register is set to 1, the FIFO size is limited to the value of the FTH_[11:0] bits in the FIFO_CTRL1 and FIFO_CTRL2 registers: in this case, the FIFO_FULL bit of the FIFO_STATUS2 register is set high when the number of samples in FIFO will reach or exceed the FTH_[11:0] value on the next FIFO write operation.

Regards

[Ozone]

I would suggest to direct your attention to the software part.

> I have confirmed readings on a scope with I2C decoder so I am pretty sure that everything I read is actually sent from the LSM6DS3. Signals are clean, scope is not detecting any I2C errors at all.

I would instrument the code to toggle a GPIO on your dropout error, and use this signal as trigger to stop the scope recording.

Which requires a scope having appropriate memory depth.

Check the recordings if the I2C signals (not only the decodings) show an issue.

If not, it gets lost somewhere in your software.

From experience, I can tell this is most often the case.

[oversc0re]

Thanks for your replies.

I did exactly what Ozone suggested. I stopped the program execution when the error occurred and checked the signals. I was able to see a bunch of normal reads

3C -> 0000

3E -> 0A0A

3C -> 0001

3E -> C4D2

3C -> 0002

3E -> F2AC

...

Followed by a broken read:

3C -> 0000

3E -> 0ABB

3C -> 0001

3E -> C4D1

3C -> 0000

3E -> 0AB1

As you can see above, the pattern 02 simply missing in the sequence.

I also checked timings, stop-to-start delay time explicitly and i can't seem to find a problem. When I detect an incorrect frame sequence, I can add a delay and retry after that, but the reading is still the same.

I will try using FTH and stop on FTH as Eleon suggested. I'll report the results.

Best regards,

Matic

[oversc0re]

Hi!

This problem is still driving me crazy. I tried setting STOP_ON_FTH and set the FTH to 9, so only 3 samples were captured each time, but it didn't work. After reading the datasheet and AN again I discovered that by setting STOP_ON_FTH I actually lowered buffer size to 9 but capture did not stop in continuous mode. Therefore, I got an overrun and data got corrupted anyway. 

To make at least some progress bought myself a proper logic analyzer and then set ODR to 416Hz, FTH to 800, enabled STOP_ON_FTH and used normal mode, so capture would stop once 266 samples are read (after 0.63s). After one second I would then read the buffer by the book: read 6 bytes starting from 0x3A (fifo status 1) until available data is exhausted. This way for each sample I can see number of readings remaining, the pattern, flags and data. After the buffer is read I would restart the fifo by disabling it and setting it back to FIFO mode.

Unfortunately after quite some time (I'd say it happens once per hour) I received and invalid pattern while reading the buffer. I have managed to record it on logic analyzer. The image is to large to upload: link

As you can see, the data is being read correctly (last 2 bytes of each read is in the following order: 0xFFXX, 0x00XX, 0xC1XX) and the pattern is cycled correctly (byte 3) 0->1->2->0,... until the last sample where pattern 0 is followed by pattern 2 even though the data is correct and corresponds to the data from actual pattern 1 (0x0072). Reading another sample (not shown in the picture) returns data from pattern 2 (0xC166) but is labeled with pattern 0, which I think confirms that the data is actually written incorrectly in the buffer.

This problem can be reproduced any time, it just takes a while until it happens!

Does anyone have some other suggestions I could try? We have a few 1000 devices deployed so I really need to find a way around this. Is there an official support for such issues other than this forum?

Thanks,

Matic

[amistar]

@oversc0re Did you managed to solve FIFO issues or switched to other device with better documented FIFO?