BDU - Block Data Update - Which registers are covered ASM330LHH

[m_kolesinski]

Hello,

For the ASM330LHH, it's not clear which registers are covered by the BDU setting.  Although the datasheet and application notes list some registers that are covered, they are presented more as examples than an exhaustive list.

In my testing, it appears the BDU register doesn't protect the temperature (non-FIFO) registers at all.  With BDU enabled, I would still get ~1 degC temperature spikes when the sensor was operating at the rollover boundary (LSB near 0x00 or near 0xFF), due to the slight time skew between the two registers.  I was able to work around this by using the FIFO.

I also need to be able to sample the TIMESTAMP registers (TIMESTAMP1, TIMESTAMP2, TIMESTAMP3, TIMESTAMP4), from outside of the FIFO.  This is important because I need to periodically correlate the ASM330LHH's internal timestamp to an external time/clock; using the FIFO would introduce a large skew and a lot of complexity.

Are the timestamp registers protected by the BDU feature?  Can I reliably read them consecutively, and not have to handle saturation/rollover conditions at each byte's boundary?

Thanks!

[m_kolesinski]

Well, I haven't gotten any response, so I don't know if these results are expected, but I will share my observations based upon low-level testing:

• Timestamp registers (not in the FIFO) are *not* protected by BDU; if you read them spanning a rollover in any of the bytes, it will most definitely bias your time upwards by the corresponding amount.  Why this wasn't considered in the design I don't know, but the documentation on this feature is incomplete and misleading.
• Temperature sensor registers (not in the FIFO) are *not* protected by BDU.  Another topic on this forum was closed with the suggestion that the user turn on BDU, but it does not work on temperature data outside of the FIFO.  Again, why this sensor was excluded, I don't know.

Here is some sample data proving the rollover issue affecting timestamps (this example is on the LSB; it's more difficult to catch the other bytes since they come up less frequently)...the timestamp was sampled at approx 50ms intervals; anytime the LSB is within a few ticks of rollover, there's a large delta on the order of ~6ms (on the order of ~256 ticks, with some variability due to the imprecision of task scheduling in Linux, which corresponds to full-scale of the LSB):

timestamp	%255	delta
0x00EC2FCB	203	2112
0x00EC37CF	207	2052
0x00EC402D	45	2142
0x00EC4860	96	2099
0x00EC5082	130	2082
0x00EC588E	142	2060
0x00EC61FF	255	2417
0x00EC6925	37	1830
0x00EC715D	93	2104
0x00EC79AF	175	2130
0x00EC81D3	211	2084
0x00EC8A01	1	2094
0x00EC9227	39	2086
0x00EC9A73	115	2124
0x00ECA272	114	2047

[Smithson]

Yes, your data is skewed.  See analysis.