vl53l5cx_check_data_ready returns C5 GO2 error

[BPutt.1]

I was able to run the vl53l5cx demo, however when calling 53l5cx_check_data_ready, I see that it reported a 'GO2'error. The code is C5.

The content of the (relevant?) config.tempbuffer is 0, 5, C5, 81.

How to figure out what is wrong here, is there an list of error codes of the GO2 error(s)?

[Anne BIGOT]

Hello

This is an internal error of the FW.

Is it reproducible or it occurs once only ? If reproductible ot could be an issue with your module.

What sort of setup are you using ? an ST expansion board or your own one ?

Regards

[BPutt.1]

Hi Anne, thanks for your reply.

We are using a sparkfun module and Raspberry Pi. The error is reproducible, so I will try a second module to be sure the problem is not on the hardware side.

[BPutt.1]

Second module shows the same error. What does the error mean?

It took us quite a while migrating the C-code into C# code and modification of the Raspbarry Pi was needed to be able to transfer the firmware bulk data over I2C. If we have more info on the error code(s) we might track down the problem. The origin of the problem might still be in our software modification.

[John E KVAM]

I'm thinking it's an I2C error. When you downloaded the initial 80K bytes, it somehow did not succed. So the sensor did not get started.

The trick to downloading the data is the I2C transfers are really long. But I believe the RPI can handle that.

Did you get success for every I2C transfer during the bootup process?

That is where your issue is.

• john

[beustens]

Also see here: VL53L5CX ULD vl53l5cx_check_data_ready() returns e... - STMicroelectronics Community

I have a similar issue with the VL53L7CX. It initializes and runs just fine for a few hours, but then I also run into an "GO2" error. I my case, it is 0xEA.

Can you please publish the error descriptions for these errors?

[beustens]

As it takes so long to produce the error, it is difficult to debug and try to solve it. I can restart the sensor, but due to the large firmware, it takes always 2 seconds or so to re-initialize it, which is too long in our application during runtime.

Is it necessary to run through the complete initialization or can the problem be solved by a simple LPN pin toggle? 

[Anne BIGOT]

Did you try to do a start / stop ? 

[Deep_bang]

Hi John,

I am also facing the same issue. 

let me explain the scenario.

We have planed to use VL53L8CX TOF for keystone correction in our projector.

We have nucleo53L8A1 -F401RE board for testing. During sensor initialization , the loop i.e _vl53l8cx_poll_for_answer() this read data in all its occurrences is noted .

When I interfaced this TOF sensor with our LPC55s69 controller , its able to read revision id, device id and then 

in sensor initialization , this loop read data i.e _vl53l8cx_poll_for_answer() and status return is matching with the 

above standard noted values. "so, sensor initialization might be happening properly".

But , when it comes to "vl53l8cx_check_data_ready(&Dev, &p_data_ready);" the temp_buffers not getting required values. This is the data I am getting with return status integer as 156.

 p_dev->temp_buffer[0] as 0xff.

p_dev->temp_buffer[1] as 0

p_dev->temp_buffer[2]  as 0x9c

p_dev->temp_buffer[3] as 0x81

Its entering the else loop as attached :

How to resolve this ?

Thanks & Regards,

Deep_Bang

[John E KVAM]

There are basically two possible software issues. 1 is that you have a byte-swap or word-swap issue. The other is that unlike the STM32, your MCU cannot send 0x8000 byte-long hex transfers. 

Either issue will allow you to read the chip ID - it's one byte and you cannot screw that up. But you still have issues.

Have a look at: Solved: Struggling to successfully operate the satel vl53l... - STMicroelectronics Community for some advice. It's how to identify the byte-swap issue.

The max I2C transfer issue is a bit easier, generally the transferred data length is returned. Add some code to check that.

A hardware issue that people run across is a line-length issue. The I2C is not a very robust bus. Try it with shorter wires if you above about a foot. 

- john