VL53L4CD Driver Questions

[hegdeprashanth]

I am using the VL53L4CD sensor board very similar to https://www.sparkfun.com/products/18993 with my application. I am using the modified version of https://github.com/stm32duino/VL53L4CD driver on the Raspberry Pico board.

I am using the both the xshut and INTR pins.

I am able to read the sensor ID and load the default configuration without any issues. However, the call to 

VL53L4CD_CheckForDataReady times out in the SensorInit function. Also, in the function 

VL53L4CD_SetRangeTiming, reading the osc frequency return 0, instead of non-zero. I have also compared the driver files with the https://github.com/STMicroelectronics/x-cube-tof1/blob/main/Drivers/BSP/Components/vl53l4cd/ . They seem to be identical except the platform functions. Please let me know what could be causing these issues?

 

 

[John E KVAM]

If you've gotten to SensorInit, you have been communicating with the chip quite a bit. But it's clearly not right, and the first opportunity to know this is the 'are you done yet' is failing. 

I'm going to guess that it's a byte-swap or work-swap issue. Because it always is. 

#define I2C_TEST
#ifdef I2C_TEST
int rd_write_verification( uint16_t dev, uint16_t addr, uint32_t expected_value)
{
	VL53L4CD_Error Status = VL53L4CD_ERROR_NONE;
	uint8_t bytes[4];
	uint16_t words[2];
	uint32_t dword;
	int i;
	for (i=0; i<4; i++){ VL53L4CD_RdByte((uint16_t)dev, addr+i, &bytes[i]); }
	for (i=0; i<2; i++){ VL53L4CD_RdWord(dev, addr+i*2, &words[i]); }
	Status = VL53L4CD_RdDWord(dev, addr, &dword);

	printf("expected = %8x,\n",(unsigned int)expected_value);
	printf("read_bytes = %2x, %2x, %2x, %2x\n", bytes[0],bytes[1],bytes[2],bytes[3]);
	printf("read words = %4x, %4x\n",words[0],words[1]);
	printf("read dword = %8x\n",(unsigned int)dword);

	if((bytes[0]<<24 | bytes[1]<<16 | bytes[2]<<8 | bytes[3]) != expected_value) return (-1);
	if((words[0]<<16 | words[1]) != expected_value) return (-1);
	if(dword != expected_value) return(-1);
	return Status;

}
#define REG 0x3A
void i2c_test(uint16_t dev)
{
	VL53L4CD_Error Status = VL53L4CD_ERROR_NONE;
	int err_count = 0;
	uint8_t buff[4] = {0x11,0x22,0x33,0x44};

 	int i=0;

	Status = rd_write_verification(dev, 0x10f, 0xebaa10ff);			// verify the Chip ID works

	Status += VL53L4CD_WrDWord(dev, REG, 0xffeeddcc);			// check WrDWord
	if (rd_write_verification(dev, REG, 0xffeeddcc) <0) err_count++;

	Status += VL53L4CD_WrWord(dev, REG, 0x5566);				// check WrWord
	Status += VL53L4CD_WrWord(dev, REG+2, 0x7788);
	if (rd_write_verification(dev, REG, 0x55667788) <0) err_count++;

	for (i=0; i<4; i++){ VL53L4CD_WrByte (dev, REG+i, buff[i]); }
	if (rd_write_verification(dev, REG,0x11223344) <0) Status++;
	if (Status > 0)
	{
		printf("i2c test failed - please check it. Status = %d\n", Status);
	}
}

#endif

 

Put this bit of code in just after you think your sensor is booted.

It simply writes bytes and reads words and longwords. 

It's my guess that because you had some writes 'backwards' the sensor was just not understanding the commands you were giving. 

I could be wrong of course, but it's easy enough to check.

- john

[hegdeprashanth]

Thanks. Here's the result of the below code after the sensor has booted ( it reads 0x3 as the boot state):

 

expected = ebaa10ff, read_bytes = eb, aa, 10, ff read words = ebaa, 10ff read dword = ebaa10ff

expected = ffeeddcc, read_bytes =  0,  0,  0,  0 read words =    0,    0 read dword =        0

expected = 55667788, read_bytes =  0,  0,  0,  0 read words =    0,    0 read dword =        0

expected = 11223344, read_bytes =  0,  0,  0,  0 read words =    0,    0 read dword =        0

[John E KVAM]

That's crazy - The first read is of a defined hardware register. and it sure looks like it was read correctly.

So, your reads work!

But the other lines write the data as bytes, words and long-words. And you are reading back zeros.

QED, your writes are failing to actually write. 

At this point you must debug the I2C write themselves. It's got to be in there somewhere. 

If you don't write, you can't configure the chip - or start it. 

Which is what you are seeing.