2022-01-10 01:42 AM
Hi,
I have setup the ToF VL53L5 and started with the simple rangedetektor example in Cube IDE (I'm using the Nucleo STM32F401 board with the X-Nucleo 53L5A1). I'Ve got the message in my serial terminal, that the VL53L5 was not found at the Default I2C address. What I found out is that the setup of the Tof Chip, eq, Reset of power, I2C and I2C reset in the example code dit not work. It seems that the I2C was in 3state or disabled or the chip disabled
This is part of the orignal code:
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_I2C1_Init();
MX_USART2_UART_Init();
/* USER CODE BEGIN 2 */
Dev.platform.address = VL53L5CX_DEFAULT_I2C_ADDRESS;
HAL_GPIO_WritePin(I2C_RST_C_GPIO_Port, I2C_RST_C_Pin, GPIO_PIN_RESET);
HAL_Delay(20);
HAL_GPIO_WritePin(PWR_EN_C_GPIO_Port, PWR_EN_C_Pin, GPIO_PIN_RESET);
HAL_Delay(20);
HAL_GPIO_WritePin(LPn_C_GPIO_Port, LPn_C_Pin, GPIO_PIN_RESET);
HAL_Delay(20);
HAL_GPIO_WritePin(PWR_EN_C_GPIO_Port, PWR_EN_C_Pin, GPIO_PIN_SET);
HAL_Delay(20);
HAL_GPIO_WritePin(LPn_C_GPIO_Port, LPn_C_Pin, GPIO_PIN_SET);
status = vl53l5cx_is_alive(&Dev, &isAlive);
if(!isAlive)
{
printf("VL53L5CXV0 not detected at requested address (0x%x)\n", Dev.platform.address);
return 255;
I've changed to this, special the sequence order and amount of delays adapted (delays are probably not optimized) but this worked for me:
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_I2C1_Init();
MX_USART2_UART_Init();
/* USER CODE BEGIN 2 */
Dev.platform.address = VL53L5CX_DEFAULT_I2C_ADDRESS;
//Dev.platform.address = 0x52; //it seems not to be the standard I2C address
HAL_Delay(20);
HAL_GPIO_WritePin(LPn_C_GPIO_Port, LPn_C_Pin, GPIO_PIN_SET); //Enable I2C bus chip
HAL_Delay(100);
HAL_GPIO_WritePin(PWR_EN_C_GPIO_Port, PWR_EN_C_Pin, GPIO_PIN_SET); //set high to enable power chip
HAL_Delay(100);
HAL_GPIO_WritePin(I2C_RST_C_GPIO_Port, I2C_RST_C_Pin, GPIO_PIN_SET); // set high to reset I2C
HAL_Delay(200);
HAL_GPIO_WritePin(I2C_RST_C_GPIO_Port, I2C_RST_C_Pin, GPIO_PIN_RESET); // set low to activate
HAL_Delay(100);
//HAL_GPIO_WritePin(PWR_EN_C_GPIO_Port, PWR_EN_C_Pin, GPIO_PIN_RESET); //set low to disable power chip
//HAL_Delay(100);
status = vl53l5cx_is_alive(&Dev, &isAlive);
if(!isAlive)
{
printf("VL53L5CXV0 not detected at requested address (0x%x)\n", Dev.platform.address);
return 255;
Is someone has the same experience and a explanation, I find the strange that the example code would not work, but it seems it isn't.
Thanks for your respons.
Bart.
2022-01-11 07:35 AM
Bart -
I'm sure the example code worked at least for a few boards. It was validated by our software team, but I'm also willing to bet that those delays might have been close to the edge and that code was not tested an a large number of expansion boards. In fact, all the boards probably came from the same batch.
Your board might be ever so much slower than the boards the code was developed on.
The sensor is the same, but a variance in capacitance might keep your sensor alive for more than the 20ms. And it does not reset.
If you have time, (and I know you are probably busy) it would be interesting to know what the minimum delay works in your system. It might be that 22 or 25ms works as well.
Congrats on finding this. Not everyone would have hit on extending the delays.
2022-01-28 08:17 AM
Thank you John. Strange now I've set it up with an STM32F401CC on a other board (other clocks settings inside, but for the rest alle the same as the 32F401 Nucleo, and connected to the NUCLEO 53l5a1 center, and starts up with the original code and delays. So all good for now. No clue what was wrong in my previous setup.