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

[NKohl.1]

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

[NKohl.1]

Update:

I tested all addresses on the I²C and found no device (always returns HAL_BUSY).

I did a little bit of research and found this: https://www.st.com/content/ccc/resource/technical/document/errata_sheet/f5/50/c9/46/56/db/4a/f6/CD00197763.pdf/files/CD00197763.pdf/jcr:content/translations/en.CD00197763.pdf

I tried to follow the instructions, but I can not set and reset the SCL and SDA in Output-Mode and read back the correct values.

[John E KVAM]

During the init() you are downloading some 83K bytes. So it's going to take a bit.

The binary that the GUI downloads into the STM32 on the development kit was written with that same ULD you have.

(To do it any other way would be cheating.)

If you don't get a response from address 0x52/0x53 (or address 0x29 depending on how you count) then either the chip is not alive or the I2C_RST is not set correctly.

So a quick check of the power rails should be first.

We ship some example code along with the ULD that should run out of the box.

Did you get that going?

In the STSW_IMG023 there is an CUBEIDE_F401RE_EXAMPLE.

Download the STM32CubeIDE and run the code from there.

Prove that works and then compare the working example to your code.

Good Luck,

• john

[NKohl.1]

Hello John,

I have tried to run the example code but it did not work. My software is up to date, but the example uses older firmware, so I tried migrating the project and I tried it with the older firmware.

I have checked the power rails as well, everything is fine there.

At this point, I would normally change the chip, but it is working with the Windows GUI, and that is bugging me.

Is it possible to get my hands on the project behind the binary of the GUI, and see if I can run that?

Kind regards,

Niklas

[NKohl.1]

Another update:

I have two Nucleo-F401RE and one Nucleo-L476RG on my desk. It seems to work with the L476 but still nothing with both of the F401REs, except when I am using the GUI.

[John E KVAM]

The GUI is basically a python program that can move a .bin file into the Nucleo-F401RE and send it commands via the USB (acting as a serial port). It then just plots whatever it gets back.

So it is the .bin file that is important. And that works only with the F401RE.

That is why the GUI works.

Now when writing you own software start with the example code.

Download the

STSW-IMG023

• Ultra Lite Driver (ULD) for VL53L5CX multi-zone sensor

In there, if you go to:

C:\...\VL53L5CX_ULD_driver_1.1.2\CubeIDE_F401RE_Example\

you can build a running example.

Can you tell me why it didn't work?

If the GUI works, the hardware is proved. So that's not an issue.

But if the IDE cannot compile and run, I need to know why. It sure works for me.

I just downloaded the code - 1.1.2, Went to the CubeIDE_F401RE_Example directory, and clicked on the .project file.

this opened the IDE. I clicked on the project to select it and hit the hammer (build) icon.

It built.

I then clicked on green right arrow and saw that the LED blinked indicating downloading.

I then opened a Tera Term terminal emulation window, selected the com port that said ST.

Selected 460800 baud rate and got:

• Zone : 0, Nb targets : 1, Ambient :  3 Kcps/spads, Target status :  5, Distance : 1602 mm
• Zone : 1, Nb targets : 1, Ambient :  2 Kcps/spads, Target status :  5, Distance Zone : 0 ...

Sure looks like it works for me.

What did you get (or not get)?

[NKohl.1]

I took the example build it and ran it in CubeIDE using the debugger. It compiles and it 'runs'. The important part are lines 136 and 137ff:

The status of the sensor is checked, and if it is not available, the example program returns with 255 and then enters the hard fault handler.

...

136: status = vl53l5cx_is_alive(&Dev, &isAlive);

137:  if(!isAlive)

138: {

139:   printf("VL53L5CXV0 not detected at requested address (0x%x)\n", Dev.platform.address);

140: return 255;

141: }

...

What always happens for me, is that "isAlive" always gets the value "0", which causes the program to return with some error code.

I then added the line "status = HAL_I2C_IsDeviceReady(&hi2c1, Dev.platform.address, 10, 10);" which always returns "HAL_BUSY".

[John E KVAM]

when you issue a I2C command there are 2 failure modes.

1) The device refuses to respond and you get a timeout

2) you somehow get the wrong data.

so first check that the I2C status is correct and you are not timing out.

If you get past that and you see you are communicating, I'm going to assume the Sensor is sending the wrong ID.

So try this...

return success from the Is_Alive function and keep going. What happens?

And what device ID and revision ID did you get?

(Years ago we had trouble with the device ID. I sure hope those days are not back.)

[NKohl.1]

I took a close look at vl53l5cx_is_alive() and watched what happend in the debugger. The HAL_I2C_MasterTransmit gets called with correct values on the WrByte() in plattform. The function then fails at

... line 1068 in stm32f4xx_hal_i2c.c

   /* Send Slave Address */

   if (I2C_MasterRequestWrite(hi2c, DevAddress, Timeout, tickstart) != HAL_OK)

   {

     return HAL_ERROR;

   }

...

and returns HAL_ERROR. Every following R/W operation on the I²C in returns HAL_ERROR as well. The device_id and revision_id get the value 244 (0xF4) and the function is_alive() returns with 1.

So the I2C status is not correct and the data that is read is propably not valid.

[NKohl.1]

Update:

I have it running using my Nucleo-L476RG,still nothing with the F401RE, however the data I am receiving seems to be wrong. E.g. in VL53L5CX_ResultsData I get values for nb_targets_detected greater than 4, which does not make any sense to me... the target status also contains values not stated in user manual, the distance values do not change and are well out of range.

[John E KVAM]

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.