Skip to main content
Visitor II
July 29, 2026
Question

VL53L8CX I2C Communication Instability

  • July 29, 2026
  • 2 replies
  • 89 views

**VL53L8CX ranging stops after a few frames (2-4 typical, up to 28 seen once) clean status, no error on three independently-built boards**

**Setup:** Custom board, VL53L8CX (I2C mode) + STM32G0B1KBU6 host MCU, ULD driver, 4x4 resolution, 10Hz continuous ranging mode, 30ms integration time. 

**Symptom:** `vl53l8cx_init()` and `vl53l8cx_start_ranging()` both succeed. Ranging produces good frames (plausible per-zone status/distance data) for a small number of frames usually 2-4, occasionally more (saw 28 once) then `check_data_ready()` starts returning `VL53L8CX_STATUS_OK` with `data_ready` staying false indefinitely. No error code in the common case. I2C bus itself stays healthy throughout (clean ACKs on every transaction, confirmed via logic analyzer).

**One-off exception:** on a single occurrence, `check_data_ready()` returned `0x84` instead of `0x00`. I found the earlier thread here (linking below) where a `0x81`/`0xC5`/`0xCA`-style status was identified as a GO2 (internal MCU) error. I want to be upfront that this has only happened once for me — my typical stall is the silent/clean-status kind above, not this. Mentioning it in case it's a related data point, not because I think it's my main bug.

**What I've ruled out:**
- I2C bus faults — no address NACKs, no mid-transaction NACKs anywhere in captures; every byte cleanly ACKed through the stall.
- Board-to-board assembly variance (cold solder joints, etc.) — all independently-built boards fail identically, same frame counts, same behavior.
- My own recovery/retry logic — reproduced the exact same stall with a bare-bones build that has zero stop/start/reset logic in the main loop, so it isn't my code interrupting an in-flight transaction.

**Question:** Is there a known cause for the ranging engine going quiet mid-session (clean I2C, no error code) after a handful of good frames? Is there additional diagnostic/status information I can read from the sensor beyond `check_data_ready()`'s return code that would help narrow down what's happening internally at the moment it stalls?

Happy to provide I2C captures, my init/config sequence, or anything else that would help. 

I’m hoping this is a firmware issue as I am new to cube IDE but please let me know your opinions, thank you in advance.

[Original thread: https://community.st.com/imaging-sensors-49/i2cdetect-disrupts-vl53l8cx-operation-causing-go2-error-146394]

2 replies

ST Technical Moderator
August 7, 2026

Hi:

Can you share the pin connection between L8CX and STM32G0B1KBU6? By default, L8CX ULD is based on STM32F401, the connection of the pins may need to be redefined.

In addition, VL53L8CX_ULD_driver_2.0.1 package, we have 12 examples code, can you log all print data of example1 and example9

Best regards,

Bin FAN

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Andrew Neil
Super User
August 7, 2026

Welcome to the forum

Please see How to write your question to maximize your chances to find a solution for best results.

In particular, please show your schematic.

Some good, clear photos of your setup could also help.

 

Flaky I2C could be a hardware issue, so:

  1. Have you verified on an oscilloscope that the signals are clean, good edges, etc?
  2. Have you used a logic analyser to see what’s actually happening on the wires when it fails?
A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.