ADXL372 FIFO data error with long time reading

Hi

I was wondering if there was any update regarding this? I've recently noticed one of the devices that contain the ADXL372 exhibits the same issue with FIFO axis swapping during some reads with a watermark of 160 values (Data is completely swapped or we get random spikes). Is there a workaround to continue using the FIFO? If I do a single read from the FIFO (When it's set in-stream mode) for the total amount of data I want (640 Samples), will the FIFO keep popping data and adding new data to it?

I've previously tried to read the XYZ register but had overhead issues causing delays in the data collection when the ODR is set a 6400Hz. If the FIFO is unsuitable is there a way to sample the data from the XYZ registers at 6400Hz?

Cheers

Jay

I know this is an old thread, but I had a very similar problem when I first started working with XYZ data in the FIFO.  I don’t know if it is this exact problem described in this thread but it certainly looks like it to me.  In case it helps anyone, I’m posting my solution here.

I configured the ADXL372 to stream at 6400Hz, set the watermark interrupt at 384 entries, started streaming and went to sleep waiting for the FIFO to fill.  After each watermark interrupt, I would read the STATUS, STATUS2 and FIFO_ENTRIES registers.  If everything was OK, I would then read FIFO_ENTRIES - 3 entries from the FIFO_DATA register to always leave a full sample set in the FIFO.  I used a fairly regular vibration input for testing, and I noticed that periodically the axes would obviously swap/rotate (e.g. X->Z, Y->X, Z->Y).  It turned out that when the swap occurred it would happen near a FIFO read boundary and usually several in a row if not every single one; (e.g. it happened about every 384 samples and if I reduced the watermark to 15 samples, the swap would occur in multiples of around 15 samples).  After a lot of experimenting and debugging, the solution I found that finally worked was to calculate FIFO_ENTRIES MOD 3 and then subtract three samples from that value as the number of samples to read from the FIFO_DATA.  This guaranteed that I would only read samples in multiples of three and never empty the FIFO.  The problem completely stopped occurring with this change.  I had previously been blindly using whatever was in the FIFO_ENTRIES register, which was sometimes not a multiple of three.

Thank you, user2022 for sharing your experience with us, in this forum! 

PdelCorro If you have a moment, can you share if  this correlates with what you have learned about the FIFO function, on this unit? 

Hi user2022 and Mark, 

thanks for your post. This is an interesting approach that we explored before as well, but unfortunately, we found that data can get misaligned randomly even when doing what you suggested. And the misalignment will generally occur in a random position of the FIFO memory. But I have to mention that some of the parts tested will show no misalignment at all and that might be what you are experiencing. We generally test several dozens of parts from different lots (at least 3) at different temperatures and due to the inconsistency of results we concluded this approach was not reliable. 

The good news is that we have found a possible workaround that showed to be robust and reliable, so far (we are still conducting tests on FIFO trigger mode, Stream and Oldest saved mode showed no misalignment).

This workaround requires using the synchronized data sampling feature, described on the datasheet (page 24). Using this feature bypasses the internal default logic that control the FIFO memory write pointer, where the root cause of the misalignment issue was determined to be. 

 So all you need to do, is to provide the external sync signal through INT2 pin following the datasheet guidelines to define the desire sampling frequency. 

Once all tests are completed, we plan to revise the datasheet including this workaround. 

I hope this helps and please let me know if more details are needed. 

Pablo. 

Thank you, PdelCorro !!

Hello, is the issue solved or do we still need to use this workaround? Also which revision of the datasheet are you referring to in this answer?
Thanks in advance.

AR

Hi reuter187 , 

The datasheet for ADXL372 has been updated to revC, adding the FIFO workaround.  You can download the datasheet from www.analog.com

I hope this helps, 

Pablo 

Thank you for the fast reply. Yes we saw the workaround in the datasheet and will try to implement. Is there any expectation to solve this in hardware?

Hi reuter187 , 

Currently, there is no plan to fix this issue at the ASIC level. 

Regards, 

Pablo

Ok, thank you. Is there an example on how to implement the workaound using no-OS?