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]

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]

To be updated and doesn't seem to be inline with changes done in https://github.com/zephyrproject-rtos/zephyr/pull/105238/changes

[faxe1008]

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

[avolmat-st]

Thanks @faxe1008. I just gave it a try. I had to perform few updates in the PR to have it work.
Cf the diff below:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index eceb3f95..683d8fc9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -46,6 +46,8 @@ zephyr_include_directories(audio/microphone)
 zephyr_library_sources(audio/microphone/OpenPDMFilter.c)
 endif()
 
+endif()
+
 # STMEMSC - Hardware Abstraction Layer for ST sensor
 add_subdirectory_ifdef(CONFIG_HAS_STMEMSC sensor/stmemsc)
 
diff --git a/sensor/vl53l5cx/api/inc/vl53l5cx_api.h b/sensor/vl53l5cx/api/inc/vl53l5cx_api.h
index 0e870ac0..40c32c68 100644
--- a/sensor/vl53l5cx/api/inc/vl53l5cx_api.h
+++ b/sensor/vl53l5cx/api/inc/vl53l5cx_api.h
@@ -19,7 +19,7 @@
 
 
 
-#include "platform.h"
+#include "vl53l5cx_platform.h"^M
 
 /**
  * @brief Current driver version.
diff --git a/sensor/vl53l5cx/api/inc/vl53l5cx_buffers.h b/sensor/vl53l5cx/api/inc/vl53l5cx_buffers.h
index 35eaff8b..8cc3007f 100644
--- a/sensor/vl53l5cx/api/inc/vl53l5cx_buffers.h
+++ b/sensor/vl53l5cx/api/inc/vl53l5cx_buffers.h
@@ -15,7 +15,7 @@
 #ifndef VL53L5CX_BUFFERS_H_
 #define VL53L5CX_BUFFERS_H_
 
-#include "platform.h"
+#include "vl53l5cx_platform.h"
 
 /**
  * @brief Inner internal number of targets.

An endif is missing in the CMakeLists.txt.
I also renamed the platform.h include file so that it is done in a similar way as the other tof sensor drivers. The vl53l5cx_platform.h is provided by the Zephyr driver.

I am cleaning up the Zephyr PR to use that new version of the HAL driver as well as expose all distance values.

[faxe1008]

I updated the PR :^)

[avolmat-st]

LGTM. Tested with PR zephyrproject-rtos/zephyr#105238

[erwango]

Otherwise LGTM

[faxe1008]

Aside from @erwango comment:
https://github.com/zephyrproject-rtos/hal_st/compare/9c1a2b4f8adac1cfcb25a3f43f802f609bf50388..e3ed50f49e0923b2e290633b310a50932ef24fdf

I had something like this:

#ifndef VL53L5CX_BUF_ATTRIBUTES
#define VL53L5CX_BUF_ATTRIBUTES
#endif

/**
 * @brief This buffer contains the VL53L5CX firmware (MM1.5)
 */

const uint8_t VL53L5CX_FIRMWARE[] VL53L5CX_BUF_ATTRIBUTES = {

To allow Zephyr to place firmware or xtalk buffers into a specific DMAble memory region. IIRC (this was a year or so ago at this point) I did that to help with I2C transfer speed.

Any thoughts @avolmat-st ?

[avolmat-st]

@faxe1008 indeed, maybe that's good to test. Since it takes a little while to upload via I2C I had to increase the i2c timeout to allow properly booting.
Let me give it a try on my side first.

[avolmat-st]

@faxe1008 I performed some more test using I2C / DMA and I was able to use it without having to place the data into a specific buffer.
I mostly tested regarding to the FW loading part since during the driver loading it will load the TOF firmware into the device hence, leading to large i2c transfer.
I tested while using the recent / ongoing I2C Zephyr driver update PR zephyrproject-rtos/zephyr#110920

I didn't have to put the code into a specific area for that purpose (at least on the which is the platform I am using now)