VL53L5CX ULD vl53l5cx_check_data_ready() returns error CA 81

[DBonh.1]

I'm trying to implement the VL53L5CX ULD v1.3.4 on an Atmel ATSAM4L. Per an Total Phase I2C analyzer, I have it almost all running correctly. It's uploading the firmware, and the firmware bytes captured by the I2C analyzer match the bytes in vl53l5cx_buffers.h. I send sensor config parameters that match those sent by an eval board, and the sensor reports those parameters back correctly (8X8, integration time 10ms, power mode 1, ranging freq 10, sharpener 14%, target order 1, ranging mode 3). But when I enter the ranging loop the calls to vl53l5cx_check_data_ready() are responded to by FE 04 CA 81. The high bit in 81 appears to be a GO2 error. I attached screenshots from the analyzer and printf() diags. Any ideas what's wrong?

[John E KVAM]

I'm going to guess that you got a good status from your call to:

status = vl53l5cx_start_ranging(&Dev);

(Everyone reads back the status, but few people actually check it.)

Consider using the line:

status += vl53l5cx_start_ranging(&Dev);

then you can use the debugger to check to see if status is still equal to 0 after several calls.

In the driver API there are a number of example programs.

Can you locate the example that is closest to yours can compare them.

I'm going to guess you missed something.

[DBonh.1]

Progress. I fixed the error in _start_ranging() by replacing that function with a fresh copy from ULD v.1.3.4. Before I replaced it tmp was always 4 bytes less than data_read_size.

But _check_data_ready() is still returning 00 05 84 81. The 81 apparently means a "GO2" error.

I attached screenshots from my I2C protocol analyzer and my printf() monitor.

[MNguy.7]

Hi @John E KVAM​ @DBonh.1​  , I have same issue, my vl53l5cx sensor running well with my initiation, but after 5 days, it cannot check_data_ready correct (isReady is false). So do you know this issue? I am on Project, please help me!

[John E KVAM]

generally if the sensor "just stops" it's related to noise on the lines.

If there are any glitches on the power line or on the XShut line, the sensor will partially reboot.

(I suggest big caps on these lines to prevent the glitches. Twisting the clock and data lines with a ground wire also helps. )

And when it comes back on, it will be in a stopped state.

If you expect an answer and don't get one on schedule, your only option is to go through the initialization process, and start again.

But there are things you can do.

Step one, if you can, check to see if the sensor is still running and it's an I2C issue.

By using a camera one can see the IR from the sensor. (But you cannot use an IPhone for this. Some phones have really good IR filters. ) So it's best to find a camera that you know can see the light.

If the sensor is flashing, then you have an issue, you can check it. I have yet to see a laptop camera that has a good filter, so a webcam will work.

Next, if you have a scope handy check the I2C lines. 'Bus stuck low' is an incredibly common issue.

(Both clock and data high is the default state of the I2C. If one is low for any length of time, it's a problem.) One can clear the issue by sending a bunch of clocks. Normally one or two will do, but 9 clocks is guarenteed to clear the line. (This is a problem will all I2C devices, not just this one. But because the sensor uses the I2C so much, it's seen a lot.)

To be completely fail safe, put a timer in your code. If the sensor is ever late, restart it.

And if it takes 5 days to see the issue, try inducing some static shock on your box to see if you can cause the issue.

[MFabb.1]

Hi John,

VL53L5CX does not have a pin dedicated to XSHUTDOWN line (as seen on VL53L0/L1).

Is the XSHUTDOWN signal masked as a reserved pin (RSVD6 or RSVD5) or I2C_RST pin?

Eventually, could glitches on the I2C_RST be the cause of I2C transaction errors?

We also investigating some issues on the I2C communication between host and VL53L5CX.

Thank you

[MFabb.1]

Hi John,

VL53L5CX does not have a pin dedicated to XSHUTDOWN line (as seen on VL53L0/L1).

Is the XSHUTDOWN signal masked as a reserved pin (RSVD6 or RSVD5) or I2C_RST pin?

Eventually, could glitches on the I2C_RST be the cause of I2C transaction errors?

We also investigating some issues on the I2C communication between host and VL53L5CX.

Thank you

[John E KVAM]

C2 is a Unused GPIO. It's an output so just pull it up gently and ignore it.

You aren't going to use an significant amout of power.

And could you start a new thread when you have a different question please?

It makes it easier for others to see the answer.

Thanks,

- john