Post Go back to editing

ADXL372 FIFO data error with long time reading

Hello,

I am using the adxl372 to measure the x,y,z acc data, the initialization is normal.

and i get the data through the FIFO, here comes the problem.

I set FIFO samples num as 480 (0xE0,160 samples for each axis),set the watermark interrupt, in the interrupt callback function,

I read the FIFO data through SPI.(read 157 samples each time)

Everything is fine in the begining, but a little moment later, the data goes wrong, and then three axes data begin to swap. 

As the picture shows below,

I don't know why this comes like this, the data swaps every time i read the fifo(157 samples).

Best regards.

Parents
  • I am experiencing the same problem for sampling rates above 3200 Hz, with and without EXT_CLK (<= 3200 Hz works perfectly fine). In short, the series start indicator moves from X axis to another one as shown on picture below. I check all STATUS register flags before read and I control that at least one sample set (6 bytes for XYZ) remains in a FIFO after read. I do 960 multi-byte read on watermark, FIFO_SAMPLES=0x01E3, so 160 XYZ concurrent samples are read all at once. The FIFO is in a stream mode, package marking code "372B 1904 3263" (space=new line).

    Did anyone found out what might be the cause?

Reply
  • I am experiencing the same problem for sampling rates above 3200 Hz, with and without EXT_CLK (<= 3200 Hz works perfectly fine). In short, the series start indicator moves from X axis to another one as shown on picture below. I check all STATUS register flags before read and I control that at least one sample set (6 bytes for XYZ) remains in a FIFO after read. I do 960 multi-byte read on watermark, FIFO_SAMPLES=0x01E3, so 160 XYZ concurrent samples are read all at once. The FIFO is in a stream mode, package marking code "372B 1904 3263" (space=new line).

    Did anyone found out what might be the cause?

Children
  • Thanks for the question. It looks like this is some timing-related issue with the internal FIFO architecture and we are currently investigating the potential root cause. In the meantime, I'd suggest to stream from data register to avoid this data misalignment issue.

  • Hi jwang, thank you for looking into this. I have some more inputs that might help.

    In order to investigate the issue, we have started to read the STATUS, STATUS2 and FIFO_ENTRIES register always before and also after reading the FIFO_DATA register. We have found, that while we always get enough FIFO_ENTRIES (0x01E3) prior the multibyte-read of 960B from FIFO_DATA register, sometimes we get unexpected FIFO_ENTRIES after pulling FIFO_DATA. To explain, when it works (series bit correctly set), we get expected following readings from the FIFO_ENTRIES right after we pull the FIFO_DATA:

    ODR [Hz] / FIFO_ENTRIES [dec]: 400/15, 800/27, 1600/54, 3200/107, 6400/226

    However, when the FIFO series bit gets misaligned, the FIFO_ENTRIES returns 0 samples (after constant 960B FIFO_DATA read). I guess this explains the data misalignment as there are no valid data left in the FIFO. However, we don't know why this happens as there are certainly enough entries prior the read and therefore should be also enough after the read. I have tried different variations - 1) keep FIFO_SAMPLES = 0x01E3 and pull just 240B from FIFO_DATA; 2) lower FIFO_SAMPLES to 0x0078 and read just 199B from FIFO_DATA, but nothing helped to resolve this problem.

    We are now planning to buy a SPI logic analyser to see what's happening on SPI and power lines when this happens. To me it seems that either we are somewhat pulling more data from the FIFO when this happens or the ADXL372 dis-validate or forgets it's own FIFO_ENTRIES. This happens in about every third measurement on 6400 Hz we do, there are measurements where everything seems nominal.

  • 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,  for sharing your experience with us, in this forum! 

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

  • Hi  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.