BMI270 - incorrect number of samples in FIFO when auxiliary sensor is enabled

[zgg]

Hello

Thanks for your posts and interests in using Bosch sensors.

I checked your settings into details, one thing I noticed is that:

aux_rd_burst = 6; /* 3 axes */

actually, 6 is an invalid value, valid values range from 0 to 3, from the datasheet:

https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi270-ds000-2.pdf, page 116 or search for: man_rd_burst

0: burst read of length1

1: burst read of length 2

2: burst read of length 6

3: burst read of length 8

You may want to change this and see what happens.

I personally had tested the sensors' streaming in FIFO with accel/gyro/mag in the past, but never seen issues with samples dropped or alike.

One thing to be noted though: the actual ODR is not exactlly the same as what is selected due to the fact that the clocks on the sensors can not be perfect, for example, when you set the ODR to 100hz, the actually ODR could be 99hz or 101hz, and this error is also specified in the datasheet on page 14 (ODR Accuracy), so in one second you might see  99 or 101 samples instead of expected 100 samples, if you see 99, you might think a sample is lost while this is absolutely expected normal behavior.

Hope this explains!

Take care!

[alastair]

Even with that value fixed it doesn't work. Interestingly it made no difference to operation (6 bytes was correctly being read by the BMI270 with both settings), I guess the library masked off the top bit making the values 2 and 6 the same anyway.

[alastair · Accepted solution]

I found the problem. The extract_xxx functions for extracting data from the FIFO use the record lengths in the fifo frame structure (e.g. fifo_all_frm_len), but these values are incorrectly populated by the library. They're set to hardcoded values rather than matching the actual configuration of the device. So.. setting the burst read length of the auxilliary sensor to anything other than 8 results in these functions producing incorrect results. I'm going to open a bug on the github repo with this but Bosch doesn't seem to pay any attention to these.

[Vincent]

I will ask our API team to look into this and come back to you later.

[alastair]

---

@Vincent wrote:

Can you print out the frame header which you parse error to cause the function exited?

Your implementation looks fine and our API is considering all possible FIFO frame header situation in our API code. 

It will only finish parsing if they met 0x8080 as padding bytes under FIFO header mode. 

---

The length for aux data is hardcoded, it's not using the setting as far as I can see. When I had the aux read size set to 6 I would expect a full frame to have 6 aux + 6 accel + 6 gyro = 18 bytes, but the library assumes 20 bytes, so as soon as it seems a frame with aux data in it it breaks.