I found a thread on this same issue from two years ago that never seemed to have a conclusion. Rather than bumping the thread, I am starting a new one.
I have three units on a device, but I can see the problem even when I hold two of the units in reset. The issue is that after a random-ish amount of time, the Pololu library readRangeContinuousMillimeters returns -1 (65535). From code inspection this only happens if the RESULT_INTERRUPT_STATUS bit stay low for the time out period. When this happens there is no recovery. It stays stuck from them on. Also the IR light from the sensor stops coming out as seen using night vision goggles.
I have not tried to re-initialize the part when it gets stuck, but I think it would likely come back to life. As this is what happens when I do a reset holding power on to the sensors.
My initialization is to call setTimeout(500), init(), and then startContinuous().
Somehow I think the sensor is losing its programing.
The I2C master is an ESP32. It gets its power either via a USB cable or via battery. The battery architecture is two 18650’s that feed into a Pololu 5 volt buck regulator. The 5V feeds the ESP32 that has its own 3V3 buck to power the board.
I do find the time it takes for the VL53 to enter the "timeout error mode "takes less time (on average) running from the USB. Sample size of about 20.
The wiring is point to point solder with 26 gauge wire of lengths less than 8 inches longs.
The environment can be very benign when the failure occurs. The sensors are mounted in a robot with two drive motors, but the failure can happen even when the motors are disconnected from the system. The reset of the robot includes four reflective light sensors connected to analog pins on the ESP32.
The failure SEEMS to occur if the sensor is looking “into the void” or at a close object.
I am using the Pololu Arduino library with one exception. Since I could not tolerate the busy loop wait in the readRangeContinuousMillimeters routine, I create a polling method to determine if a measurement exists before I call the above to retrieve the new measurement. The function looks like this:
return (readReg(RESULT_INTERRUPT_STATUS) & 0x07) ? true: false;
(By the way, I suggest this as an addition to your library.)
So was any progress ever make in finding out why people’s sensors would stop reporting?