cancel
Showing results for 
Search instead for 
Did you mean: 

VL53L1X - Boot states Ultra Lite Driver (ULD)

Hardwariano
Associate III

Hello

I open this thread as a continuation of this other one, which is very long. My problem is that the boot states I read with "VL53L1X_BootState" (0x02 and 0x03) do not match the documentation (0x00 and 0x01).

As John says in the aforementioned thread:

"The bootstate register spec is:

[1] firmware_first_range: FW first range status

[0] firmware_bootup: FW initial boot status, Set by FW after completing initial coldboot."

And as VL53L1X_api.h says:

0693W000003Rpo3QAC.png

In the above-mentioned thread, John suggests:

"I had problems with this register too. I think the documentation has it backwards.

So boot, read the register quickly, see what it reads a few millisec later, then range. With a little luck it will go from 0 to 2 to 3 after ranging."

I have done all of the above John said except ranging. This is my code (my code is located at the beginning of the FIRST thread of the program, so It is the first thing to be executed after the internal MCU initializations).

0693W000003Rq54QAC.png

These are the values of the five calls to "VL53L1X_BootState()" :

0693W000003RpywQAC.png

Write: 52 00 e5

Read: 53 02

Write: 52 00 e5

Read: 53 02

Write: 52 00 e5

Read: 53 03

Write: 52 00 e5

Read: 53 03

Write: 52 00 e5

Read: 53 03

So, my questions are:

  1. Am I doing something wrong and that is why I get wrong boot states?
  2. If my code is correct, could it be that the documentation was wrong?

Maybe 0x02 = No booted and 0x03 = booted?

Regards

3 REPLIES 3
John E KVAM
ST Employee

It sure looks to me like the LSB is the 'booted' flag. And what the other bit is still in question.

[0] firmware_bootup: FW initial boot status, Set by FW after completing initial coldboot."

So the LSB is as advertised. It's 0 until booted and then 1.

One might surmise that the other (first_range) bit might turn off after the first ranging.

Really should look at that.

The initial intent of the 'Booted flag' was to determine if the chip rebooted due to a power glitch or other anomaly.

So setting (or clearing) a bit after first range would give useful information.

If the 'first_range' bit goes from 1 to 0 after ranging, you get exactly what you want. It's just that the polarity of the first_range bit is unexpected.


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.
Hardwariano
Associate III

Hello John, thanks for your help. I was confusing bit values with byte values. Now it is clearer to me.

I finally did this at the begging of my code:

    g_ioport.p_api->pinWrite(VL53L1X_OUT_XSHUT, SENSOR_STATE_OFF);
    R_BSP_SoftwareDelay(100, BSP_DELAY_UNITS_MILLISECONDS);
 
    g_ioport.p_api->pinWrite(VL53L1X_OUT_XSHUT, SENSOR_STATE_ON);
    R_BSP_SoftwareDelay(100, BSP_DELAY_UNITS_MILLISECONDS);
   
    while(((sensorState & 0x01) == 0) && (status_ST == VL53L1_ERROR_NONE) && (count_retry < 10))
    {
        status_ST = VL53L1X_BootState(I2C_ADDRESS_29, &sensorState);
        R_BSP_SoftwareDelay(2, BSP_DELAY_UNITS_MILLISECONDS);
        count_retry++;
    }

After waking up the sensor I check the first bit ([0] firmware_bootup) for a while, looking for value 1. There are two possible situations:

1) There's no delay between XSHUT=ON and VL53L1X_BootState. The secuence is:

Write: 52 00 e5

Read: 53 02 (0000 0010)

Write: 52 00 e5

Read: 53 02 (0000 0010)

Write: 52 00 e5

Read: 53 03 (0000 0011) --> Sensor booted

Write: 52 00 e5

Read: 53 03 (0000 0011)--> Sensor booted

Write: 52 00 e5

Read: 53 03 (0000 0011)--> Sensor booted

2) There's a delay of a few milliseconds between XSHUT=ON and VL53L1X_BootState(). The sensor has enough time to wake up, so the first time I ask for the boot state the sensor answers it's already booted:

Write: 52 00 e5

Read: 53 03 (0000 0011)--> Sensor booted

With respect the second bit ([1] firmware_first_range), it always returns the value 1, regardless of whether a measurement has already been made or not. Regardless of that, the sensor seems to be working.

Regards

andrvisht
Associate

Note that in case of receiving 0x02 the target does not acknowledge index 0xE5 and thus we cannot be absolutely sure that the 0x02 we received is related to the register being read.