VL53L0X full register map & documentation

[sbickham-itwfeg]

Does anyone have access to documentation with an actual list of registers with addresses and functionality and a full description of the register bits for the VL53L0X? 

All I have been able to find is documentation that refers to the questionable API driver package and some doxygen-generated document based on the comments in the API.  

[John E KVAM]

This is the most asked question - and the answer is we don't give out the register map. And before you ask, there are a few reasons.

1) there are a LOT of registers. And while I'm sure you could write a driver eventually- you would end up hating ST forever. 

2) support would be near impossible. You might not get the accuracy or distance you need and there would be no way for me to tell you what you needed to change. 

3) Our first chip was duplicated by some company in China. Theirs didn't work very well, but it cost us some sales and we don't want to go through that again.

ST has a driver. It's been well tested over the last 8 years, and it works. There have been many, many designs and the L0 is still one of our best-selling ToF parts. 

ST has a driver. It has more lines of code in it than most people want, and I think it should be a lot simpler. But one must argue that it works. And if you don't call a function, a reasonable linker will not include it.  

Lots of people have re-engineered our driver, and most of them work. Try one, and if you have an issue, go back the to original and see what differences there are. 

One guy used our driver to get the config he wanted, then monitored the I2C traffic, then just implemented functions to duplicate the I2C traffic. I'm not suggesting you do that, but if you were really tight one space, it would work.

- john

[sbickham-itwfeg]

Comically, I just received an automated email from ST asking if your non-response solved my problem.  Apparently, it has not...

First of all, let me explain that I have been a software engineer for about as long as ST has existed.  I am currently working on a project for a company that has already given up on using your sensor in a previous project and this project is going about as well.

Before I came onboard, someone rigged up a demo using a Raspberry Pi and, what appears to be, your "Continuous Ranging example" from "en.STSW-IMG005.zip". Nobody has bothered to stress-test the thing, or verify the accuracy of the data it sends back, but at least it runs.

For development purposes, we are using a NUCLEO-G071RB and a TOF200C-VL53L0X.

The sensor is connected CN6-4 (3.3v) and CN6-6 (GND), CN5-10 and CN5-9 (I2C1).

Although I was originally cycling the power to the sensor by hand for each test, but it didn't seem to help and I got tired of it, so I also attached the SHUTDOWN pin to a GPIO so that I could cycle the power automatically at the beginning of the program.

I have created a clean project in STM32CubeIDE 1.16.1, downloaded this same sample code, and built the project.

I scraped out anything that has anything to do with Windows, Linux, etc.

I added the HAL I2C function calls.

I renamed your "main()" to "run_example()" so that I could call it from within the default "main()" after system initialization is complete.

Without exception, every time it runs, it times out in the exact same place-

Thread #1 [main] 1 [core: 0] (Suspended : Breakpoint)

VL53L0X_measurement_poll_for_completion() at vl53l0x_api_core.c:81 0x8006730

VL53L0X_PerformSingleMeasurement() at vl53l0x_api.c:2,123 0x80047aa

VL53L0X_PerformSingleRangingMeasurement() at vl53l0x_api.c:2,649 0x80050a6

perform_ref_signal_measurement() at vl53l0x_api_calibration.c:658 0x8005acc

VL53L0X_perform_ref_spad_management() at vl53l0x_api_calibration.c:793 0x8005d5a

VL53L0X_PerformRefSpadManagement() at vl53l0x_api.c:3,136 0x80056c0

rangingTest() at vl53l0x_ContinuousRanging_Example.c:120 0x8002e56

run_example() at vl53l0x_ContinuousRanging_Example.c:280 0x8003230

main() at main.c:114 0x8002856

A) I have seen no problems related to the I2C bus and have tried every reasonable combination of settings just to make sure that there was no change.

B) The function that it is getting stuck in is called in other places before getting stuck here and it always succeeds in those calls.

C) As a matter of due diligence, I increased the timeout loop count to 2000 and even added in 10ms delays for each loop.  It made no difference.

D) I enclosed the call to "PerformSingleMeasurement()" in a loop that retries infinitely until it succeeds.  It never escapes the loop.

E) I have also tried adding delays at various places before this function gets called in case the NUCLEO board is sending commands faster than the sensor can process them.  It made no difference.

Since I have no insight into what your sensor is doing, here we are.  This project is already on a tight schedule and this thing is taking up way too much of our time.  I am hoping that you will be able to use your insider knowledge to provide a solution.

[John E KVAM]

Are you checking the return status from all your I2C calls? It's easy to assume they all complete, when they do not.

When you issue the PerformSingleMeasurement, the VCSEL (laser) will start. One cannot see it, but a web-cam can. (Don't use an IPhone - the IR filter on that camera is too good. It filters out the 940nm light.) Is the VCSEL running? Do you see the glow of the sensor light?

If you've completed all those steps, one has to assume the I2C is functioning correctly. And if you are polling, you don't need the interrupt line. 

So power, ground, both I2C lines, and Xshut are all you need.  Sometimes the XShut is connected to power on the board - for simplicity. 

But if XShut were low, your I2C would not be completing during the initialization phase.

I did a web-search for TOF200C-VL53L0X and I came up with two different parts. Not sure which one you have. 

I have seen something like this before, and the device was being starved for voltage. But if you've hooked it up as you say, that is not the issue. 

Another issue is I2C reliability. Are your wires exceptionally long? Over a foot, you can have issues unless you play with the pull-ups. 

That is all I can think of. 

[sbickham-itwfeg]

The device we were using was (I believe) a custom-built module. 

In order to verify that it is not the problem, I had the company purchase a X-NUCLEO-53L0A1 expansion board.

I removed one of the wing-board modules from the kit and attached it to the NUCLEO-G071RB dev board with approximately 3-inch jumpers. The problem persists.

The power comes directly from the 3.3v pin (CN7-16) on the dev board which is attached to a powered USB hub that supplies 1.5A.  I have not noticed a voltage drop on the oscope, but I will check at the sensor.  That being said, the expansion board regulates everything down to 2.8v when the sensor is attached, so I have to believe that I am good.

With I2C, you always need pull-ups. Since I wasn't sure about the sensor side, I enabled the pull-ups on the G071.  As far as I can tell, every line of code in this example is error-checking to make sure the I2C comms are completing properly.

Our module has the XSHUT line exposed and I was using it to reset the chip before every run through the debugger.  The 53L0A1 module does not, so I have switched to using the VL53L0X_ResetDevice() swr reset.

I am currently working on something else, but I will hook up the board again and verify the voltage and see if we can detect the IR lights.

[sbickham-itwfeg]

As far as I can tell from the oscope, the voltage at the sensor never changes. 

The IR emitters remain on even after the VL53L0X_measurement_poll_for_completion() function times out.

And just to be clear, the VL53L0X_PerformSingleMeasurement() function succeeds twice during calibration before failing on the third time it is called.

[John E KVAM]

Interesting. If the sensor is flashing, it's running. So clearly the start, started the sensor. The sensor is working, gathering data, but it's the VL53L0X_measurement_poll_for_completion() that is hanging you up. 

So let's try something. Just read the data in a loop with a delay more or less equal to the timing budget. You should get changing data. 

call 

VL53L0X_GetRangingMeasurementData().

your distances should be easy to check. And they should change by moving your hand around the sensor. 

If that works - and it should as the sensor is running. 

Then we have to figure out why the wait_for_completion is failing.

did you do a clear interrupt prior to starting?

Status = VL53L0X_ClearInterruptMask(Dev, 0);

I know the perform single measurement function calls it, but somehow you might have started the sensor with the interrupt already sent - and it needs a clear first.

- john