Using a VL53L3CX sensor with a STM32G030J6M6

[MafteiAlbert]

I got a custom board made with these two ics and I tried to program the mcu. However, when facing FLASH and RAM size constrains I decided to remove certain parts of the library to make it fit(I removed crosstalk calibration since I don't have a cover material).  However I am now facing issues with the sensor not working(I2C works), and I have to determine if it's because of something I did, board design or something wrong with the sensor. The measurements that I'm getting have the 255 status, and while debugging I found that the sensor returns less streams than expected. So a couple questions first:

1) Does the sensor require restarting via XSHUT to properly work?

2) Would the ST-LINK programmer be able to supply enough power for both chips?

3) How should I proceed with debugging?

4) Does ST have a smaller library for this sensor(I have been unable to find one)?

[John E KVAM]

1) You should not have any crosstalk if you are not using a coverglass. API will run fine without it.

2) I'm going to guess you have a byte-swap or word-swap issue. There is some verification code. Unfortuantely it's not specifically for the L3. So you are going to have to adapt the L1 code to make it work. (It's just changing the function names from L1 to L3). Just put the code in after your first init. You can remove it when the bytes line up with the words and longwords.

3) Xshut is basically an on/off switch. Shouldn't need to cycle it. If it's up when power come on, it's fine. Or you can lift it after power is supplied.

255 status generally means there is something odd about your target. Try pointing at a white piece of paper from about a foot or two away. 

you could use the VL53L1X UltraLiteDriver on the L3. The driver is really small (0.3K) and simple. It would probably limit the max range to 2M though. The only thing you would need to do would be to change the chip id check.

But keep in mind that the numbers in the datasheet were determined using the L3 driver. 

[MafteiAlbert]

Hello again,

I tried using the I2C verification but it's behaving very weirdly, reading the i2c is consistent, but writing to it is not happening properly. I'm going to scope the lines today, but I'm wondering if the 0x4 address used for testing on the Vl53L1X is not ok for this sensor. I also have the option to swap the Vl53L3CX sensor for a Vl53L1X on the board so I may try that soon. Here is the code I'm using to test, I'm basically trying to test if writing properly goes through with the 0xFFFFFFFF

[John E KVAM]

Looks like you took the print statements out - which is fine, but you need to put a breakpoint in there to check the that the returned data is of the right order. You should not have had to comment out the Chip ID. Your's is different, but you should still get one. Verify that reading in bytes, words and longwords return the same value. 

Location 4 is a 32bit R/W register. 

And if you i2C looks off, then you have isolated the issue. 

Although this code assumes a byte or word swap issue, but not getting values could be an I2C hardware issue as well.

- john

[MafteiAlbert]

Hello,

I built another prototype board but this time used the VL53L1X and it worked without too much hassle. I think the problem with using a VL53L3CX was either:

a) I somehow damaged my sensor with my prior tests on the board(most likely variant)

b) The VL53L1X ULD API isn't 100% compatible with the VL53L3CX

[Anne BIGOT]

Hello,

Regarding your comment : 

b) The VL53L1X ULD API isn't 100% compatible with the VL53L3CX

ST is delivering a SW package for each of its sensor. This is a couple HW/SW. If you are using another API than the one deliver for a specific sensor, ST does not guarantee it will work. 

[John E KVAM]

Anne is right. ST does not guarantee swapping code will work. But I've seen examples where people have tried it and they have had favorable results.

The VL53L1, L3 and L4 sensors are all based on the same basic logic so a function from one might work on the other. The L3 is an L1 without the lens and the L4 is an L1 without the lens and with a more narrow VCSEL.

There is the ST code base of course, but SparkFun, Pololu and Adafruit all have different code. And GitHub has several distrubutions where people have tried other things. 

As an ST employee, I don't want to comment on the quality of someone else's software, but if you are willing to try it, it's easy enough to prove if it works for you or not. 

We have done a lot of test and verification on the ST code, so using that is the safe choice. But a little hacking might prove interesting. ST just cannot support it though. You are kind of on your own.

-john