ADXL372 FIFO data error with long time reading

Thanks for the question. It looks like some digital communication issue. Can you verify if your SPI communication is reliable? By the way, have you tried multibyte read for the three axes of data? Let me know if it helps.

Thanks for your reply.

1) I think my spi communication is reliable.

Because when i communicate with ADXL345, it works properly.

2) I use multibyte read now, but the problem still happens occasionally.

this problem just happens occasionally. what's more, it doesn't last long time and the data become normal. like the picture shows below.

Thanks for your reply.

1) I think my spi communication is reliable.

Because when i communicate with ADXL345, it works properly.

2) I use multibyte read now, but the problem still happens occasionally.

this problem just happens occasionally. what's more, it doesn't last long time and the data become normal. like the picture shows below.

Thanks for your feedback. It's not quite clear what is shown on the graph you sent. So what is the signal in the blue line and what is the unit on the vertical coordinates? The noise seems pretty high on that axis. It seems the data is not swapped any more with multibyte read, did you do a multiple of 3 axes of data? Have you also checked if the series start indicator is correct in the part of data you circled out?

jwang, Thanks a lot.

1)Yes, I do a multiple read of FIFO for 3 axes of data with a multiple byte length of 960.

Code like this:

ADXL372_Read_Buf(XL372_FIFO_DATA,&SdWriteBuf[10],960);

But I didn't check the series start indicator is correct or not.

(I think if I read the FIFO correctly each time, there should not be errors.)

2) Sorry for the indistinct picture. The blue line data is correct. I zoom in the picture shows last time. As below:

As you can see, data swap still exist. 

3)here is my code for reading data.

// the watermark interrupt function
void intCallbackFxn(PIN_Handle handle, PIN_Id pinId)
{
   uint8_t  buf[2];
   uint16_t fifonum;
   switch (pinId) {
        case Board_DIO14:
            ADXL372_Read_Buf(XL372_FIFO_ENTRIES2,buf,2);
            fifonum=((uint16_t)(buf[0]&0x03)<<8)|buf[1];//FIFO entry大于480才读取数据，否则是误碰
            if(fifonum>480){
                AccOver=1;
            }
            break;
        default:
            /* Do nothing */
            break;
    }
}

//in the main function
if(AccOver){
    AccOver=0;
    ADXL372_Read_Buf(XL372_FIFO_DATA,&SdWriteBuf[10],960);

    SdWriteBuf[1]=(uint8_t)(RfSeqNumber>>8);   //记录帧标记
    SdWriteBuf[2]=(uint8_t)(RfSeqNumber);

    result = SD_write(sdHandle, SdWriteBuf, ACCSTARTSECTOR+accSectorLocation, 2);    //2sector 160samples/3200Hz/0.05s数据
    if (result != SD_STATUS_SUCCESS) {
        Display_printf(display, 0, 0, "Error writing to the SD card\n");
        while (1);
    }
    //RfReportTimeCount++;
    accSectorLocation += 2;
    if(accSectorLocation > ACCFULLSECTOR){   //25s数据
        ADXL_Stop();
        Display_printf(display, 0, 0, "ACC %d SECTOR FULL\n",ACCFULLSECTOR);
    }
}

Waiting for your help.

Thanks for the feedback. So what FIFO mode are you in? You should be streaming data out continuously in FIFO Stream Mode. While in the Oldest Saved mode, after reading the data, the FIFO must be disabled
and re-enabled to save a new set of data. Meanwhile, you can check on the serial start indicator to double confirm if the data is actually swapped.

By the way, is this released version of the sensor material, you can check the number printed on the package.

Hello,

 I have same problem here. After some minutes, the begin of fifo buffer is erroneous.

 My configuration is:

- Stream mode on 3axis

- Interrupt watermark (int1) @492 samples (164x3).

- ODR @6400Hz, BW@3200Hz.

- LPF, HPF disables.

When interrupt occur, I read status flag, FIFO entries then FIFO dat.

I read (492-3) samples =>978 bytes, for respect datasheet revB p20, "When reading data from multiple axes from the FIFO, to ensure that data is not overwritten and stored out of order, at least one sample set must be left in the FIFO after every read" ).

Down you will found some logic analyzer measurement.

Here a correct transaction :

Status read: Awake, fifo_full, fifo_rdy, data_rdy.

FIFO entries read: 0x1ED = 493 samples (+1 ?).

Begin of FIFO data read (0xD1 with LSB to indicate start of sample set XYZ).

End of FIFO data read (0x11 with LSB to indicate start of sample set), Z axis is not seen on this capture but is present.

And here an erroneous transaction:

Status read: Awake, fifo_full, fifo_rdy, data_rdy

FIFO entries read: 0x1ED = 493 samples (+1 ?).

Begin of FIFO data read (0x20 don’t have LSB to indicate start of sample set).

End of FIFO data read (0x11 with LSB to indicate start of sample set), Z axis is not seen on this capture but is present.

Thanks you for your help.

Emeric L.

I have the similar observations as Emeric L. and Howto:

Configuration is:
FIFO Watermark Level Interrupt ON
HPF on
BW = 1/2 ODR
Filter Settling Time: 370ms
Full-Bandwidth mode
FIFO is in XYZ (3-Axis) acquisition mode and stream mode

ODR might be 400Hz,800Hz,1600Hz, 3200Hz or 6400Hz and is selectable by user input.

The described problem does not occur at low ODRs like 400 and 800, it is negible at 1600Hz and present at 3200Hz and 6400Hz.

SPI is used with 6Mhz CLK using DMA download on a TI CC2640R2F micro-controller and with the TI SimpleLink SDK.

All operations involving changes in the ADXL372 configuration are performed while the ADXL372 is in ADXL372_MODE_STANDBY

The time it takes to service clear the interrupt from task context is around 500us. A worst case scenario would be 1ms and ODR = 6400Hz, which means that 19.2 fifo entries are generated by the ADXL372 in this time, so the candidate value for the watermark level should be smaller as 492.8 = (512 - 19.29). The previous multiple of three is 492 (164 * 3) and in order to have a small security factor we chose 489 (163 Triplets) as the watermark level.

The FIFO Watermark Level is set to 489 (163 XYZ Triplets) and 486 samples will be downloaded from the FIFO into a buffer in the MCU RAM.

After download, the buffer containing FIFO data is inspected and the number of sample sets is extracted by inspecting the series start indicators.

If the number of XYZ triplets is not 162 (the number of downloaded triplets), the program will reset the FIFO as following

1. Set ADXL372_MODE_STANDBY in ADXL372_POWER_CTL,
2. Set ADXL372_FIFO_MODE_BYPASS in ADXL372_FIFO_CONTROL,
3. Set ADXL372_FIFO_MODE_STREAM in ADXL372_FIFO_CONTROL
4. Set ADXL372_MODE_FULL_BANDWIDTH in ADXL372_POWER_CTL

The reset mechanism will recover the FIFO order for the next sampling, but at the cost of having a gap the size of the filter settling time. For ODR 6400Hz this is a big gap in our application as we rely on oversampling to improve the resolution of our signal.

Currently around 1 in 1000 downloaded FIFO windows will not have the first element marked as start-of-sample-set. In our case we record 1000 FIFO windows, so one gap is certain in our sampling.

We know how to recover, however we want to avoid the gap it generates.

The diagnostics show us that we have never gone to the FIFO_OVR condition. Also the diagnostic software has shown that the number of FIFO entries is around 489 to 495 before downloading and that enough samples remain in the FIFO. The status register always contains 0x47 before the download is started.

Even with the precautions we take, there is to be an out-of-order situation in the FIFO.

Is there any hint to avoid this?

Is there anything wrong in my previous thinking?

Regards,

Francisco LL.