VL53L1X returns 0x00 instead of 0xEA on PIC18F16Q41 hardware I2C

[AndyO]

Hello,

I am trying to communicate with a VL53L1X sensor using a PIC18F16Q41 hardware I2C peripheral (MCC-generated driver).

The sensor module is AE-VL53L1X from Akizuki Denshi (Japan), which includes the original ST VL53L1X sensor and onboard level shifter.

Current issue:
The sensor ACKs correctly, but reading the Model ID register (0x010F) always returns 0x00 instead of the expected 0xEA.

Current I2C sequence:

START
W 0x29 ACK
0x01 ACK
0x0F ACK
STOP

(wait about 1 ms)

START
R 0x29 ACK
0x00 NACK (expected 0xEA)
STOP

What I already confirmed:

* Wrong I2C addresses correctly return NACK from the sensor
* XSHUT is correctly pulled up
* Sensor power is stable before PIC startup
* Oscilloscope confirms correct ACK/NACK behavior

Important comparison:
Using a RATOC USB-I2C converter with the same sensor module, register 0x010F correctly returns 0xEA.

So the sensor module itself appears to work correctly.

I compared the oscilloscope waveforms between RATOC and PIC.
One difference is the STOP timing generated by the PIC hardware I2C, but according to the VL53L1X datasheet timing requirements, it still appears to satisfy STOP timing specifications.

The attached SDA/SCL waveforms show some overshoot/ringing because the wiring is relatively long (about 50 cm total).

However, the same wiring length and similar overshoot are also present when using the RATOC USB-I2C converter, and in that case the VL53L1X correctly returns 0xEA from register 0x010F.

Therefore, the overshoot itself does not appear to be the root cause.

Has anyone experienced compatibility issues between VL53L1X and PIC18 hardware I2C peripherals?

Or is there anything special about VL53L1X register read timing/state handling that might explain why ACK works correctly but the returned data becomes 0x00?

Thank you very much.

[AndyO]

Hi Bin,

Thank you very much for your time and for helping me investigate this issue.

Your comments helped me verify the protocol details and eliminate several possible causes.

Based on the additional comparison with a RATOC USB-I2C adapter, it now appears that the VL53L1X device and protocol are functioning correctly, and that the remaining issue is likely related to the PIC18F16Q41 I2C peripheral or MCC driver implementation.

I appreciate your support and your honest assessment of the situation.

Thank you again for your assistance.

Best regards,
Yasutoshi Oyamada

[Bin]

Hi:

Based on the observed behavior, the fact that the device address and register address phases are both correctly acknowledged suggests that the physical IC connection and the basic address communication are fine.

 

The most suspicious point is the way the register read transaction is organized.

On the PIC side, the current sequence appears to be:

- write the 16-bit register address

- STOP

- then a new START for the read

However, the Slave sensor is more likely expecting the register read to be performed as:

- write the 16-bit register address

- then **repeated START**

- and immediately continue with the read

In this situation, even if all ACKs look correct, the internal register address pointer/context inside the device may not be preserved correctly across the STOP condition. As a result, the device can still acknowledge the transaction but return `0x00` instead of the expected `0xEA`.

 

Since the same module works correctly with the RATOC USB-IC converter, and under the same wiring length it also returns the correct value, this points much more strongly to the PIC hardware IC transaction handling or the MCC driver handling of a 16-bit register read, rather than to the sensor itself.

 

Best Regards,

Bin FAN

[AndyO]

Hi Bin,

Thank you very much for your detailed explanation.

To further investigate your point regarding the STOP condition and possible register pointer/context handling inside the VL53L1X, I captured an enlarged oscilloscope waveform of the final part of the write transaction:

0x0F ACK STOP

This is the STOP condition generated by the PIC18F16Q41 hardware IC peripheral after transmitting:

W 0x29
0x01
0x0F

From my understanding, the STOP condition itself appears to satisfy the IC specification:

• SCL is high

• SDA transitions from low to high

However, I would appreciate your opinion:

Does this STOP condition waveform appear valid enough for the VL53L1X to correctly recognize the end of the write transaction?

Or do you see anything suspicious in this waveform that could prevent the device from correctly latching the register index before the subsequent read operation?

Thank you again for your support and technical insight.

Best regards,
Yasutoshi Oyamada

[Bin]

Hi:

From the waveform, the STOP condition itself appears to be electrically valid. In other words, SCL is high and SDA transitions from low to high.

the question is probably not whether the STOP is valid, but whether the slave sensor expects the register-address phase and the read phase to remain within one combined transaction. If possible, I would recommend trying a repeated START sequence from the PIC side, or comparing the exact RATOC read transaction at the protocol level to see whether it uses repeated START instead of STOP.

Best Regards,

Bin FAN

[AndyO]

Hi Bin,

Thank you very much for your reply.

I agree that the STOP condition itself appears to be electrically valid.

I checked the VL53L1X datasheet again, and Figure 14 Data format (read) appears to show a STOP condition between the register index write phase and the following read phase.

I also tried the repeated START sequence from the PIC side, but the returned data was still 0x00.

For comparison, I captured the RATOC USB-I2C transaction. The RATOC transaction appears to use a STOP after sending the register index:

W 0x29
0x01
0x0F
STOP

Then it performs the read transaction:

R 0x29
0xEA

So the RATOC converter can read the expected 0xEA value with a STOP condition between the write and read phases.

Based on this comparison, it seems that the difference may not be the STOP vs repeated START sequence itself, but something else in the PIC I2C transaction timing or bus handling.

I have attached the oscilloscope captures for:

• PIC repeated START transaction returning 0x00

• RATOC request phase with STOP

• RATOC answer phase returning 0xEA

• VL53L1X datasheet Figure 14

If you notice any important difference between the PIC and RATOC waveforms, I would greatly appreciate your advice.

Best regards,
Yasutoshi Oyamada

[Bin]

Hi:

Based on your test results:
RATOC
request phase?W 29 -> 01 -> 0F -> STOP
answer phase?R 29 -> EA
This fully complies with VL53L1CX datasheet.
PIC
W 29 -> 01 -> 0F -> R 29 -> 00
The ACK during the index writing phase is normal
The ACK during the address reading phase is also normal
But the read back data is fixed at 0x00.

 

After checking the VL53L1X datasheet, especially Section 4 Control interface, the STOP condition between the 16-bit register index write phase and the read phase is valid and explicitly shown in Figure 14.

So, the issue does not appear to be STOP versus repeated START.

Since:

- the VL53L1X ACKs the write address and both index bytes,

- the read address is also ACKed,

- the same sensor module and same wiring work correctly with the RATOC adapter,

- and both STOP and repeated START on the PIC still return 0x00,

the most likely root cause is on the PIC hardware I2C / MCC driver side during the read-data phase, rather than in the VL53L1X protocol itself.

Unfortunately, I am not familiar enough with the PIC18F16Q41 hardware IC peripheral to provide further useful advice, sorry for that.

 

Best Regards,

Bin FAN

 

[AndyO]

Hi Bin,

I would like to report the final resolution of this issue.

The root cause was not related to the VL53L1X communication protocol.

After further debugging, I found that an AI-generated initialization sequence contained a VL53L1X reset command, but the corresponding release-from-reset command was missing.

Therefore, the sensor remained in reset state.

This explains why:

* The device address was ACKed
* The register index bytes were ACKed
* The read address was ACKed

but register 0x010F always returned 0x00.

After removing the incorrect reset command, the sensor immediately became operational and register 0x010F returned the expected value 0xEA.

No special delays, clock stretching handling, or protocol modifications were required.

The attached oscilloscope capture shows the successful read transaction.

Thank you very much for your assistance and analysis. Your comments helped me confirm that the issue was likely outside the VL53L1X protocol itself and encouraged me to continue investigating the software side.

Best regards,

AndyO
 

 

[Bin]

Hi:

Thanks for your sharing and appreciate your in-depth research. Congratulations👍