Unable to get a reading from a VL53L3CX sensor on Zephyr rtos

[jaachaparro]

Hello STM Community team:

I'm working  with a vl53l3cx sensor on a custom board with zephyr rtos but i am not able to get a reading.

To use the sensor I just modified the zephyr driver for the vl53l1x, on the .c file inside the driver I made the following changes:

1) added a VL53LX_MultiRangingData_t member in "struct vl53l3cx_data".

2) in function "_read_sensor" changed the "GetRangingMeasurementData" for GetMultiRangingData, using the new MultiRangingData_t member as argument.

3) in function "_channel_get", changed to get NumberOfObjectsFound instead of RangeMilliMeter.

4) Replace the VL53L1X API functions for the VL53L3CX API functions, as indicated on the UM2778.

the result is that the number of object found is always 0, this is independent of the distance mode . What I am doing wrong? Any suggestion to get the sensor made a reading.

Let me know if I can clarify anything, and thanks in advance for any help.

[Anne BIGOT]

Hello

Did you ask the same on the Zephyr community ?

There is for sure more than the modifications you did to be done. 
On Zephir pages, there is a log on the modifications done to move from L0 to L1 here

You can perhaps have a look if not already done,

Best regards

Anne

[jaachaparro]

Hi Anne.

No I haven't ask the zephyr community, and you are right, I made more changes than, I didn't think mention them are relevenat, like modifing the corresponding CMakeList.txt and Kconfig, adding the .yaml file, change the .h files inside drivers/sensor/vl53l1x etc etc. I have no problems binding the new st_vl53l3cx device to the device tree. Hence, no reason to ask the zephyr community, and because I didn't find someone with a problem similar to mine.

I don't think is a problem related to zephyr, but any  advice on how to make the sensor work woul be accepted

[Anne BIGOT]

Hello,

Can you please check your I2C communication is working well ?

Here an example of test to be tried :

  uint8_t byteData;
  uint16_t wordData;
  uint32_t DwordData;
  uint8_t test_buffer_write[14]={0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE};
  uint8_t test_buffer_read[14];

  VL53L1_RdByte(Dev, 0x010F, &byteData);
  printk("VL53L1X Model_ID: %02X\n\r", byteData);
  VL53L1_RdByte(Dev, 0x0110, &byteData);
  printk("VL53L1X Module_Type: %02X\n\r", byteData);
  VL53L1_RdWord(Dev, 0x010F, &wordData);
  printk("VL53L1X: %02X\n\r", wordData);

  VL53L1_WrWord(Dev, 0x0016, 0x5AA5);
  VL53L1_RdWord(Dev, 0x0016, &wordData);
  printk("Write 0x5AA5, read value: %02X\n\r", wordData);

  VL53L1_WrDWord(Dev, 0x0016, 0x5AA5AA55);
  VL53L1_RdDWord(Dev, 0x0016, &DwordData);
  printk("Write 0x5AA5AA55, read value: %02X\n\r", DwordData);


  VL53L1_WriteMulti(Dev, 0x0016, test_buffer_write,14);
  VL53L1_ReadMulti(Dev, 0x0016, test_buffer_read,14);
  printk("WriteMulti 14 byte: 0x112233445566778899AABBCCDDEE\n\r");
  printk("ReadMulti 0: %02X\n\r", test_buffer_read[0]);
  printk("ReadMulti 1: %02X\n\r", test_buffer_read[1]);
  printk("ReadMulti 2: %02X\n\r", test_buffer_read[2]);
  printk("ReadMulti 3: %02X\n\r", test_buffer_read[3]);
  printk("ReadMulti 4: %02X\n\r", test_buffer_read[4]);
  printk("ReadMulti 5: %02X\n\r", test_buffer_read[5]);
  printk("ReadMulti 6: %02X\n\r", test_buffer_read[6]);
  printk("ReadMulti 7: %02X\n\r", test_buffer_read[7]);
  printk("ReadMulti 8: %02X\n\r", test_buffer_read[8]);
  printk("ReadMulti 9: %02X\n\r", test_buffer_read[9]);
  printk("ReadMulti 10: %02X\n\r", test_buffer_read[10]);
  printk("ReadMulti 11: %02X\n\r", test_buffer_read[11]);
  printk("ReadMulti 12: %02X\n\r", test_buffer_read[12]);
  printk("ReadMulti 13: %02X\n\r", test_buffer_read[13]);

Below, the output you should see : 

Model_ID: EA
VL53L1X Module_Type: AA
VL53L1X: EAAA
Write 0x5AA5, read value: 5AA5
Write 0x5AA5AA55, read value: 5AA5AA55
WriteMulti 14 byte: 0x112233445566778899AABBCCDDEE
ReadMulti 0: 11
ReadMulti 1: 22
ReadMulti 2: 33
ReadMulti 3: 44
ReadMulti 4: 55
ReadMulti 5: 66
ReadMulti 6: 77
ReadMulti 7: 88
ReadMulti 8: 99
ReadMulti 9: AA
ReadMulti 10: BB
ReadMulti 11: CC
ReadMulti 12: DD
ReadMulti 13: EE

Hope this helps,

Anne

[jaachaparro]

Hi Anne

I tried the code, here is the result:

VL53L1X Model_ID: EA
VL53L1X Module_Type: AA
VL53L1X: EAAA
Write 0x5AA5, read value: 5AA5
Write 0x5AA5AA55, read value: 5AA5AA55
WriteMulti 14 byte: 0x112233445566778899AABBCCDDEE
ReadMulti 0: 11
ReadMulti 1: 22
ReadMulti 2: 33
ReadMulti 3: 44
ReadMulti 4: 55
ReadMulti 5: 66
ReadMulti 6: 77
ReadMulti 7: 88
ReadMulti 8: 19
ReadMulti 9: AA
ReadMulti 10: BB
ReadMulti 11: CC
ReadMulti 12: DD
ReadMulti 13: EE

[John E KVAM]

The 3 major problems with the i2C interface is byte-swap, word-swap or the inability to read multi-byte sequences. 

the issue with that test is that if there is a byte swap issue your write-word/read-word sequence will not find it if they are both wrong, but consitent with each other. 

I use a different test - which I like better. And it indicates what you should be getting.

This version is for the L4CD, but you can easily change the function calls for your L3.

I've also included an app-note, but I don't think it's an offical app note.

- john

[jaachaparro]

Hi John. I tried your code but don't see anything wrong in the output, but the previous one there is a 1 where a 9 is expected in the 9th reading (ReadMulti 8: 19 instead of ReadMulti 8: 99). here is the code output

expected = eacc10ff,
read_bytes = ea, aa, 10, ff
read words = eaaa, 10ff
read dword = eaaa10ff
expected = 11223344,
read_bytes = 11, 22, 33, 44
read words = 1122, 3344
read dword = 11223344
expected = 55667788,
read_bytes = 55, 66, 77, 88
read words = 5566, 7788
read dword = 55667788
expected = 11223344,
read_bytes = 11, 22, 33, 44
read words = 1122, 3344
read dword = 11223344

[John E KVAM · Accepted solution]

Ok - so the I2C works. I'll believe that. But you say you are using the Zephyr driver. As an employee of ST, I'm exclusively working with the STM32, but the code should run on the Zephyr. I've just not seen that driver. 

I'd try undoing the change to the channel_get funciton and see what happens. The debugging strategy here is to simply undo stuff until you get a working system then start applying your changes. 

It's all I can suggest.

- john