VL53L8CX not working on nrf9151 and getting NAKs

RobinSuneti · ‎2025-06-19

Hi everyone,

So I'm trying to get the VL53L8CX ToF lidar working in ZephyrRTOS running on a NRF9151 chip. I'm using the VL53L8CX ULD driver version 2.0.1. The VL53L8CX is connected to the NRF9151 using i2c with the address 0x52, however when I call the vl53l8cx_is_alive() function from the driver i only see the messages being sent over i2c and getting a NAK.

The i2c setup itself is confirmed to be working given that other devices use the same bus and are working as intended (we have tested with just the VL53L8CX connected as well with no difference in behaviour). We are using a custom pcb and the lpn pin is connected to 1.8v IOVDD with a 47k resistor and the system is powered with 3v AVDD. The VL53L8CX relevant circuitry for our custom pcb looks like this:

With pull-up resistors for the i2c lines.

The vl53l8cx_is_alive() function is called right at the beginning of main, but we have tried to add a delay before calling to give the system time to get fully powered up without effect.

As we are using ZephyrRTOS and the NRF9151 I've had to implement the platform layer functions for i2c myself. I've used the VL53L1x driver that was already present in the ZephyrRTOS repository as the reference for this.

Additionally, we have purchased a x-Nucleo-53L8A1 development board to use with our NRF9151DK development board. When using this setup we are manually setting the lpn and power-enable pins high before calling the is_alive function. We have tried various gpio_configure flags without success.

However, when using this setup we are experiencing strange behaviour on the i2c line. The clock line is permanently pulled high and the NRF9151DK doesnt seem to be able to sent the clock signal.

The first spike going down on the clock line(white) and data line (orange) is the power enable pin being pulled low and then high again after a few milliseconds. The data line is then pulled low and as there is no clock signal it stays low until the 500ms timeout is reached, which are the spikes you see on the data line, 4 messages timing out after 500ms.

There must be something I'm doing wrong and am not seeing, any help would be very much appreciated for both our custom pcb setup and/or the x-Nucleo-53L8A1 setup. If there is any need for further context or questions you need answers for let me know and I will try to respond as soon as possible.

Thanks!

Andrew Neil · ‎2025-06-19

@RobinSuneti wrote:
i only see the messages being sent over i2c and getting a NAK.

Suggests wrong I2C address?

Are you sure you have the correct I2C address, and that you are presenting it correctly to the driver?

In particular, does the driver require the 7-bit address left- or right-justified ... ?

Have you run a simple test where you just try every I2C address, and see which one the device ACKs ?

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.

View solution in original post

Andrew Neil · ‎2025-06-19

@RobinSuneti wrote:
i only see the messages being sent over i2c and getting a NAK.

Suggests wrong I2C address?

Are you sure you have the correct I2C address, and that you are presenting it correctly to the driver?

In particular, does the driver require the 7-bit address left- or right-justified ... ?

Have you run a simple test where you just try every I2C address, and see which one the device ACKs ?

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.

RobinSuneti · ‎2025-06-19

Hi Andrew,
The datasheet says it uses 8 bit addressing, but it looks like that just means 7-bit address left justified with a r/w bit on the LSB. Which unless I'm mistaken is the default behaviour of i2c in Zephyr and most i2c.

I have not tried to test every single address yet, ill try it out.

Andrew Neil · ‎2025-06-19

@RobinSuneti wrote:
The datasheet says it uses 8 bit addressing,

That's just plain wrong. I2C addresses are, by definition, 7 bits; the R/W bit is in addition to the Address:

https://www.nxp.com/docs/en/user-guide/UM10204.pdf#page=12

Unfortunately, this is an extremely widespread mis-description and source of endless confusion:

https://www.avrfreaks.net/s/topic/a5C3l000000UXMPEA4/t142031?comment=P-1150738

The other question is how the Zephyr software driver expects the address to be presented.

Software authors & documentation are also notoriously bad here.

#I2CAddress

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.

RobinSuneti · ‎2025-06-19

i am aware, thats why i added "but it looks like that just means 7-bit address left justified with a r/w bit on the LSB." and the image showing that exact thing you also describe.

however ive checked the i2c addresses by trying every single one like you suggested, and it didnt help on the nucleo board, but i did get an unknown address to pop up on our custom pcb, address 0x29. Looking over the datasheet for the vl53l8cx it says the lidar should be 0x52 and 0x29 is not listed as an alternative address. however i tried to use that address anyway, and i seem to be communicating properly with the lidar unit now. i now seem to get a stack exception, but thats a new issue for me to worry about.

Thanks for pushing me in the right direction!

Andrew Neil · ‎2025-06-19

@RobinSuneti wrote:
Looking over the datasheet for the vl53l8cx it says the lidar should be 0x52 and 0x29 is not listed as an alternative address.

They are the same thing, shifted:

0x52 =    0 1 0 1 0 0 1 0
0x29 =  0 0 1 0 1 0 0 1

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.

John E KVAM · ‎2025-06-20

And that is the problem with the I2C bus definition of addressing.

The 0x29 is the base address. To get the write address, the base is shifted one bit to the left, and a zero is in the LSB.

To get the read address shift the base one to the left and set the LSB.

So 0x29 => 0x52 and 0x53. The base address becomes the write and read pair.

But when writing a manual does one use the base address or the write address? Perhaps a better way to describe the address would be to use the notation 0x52/0x53. Then it would be obvious which you were referring to.

Not a very good system and very confusing. But not the sensor's fault. That addressing scheme was invented by Philips long ago, and they never envisioned what I2C would become.

If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

Andrew Neil · ‎2025-06-20

@John E KVAM wrote:
The 0x29 is the base address.

No. It is The address: there is only one address, and it is 7 bits^*.

The I2C specification is quite clear on this (see previous).

@John E KVAM wrote:
To get the write address

There is no such thing as a "write address".

There is an entirely separate bit which indicates the access direction - read or write.

It's like a traditional parallel bus with a direction line (or lines) separate from the address lines; eg,

https://os.mbed.com/users/nxp_ip/notebook/parallel-bus-access/

@John E KVAM wrote:
But when writing a manual does one use the base address or the write address?

One should use the one & only 7-bit address.

If you are combining the 7-bit address with the R/W bit into a byte, then make that clear.

[/rant-over]

* Not considering 10-bit addressing!

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.