2020-09-16 05:43 AM
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:
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).
These are the values of the five calls to "VL53L1X_BootState()" :
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:
Maybe 0x02 = No booted and 0x03 = booted?
Regards
2020-09-16 08:22 AM
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.
2020-09-29 03:12 AM
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
2024-11-06 07:40 AM
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.