cancel
Showing results for 
Search instead for 
Did you mean: 

Ported VL53L0X Pololu code to STM32 - Always times out, can't find error!

Adam Halliwell
Associate II
Posted on May 29, 2018 at 04:06

Hi all

In lieu of the VL53L0X API being so awkward to use, I've made an effort to port the Pololu version of the VL53L0X library to STM32-compatible C code, using HAL functions to manage I2C communication.

Using an STM32F072RB board, with fast mode I2C (400KHz) and the 'D3' pin as XSHUT1, the setup and operation of the sensor in main.c goes as follows (removed surrounding code for readability)

VL53L0X sensor1;
char msg[64];
main()
{
setup_VL53L0X(&sensor1);
HAL_GPIO_WritePin(XSHUT1_GPIO_Port, XSHUT1_Pin,false);
 HAL_Delay(100);
HAL_GPIO_WritePin(XSHUT1_GPIO_Port, XSHUT1_Pin,true);
 HAL_Delay(20);
if(!init(&sensor1,true))
 {
 snprintf(msg,sizeof(msg),'Failed to initialize\r\n');
 HAL_UART_Transmit(UART, (uint8_t*)msg, strlen(msg), 0xFFFF);
 }
 else
 {
 snprintf(msg,sizeof(msg),'Successfully initialized\r\n');
 HAL_UART_Transmit(UART, (uint8_t*)msg, strlen(msg), 0xFFFF);
 }
setTimeout(&sensor1,500);
 startContinuous(&sensor1,0);
while(1)
{
snprintf(msg,sizeof(msg),'Read value: %u\r\n');//,readRangeContinuousMillimeters(&sensor1));
 HAL_UART_Transmit(UART, (uint8_t*)msg, strlen(msg), 0xFFFF);
}
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Unfortunately the function readRangeContinuousMillimeters(...) always returns a timeout (65536), as if the sensor is never initialised to read continuously (but, as shown in the code, it definitely is). Furthermore, reading WHO_AM_I always returns 0xEE which is correct and proves that the I2C bus is working.

Every function in the VL53L0X library has been ported over appropriately, and I've scanned every line of code to try and find the source of the problem. However, zero luck as of yet.

I have attached both the Pololu and my own version of the VL53L0X library, plus a custom I2C library which makes use of HAL functions, and the full main.c of this project.

If anyone is able to play spot-the-difference in order to get this working I'd be eternally grateful, as I'm completely stumped. Not that it's much in return, but this code is free for anyone to use if they can get it working.

Cheers

#port #vl53l0x
28 REPLIES 28
Primoz B.
Associate
Posted on May 31, 2018 at 18:51

Hello there,

I'd like to help you, but cannot compile the code you've given, because some I2C libraries seem to be missing. Are you using any custom libraries (I2CDev.h?), if so - could you provide it for me? I am using STM32F407VGTx Discovery Board, but the code should be portable without major issues.

Posted on June 04, 2018 at 11:38

Hi Primoz B

Thanks for offering to help.

Please see the updated attachment which now has the I2CDev library, as well as the main.c of my project.

Cheers

Sergii Volchenko
Associate III

Hi

Did you find a problem in your code?

Thank you.

ZVita
Associate

Your code is absolute working. I tested on STM32F4DISCOVERY.

It is necessary to implement two functions readMulti () and writeMulti (),

I inserted them into main.c

SLAVE_ADDRESS= 0x29 Channel hi2c1

Also in the main.c add lines after init (& sensor1, true)

 setVcselPulsePeriod (& sensor1, VcselPeriodPreRange, 18);

 setVcselPulsePeriod (& sensor1, VcselPeriodFinalRange, 14);

Adding project archive to COOCOX I2C_PROBA.ZIP

Good luck

Adam Halliwell
Associate II

Hi Sergii and Vitalij

Yes I found the problem a while back - sorry for not updating the thread.

The code itself does work. The problem was in my custom I2C functions.

Writebyte worked correctly

HOWEVER when writing more than one byte ( e.g. 16 bits) a brackets error made me typecast the data before bit shifting! Very stupid!

Example:

Wrong pseudocode:

void Write16Bits(uint16_t data)
{
uint8_t temp[2];
temp[0]=(uint8_t)data;
temp[1]=(uint8_t)data >> 8;
Write_I2C((uint8_t*)temp);
}

Correct pseudocode:

void Write16Bits(uint16_t data)
{
uint8_t temp[2];
temp[0]=(uint8_t)data;
temp[1]=(uint8_t)(data >> 8);
Write_I2C((uint8_t*)temp);
}

It took a logic analyser looking at every packet before I realised that my multiple-byte sending functions were sending the first byte only, followed by 0x00 for the remaining bytes.

ZVita
Associate

Yes, this is true

Thank you.

Mahdi Bayati
Associate

Hi @Adam Halliwell​ 

I programmed the files attached by @ZVita​ .

I displayed the results in a seven segment TM1637. I have uploaded the files that are exactly the same as what @ZVita​ has uploaded. My Project has been carried out by STM32F030F4. All Settings have adjusted. For instance, XSHUT Pin and other needed pins.

I have only a problem. My code results in displaying the number "65536" after 20 seconds.

I have correct results for 20 seconds and after that, I have "65536".

This error is persistent. It remians. I have the same problem exactly the same as you.

You solve the problem in the final comment in this page. But I did not understand it. Is it possible for you to solve my problem? I have attached my project. Please answer me because I have spent many days to solve it. A million thanks to you. @ZVita​ Can you help me? @Adam Halliwell​ Can you help me? How did you solve your problem?

See my project. typcasting after >>8 or typcasting after many different codes?

I appreciate that you migrated this program into one genetared by STM32CubeMX.

Apparently, I have the same issue as other mates, after approximately 20 seconds I get 65536 from "readRangeContinuousMillimeters" function

Finally, I understood the problem and I solved it