VL53L0X intermittent failure: no IR emission, re-init fails, only VL53L0X power-cycle recovers

[Bena_Rock]

Hello everyone,

I am using a VL53L0X and have encountered an intermittent failure. I would like help identifying the possible cause and the next debugging steps.

Hardware setup:

• MCU: Cortex-M0, model MM32SPIN06PF

• I2C: GPIO bit-banged I2C in open-drain mode, with 4.7 kΩ pull-ups.

• An ENS210 temperature/humidity sensor is also on the same I2C bus. ENS210 address: 0x43.

• VL53L0X 7-bit address: 0x29; 8-bit address: 0x52.

• The VL53L0X XSHUT pin is only pulled up to 3.3 V through a 10 kΩ resistor. It is not controlled by an MCU GPIO.

• VL53L0X supply voltage: 3.3 V.

• VL53L0X API version: 1.0.4.

Failure symptoms:

• The VL53L0X works normally at first, but occasionally malfunctions.

• When the failure occurs, no IR emission can be seen from the VL53L0X using a phone camera. Can IR normally be seen with a phone camera? ____

• Pressing a hardware button to re-initialize the VL53L0X does not recover it.

• Only after power-cycling the VL53L0X alone and then pressing the button to re-initialize it does the VL53L0X return to normal operation.

My main questions:

1. Is it possible that, because XSHUT is not controlled by the MCU, the software cannot perform a true hardware reset of the VL53L0X?

2. Could sharing the I2C bus with the ENS210 cause bus lock-up or state conflicts?

3. What logs, waveforms, or register data should I capture to locate the root cause?

Thank you. Any help would be appreciated.

[Bena_Rock]

When the failure occurs, no IR emission can be seen from the VL53L0X using a phone camera. Under normal operation, the IR emission can be seen with a phone camera.

[John_Kvam]

Bena - 

It has been my experience that when a device is working and then just quits, it’s one of two things. Either the I2C glitched, or you took a hit on the XShut line.

When this happens again, check the I2C. When a long I2C line gets hit with a bit of noise, either then sensor, or the processor clocks a phantom bit. And once the devices get out of sync, either the I2C CLK line or the data line will be stuck low. And this is pretty fatal. Only solution is to reset the devices, or - if you can - you can get your processor to clock 8 more bits. That will clear the issue and you can start again. 

But the Xshut line is way too touchy. And a small drop will cause a partial reboot of the sensor. And this is really hard to catch. Best thing to do is pull that pin high hard and put enough capacitance on it so noise will not affect you.

One can (and should) spend some time looking at the I2C circuit. Long lines and un-shielded traces can be a real issue. Twisted pair, grounding and proper pull-up design can all help. There are a zillion references on the Web to tell you how to design an I2C to avoid noise. Might want to have a go at those. 

Good luck - 

• john