Register Map for VL53L8CX

[Rituraj]

I am trying to use VL53L8CX with stm32f4 discovery but had no success.  Implementing the preexisitting API has been tough.  Is there a register map for this sensor whcih can be used to create a minimalistic driver and interface sensor using I2C or SPI.
If anyobne knows what is register 0x7FFF . Please let me know.

[John E KVAM]

The VL53L8CX actually has an MCU in it, and that 80K of code you write to it to start the sensor is the Firmware running in that sensor. 

As such a 'register map' would more reasonably be called an interface protocol. But we do communicate over the i2C using addresses - and for all the world it's a register map. But a pretty complex one. 

There are a couple of ways you can hook up that stm32f4 discovery. If you are using the VL53L8-satel, you might be having a known issue with the SPI (Our supply stuffed the wrong level shifter.) 

Solved: VL53L8CX SPI doesn't work properly - STMicroelectronics Community

Check your board for the wrong part.

It was also noted that if you run the SPI too slowly it has an issue. 3Mbits seems to work just fine. 

But you should be able to get the sensor running with the I2C. 

The startup code downloads some 80K and we have to change pages to get it all downloaded. That's register 0x7fff.

When running all the communication is done on the same page.

If using a non-ST MCU sometimes the I2C cannot make those large I2C transfers, and one has to break them into smaller chunks. (This is not your issue, but it happens to others. )

Don't give up on the APi so quickly please. Running this beast with a register map can be done, but it took us years. And you would end up hating ST. The API is validated and well tested. It has lots of advantages. 

- john

[Rituraj]

Hello John,
I Thank you for your response. I just checked the evaluation board I own  , The level shifters(PI4ULS3V204) are fine .

I am not using SPI so as per your response on another query this must be a misconfigured I2C .  I have already gone through most of documentations UM3109 , UM3108 , AN5945.   Can you tell me what should be the configuration of I2C ?

This is what I have done, What could be wrong here.


I also tried another and TOF configuration for it is here 

Please let me know what needs to be changed

 

[John E KVAM]

When you generate the code, do you get:

/**
 * @brief I2C1 Initialization Function
 * @PAram None
 * @retval None
 */
static void MX_I2C1_Init(void)
{
	hi2c1.Instance = I2C1;
	hi2c1.Init.ClockSpeed = 1000000;
	hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2;
	hi2c1.Init.OwnAddress1 = 0;
	hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
	hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
	hi2c1.Init.OwnAddress2 = 0;
	hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
	hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;
	if (HAL_I2C_Init(&hi2c1) != HAL_OK)
	{
		Error_Handler();
	}
}

This is what works for me. 
I don't have a discovery board, but I know that processor has more than one I2C. You need a schematic to verify that you have chosen the correct I2C pins. Make sure it's I2C1. 

(And the ClockSpeed will work at 1M but sometimes you have to change it after you generate the code.

If you have a scope, See if you are getting any wiggles at all on the I2C. 

And until it gets working - keep you i2C wires short.  

[AlexCloned]

Hello JaoIndio,
The best and most advantageous way to approach this is by editing the provided open-source driver. The API makes things easier and is the most reliable path. It is highly discouraged to try to make these complex sensors work through simple register writes.
The issue you're facing is very common when a non-ST MCU's I²C peripheral has limitations on the size of a single transaction. The core issue lies with how the default driver's WrMulti() function handles large I²C transfers, which often exceed these limits during sensor initialization.

---

 

The Solution: Rewriting WrMulti() in platform.c

 

You're on the right track; the key is to manage the data flow from your host MCU to the sensor. The most effective approach is to implement a solution that breaks these large transfers into smaller chunks, tailored to your MCU's I²C buffer size. This ensures the data is sent in a way your hardware can reliably handle.

This community post provides an excellent example of a proven solution for this exact problem, showing how to rewrite the function WrMulti() to chunk the data:

https://community.st.com/t5/imaging-sensors/init-failures-on-vl53l5-l7-and-l8-due-to-long-i2c-writes/m-p/809411#M5615

By adapting this approach to your MCU's specific I²C capabilities, you'll be able to build a robust custom driver that can successfully interact with the VL53L8CX firmware.

Conclusion see that post and several similar posts about i2C large packets managing.