cancel
Showing results for 
Search instead for 
Did you mean: 

VL53L1X hanging on first wait for data

SK.61
Associate II

I have a VL53L1X connected to a multi-slave I2C bus hosted by a broadcom bcm2835 running linux (4.19). I have configured the `vl53l1_platform.c` from the api ("stsw-img007") to use the <linux/i2c-dev.h> interface with tracing and see bi-direction communication. However, after that `StartMeasurement` call, GetMeasurementDataReady consistently reports that data is not ready, despite waiting for minutes. Since there is no published i2c command/register list/help (?), I am working in the dark. Can someone familiar with this device's i2c interface take a look? Here's the i2c trace log:

Fail; line: 173, expected: 2, got: -1, errno: 121

Fail; line: 173, expected: 2, got: -1, errno: 121

Fail; line: 173, expected: 2, got: -1, errno: 121

Read register: 0x00e5 = 03

wrote register: 0x0000 = 00

wrote register: 0x0000 = 01

Read register: 0x00e5 = 03

Read register: 0x00e5 = 03

Found (booted) device.

Read register: 0x010f = ea cc 10

Validated device.

Read register: 0x002e = 00

wrote register: 0x002e = 01

Read register: 0x0001 = 29 02 10 00 2c bd 1e 81 80 07 95

Read register: 0x000d = ff f7 db bf ff 0f 00 11 01 00 00 00 00 00 00 00 00 00 00 00 39 00 14

Read register: 0x010f = ea cc 10 ff fe 2c 04 03 3c 3f 01 00 01 2a 03 ff ff ff fe 7e bb ff ff 7f ff ff ff ff fd bf ff ff ff ff ed fe de ff ff df 3f ff fe ff 7f fd df 47 55

Read register: 0x00de = 00 25

DataInit completed

StaticInit completed

wrote register: 0x0001 = 29 02 10 00 2c bd 1e 81 80 07 95 00 ff f7 db bf ff 0f 00 11 01 00 00 00 00 00 00 00 00 00 00 00 39 00 14 0a 00 00 00 00 00 00 00 00 00 00 00 11 02 00 02 08 00 08 10 01 01 00 00 00 00 ff 00 02 00 00 00 00 00 20 0b 00 00 02 ff 21 00 00 01 00 00 00 00 8c 00 00 38 ff 01 00 14 00 17 02 f3 0f 03

 8b 0d 01 68 00 c0 08 b8 00 00 00 99 c8 00 00 03 00 00 00 00 00 02 0f 0d 0e 0e 03 00 02 6a 44 db 02 00 00 01 01 21

StartMeasurement completed

Read register: 0x010f = ea cc 10

Read register: 0x0031 = 03

Read register: 0x0031 = 03

Read register: 0x0031 = 03

Read register: 0x0031 = 03

...

1 ACCEPTED SOLUTION

Accepted Solutions
Julien NGUYEN
ST Employee

​Hi Dominic, I would go to ST.COM to download the STSW-IMG013 (VL53L1X LINUX Example Code), to inspire from this example to build your own code. Please note that it is not a Linux driver, it is a Linux example code running in the user space. Thanks, Julien


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

5 REPLIES 5
Julien NGUYEN
ST Employee

​Hi Dominic, I would go to ST.COM to download the STSW-IMG013 (VL53L1X LINUX Example Code), to inspire from this example to build your own code. Please note that it is not a Linux driver, it is a Linux example code running in the user space. Thanks, Julien


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
John E KVAM
ST Employee

The most common problem is that although the read-byte and write-byte work there can be a byte-swap or word-swap issue. When this happens it looks like everything is set up, but it's not correct.

The platform.c file in STSW-img007 is basically empty. Can you verify that it's filled in?

If all you want to do is basic ranging consider the ultra-lite driver (STSW-IMG009). It's less functional, but a lot smaller, and more clear.

It has a lot of example code which should get you going as well.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

That almost worked out of the box, but it shows me how to use this api. I was thinking there had to be a simpler way then that monstrous api. Thanks.

Julien beat you to it, with an answer that actually works. Yes, the ultra-lite is probably the best choice for me, but my original intent was to confirm the i2c trace I posted, including potential byte-swapping, as the actualy meaning (and correct order) of the i2c commands are not published.

If you had actually read the question I would hope you could see that I was getting 2-way communication, and therefore obviously didn't leave the platform file empty like the idiot you so quickly assumed me to be.

John E KVAM
ST Employee

Julien is a good man, but he cheated. He lives in Europe so he had an 9 hour jump on me. He's also a good friend.

I'm glad you're happy.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.