i2cdetect disrupts VL53L8CX operation, causing GO2 error

[Voklaif]

Hello,

I am using the VL53L8CX sensor on an I2C bus, and it operates normally until I run the i2cdetect command. After running i2cdetect, the sensor stops working properly, and calling vl53l8cx_check_data_ready() returns a GO2 error status.

Interestingly, if I have another sensor (e.g., a temperature sensor) enabled on the same I2C bus, the VL53L8CX recovers and continues working after i2cdetect. The temperature sensor is at a different address and only performs normal read operations.

• Why does i2cdetect disrupt VL53L8CX?
• Why does another sensor’s read operations seem to "fix" the issue?
• How can I debug and prevent this problem without adding a secondary sensor?

Any insights or debugging tips would be greatly appreciated!

Thanks!

[John E KVAM]

This is just an educated guess...

The VL53L8 differs from other I2C devices in that it uses a 2-byte register address field. So instead of sending a I2C address, a one-byte register address, and some sort of payload, The L8 uses 2-bytes.

I'm going to postulate that the i2cdetect that knows nothing about the L8 is just sending a read request of register 0 expecting some sort of response. 

But in the case of the L8, this is just screwing up the L8. 

I've used i2cdetect many times but never after the firmware has been downloaded into the L8. 

If you have control over the LPn pin, I believe toggling this will clear the issue as well. 

(Internally the I2C is one process and the ranging engine is a second one. The LPn simply disables the I2C function so toggling it will reset the I2C. 

-john

[Voklaif]

Thank you for the answer John,

I think it doesn't have to do with it, since I had a VL53L1X on the bus, and it had no problems with the i2cdetect, they are even on the same 0x29 address. I've also looked at the datasheet of both sensors and the I2C protocol seems to be identical.

Do you have any other leads or ideas on how to debug this issue?

Thanks

[John E KVAM]

Dropping the LPn and bringing it back up is the preferred solution to any I2C issue.

However, the only way to debug what is going on is to analyze the I2C bus. 

presumably the L8 is waiting for the completion of a message. And the command given to a different sensor is enough to convince the L8 that it should give up and wait for a new command.

One thing you might try is just clocking 0's on the line. 

When the host and the sensor get out of sync, one accepted solution is to just clock some bits. In theory 9 clocks will clear any issue, but 99% of the time you need only one clock.

- john