Skip to main content
Visitor II
October 8, 2017
Solved

LIS3MDL Doesn't Respond Properly Over SPI

  • October 8, 2017
  • 1 reply
  • 1011 views
Posted on October 08, 2017 at 06:56

I am attempting to communicate with a LIS3MDL through the SPI interface, yet I am unable to get a single, valid response back. Moreover, the responses I am getting violate the setup and hold times on the SPI interface.

You can see from the following image that I am attempting to read from the LIS3MDL's WHO_AM_I register (address: 0x0F; expected: 0x3D), but I am getting garbage out. Moreover, the output from the LIS3MDL is transitioning at the rising and negative edges of SCLK!0690X00000608WJQAY.png

I have the LIS3MDL breakout board (STEVAL-MKI137V1) so I expect the hardware should be solderd properly.

Any other suggestions or anyone having a similar issue?

#spi #lis3mdl #who_am_i
    This topic has been closed for replies.
    Best answer by Miroslav BATEK
    Posted on October 09, 2017 at 10:32

    What is the distance between your microcontroller and the sensor?

    Can you please capture the SCLK signal close to the sensor by the scope. Maybe there is ringing on the rising and falling edges which are interpreted as clock pulses. A solution could be to slow down the rise/fall time of you clock signal.

    1 reply

    ST Employee
    October 9, 2017
    Posted on October 09, 2017 at 10:32

    What is the distance between your microcontroller and the sensor?

    Can you please capture the SCLK signal close to the sensor by the scope. Maybe there is ringing on the rising and falling edges which are interpreted as clock pulses. A solution could be to slow down the rise/fall time of you clock signal.
    Tim SAuthor
    Visitor II
    October 10, 2017
    Posted on October 10, 2017 at 17:28

    The distance is about 3cm, including the lead cables. My scope seems to not want me to capture right now, but after your suggestion, I observed SCLK ringing with a ~0.7V peak (I wish the datasheet told us what VIH and VIL should be), likely being registered as a clock pulse (which should have been more obvious to me with the data transitioning on both clock edges). Fixing the impedance on SCLK fixed the issue.

    I'll have to change the series resistors in our design to reflect these changes.

    Thank you for your help, Miroslav.