Showing results for 
Search instead for 
Did you mean: 

H3LIS331: SPI read response is always 0x00


Hello, I am attempting to communicate using SPI with an H3LIS331 accelerometer. The H3LIS331 is on a custom board that originally had a LIS3DSH on it. The LIS3DSH had been working without a problem, but we were looking to expand the acceleration scale.

No matter what register I attempt to access, the MISO line puts out one byte of 0xFF and one byte of 0x00. See the attached logic analyzer screenshot, which shows writing to 3 CTRL registers and then attempting to read the WHO_AM_I register. The SPI traffic in the screenshot is the first to occur after powering the board on.

Additional information:

  • I am using a SPI clock of 9.4 MHz
  • I have my SPI set up per the datasheet: Clock idle high, data valid on rising edge
  • I have verified that the devices' pins are at the correct voltages
  • This SPI bus is shared with other devices (different CS lines), and those still communicate correctly
  • the SPI signals all look okay on an oscilloscope

I did notice that the MISO line has an unusual "long tail" after the low byte; see the attached oscilloscope capture which also shows the SPI clock. That might be a symptom of some fundamental problem, but isn't a problem in itself.

Can you see anything I'm missing, or do you have suggestions of what to check next? Thanks!

ST Employee

Hi @MRigg.1​ ,

the H3LIS331(DL) and the LIS3DSH are pin-to-pin (and voltage) compatible, so in principle there should be no difference. The suggested electrical connections are the same too.

So I believe there could be two reason for the malfunction:

  • H3LIS331 has been damaged during the re-soldering phase, and/or some pads could have been accidentally left open (do you have the possibility to test the pin continuity?);
  • There could be some issues related to the timings of the SPI interface, that might occur in the case the soldering phase is ok but there are some unwanted parasitic on the lines --> you can try to reduce the SPI speedy.

Another point to test is to check the timings you can find in the p.11 of the datasheet:


Can you confirm they are fulfilled?



Hello Eleon,

Thanks for the fast response!

All of the timing parameters are met except for t_dis(SO), which is very out of spec at ~650 ns (compared to the maximum 50 ns spec). See the attached screenshot. This may point to damage to the H3LIS331, I'm not sure. I don't have access to the pads themselves, only the traces as they leave the chip footprint. I have applied pressure on the chip to try and force contact, but I didn't see a change in behavior.

Regarding parasitics, I slowed the SCLK down to 1.9 MHz to test this, but the behavior is the same as described in my initial post.

At this point, I'm going to get another H3LIS331 swapped in and hope for different behavior. If you have other suggestions to try, I would appreciate them.

Thanks again!


Associate II

Me too, no solutions