cancel
Showing results for 
Search instead for 
Did you mean: 

Wait for sensor booted fails

PBoer.1
Associate II

I was using the sensor until now on an Raspberry Pi with direct access to the I2C bus without problems.

Now I use an FT260 USB-I2C interface to communicate to the sensor from a PC via USB. In principle the communication is working, e.g. vl53l5cx_is_alive() works as expected.

But the initialization fails. On the poll for sensor booted status I now always get a 9 as the answer instead of the expected 1 until the timeout is reached.

In the documentation I haven't found any hint what the value of 9 at this point means.

This is the place where vl53l5cx_init() fails:

 

	/* Wait for sensor booted (several ms required to get sensor ready ) */
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x00);
	status |= _vl53l5cx_poll_for_answer(p_dev, 1, 0, 0x06, 0xff, 1);
	if(status != (uint8_t)0){
        printf("vl53l5cx_init(): Wait for sensor booted failed\n");
		goto exit;
	}

 

And inside _vl53l5cx_poll_for_answer() I see that the returned value is 9. Because the expected value is 1 _vl53l5cx_poll_for_answer() fails.

Any idea?

1 ACCEPTED SOLUTION

Accepted Solutions
PBoer.1
Associate II

Solved!

Looking to the recorded data on the oscilloscope I saw that sometimes a byte was missing in the write sequence. Digging into the code I found the place responsible for this. Now it's working as expected.

View solution in original post

4 REPLIES 4
John E KVAM
ST Employee

Just prior to that query is an I2C transfer of 0x8000 and not all MCU's can handle it. The trick is to see if there is a limitation on your I2C maximum length, and if so, write the I2C data in smaller 'chunks'. I know others have had this issue and solutions exist for lots of MCU's. 

I seem to remember one on this forum. So if you do have a limitation, google for a solution. You will find one.

- john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
John E KVAM
ST Employee

If your problem is at I2C long-write issue, try adapting this code to your device.

One example of how someone solved this problem for an Arduino platform is here:

VL53L5CX/src/platform.cpp at main · stm32duino/VL53L5CX · GitHub

have a look and take the while loop out of the uint8_t VL53L5CX::WrMulti() function.

- john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

When I see it right only WrByte and RdByte is called just before the first poll. So only short writes and reads are done.

But what I meanwhile found out is, with lower clock speed (10 kHz instead of 100 kHz) the first poll works. But then the next fails. Looks like the FT260 has problems to communicate with the VL53L5CX. It's time to connect the oscilloscope.

PBoer.1
Associate II

Solved!

Looking to the recorded data on the oscilloscope I saw that sometimes a byte was missing in the write sequence. Digging into the code I found the place responsible for this. Now it's working as expected.