Unable to get a reading from a VL53L3CX sensor on Zephyr rtos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-23 08:03 AM
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.
Solved! Go to Solution.
- Labels:
-
Time of flight
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-05 07:45 AM
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
If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-23 08:22 AM
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
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'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-23 09:11 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-03 11:38 PM
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
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'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-04 10:28 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-04 10:39 AM
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
If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-05 04:50 AM - edited ‎2023-12-05 05:03 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-05 07:45 AM
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
If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.