VL53L5CX - What does the constant VL53L5CX_STATUS_CRC_CSUM_FAILED correspond to?

[HaLmarin]

Hello,

I'm currently working with the VL53L5CX sensor and I came across the following definition in the header files of the API provided by ST : 

#define VL53L5CX_STATUS_CRC_CSUM_FAILED ((uint8_t) 3U)

However, this constant doesn’t seem to be used anywhere in the API or referenced in error handling functions.

I would like to know:

1. What exactly does this constant represent? Is it related to an internal CRC or checksum mechanism?

2. Does the VL53L5CX sensor implement any internal CRC checking ?

3. Are there other ST Time-of-Flight sensors that implement CRC or similar integrity checks in their communication protocols?

Thanks in advance for your insights!

Best regards,

[John_Kvam]

If you can't find anywhere, then it's not used. One expects that there was a plan to put something in, but it wasn't implemented in your version. 

I remember a long conversation with a cell-phone company where they wanted it implemented, so they might have a special version, but it's not in yours.

But here is the thing. The I2C is a pretty iffy bus. Lots of times the transmission goes bad. 

But what happens is the Transmitter and the receiver get out of sync, and the bus hangs with the famous 'bus stuck low' issue. (Google it.)

This is by far the biggest issue. And when it happens it's really obvious that the bus is stuck.

If you have control over the clock line, you can toggle it. It might take up to 8 times, but that will clear the jam and you can start over. 

But I'm pretty certain the checksum is not implemented - and if your bus is not hung, you didn't need it. 

- john

[Victo]

Hi John,

I am investigating to use the VL53L5 measurement for a safety function processing. Thus, I would need to have a reliable communication.

1. Without CRC or checksum, the only way to trust the data would be to implement a redundant pair of VL53L5 sensors ?
2. How often this I2C bus stuck is likely to happen ? I guess it would force me to stop my system if it cannot be resetted inside a safety period.

Thank you for your support,
Vic.

[John_Kvam]

The I2C 'bus held low' issue depends on the quality of your design. Short wires, wide traces, properly adjusting the pull-ups to handle the capacitance of your system and immunity to electrical noise are all things you need to think about. There are lots of web sites that do a great job of telling you how to make an I2C bus more reliable.

And I got the story on the checksum. It was in there - until someone wanted the code space for something they really wanted. And something had to go.

And it's possible to get a wrong byte or two, but if it happens during the download, the download will fail. If it happens while the sensor is running, use a subsequent range to verify the data. 

- john

[Victo]

• Comparing the data frame #N with the frame #(N-1) would actually double the reaction time of the sensor data interpretation, correct ?
• This would solve random byte corruption but cannot be use to detect sensor persistent defect that would result in unrealistic data ?

[HaLmarin]

is this possible to obtain it again ?

[John_Kvam]

An interesting idea. But it's going to take a little doing.

Once a range is complete, the sensor starts on the next range - assuming you are running in continuous mode. This saves a lot of time. But one needs a bit of an interlock to keep the next range from overwriting the one you are currently reading out. 

So, if you are very slow reading data, the sensor will stall and not update the data until you are done.

Once you have read the last byte, the sensor is free to overwrite the data with the newer data.

If you want to read it twice, you can - as long as you stop reading before you get to the last byte. Then you can read it all again, this time reading all the data. 

Let us assume you are wanting to read 2500 bytes. (The amount you want depends on the settings in platform.c) 

Simply read 2498 bytes, then start over and read all 2500 bytes the second time. 

I'd be very interested to know how many times the I2C went wrong, but as I've retired, I really can't ask you for the statistics. 

But if you wanted to post that, it would be interesting.'

- john