drivers: sensors: Add official ST library for vl53l5cx

[faxe1008]

Adds the official ST library for the vl53l5cx tof sensor.

Will open the corresponding zephyr driver PR soonish.

[erwango]

Will open the corresponding zephyr driver PR soonish.

Thanks. Please ping us once it's ready for review

[erwango]

@faxe1008 Is this PR still in your plans ?

[faxe1008]

Hey @erwango,

yeah so I did some work on the zephyr side for this:
faxe1008/zephyr@caf5525

But for some reason part of the initialization fails:
8fdc319#diff-909a8a275d4d87c7f05a575c52f45e54f5319a6babbf41300bcec44590ffa712R363

The plattform abstraction for the I2C seems to be working - I can read the sensor ID and the other operations prior to reading the NVM data in the init method seem to work. It's not really evident to me why this happens. Need to see if I can use a working refrence implementation and see what is happening there.
Besides that I wonder if the upload of the firmware does need to be part of init sequence, would hiding this behind a Kconfig flag be an accetable addition to cut down on flash usage?

So yeah, I'd love to continue on this one gotta find some time and a lead to fix up the init sequencing though.

[avolmat-st]

Hey @erwango,

yeah so I did some work on the zephyr side for this: faxe1008/zephyr@caf5525

But for some reason part of the initialization fails: 8fdc319#diff-909a8a275d4d87c7f05a575c52f45e54f5319a6babbf41300bcec44590ffa712R363

The plattform abstraction for the I2C seems to be working - I can read the sensor ID and the other operations prior to reading the NVM data in the init method seem to work. It's not really evident to me why this happens. Need to see if I can use a working refrence implementation and see what is happening there. Besides that I wonder if the upload of the firmware does need to be part of init sequence, would hiding this behind a Kconfig flag be an accetable addition to cut down on flash usage?

So yeah, I'd love to continue on this one gotta find some time and a lead to fix up the init sequencing though.

Hi @faxe1008,

I gave a try with this PR and the related Zephyr commit you pointed as well from your repo. I also faced the same NVM data init, but it turns out that that the issue is in the WrMulti function in which there is a typo.

diff --git a/drivers/sensor/st/vl53l5cx/vl53l5cx_platform.c b/drivers/sensor/st/vl53l5cx/vl53l5cx_platform.c
index e5ceeddb8f9..e5fec09993e 100644
--- a/drivers/sensor/st/vl53l5cx/vl53l5cx_platform.c
+++ b/drivers/sensor/st/vl53l5cx/vl53l5cx_platform.c
@@ -33,7 +33,7 @@ uint8_t WrMulti(VL53L5CX_Platform *p_platform, uint16_t RegisterAdress, uint8_t
                {.buf = p_values, .len = size, .flags = I2C_MSG_WRITE | I2C_MSG_STOP},
        };
 
-       if (i2c_transfer_dt(&p_platform->i2c, msg, size) < 0) {
+       if (i2c_transfer_dt(&p_platform->i2c, msg, 2) < 0) {
                return VL53L5CX_STATUS_ERROR;
        }

I am using this on the STM32N6570_DK board. Since there is quite a large amount of registers to set during the init, leading to having quite long (in time) i2c transaction. Depending on the I2C bus speed, this can take a little while, leading to timeout of the I2C STM32 driver which has a default limit in time. To overcome it it is thus necessary to change the default timeout value and increase it via the Kconfig CONFIG_I2C_STM32_TRANSFER_TIMEOUT_MSEC.

With that done, I am able to get the initialization working fine and also getting result_data which do not seem too wrong.

So, idea now is thus to add more stuff in the driver and expose the captured value via the sensor interface. After this PR have you been able to improve / debug also this issue in which case do you have already a more recent version of the code ?
If no, I propose to rebase this PR and open a PR on the Zephyr side to work on the Zephyr driver, starting from your commits of course and adding some more bits to add ability to capture and report data.

[faxe1008]

I have not put much more effort into this, happy if this gave you anplace to start though. Feel free to pick it up 😀

Maybe the firmware upload needs to be guarded by a kconfig as this is also quite hefty in regards to flash...

[avolmat-st]

@faxe1008 I have improved the Zephyr part for this TOF and will push the updates enabling this TOF on Zephyr. I will make the west.yaml point to this hal_st update. Currently this is outdated so would you be able to simply rebase this PR on top of the head of hal_st ?
This is simply to avoid having to open another PR since I don't think I have the right to update this PR branch myself.
If you prefer I do this on my side, let me know.

[faxe1008]

@avolmat-st sure, rebased and resolved the conflict.

[avolmat-st]

Thanks a lot @faxe1008 !!

[erwango]

I'm seeing v2.4.5 version on the st webpage. Can you x-check ?

[erwango]

Ok, my bad the issue is the st webpage provided. It should be:
https://www.st.com/en/embedded-software/stsw-img023.html.

Btw, it could be worth updating to the latest version (v2.0.1)

[avolmat-st]

Thanks @erwango for spotting the update. Indeed, having rapidly done the comparison, indeed there are changes to be applied.
@faxe1008, how do you wish to proceed ? Do you want to handle this on your side or do you want me to do the update ?

[faxe1008]

Will do so tomorrow-ish

[erwango]

Suggested change

	* include vl53l5cx_api.h and vl53l1_platform.h in the driver .h
	* include vl53l5cx_api.h and vl53l5_platform.h in the driver .h

[erwango]

Ok, my bad the issue is the st webpage provided. It should be:
https://www.st.com/en/embedded-software/stsw-img023.html.

Btw, it could be worth updating to the latest version (v2.0.1)

[faxe1008]

@avolmat-st @erwango updated the pr with the latest version from sts page.