I have found that this issue happened always when I got a certain pattern (0x80 0x00) in my data which let me to this part in the driver code:
|* @brief This API checks the presence of non-valid frames in the read fifo data.|
|static void check_frame_validity(uint16_t *data_index, const struct bmi160_dev *dev)|
|if ((*data_index + 2) < dev->fifo->length)|
|/* Check if FIFO is empty */|
|if ((dev->fifo->data[*data_index] == FIFO_CONFIG_MSB_CHECK) &&|
|(dev->fifo->data[*data_index + 1] == FIFO_CONFIG_LSB_CHECK))|
|/*Update the data index as complete*/|
|*data_index = dev->fifo->length;|
Is this a bug in the driver or is this intentional behavior?
It is recommended that you refer to the example code and check whether the FIFO reading data is normal according to your ODR and FIFO watermark settings. For example, if you set 100 Hz ODR, enable accel, gyro and FIFO header, and set FIFO watermark to 78(means 78*4 bytes FIFO data), then after receiving FIFO watermark interrupt, you will read 24 frames of accel and gyro data, with a time interval of about 240ms.
First confirm that the FIFO reading is normal, and then check whether the data is correct.
Before I do the read operation I check the available data as is done in the example application (rslt = get_fifo_byte_counter(&bytes_to_read, dev);). This reads consistently 768. When I toggle a GPIO pin of my microcontroller outside to check the interrupt timings it is also consistent. Also if the PCB is laying still on the desk this issue does not appear to happen. It consistently happens when the desribed pattern appears in the data and it does not happen when I turn of the check for the data. When I for example plot the data it looks correct when I ignore this 0x80 0x00.
Thanks and best regards,
Did you run reference code?