Skip to main content
Associate
January 26, 2025
Solved

Looking for VL53L4ED documentation

  • January 26, 2025
  • 8 replies
  • 4487 views

Hi everybody.

Please help me. 

I bought a VL53L4ED sensor and would like to learn how to use it.
I have found a number of documents and driver examples, but have been unable to find a document describing the internal registers and their function. (programming manual) .

I must be looking for it wrong. Can you please direct me to the proper document?
Thank you very much.

 Jaroslav

Best answer by John E KVAM

Your issue is the sensor averages all the photon return times it gets to give you a distance.

So if your rod is the only thing in the field of view, then it works fine.

But with a background – especially a reflective background you are stuck.

The other problem is your distances. These sensors really don't do well at zero distance. 

(Actually, we spend a lot of time trying to eliminate the signal which comes from the coverglass.)  

But from your picture, your tube looks a lot like a coverglass.

Before you keep making experiments, attach a coverglass to your sensor. 

Not having one and having the sensor touch stuff is going to cause debris to enter the cavity and it will ruin the sensor and ruin all your results. 

I don't think the distance is going to give you good results. But consider using signal strength. Try looking at the signal strengths of the empty gripper and a full one. There might be enough difference to imply that the tube is there. 

but to make this experiment, change the GetResult() function to use floating point. The integer arithmetic is simpler, but you need more accuracy. 

8 replies

John E KVAM
ST Employee
January 27, 2025

I just responded to someone with a similar complaint.

Please don't hate me.

But ST does not publish the register map. Instead we publish the API. It's 

STSW-IMG044

It contains simple C functions that enable everything the chip can do. Start there, read that. 

There are lots of examples. 

There are several reasons for not publishing the register map. 

1) Too many registers. I'm sure you could write a driver given the register map, but you'd end up hating ST forever.

2) Some of the register settings would cause your application to not meet the specification in the Datasheet, and again you would hate us.

3) It would be too hard to support. We'd spend the rest of our days looking through code with one wrong register setting. And when we couldn't find the error - you'd end up hating us.

But honestly it took us years to write that code; and it works; and it's validated. 

There is the firmware in the chip. So rather than a bunch of I2C registers you are actually using the I2C to communicate with firmware thinly vailed as hardware registers. 

Is it a perfect solution? No.

Is it annoying? Yes, undoubtedly. People hate being told they cannot dig into stuff. I don't like it either. 

But it's how we've decided we can best support our customers, and so I'm going to have to live with it.

 

BrazdilAuthor
Associate
January 27, 2025

Hi John.

Thank You for the respons and please apologize my english.

I had downloaded the api (and a lot of pdfs)  before I posted here on the forum.

I spent two days to understand the driver and to adapt it for my HW. I use Example_1_ranging_basic example.

I had some minor problems probably with the I2C timing,
I tried to upload the configuration in one block, I couldn't do it.
I succeeded with uploading byte by byte.

I can now read the correct ID by VL53L4ED_GetSensorId,

VL53L4ED_FIRMWARE__SYSTEM_STATUS   as 0x03   (thats OK),


I do the configuration as VL53L4ED_SensorInit, ( with 0 and also with 0x40 on the end of array (0x87))

I tried  VL53L4ED_StartRanging (I read a zero from the VL53L4ED_INTERMEASUREMENT_MS register)

but I finish in the VL53L4ED_CheckForDataReady procedure
to test the Ready state.

I read 0x11 from VL53L4ED_GPIO_HV_MUX__CTRL
and 0x03 from VL53L4ED_GPIO__TIO_HV_STATUS,

I get a 0 as result, (not ready).

Because I have no idea what is the meaning of those registers and the bits in them,
I can't look for an error. It's probably some small thing, but there's nothing to go by.
I have no idea which register to look in to see if the circuit is running.

I can read :
VL53L4ED_RESULT__RANGE_STATUS ((uint16_t)0x0089)    => 0
VL53L4ED_RESULT__SPAD_NB ((uint16_t)0x008C)               => 0
VL53L4ED_RESULT__AMBIENT_RATE ((uint16_t)0x0090)     => 0xFF00   / may be thats no correct byte order
VL53L4ED_RESULT__SIGMA ((uint16_t)0x0092)                     => 0 
VL53L4ED_RESULT__DISTANCE ((uint16_t)0x0096)               => 0

I have my HW with Kinetis MK20Dx265 :

* pin 1 (GND) of the VL53L4ED   connected to GND
* pin 2 (VDD) of the VL53L4ED   connected to 3V3 
* pin 3 (SCL) of the VL53L4ED    connected SCL of the Kinetis MCU
* pin 4 (SDA) of the VL53L4ED   connected SDA of the Kinetis MCU
* pin 5 (GPIO1) of the VL53L4ED  NC
* pin 6 (XSHUT) of the VL53L4ED connected to 3V3 
*/

it's very hard for me to find a bug without knowing the function of the circuit. 

I need to at least know what It mean when I read the 

I read 0x11 from VL53L4ED_GPIO_HV_MUX__CTRL
and 0x03 from VL53L4ED_GPIO__TIO_HV_STATUS,

and why it is not ready state.

 

Annoying  is,  that  I can only look at non-functioning device now.
May be I've just made some kind of schoolboy bug rewriting the driver.

Can You help me please?

We like the circuit, we would like to use it to measure short distances.

 

Best regards

 Jaroslav

 

Tesla DeLorean
Guru
January 27, 2025

One of the standard ways of dealing/debugging this type of black-box type stuff is to work with the original materials on the original platform (ie STM gear), with that knowledge/working you can pivot into secondary architectures, and can contrast the relative behaviours. This can be done by adding instrumentation, or wrapping of key function, OR externally with the logic analyzer.

 

Yes, does sound like an I2C or driver level porting issue.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
John E KVAM
ST Employee
January 27, 2025

you have an I2C issue and I'm 99% sure it's a byte swap issue. Although word-swap is also possible.

I put some code in below. 

See if you can insert that code into your project. 

Just after getting the I2C initialized and the sensor powered up, see if you can get this to run.

It writes byte and reads back words. They should match.

it also does longwords and strings of bytes. 

Give it a shot.

- john

John E KVAM
ST Employee
January 27, 2025

That code lacks a little documentation. So look at this as well.

The doc was written with an VL53L1 in mind, so it's not exact, but it's close enough. 

all the VL53L sensors have the same I2C logic.

- john

BrazdilAuthor
Associate
January 28, 2025

Hi John,

Thank you very much for sending the test.
It has helped me a lot and is very useful. Consider adding it to STSW-IMG044, it might help other guys.

Also very useful for me is the information that register 0x3A is writable and readable.

Before I got your test I prepared a completely new project, I used your example Example_1_ranging_basic as it is.

I only added I2C read and write functions to platform.c.

After starting the project, it  was the same as my previous attempts.
I get locked in the procedure VL53L4ED_CheckForDataReady where I read same data:

I read 0x11 from VL53L4ED_GPIO_HV_MUX__CTRL
and 0x03 from VL53L4ED_GPIO__TIO_HV_STATUS,

Then I got your I2C test. Beautiful.

I can read the circuit ID correctly, but I always read 0 from register 0x3A.

I spent many hours checking the I2C, found one minor bug (the read routines always physically read one more byte  , but returned the correct data). Just like the ID read.
I fixed this bug. I also checked the byte order , it is ok.

I checked the SDA and SCLK signals on the I2C bus.
I've looked at them in detail and I'm convinced they are fine. Correct read address, correct write address.
The data also matches the required write.
The read and write waveforms are in the attached image.

I've tried writing a single byte repeatedly and re-reading it. I always read zero.
I've tried reading different registers and the reads seem to be ok.

So,

I believe the I2C controler is ok, but for some reason the registers are not being written to.
Isn't there any write protection? Did I inadvertently manage to activate it?

Thank you for your patience.
Could you give me some more advice, please?

 

Best regards

  Jaroslav

 

John E KVAM
ST Employee
January 28, 2025

There is one last thing to look at with I2C. And it happens to people who know how i2C works. We use 2-byte register addresses. 

There are way more registers than will fit in one byte. 

So, when you write to address 0x29<1, (which is 0x52) the next TWO bytes are the register address. And then the data. 

This is different from all the tiny I2C devices you are used to. 

(We tried using single byte address and a page resister on the VL53L0X and everyone hated it. So now we use 2-byte addresses.)

If you can't seem to get the sensor to talk, this might be the reason.

- john

BrazdilAuthor
Associate
January 29, 2025

Hi John.

I'm using 2 byte register addres.

Addres of device (0x52 / 0x53),  0x01, 0x0f,     for ID reading. It works.

I'll try another VL53.

 

Best regards

 

  Jaroslav

 

BrazdilAuthor
Associate
January 29, 2025

Hi again.

I tried the second piece and unfortunately it behaves the same.

I did a detailed analysis of the I2C and I can't find anything wrong with it. I'm attaching an image

(frequency of SCL is 20kHz).

I am also attaching the sensor wiring diagram, maybe I am making some basic mistake.

I will be really grateful for any further advice.
What could be causing the data not to be written?
Is register 0x003A of the VL53L4ED circuit really correct?

One more question please, so I don't do unnecessary work.
We would like to use the sensor to measure a distance of 1-30mm to a glass or plastic vial. Is the sensor suitable for this application?

Brst regards

  Jaroslav Brazdil

John E KVAM
ST Employee
January 29, 2025

The VL53L4ED is an extended temperature version of the VL53L4CD. The CD is a bit cheaper, so I'd go with that one. 

If you have power and ground, and the I2C lines are hooked up correctly, and the XShut line is lifted high there is nothing that can prevent the chip from responding.

But try this...

Search GitHub for the VL53L1, or L4 and your MCU. With a little luck someone has done the work for you.

Try this snippet of code. change the the L1 to L4X and your model ID will be different. But you should get a response.

(The L1X and the L4CD are the same silicon but with different optics. 

 VL53L1_RdByte(Dev, 0x010F, &byteData);
 printf("VL53L1X Model_ID: %02X\n\r", byteData);
 VL53L1_RdByte(Dev, 0x0110, &byteData);
 printf("VL53L1X Module_Type: %02X\n\r", byteData);
 VL53L1_RdWord(Dev, 0x010F, &wordData);
 printf("VL53L1X: %02X\n\r", wordData);
I got:

VL53L1X Model_ID: EA
VL53L1X Module_Type: CC
VL53L1X: EACC

There is also an 'is_booted' function that should return a 1. Can't get much simpler than that.

I didn't know I2C can go down to 20KHz. Might want to crank that up to 100KHz.

- john

BrazdilAuthor
Associate
January 30, 2025

Hi John,

I guess we don't quite understand each other,
I've been reading the I2C from the beginning, and I can read the ID code reliably.

The sequence of writes to register 0x003A appears to be fine according to the oscilloscope,
the I2C cycle ends with ACK, but subsequent reads from 0x003A 0x00 (I2C waveform also OK but with 0 in the data).

According to the datasheet the minimum I2C frequency is not limited,
but I've tried slowing down and speeding up I2C. I also inserted a delay between writing and reading a byte. All without success.

 

Where can I please find the 'is_booted' function you mention?
I can't seem to find it.


I found a VL53L0X board on the web. The programming is probably much different, but I want to verify the I2C communication.
Does the VL53L0X also have a register (like 0x3A) to test writing and reading on?

Thank you,

best regards

   Jaroslav Brazdil

 

BrazdilAuthor
Associate
May 22, 2025

Hi John,

After some testing, it looks like we'll be able to use this sensor.
On your recommendation we only measure the signal strength.
Therefore I would like to ask, is it possible to simplify (and speed up) the measurement process when measuring only signal strength?

It would help us.

 

Thank You,

best regards

            Jaroslav

 

John E KVAM
ST Employee
May 23, 2025

If you really want to go fast you can consider using the Ultra Low Power driver. 

This driver allows for integration times that quite short. Too short to get a good distance measurement, but it might be exactly what you need. 

Go to ST.com and search for the VL53L4CD. From there, you can download the ULP driver.

This driver lets you pick VERY short integration times. 

And you can extract the signal strength and number of SPADs. 

To get a good estimation of the real signal strength, use the signal per SPAD.

See if that works.

- john