VL53L4CX: How/where to store calibration data

[unicyclebloke]

I need to calibrate a VL53L4CX and have been reading UM2923. The functions described do not seem to bear any obvious relationship to the functions in the STM32Cube middleware which was generated for my project, which I find confusing. I it is not clear which functions I should be calling in order to satisfy the flow charts in UM2923. I have found essentially no other useful information about this device or its specific set of registers. I'm usually a huge fan of ST devices and documentation...

The first sticking point is how to properly understand what to do with calibration settings. Am I supposed to store them in my own flash somewhere? That seems to be implied by UM2923. I can do this, but imagined the device would have its own NVM storage on board, since it is calibrated in the factory anyway. Is this the case? I thought so because the wrapper function VL53L4A2_RANGING_SENSOR_OffsetCalibration() ends by writing a data structure over the I2C interface from a function called VL53LX_set_customer_nvm_managed(). This function only updates a data structure with NVM in its name, but does not actually store anything in NVM. I have not found any APIs which indicate that they update the NVM on the device itself.

The second question is about the content of the calibration data. UM2923 says after each calibration section that it is better to call VL53LX_GetCalibrationData(), modify specific named fields, and then call VL53LX_SetCalibrationData(). Is this still necessary if I perform all three of the calibration steps? I imagine in this case that the data fetched by VL53LX_GetCalibrationData() would be exactly the data to use for VL53LX_SetCalibrationData(). Does the data structure contain other values which change at runtime and are not in fact calibrations? 

[John E KVAM · Accepted solution]

Am I supposed to store them in my own flash somewhere? - Yes, exactly.

Is this (calling GetCalibrationData) still necessary if I perform all three of the calibration steps? No. You can do all three and then get the calibration data. The trick is to change targets between the offset and crosstalk calibration calls.

That CubeIDE middleware has an issue that has flummoxed me as well. The code is valid for all our sensors. To do this they put a layer in between your MCU and the sensor. This layer is full of function address pointers and, although it works, it's really hard to follow.

The trick is to figure out how they derive the dev pointer. With that you can make your own calls.

Easiest way to do this is to use the debugger and single step through the program.

Look especially at those lines where it appears they are calling a function by using the address in an array. 

Once you figure out where the store the dev device header, you can make your own function calls.

I give the credit for a fancy implementation that works, but I kind of wished they went with a more obvious bit of code people could have used as an example.

- john

[unicyclebloke]

Thanks. That's helpful. I have already added the necessary flash storage, figuring that would be the response. It does seem a bit strange that the device could not make a little of its own flash space available. No matter. Next up: a state machine to walk the production team through calibration steps... 

[unicyclebloke]

Actually, what I meant by the second question is do I need to call GetCalibrationData() in the *field* code, modify specific fields using the values from my flash storage instance of the data structure? It seems like the idea of that is to preserve existing values on the device if I don't do all three calibrations. But if I do all three and store the results, then I assume there would be no calibration values on the device worth preserving. I would simply pass my stored copy of the calibration data to SetCalibrationData(). I just wanted to confirm my assumption.

[John E KVAM]

When you do the calibration, the data is stored in the Sensor's volatile memory. After doing all the calibrations you issue the GetCalibrationData() to suck the data out. 

We considered creating some non-volatile memory for the calibration, but it would have involved you needing a different power rail, and we'd need to give you access to registers that would screw up the entire system. And then we'd need to do something about re-calibration, and it got completely unreasonable. 

If you do all three - without shutting down the system - the cal data will be in the sensor. Suck it out, store it, and put it back at each subsequent reboot.

[unicyclebloke]

I'm grateful for your assistance. I have now written a state machine to guide a user through the calibration procedure and store the data to flash. A note for other readers: my stack for this task was 2KB and this led to an overflow in the cross talk stage. I just doubled it to 4KB and it was fine.