The tof chip anomaly after a long period of non-use

[Blue666]

I discovered a strange phenomenon:

After I powered on the VL53L4CD, I called the interfaces:

The interfaces such as VL53L4CD_SensorInit, VL53L4CD_SetRangeTiming, VL53L4CD_SetDetectionThresholds, and VL53L4CD_SetSignalThreshold complete the initialization operation.

Then call the VL53L4CD_ClearInterrupt and VL53L4CD_StartRanging interfaces to start the measurement. At this time, interrupts can be received normally, and the interrupt pin can rise and fall normally.

At this point, I call the VL53L4CD_StopRanging interface to stop the measurement. At this time, tthe interrupt pin is at a high level.

At this point, I put the device aside without operating it for about two or three days.

I recalled VL53L4CD_ClearInterrupt and VL53L4CD_StartRanging, and immediately received an interrupt. At this time, I called the VL53L4CD_GetResult and VL53L4CD_ClearInterrupt  interface to read the result and found that the value of range_status was 2.

Subsequently, the interrupt pin remained at a low level. I kept calling VL53L4CD_ClearInterrupt, VL53L4CD_StartRanging, and VL53L4CD_StopRanging, but the interrupt pin would not be raised again. Only after setting the xshut pin to low level, turn off the VL53L4CD chip, the interrupt pin will be a high level.

This phenomenon is not certain to occur, but there is a probability of it happening. Could you help me figure out the reason for this? I confirm that the execution mode of the VL53L4CD_StopRanging interface is VL53L4CD_WrByte(dev, VL53L4CD_SYSTEM_START, 0x80).

I repeatedly called to start ranging and stop ranging, and the interrupt pin was normal. So, could it be that there was a problem with the chip's own state after being placed for a long time?

These are the register values read under normal and abnormal conditions, in the attachment.

Could you help me check what the problem is.

[John E KVAM]

I'm going to assume that during that long period of non-use, something happened. Perhaps a glitch on the XShut line caused a partial reboot, perhaps noise on the power line caused it, but it appears your sensor is not in the state you left it in.

So let us proceed with the assumption that something went wrong and try to fix it. 

1) Getting an interrupt immediately after starting is not an issue. Just clear that one and wait for the next. 

2) getting a range_status of 2 is also not an issue. It means that there was not enough signal to get a good range. (Happens if there is no close target.)

3) but not being able to clear the interrupt IS an issue. 

I'd suggest putting in a mechanism to detect the issue and reboot the sensor. 

To reboot, drop the XShut line, wait 5 or 10ms and bring it back up. Then start over with the call to the Init() function

But the real trick is figuring out if the sensor is stuck and just returning the same stale data. 

If you read the distance, the signal rate and the ambient rate, it is extremely unlikely that all three of these numbers are the same. They should be about the same between ranges but never identical. 

So if you get some range data, wait one integration period and see the same identical values, the sensor is 'stuck'. 

Drop the Xshut and start over. 

- john

[Blue666]

Thank you for your reply. I will check your points of doubt.

Regarding the judgment of abnormalities, since when the problem occurred, the interrupt pin remained at a low level, I was unable to obtain the result（Because I read the data after the interruption was triggered.）, and it was not suitable to use this as the basis for abnormal judgment.

If I call the clear_interrupt instruction before each start command, and then call checkDataReady to obtain the status. If the status is 1 and the interrupt line remains at a low level, then consider that the current sensor is in an abnormal state and needs to be reset. Is this judgment method okay?

[Blue666]

I'm very sorry, but I need to bother you again.

I would like to know how to determine if this is a problem with my device's circuitry? Is there any good solution?

Can the current state of the chip being in an abnormal condition be known by reading the value of which register?

Additionally, I would like to know what a fault occurs in the chip, will cause the interruption cannot be cleared? This will help me check if there are any problems on my circuitry.

Apart from using the xshut pin to reset the chip, is there any way to solve this problem through software reset? How can the VL53L4CD be reset via software?

[John E KVAM]

Based on my experience, your chip is doing a partial reboot. 

And when the chip does this everything appears normal except that it boots in the stopped condition. 

A partial reboot can happen when there is:

• A drop on the power rail. 
• Noise on the XShut line.
• EMI or static electric pulse.

It's my guess that one of these is getting you.

You want to cut down the electrical noise as much as possible.  

But if this does happen to you and you stop getting interrupts or if the data you get from the chip is constant, then you want to drop the XShut line, wait a bit and basically start over. 

A partial reboot leaves the sensor in an unknown state. So you have to start over.