cancel
Showing results for 
Search instead for 
Did you mean: 

vl53l5cx_check_data_ready returns C5 GO2 error

BPutt.1
Associate II

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)?

10 REPLIES 10
Anne BIGOT
ST Employee

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


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
BPutt.1
Associate II

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
Associate II

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
ST Employee

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

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.
beustens
Associate

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
Associate

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? 

Did you try to do a start / stop ? 


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

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

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


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.