cancel
Showing results for 
Search instead for 
Did you mean: 

BUG: VL53L1X API for uC where int is 16 bits (AVR)

pannagger
Associate

Hi, 

I asked for help because my measurements took >> 15 seconds (up to 30s) in:
https://community.st.com/t5/imaging-sensors/vl53l1-measurement-takes-up-to-30-seconds/td-p/843640

Now after hours of debugging i found a bug in the API at least for platforms where an Integer is not 32 bit, in:
vl53l1_core_support.c:114 
the code is:

pll_period_us = (0x01 << 30) / fast_osc_frequency;

 but on AVR uC like atmega644 0x01 is 16 bit wide. Which leads to pll_period_us = 0.

The wrong value messes up all tim_cfg and gen_cfg, and introduces weird behavior.

Fix:

pll_period_us = (0x01UL << 30) / fast_osc_frequency;

Telling the compiler to use unsigned long fixed the problem for me.

This bug should be fixed to be more platform independent I suggest.

Kind regards,
Philip

1 REPLY 1
Anne BIGOT
ST Employee

Hello,

Thank you for your feedback.
Can you instead try the following fix : 

pll_period_us = ((uint32_t)0x01 << 30) / fast_osc_frequency;

This is the way we are handling the pll period in othre function.

Fix will be integrated in a future release,

Regards

Anne


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'