Issue with VL53L8CX: No data-ready interrupt signal via SPI on STM32F405 with FreeRTOS

[HarukiTanaka]

I am trying to implement Time-of-Flight data acquisition using an STM32F405 microcontroller running FreeRTOS, with the MCU and the VL53L8CX communicating via SPI. However, the vl53l8cx_check_data_ready() function keeps failing, and I have been trying to track down the root cause.

Here is what I have verified so far:

• After loading the firmware to the VL53L8CX and starting it, I confirmed that the sensor is emitting infrared light (observed using a camera).

• I checked the status return values from the API functions, and no errors were reported.

• There were no issues with the 3.3 V power supply, and no temporary voltage drops were observed during sensor reboot.

• I probed the INT pin with an oscilloscope to check if the VL53L8CX is outputting an interrupt signal at the interval set by vl53l8cx_set_ranging_frequency_hz. However, no interrupt signal was observed.

For comparison, I tested a bare-metal (non-FreeRTOS) SPI implementation on a NUCLEO-F446RE evaluation board. In that setup, the interrupt signal was generated properly, as shown in the attached photo. Since this interrupt signal is completely absent on my STM32F405 setup, I believe this is the core of the issue.

Does anyone know under what specific conditions or states the VL53L8CX fails to output the interrupt signal? Any insights on what might be causing this (especially in an RTOS context) would be greatly appreciated.

Thank you in advance.

Monitoring the interrupt signal

https://github.com/sarulab-ou/crazyflie-firmware-vl53l8cx/tree/feat%231-only-vl53l8cx

PS: The implementation is being carried out on a branch of the repository linked above (src/init/main.c). I also tested an implementation without using FreeRTOS, but no interrupt signal was observed.

[John_Kvam]

If you see the light flashing and you see the interrupt line pulled low when not connected, then the sensor is working. But what you have is a GPIO configuration problem. And those things drove me crazy when I was working. The thing to do is find some working code - even if it's on a different STM32 and see if your GPIO configuration is the same. Keep in mind that not all GPIOs can do everything, so you might have to choose a different one. 

Another approach would be to use the STM32CubeMX tool to configure your PIO. You don't need to use the entire generated code - just the configuration bits. 

Or you can post the question to the STM32 forum and ask there. Those people are really pretty good at configuring GPIOs and getting the interrupt logic right.

Good luck,

- john

[HarukiTanaka]

Thank you for your reply.

As you mentioned, I also suspect that the issue lies on the hardware side. First, I will carefully review my GPIO configuration to make sure there are no mistakes.

Additionally, I have been using DMA for the SPI implementation, but I will try switching to a CPU-driven (non-DMA) approach. When it worked on the NUCLEO board, the SPI communication was handled by the CPU.

Thanks again for your advice.