cancel
Showing results for 
Search instead for 
Did you mean: 

X-Nucleo 53L5A1 works fine with Windows GUI, but does not even init / is not alive using API

NKohl.1
Associate II

Hello,

the VL53L5CX is a really nice senor. I have done some measurements using the Windows GUI and was impressed, so I wanted to write a driver for the sensor and do some further evaluation.

I then tried to initialize the sensor using the ULD-API and my Nucleo-Board, but the sensor is not detected via I²C, I double checked with the Windows GUI - everything works just fine - so the Hardware should be alright.

I tried using the provided example in the API - same problem. I did not do anything fancy yet, are there some known issues? What is the Firmware in the Windows GUI doing different than the API? The init() loads the default firmware to the sensor, how long does that take?

Background:

  • I am using the latest API V1.1.2
  • I am using the platform.h and .c from the example
  • I²C address is VL53L5CX_DEFAULT_I2C_ADDRESS
  • before calling init() I set GPIOs PWR_EN_C, LPn_C, and reset I2C_RST_C
  • I make sure to wait long enough for the power supply to be stable

What else could go wrong?

Thank You for Your help!

Kind regards,

Niklas

11 REPLIES 11
John E KVAM
ST Employee

I'm betting Byte-swap or word-swap issues. That would explain why your Chip ID was wrong and why you get unintelligible data.

the code works on an ARM processor. Does your MCU have the same endianness?

int32_t vl53l5_dci_swap_buffer_byte_ordering() is the function that does the work.

Find that and work backwards to see what is going on.


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.
NKohl.1
Associate II

The STM32F401 and the STM32L476 are both little endian. The function you mentioned is not included in the API, there is a SwapBuffer in platform.h, and vl53l5cx_dci_read_data, vl53l5cx_dci_write_data, and vl53l5cx_dci_replace_data in the api.

I changed the byte order, which resulted in the sensor not initializing, because the endianess should have been wrong when reversing the byte order, since the F401 and the L476 have the same endianess.

Changing the byte order would also not affect the value of the target status, which is a uint8_t.