BMM150 Z value not correct

[Myzhar]

Hi,
I'm using a BMM150 as auxiliary sensor of a BMI270.
The communication works correctly, but I get weird data for the Z axis.

Debugging the sensor API I noticed that the `compensate_z` function always returns `BMM150_OVERFLOW_OUTPUT` because `dev->trim_data.dig_z2` is always ZERO.

How is this possible?

Thank you
Walter

[Myzhar]

I just noticed, debugging the Bosh API, that the function `compensate_z` always returns `BMM150_OVERFLOW_OUTPUT` because `trim_data.dig_z2` is zero...

How can this be possible? Does this mean that the initial trimming has failed?

Furthermore performing a self test after initialization I get the following errors:
Normal test: `BMM150_W_NORMAL_SELF_TEST_XZ_FAIL`
Advanced test: `BMM150_W_ADV_SELF_TEST_FAIL`

Thank you
Walter

[o_o]

The normal self-test is a continuity check. If indeed the normal self-test has failed, the most likely cause is damage to the sensor. The sensing elements are very close to the edge of the package, and using metal tweezers can chip the silicon and cut the sensing coil.

o_o

[Myzhar]

This is scaring since the PCB I'm using comes from production manufacturer, but it could explain a lot of things.

Does a chip damage explain also the zero value for Z2 trim data?

[o_o]

Hello Myzhar,

the Z2 parameter is a signed integer. Zero is a possible value, that would not indicate a failure. What is the failure rate? Do you have multiple failing parts?

o_o

[sebmadgwick]

We have been using the BMM150 in production for a few years now.  We had to make a special effort to overcome initial poor yields.  Even minor superficial damage to the package may cause it to fail.  A device will typically fail completely but we have observed other failure modes such as single axis failure, failure after a period of time (minutes), or otherwise unreliable measurements.

Physical damage can result in a whole range of unexpected behaviour. It seems reasonable to expect this to include apparent corrupted register values.