error in vl53l8cx_check_data_ready

[HarukiTanaka]

I am currently trying to control a VL53L8CX sensor via SPI communication from the microcontroller mounted on a Crazyflie drone.

However, inside vl53l8cx_check_data_ready(), the values in temp_buffer became as follows. Indices [0] to [2] look correct, but at temp_buffer[3], the condition

((p_dev->temp_buffer[3] & (uint8_t)0x10) == (uint8_t)0x10)

evaluates to false.

What exactly is this comparison checking?

When temp_buffer[3] returns an incorrect value like this, which specific part of the communication or control process is likely failing?

• temp_buffer[0]: 0x0
• temp_buffer[1]: 0x5
• temp_buffer[2]: 0xC5
• temp_buffer[3]: 0xC1
  

[John_Kvam]

If your sensor is running the value in temp_buffer[0] will change. First frame it's 255 then it counts from 0 to 127, then repeats. A temp_buffer[0] being 0 looks wrong to me. 

I'm going to guess that you failed to start your sensor. 

Check the status of every call. There's lots of initialization and something went wrong. 

One thing you can do to verify the sensor is running is to look at the sensor with a camera. (Don't use a IPhone though. The IR filter is too good on that device.) You should see it either flashing or a constant 'on' depending on how you set up the mode. No light means it's not running. 

- john

[HarukiTanaka]

Thenk you for your reply.

After executing vl53l8cx_is_alive, vl53l8cx_init, and vl53l8cx_set_ranging_frequency_hz, I called vl53l8cx_start_ranging. I confirmed that the sensor appears to start, because when I observed it with a PC camera, I saw a single IR flash.

I am also printing the return status of every API call, and so far I have not found any errors.

Are there any other possible causes you can think of for this issue?

Also, in vl53l8cx_check_data_ready(), what do temp_buffer[1] to temp_buffer[3] specifically represent?

[John_Kvam]

To be honest I don't know what temp_buffer[1] to [3] mean. This being retired has it's issues.

But if you see a single flash and and then get a failure return that should be a clue. The sensor does a flash when it's first calibrating, and perhaps stopped after that for some reason. 

What was the return value from the check data ready call?

            status |= p_dev->temp_buffer[2];    /* Return GO2 error status */

And did you put that check in a loop and keep checking until you get a success?

The range takes about 30ms by default, and that's forever for your MCU.

Summarize the calls you made and the status you got from the check data ready call, and I'll force one of my old co-workers to have a look.

[HarukiTanaka]

VL53L8CX_Configuration MDev[1];

int Init_Sensor(uint16_t DevAddr, uint8_t Frequency)
{
    uint8_t status, isAlive;

    MDev[DevAddr].platform.address = DevAddr;

    status = vl53l8cx_is_alive(&MDev[DevAddr], &isAlive);
    if (!isAlive || status)
    {
        DEBUG_PRINT("vl53l8cx_is_alive failed, status %u[%d]\n", status, DevAddr);
        return (0);
    }
    status = vl53l8cx_init(&MDev[DevAddr]);
    if (status)
    {
        DEBUG_PRINT("VL53L8CX ULD Loading failed_init[%d]. status is %u\n", DevAddr, status);
        return (0);
    }
    DEBUG_PRINT("VL53L8CX ULD ready ! (Version : %s)[%d]\n", VL53L8CX_API_REVISION, DevAddr);

    status = vl53l8cx_set_ranging_frequency_hz(&MDev[DevAddr], Frequency);
    if (status)
    {
        DEBUG_PRINT("vl53l8cx_set_ranging_frequency_hz failed, status %u[%d]\n", status, DevAddr);
        return (0);
    }
    status = vl53l8cx_start_ranging(&MDev[DevAddr]);
    DEBUG_PRINT("vl53l8cx_start_ranging %d status=%d\n", DevAddr, status);
    return (1);
}

int main(){
    Init_IO();
    spiBeginTransaction(SPI_BAUDRATE_2MHZ);

    // ↓↓↓↓↓↓↓↓↓↓implement related to vl53l8cx↓↓↓↓↓↓↓↓↓↓↓↓
    if(Init_Sensor(0, 1) != 1){
        DEBUG_PRINT(Init_Sensor() error);
    }
    VL53L8CX_WaitMs_spi_pause(&MDev[0].platform, 500); //wait 500ms

    uint8_t isReady = 0;
    int loop = 0;
    while (loop < 10)
    {
        status = vl53l8cx_check_data_ready(&MDev[0], &isReady);
        if (isReady)
        {
            vl53l8cx_get_ranging_data(&MDev[0], &Results);
            DEBUG_PRINT("Print data no : %3u\n", MDev[0].streamcount);
            for (int i = 0; i < 16; i++)
            {
                DEBUG_PRINT("Zone : %3d, Status : %3u, Distance : %4d mm\n", i,
                            Results.target_status[VL53L8CX_NB_TARGET_PER_ZONE * i],
                            Results.distance_mm[VL53L8CX_NB_TARGET_PER_ZONE * i]);
            }
            DEBUG_PRINT("\n");
            loop++;
        }
        VL53L8CX_WaitMs_spi_pause(&(MDev[0].platform), 5);
    }
}

Since I am integrating this into the drone’s microcontroller, I have modified parts of platform.c and some related sections, but the overall implementation is as mentioned above.

I think the reason why temp_buffer[0] remains 0 is that when vl53l8cx_check_data_ready() is called, isReady never becomes 1, and therefore vl53l8cx_get_ranging_data() is never called even once.

Regarding vl53l8cx_check_data_ready(), I am calling it repeatedly in a loop exactly as in the implementation  mentioned above, and it continues to be called indefinitely as long as `isReady==0`

In vl53l8cx_check_data_ready(), a GO2 error is being reported.

[DEBUG PRINT LOG] 

[0]: FF, [1]: 04, [2]: 9C, [3]: 41

[0]: FF, [1]: 04, [2]: 9C, [3]: 41

[0]: FF, [1]: 04, [2]: 9C, [3]: 41

[0]: FF, [1]: 04, [2]: 9C, [3]: 41

[0]: FF, [1]: 04, [2]: 9C, [3]: 41

[0]: 00, [1]: 05, [2]: C5, [3]: C1

GO2 error detected

[0]: 00, [1]: 05, [2]: C5, [3]: C1

GO2 error detected

[0]: 00, [1]: 05, [2]: C5, [3]: C1

GO2 error detected

・・・

[John_Kvam]

You set the frequency to 1. Doesn't seem right to me. Generally 30 frames a second is a good place to start. 

At a frequency of 1, the sensor will integrate for the entire one second before returning a result. Probably not what you want. 

Anyway you only wait a loop of 10 with a wait of 5ms before giving up. 

If your frequency were 30 that might work - but the first range might take longer. Give it twice the normal time before giving up.

- john