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 · Accepted solution]

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

[Joh70]

Hi John, 

sorry for my late reply! 
I didn't find time to work fulltime on that project.

Unfortunately i still not got the ToF-sensor to start-up on a PIC18F (8-bit-MCU).

For a test i put all voltages to 3.3V and i still dont understand why the ACK comes so late on the I2C-Bus.

I marked it YELLOW in the measurement graph below:

Is there a special start-up mode of the sensor? May it be, that it started up in a low-speed mode? Or was something wrong with the I2C lines at RESET time of the sensor? Didn't i read once about a Bootloader mode of the sensor, when both I2C lines are low at RESET time?

WHAT CONDITIONS MAY CAUSE A DEALYED ACK FROM THE SENSOR?

I dont see those delays on measurements of the sensor connected to a ST NUCLEO Board.

I really dont have a clue whats going on here on the board connected to PIC18F CURIOSITY.

As you can see in the graph all voltages are now between 0 and 3.3 V and it can't be an overvoltage behaviour.
For testing i modified my program to wait 5s after start-up before Initialization attempt of the sensor begins.
This allows me to manually RESET/POWER-CYCLE the Sensors supply voltage directly before init routine starts to be sure, no unwanted signal changes on I2C lines occur during MCU reset.

The same sensor PCB stil. works fine and flawless when connected to my ST NUCLEO Eval kit and demo program. Something must be different.

And in the above screenshot its the first data bytes sent on I2C and already delayed. So it cant be a protocol data problem. Something electrically must be different. I2C operates at 400 kHz.

Johannes from Germany.