2025-01-13 02:21 AM
Hello,
I am trying to use the VL53L7CX on a robotic project with the provided driver, but it fails at Init.
The sensor is detected as alive ("isAlive" is true), the I2C speed is set to 1Mhz (even if I tried lower speeds as well), and it fails exacly at this line of the Init function:
status |= _vl53l7cx_poll_for_answer(p_dev, 4, 0, VL53L7CX_UI_CMD_STATUS, 0xff, 2);
The status byte is 0 just before that and it goes to 66 (MCU failure) just after the above line.
And if I put 2 instead of 4 in the second argument, it doesn't fail at this line, but 2 lines after:
status |= _vl53l7cx_send_offset_data(p_dev, VL53L7CX_RESOLUTION_4X4);
For info, when I don't stop the init after these errors (forcing the following lines to be executed), I am able to "see" (with a smartphone camera) the infrared light from the sensor when starting ranging in my ranging function, but without any result, nothing detected. Does it mean that at least the firmware is downloaded?
Any help would be apreciated!
Thanks.
Solved! Go to Solution.
2025-01-13 11:29 PM
Hey,
Ok, like John said in other topics, only I2C problems have been found with this product. So I spent hours looking at every single edge of SDA and SCL, and I found the problem:
I was doing an ACK at the end of the "read multi" transaction, just before the stop bit, and I am suprised that this caused the VL53L7CX to maintain SDA low, preventing any future transaction to work normally.
So ACK when we still want to read another byte, and NACK just before STOP bit.
I don't know if this behaviour is normal... I would have expected an ACK would not be a problem as we stop the transaction anyway.
So I hope this helps!
2025-01-13 11:29 PM
Hey,
Ok, like John said in other topics, only I2C problems have been found with this product. So I spent hours looking at every single edge of SDA and SCL, and I found the problem:
I was doing an ACK at the end of the "read multi" transaction, just before the stop bit, and I am suprised that this caused the VL53L7CX to maintain SDA low, preventing any future transaction to work normally.
So ACK when we still want to read another byte, and NACK just before STOP bit.
I don't know if this behaviour is normal... I would have expected an ACK would not be a problem as we stop the transaction anyway.
So I hope this helps!