cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with VL53L1 on AVR64DB32: VL53L1_WaitMeasurementDataReady frequently times out

etogashi
Associate II

Hello,

I am working on a project using an AVR64DB32 MCU and the VL53L1 time-of-flight sensor over I2C.
I downloaded the official API from ST (STSW-IMG007) and adapted vl53l1_platform.c to my environment.
Since my I2C communication library is written in C++, I converted it into vl53l1_platform.cpp.

I also wrote a simple distance measurement test program (main.cpp).
My custom I2C driver (I2cDriver.cpp) is already used in other projects and seems reliable, so I assume the issue is not primarily there. I have attached these files for reference.

The issue:

Inside the while loop, I repeatedly call VL53L1_WaitMeasurementDataReady.

  • If successful, I call VL53L1_GetRangingMeasurementData and then VL53L1_ClearInterruptAndStartMeasurement. In this case, I blink an LED once.

  • If it fails with VL53L1_ERROR_TIME_OUT, I blink the LED twice. For any other error, I blink three times.

  • After each loop iteration, whether success or failure, I wait one second before retrying.

When running the program, I observe the following behavior:

  • Several consecutive failures (timeout) occur.

  • Then, one successful measurement occurs.

  • This pattern repeats.

When I break in debug mode, I can see that the RangingData values are valid on success.
So, the sensor does measure correctly sometimes.
However, it seems to require many seconds before a measurement succeeds.

According to the documentation, the VL53L1 should be able to deliver measurements at least once per second, but my behavior is much slower.


What I tried:

I experimented with:

  • VL53L1_SetDistanceMode

  • VL53L1_SetMeasurementTimingBudgetMicroSeconds

  • VL53L1_SetInterMeasurementPeriodMilliSeconds

But none of these improved the situation.

Note: For simplicity, the attached code does not check every initialization return value, but in my real program I do, and all calls return VL53L1_ERROR_NONE.


Additional information:

  • I2C bus speed is 400 kHz.

  • Power supply: normally from AA batteries, but I also tested with a regulated bench power supply, so I believe insufficient current is not the cause.

  • Hardware schematic is attached (see image).

    • GPIO1 is left floating (not used).

    • XSHUT is not controlled by the MCU; instead, it is pulled up with a 10 kΩ resistor.


My questions:

  1. Why does VL53L1_WaitMeasurementDataReady fail with repeated timeouts before eventually succeeding?

  2. Is there something fundamental I am missing in the initialization or measurement loop?

  3. Could the way I adapted the vl53l1_platform.c file to my custom C++ I2C driver be the cause?

1 ACCEPTED SOLUTION

Accepted Solutions
etogashi
Associate II

Hello everyone, just a quick follow-up.

I managed to solve the problem by switching to another ST library: the VL53L1X Ultra Lite Driver (STSW-IMG009). With this library, the sensor operates as expected.

While the exact cause of the timeouts with the previous library is still unknown, I wanted to share my working code here for anyone who might face a similar issue in the future. I have attached the new files.

View solution in original post

4 REPLIES 4
etogashi
Associate II

These are the remaining files.

etogashi
Associate II

Hello everyone, just a quick follow-up.

I managed to solve the problem by switching to another ST library: the VL53L1X Ultra Lite Driver (STSW-IMG009). With this library, the sensor operates as expected.

While the exact cause of the timeouts with the previous library is still unknown, I wanted to share my working code here for anyone who might face a similar issue in the future. I have attached the new files.

Congrats on finding a solution. The UltraLite Driver has always been a favorite of mine as well. 

One note. As you did not set a timing budget or an inter-measurement period, your sensor is taking 30 measurements per second and using a lot of power. If you are going to wait 1000ms between outputs you can range a lot less often. 

It would save quite a bit of power. 

But then again maybe this is just the start of your project, and you plan on doing something more than just blinking a light. In which case, I think you've gotten started. 

Good luck.

- john

If this or any post solves your issue, please mark them as "Accept as Solution". It really helps the next guy.
And if you notice anything wrong do not hesitate to "Report Inappropriate Content".
I am a recently retired ST Employee. My former username was John E KVAM.

Hi John,

Thanks for the great advice! You're right, this is just the beginning of my project, and power saving is my next step.

I may come back with more questions on that topic. Thanks again for your help!