LIS3DH stops sampling measurements after some time

[javier2]

Posted on January 24, 2015 at 22:56

We have noticed that the accelerometer stops sampling after some time (10+).  When that happens, the only work around is to write 0x0 in REG4, and then re-writing the original value of 0x37.  Anyone has encountered a similar problem?

Cheers, #sampling-freeze

[Albi G.]

Posted on February 23, 2018 at 19:07

I have the same problem. I cant figure out why this happens, but it sucks. I have the feeling that it is really susceptible to power supply issues.However your Reg4-Trick does not work for me...

Sometimes its sufficient to RebootMemory, but a lot of cases require a oiwer cycling - inacceptible problem for a Wake-up-Sensor in my application.

[Miroslav BATEK]

Posted on February 24, 2018 at 11:27

Do you have recomended blocking capacitors close to the sensor?

[Albi G.]

Posted on February 24, 2018 at 13:37

Of course, of course, since i suspected power issues, the whole thing is meanwhile burried under caps. No Help unfortunately.  I also added caps to the ADC-Inputs, since they are driven from another power supply rail (another 3.3.V rail) and i expected latchup from there... but sill no luck.

Some more Info, since there is interest:

1)  One ADC input is saturated (having 3.3V on its input).

2) the lock up occurs, when i have stepper motors activated on my PCB... those stepper motors have the following impact:

2a) they draw huge amounnt of power from a 12V rail that is feed by a DC/DC-regulator from my battery input (currently supplied by a power supply). The battery voltage also provides the 3.3V though an linear regulator.

The path from 12V to 3.3V is therefore either ground directly (which shouldnt be an issue given the anmount of caps i have) or must go though at least one DCDC (Sepic) and back through the PSRR of a linear regulator.

2b) The stepper motors also are software interrupt driven - this interrupt has the highest priority in the system, interrupting potentially everything.

2c) occasionally i saw that the last value transmitted from the ADCs seems to be the positive full scale value... but i didnt investigate further.

3) I use INT1 to signal that data is available. I also use BlockUpdate, because why not, also i dont use the FIFO. The data accuisition is therefore interrupt driven using the SPI-interface while possibly something else is going on on the SPI. (i just realized that).

-> however a fuckup of a transmission should not lead to a lockup that requires a power cycling. Does ist..?

3a) during stepper motor control the SPI is also used to adjust motor current via ADC @ SPI and also light some LEDs via a SPI shift register..... there could be collisions.

But such a serious lock up ??

The problem debugging this is that i simply dont know if its software or hardware and its very infrequent that anything happens at all, but if it happens its a catastrophic event.

[Miroslav BATEK]

Posted on February 26, 2018 at 10:17

I doubt the solution reported by Javier could work, it doesn't make sense to write these values to CTRL_REG4. What could make sense is to write the values into CTRL_REG1 register, so it will stop and start the sensor.

It is difficult to debut this kind of issue.

You can check that the SPI communication on the bus where the sensor is connected is proper, because if the sensor is not selected by CS signal it is listening the communication and expecting I2C. So you must be sure that the SPI communication doesn't create some patter which can be capture by I2C interface.

You can also try to recover from the sensor freeze by sending bunch of clock pulses to SPC pin.

[Albi G.]

Posted on February 26, 2018 at 16:32

Holy $h!t ! That does not sound like a good design, since an I2C start condition is in near every SPI-pattern :\ I just double checked, there seems to be no bit do explicitly disable the I2C bus. Awww this makes long term operation of the device a lottery if one shares the SPI bus...

Anyway: even after a lock-up the chip still responds to SPI commands in the sense that i can read and write to the registers. However the lock-up (in the sense that i will never ever get new data out of the thing) remains even if i write default values in every register and even if i use the RebootMemory bit before re-init. However i did not check if the data registers really do not update or if the interrupt pin just does not trigger the edge...

Aside from the fact that the RebootMemory sequence is nowhere described in detail, there are some 'Do not touch these'-Registers. Is there somewhere hidden a hardware reset for the internal statemachines?

Btw, since i cleaned up my SPI-fuckery i am not sure if i had any problems since then. I will watch it closely.

[Albi G.]

Posted on February 26, 2018 at 18:09

Well, the Data changes on the falling Clock edge, its about the PCB, parasitics and timing, what is recognized on the slave side at this point.  Since both edges may happen 'at the same time', one cant specificly say that it doesnt happen.

But yes, i can attatch a register dump if you like, no problem. It will take some time, since my device is currently under construction with some other stuff, and as I said, since i resolved my SPI-problem, it is possible that the whole issue has gone away.

I thank you a lot for you interest!

[Miroslav BATEK]

Posted on February 26, 2018 at 17:46

I don't think I2C start condition should be present in SPI communication, the data should not change when the clock is in high state.

I'm sorry, unfortunately the LIS3DH doesn't have possibility to disable I2C, and there is not hidden register to reset the device.

If you would be able to do dump of all registers, when the sensor is freezes we can analyze it more.