Strange start-up behaviour of VL53L5CX ToF sensor

[Joh70]

Hello Developers, Hello ST-Team,

unfortunately we are stuck in implementing VL53L5CX on our PIC18. We see a strange clock stretching behaviour of the sensor and problem downloading the firmware.

We implemented Ultra Lite Driver 2.0.0 in an application on a Microchip PIC18F57Q43 (CURIOSITY NANO Evaluation Kit) using Example_1_ranging_basic.c from the examples folder.

After the adjustments of platform.c and modification of the download routine to download the 86 KB firmware in chunks, we got the following odd behaviour:

- The function  vl53l5cx_is_alive(&Dev, &isAlive); returns SUCCESS = No error!

- The function vl53l5cx_init(&Dev); fails.

Sending the first package of data seem to be successfull. When trying to start sending the second chunk of data the sensor refuses to communicate with the MCU by returning NACK for any further byte.

Has anybody an idea why the sensor behaves like that and why the sensor stretches the clock line?

Even while stretchin SCL for each byte transmitted, it seems the sensor communicates at first until the FW download got started. Trying to send more data chunk than the first one always fails, not matter what size is used:

chunks sizes of 2 byte register index +

126 bytes or
128 bytes or
192 bytes or
255 bytes or
256 bytes of data failed.

Our HW design person said, there is a level shifter included on the sensor PCB to run conform sensor voltage. There is also an LDO voltage regulator which brings doown the supply voltage of 5V to the required 3.3V.

Please see the oscilloscope measurements:

Why the ACK from the sensor comes so late for each data byte transmitted from MCU to sensor?

Why sensor accepts the first chunk of firmware data but refuses any further data by replying with NACK on I2C?

We spend days to understand what went wrong here, but we cant find an explanation. The sensor on our custom PCB works fine when its connected to a ST MCU (using NUCLEO-F401RE Evaluation Kit).

Thanks for help!

[John E KVAM]

There are at least two ways to screw up an I2C transaction. The first is size. Some small microprocessors have very small I2C transaction buffers. And the other way is endianness. 

From the datasheet I could not tell the endianness of the microchip processor. 

(The STM32 is little-endian, the I2C transactions are big-endian. So, in our code there is a lot of byte and word swapping going on. )

One way to isolate it is to check the return on your I2C transactions. So do that.

As you have an I2C analyzer, hook it up when using the eval board. Check the transaction order. Is it the same as yours. 

That should give you some clue.

- john

[John E KVAM]

And I don't like those little half-height spikes. An I2C is either a 1 or a zero. There should be nothing in between. 

Shorten the cables. Unless you are willing to mess with pull-ups and a lot of trial and error, about 1 foot is the maximum distance an i2c can go.

The i2c is not a very fault tolerant bus. Any little noise spike can stop it. 

- john

[Joh70]

Hi John!  Thanks for reading and giving tipps! 

The half spikes seemed to be a bad zoom behaviour of the picoscope software in measurement window.
Its not showing the full high levels when zoomed-out (overview). In real, those spikes go up to VCC voltage. This can be seen when zoomed-in to those spikes.

Byte order:

Even if byte order would be flipped, why the sensor stretches the clock line (SCL) when sending its ACK?

In function  vl53l5cx_is_alive() several commands/requests are successfully sent over the I2C bus and responses are received with valid an answers from the sensor, It returns without errors, even the clock line is delayed.

Also the transmission of a FW data bytes is successfull until transmission of the second package wants to start.
All bytes furthermore get acknowledged by a NACK from the sensor.

Supply voltage Question:

If sensor supply voltage is 3,3 Volts and I2C signals have 5 Volt  as seen in those oscilloscope measurements:
Could this disturb or delay I2C transmission? 5V is +1.7V  more than VCC 3.3V of the sensor.

Maybe the level shifter does not work?

Joh.

[John E KVAM]

The ToF sensor is going to absolutely hate any voltage over its AVDD.  The I2C should not go there. 

Your choice is either a 3v3 max or a 2.8 max, but 5V is out of the question. 

And if you have 5V on that line, you've found your issue.

- john