schizophrenic LIS3DS0

[samuel23]

Posted on November 28, 2016 at 17:59

Hi everybody,

We are using LIS3DS0 on the ISK01A1 board monted on a Nucleo F103-RB...Our software is based on HAL drivers (got in the cube).We met this strange issue in some of our boards (we confirmed the test with many students and dozens of boards):1- we plug the board2- the accelerometer failed to initialize. (due to the WHO_AM_I register which is 0xD4 instead of 0x68).We can reset again and again our STM32, without any change.Then we program a flush of registers of the LIS3DS0.We confirm the registers seems to correspond to another component (L3G3200D) !(WHO_AM_I of 0xD4, )But, when we do the following steps, the component run well :1- plug the board2- -> fail to initialize3- get off the JP2 jumper4- ensure temporarly 0V on the Vcc of sensor (with wire) (to avoid a 2V power by I2C bus)5- get on the JP2 jumper-> It works!We can reset our STM32, it works each time.Any idea????!!!Thanks! #lis3ds0-iks01a1-initialize-fail

[Miroslav BATEK]

Posted on November 30, 2016 at 14:55

To correct you, the combo sensor on IKS01A1 expansion board is LSM6DS0, it is accelerometer and gyroscope in one package.

Can you please explain me what means “Then we program a flush of registers of the LIS3DS0.�?

Best regards

Miroslav

[samuel23]

Posted on December 05, 2016 at 18:32

Hi,

We solved the problem...!

You ask me about the dump of memory... we got these dump in the two situations:

Then, we found that the problem seems to be linked with the power rising time on the Nucleo+IKS01A1.

We add a 100uF capacitor to get the second curve...(between Vdd and GND)

We deduce that the accelerometer enter in non coherent state when the power reach back to 1V after a small time at 1.2V... Strange!

The second curve show the slow charge of capacitor, which crushes the fake initial rise of Vdd.

Thx!

[Seb]

Posted on December 10, 2016 at 14:42

There could be some simple SW test/advice:

Test 1: Add a SW delay before attempting to communicate with I2C Slave devices

Test 2: Before communicating by I2C, read the SDA and SCL GPIO level (as input) and make sure these lines are '1'.

Test 3: Before generating a Start Bit, make sure both SDA and SCL are high. If they are not, one option to resynchronize the slave devices (which do not have a reset pin) is to generate manually 9 STOP bit (forced as IO bit banging). Case study: Reading a slave device which data is 00 and the MCU is reset in the middle of the transmission : The SDA line will be stuck low.

[Seb · Accepted solution]

Posted on December 15, 2016 at 12:02

There is a simple way to check if it is related to supply: MEMs are low power, so you can use a push-pull free GPIO to become a power supply pin. The MCU will then be able to totally turn off and totally turn on the device instantly. The rise time will be quick and check if the supply is the culprit. Have you made sure that all the pins of the sensor are correctly programmed? The slave address select forced to ground or Vdd?

[samuel23]

Posted on December 15, 2016 at 11:51

Thx for your answer!

I've done the tests...

In our software, there is >50ms between the power up and the I2C communication.

Test 1: a software delay (400ms) do not change anything

Test 2: the I2C lines are both at level '1' before the communication.

(the Test 3 is not necessary while SDA and SCL are high... but thanks for this tip.. it can be usefull to reset a I2C slave in other contexts!)

The problem seems to be linked to the power sequence of LIS3DS0 when the voltage is not rising fast enough...

[samuel23]

Posted on December 15, 2016 at 16:13

I am confident it will run if we use a GPIO to power the sensor... (this is quite the same result than my first manual test)

But this is not practical to add a wire to the X-NUCLEO_IKS01A1 board. It is feasible on a home-made design... but with more than 120 students the scale factor is not the same ^^

In this context, the capacitor showed good results.