LIS2MDL BDU only works for 3 axis independent readouts

[amistar]

HI, it seems to me that reading the LIS2MDL sensor only works correctly if I read first the X axis, then the Y axis, and finally the Z axis separately, each axis in a separate SPI transaction.

My settings:

- continuous measurement, output data rate set at maximum 100Hz

- temperature compensation turned on

- high resolution mode

- low pass filter disabled, offset compensation disabled

- i2c disabled, SPI 3-wire clocked 10MHz, BDU enabled

- data ready interrupt on INT pin triggers enqueuing event into event queue, then main loop perform readout after some time (there are other higher priority tasks)

My observations:

1. Reading 8 bytes in one SPI transaction (from OUTX_L_REG 0x68 to TEMP_OUT_H_REG 0x6F) to read all data does not work at all, temperature data is broken, you need to split readout into 6 bytes of "axis data" and 2 bytes of temperature data

2. In certain edge cases of my application when possible readout latency is high I have incorrect readouts of Z axis from time to time (around once per 2 seconds), when I spitted SPI readouts into 3 transactions (first 2 bytes of X axis, then 2 bytes of Y axis, then 2 bytes of Z axis) the problem is gone.

Please confirm whether it is necessary to read 2-byte registers independently and if so, please check if this information is in the documentation.

[amistar]

Hi, I tried printing out raw values.

Below you can see 3 samples with broken Z axis readout, each time it was broken the MSB of Z axis was equal to LSB of X axis. This might be a problem with my software, but if you guys now know how LIS2MDL registers are upgraded and how BDU works you can make me sure that this is not LIS2MDL problem but my software problem... I would be grateful if you could take a look at these results and assess whether this is a LIS2MDL problem.

Magn X | Magn Y | Magn Z | Raw data X  | Raw data Y  | Raw data Z | 
------------------------------------------------------------------
 -975, |  171,  |   132, | 0x76, 0xfd, | 0x8e, 0xff, | 0x58, 0x00 |
 -984, |  178,  |   121, | 0x70, 0xfd, | 0x89, 0xff, | 0x51, 0x00 |
-1002, |  195,  |   112, | 0x64, 0xfd, | 0x7e, 0xff, | 0x4b, 0x00 |
 -991, |  189,  |   111, | 0x6b, 0xfd, | 0x82, 0xff, | 0x4a, 0x00 |
 -990, |  193,  |   108, | 0x6c, 0xfd, | 0x7f, 0xff, | 0x48, 0x00 |
 -994, |  193,  |   123, | 0x69, 0xfd, | 0x7f, 0xff, | 0x52, 0x00 |
-1003, |  187,  | 32764, | 0x63, 0xfd, | 0x83, 0xff, | 0x00, 0x63 |
 -994, |  192,  |   106, | 0x69, 0xfd, | 0x80, 0xff, | 0x47, 0x00 |
 -991, |  187,  |   120, | 0x6b, 0xfd, | 0x83, 0xff, | 0x50, 0x00 |
 -994, |  196,  |   103, | 0x69, 0xfd, | 0x7d, 0xff, | 0x45, 0x00 |
 -999, |  192,  |   109, | 0x66, 0xfd, | 0x80, 0xff, | 0x49, 0x00 |
-1003, |  193,  |   108, | 0x63, 0xfd, | 0x7f, 0xff, | 0x48, 0x00 |
 -997, |  198,  |   105, | 0x67, 0xfd, | 0x7c, 0xff, | 0x46, 0x00 |
------------------------------------------------------------------|
 -993, |  195,  |   118, | 0x6a, 0xfd, | 0x7e, 0xff, | 0x4f, 0x00 |
 -993, |  195,  |   123, | 0x6a, 0xfd, | 0x7e, 0xff, | 0x52, 0x00 |
 -991, |  180,  |   114, | 0x6b, 0xfd, | 0x88, 0xff, | 0x4c, 0x00 |
 -987, |  193,  |   121, | 0x6e, 0xfd, | 0x7f, 0xff, | 0x51, 0x00 |
-1003, |  183,  |   118, | 0x63, 0xfd, | 0x86, 0xff, | 0x4f, 0x00 |
 -991, |  192,  | 32764, | 0x6b, 0xfd, | 0x80, 0xff, | 0x50, 0x6b |
 -982, |  190,  |   126, | 0x71, 0xfd, | 0x81, 0xff, | 0x54, 0x00 |
-1000, |  192,  |   124, | 0x65, 0xfd, | 0x80, 0xff, | 0x53, 0x00 |
 -996, |  187,  |   120, | 0x68, 0xfd, | 0x83, 0xff, | 0x50, 0x00 |
 -996, |  189,  |   118, | 0x68, 0xfd, | 0x82, 0xff, | 0x4f, 0x00 |
 -999, |  196,  |   121, | 0x66, 0xfd, | 0x7d, 0xff, | 0x51, 0x00 |
 -994, |  190,  |   114, | 0x69, 0xfd, | 0x81, 0xff, | 0x4c, 0x00 |
-------|--------|--------|-------------|-------------|------------|
-1000, |  192,  |   121, | 0x65, 0xfd, | 0x80, 0xff, | 0x51, 0x00 |
 -996, |  196,  |   120, | 0x68, 0xfd, | 0x7d, 0xff, | 0x50, 0x00 |
 -993, |  190,  |   127, | 0x6a, 0xfd, | 0x81, 0xff, | 0x55, 0x00 |
 -996, |  181,  |   120, | 0x68, 0xfd, | 0x87, 0xff, | 0x50, 0x00 |
 -997, |  186,  | 32764, | 0x67, 0xfd, | 0x84, 0xff, | 0x00, 0x67 |
 -996, |  186,  |   126, | 0x68, 0xfd, | 0x84, 0xff, | 0x54, 0x00 |
 -985, |  190,  |   115, | 0x6f, 0xfd, | 0x81, 0xff, | 0x4d, 0x00 |
 -991, |  193,  |   120, | 0x6b, 0xfd, | 0x7f, 0xff, | 0x50, 0x00 |
 -987, |  177,  |   132, | 0x6e, 0xfd, | 0x8a, 0xff, | 0x58, 0x00 |
 -969, |  172,  |   139, | 0x7a, 0xfd, | 0x8d, 0xff, | 0x5d, 0x00 |
 -985, |  177,  |   130, | 0x6f, 0xfd, | 0x8a, 0xff, | 0x57, 0x00 |

[Federica Bossi]

Hi @amistar ,

You can read all the output registers. Can you implement our official drivers and let me know if you solve the issue?

Thanks

[amistar]

Hi

I found the problem, it was too high SPI frequency. According to info found in `stm32f7xx_hal_spi.c` file there are different limits of SPI frequencies, thus prescalers, depending on mode of operation used. We will switch to our own driver at some moment, but now sticking to 6.25 MHz instead of 10 MHz is good solution.

We have also another problem with HAL SPI, it does receive two bytes to much - below you can see a SPI transaction readout of axis X, Y, Z of magnetometer which receives 6 bytes, but SPI peripheral keeps clock working for another 2 bytes. We wont try to debug it, but rather switch to own SPI driver.

We can consider the problem solved

Best regards

[amistar · Accepted solution]

Problem solved

I found similar topic: https://community.st.com/t5/stm32-mcus-products/stm32f767-spi-bidirectional-receive-mode-more-spi-clocks-are/m-p/213384#M46791

And this description why STM32HAL cant handle bidirectional SPI properly:

http://efton.sk/STM32/gotcha/g32.html