LIS3DH don't send ACK at 9th clock pulse

[Robin Zhou]

I am using LIS3DH accemelator to acuqire gravity data. The MCU is NXP MKL16. LIS3DH's pin8 CS is set to high level to communicate with I2C protocol, and pin7 SA0 is set to connect to GND. The SCL and SDA pins are pull up with 4.7K resisttors. After setting the MCU's I2C port with 50KHz communication speed, and try to read WHO_AM_I register of LIS3DH, the value return is 0XFF, which is not correspond with 0X33. Then I use an oscilloscope the capture the signals on Lis3DH SCL and SDA pins. The signals can be seen from the picture. It seems that the acknowledge is not received at the 9th clock pulse, which is conflict with the LIS3DH's datasheet. I have spent plenty time to make LIS3DH to work correctly, but in vain.

​Does anybody know the reason? Help or suggestion is needed here. Thanks!

[Andrew Neil]

When an I2C Slave doesn't give an ACK to the Slave Address - that means you have the Slave Address wrong!

I2C Slave Addresses are seven bits - A common confusion is whether those seven bits are left- or right justified within a byte.

"The MCU is NXP MKL16"

So it's quite possible that NXP justify differently from ST - Check carefully!

https://www.avrfreaks.net/comment/2276181#comment-2276181

https://www.avrfreaks.net/comment/2126096#comment-2126096

https://www.avrfreaks.net/comment/1872781#comment-1872781

[Robin Zhou]

Thanks for Andrew's suggestion. But after carefully check, the Slave Address and sub register address seems right. As the slave address presented in LIS3DH datasheet, with SA0 pin connected to GND, 7bits slave address is 0011000b, the SDA signal of the first byte, the LSB bit is I2C Write bit. NXP MKL16 writes a byte with MSB first, the same with LIS3DH, the justify doesn't seem to be a problem.

The sequence of read a byte is correspond with the datasheet.

The WHO_AM_I register address(bit0-bit6) is 0x0F according to the datasheet, only one byte is readed, so the MSB bit (bit 7) is set to 0b, the SUB is also right.

But LIS3DH don't give SAK at 9th clock pulse for three times. Any possible cause? Thanks!

[Andrew Neil]

Do you have the NXP chip correctly configured - with open-drain pins, etc?

Have you tried this with any other Slaves?

Have you tried the LIS3DH with any other Master ?

[Robin Zhou]

I'll try it later, thanks for you advice.

[Tesla DeLorean]

The device is simply non-responsive.

You could have the wrong address, try both 0011000 and 0011001 addresses.

The chip could be powered incorrectly.

The SCL/SDA could be swapped.

The chip could be in SPI mode.

You need to examine the circuit.

You could perhaps try lower speeds, or bit-bang methods.

Your code should stop banging forward if the device doesn't ACK it's own address.

[Andrew Neil]

As @Community member​  said, your code really shouldn't continue if it hasn't got an ACK to the Slave Address.

Any decent I2C library/driver code should give you an error code indicating that the Slave did not ACK.

A simple test is to simply try every possible 7-bit slave address in a loop - and see which one gets an ACK!

If you do get an ACK, that confirms what address th Slave is responding to;

If you don't get any ACK at all, then look at the other issues Clive mentioned ...

[Robin Zhou]

Thanks to Andrew and Clive. The problem is solved, the hardware guys made a mistake.