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.

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

    Status ransaction OK

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

    Transaction OK - Fifo entries

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

    Transaction OK - FIFO read begin

    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.

    Transaction OK - FIFO read end

    And here an erroneous transaction:

    Status read: Awake, fifo_full, fifo_rdy, data_rdy

    Transaction KO - Status

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

    Transaction KO - FIFO entries

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

    Transaction KO - FIFO Read begin

    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.

    Transaction KO - FIFO Read end.

    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.

  • 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?

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