Hello, Skye.
Thanks for sharing your findings on this issue. I don’t think we at Pololu ever really looked into it before now (since it doesn’t seem to be a problem on other platforms, including standard 8-bit AVR-based Arduinos), but I tested this today with an ESP32 board and was able to reproduce something like what you described.
What I observed was that even though the library reports a sensor reading of 65535 when it gets stuck, it is not reporting a timeout, meaning it is actually reading 0xFFFF from the sensor over I2C.
In turn, this seems to be caused by some strange behavior that takes place while the library is polling for a new reading to be available. Sometimes, instead of writing just the register address for RESULT_INTERRUPT_STATUS (and then proceeding to read the register value), the ESP32 apparently keeps toggling SCL for a while without driving SDA, effectively writing 0xFF values into all of the VL53L0X’s registers. This goes on for pretty much exactly 50 ms, after which the program tries to continue running normally, but it will then only read 0xFF from the sensor.
If you do manage to confirm that this is the same thing that happens in your setup, that would be useful to know. At this point, I think there’s something wrong with either the ESP32’s I2C hardware or the Wire library implementation for it, but since I’m not aware of any widespread ESP32 I2C issues (do you know of any?), I suspect there’s a specific interaction with something in our library code that is causing this problem.
Kevin