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.