Has the Arduino Library for this sensor (SEN-18642) been tried with any of the ESP32 boards?
I have several SFE sensors where the included Arduino Library does not work with ESP32.
Dale
It should work fine; perhaps wipe the Arduino IDE folder https://support.arduino.cc/hc/en-us/art … rduino-IDE (or for whichever IDE you’re using) and re-install the board definitions/files https://learn.sparkfun.com/tutorials/es … ware-setup
I have ben able to run Example 4 Max output on my ESP 32 Thing Plus and see numbers change as I wave my hand in front of it.
I have not gotten the depth 3D depth program to run. My serial port is oddly named : /dev/cu.SLAB_USBtoUART does it need to be shortened or modified? When loading , I get the attached error messages.
I am trying to conceptualize what is supposed to happen here.
Are both Example 4 Max Output and 3D depth running at the same time with 3D Depth making calls to the Processing App?
Do the Processing App and routine need to be in certain locations in the computer?
Thanks, Mark
3D Map Error messages.txt (6.83 KB)
It certainly doesn’t seem to work on a NodeMCU 1.0 (ESP 12-E module) - specifically the KeeYees Development Board WiFi WLAN Wireless Module for ESP8266 for NodeMCU for ESP-12E. The same board runs a bunch of other things just fine, including an I2C AMG8833 IR Thermal Camera Breakout and other sensors. Tried Example1 and Example2 - all it does is restart endlessly (rst 2 or rst 3) after the message “Initializing sensor board…”
The same configuration also works fine with a VL53L1X / Qwiic. So it definitely seems like the VL53L5CX library does not work on some ESP configurations, perhaps because of the large firmware download.
It also works with the Artemis Thing Plus. But maybe that’s the only thing it works with?
TS-Russell:
It should work fine; perhaps wipe the Arduino IDE folder https://support.arduino.cc/hc/en-us/art … rduino-IDE (or for whichever IDE you’re using) and re-install the board definitions/files https://learn.sparkfun.com/tutorials/es … ware-setup
I’ve tried with a fresh install, I’ve confirmed that my setup is otherwise correct and working, and the VL53L5CX does work with an Artemis Thing Plus, but it doesn’t appear to work with a run-of-the-mill ESP-12E. What has actually been tested?
I’ve just been trying to bring up Example1_DistanceArray with a VL53L5CX (https://www.sparkfun.com/products/18642) on an ESP8266 (a Wemos D1 Mini Pro).
I get something similar, an endless loop with
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
The ExceptionDecoder tool gives me the stack trace below. It suggests that readMultipleBytes is somehow running off the end of its buffer, but I can’t see how that might happen.
Hope that helps! I’ll try a Teensy next.
Exception 3: LoadStoreError: Processor internal physical address or data error during load or store
PC: 0x40201524: SparkFun_VL53L5CX_IO::readMultipleBytes(unsigned short, unsigned char*, unsigned short) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_IO.cpp line 82
EXCVADDR: 0x4023b439
Decoding stack results
0x40201511: SparkFun_VL53L5CX_IO::readMultipleBytes(unsigned short, unsigned char*, unsigned short) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_IO.cpp line 82
0x40201460: SparkFun_VL53L5CX_IO::begin(unsigned char, TwoWire&) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_IO.cpp line 27
0x40201a26: _vl53l5cx_send_xtalk_data(VL53L5CX_Configuration*, uint8_t) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/vl53l5cx_api.cpp line 165
0x40202973: vl53l5cx_init(VL53L5CX_Configuration*) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/vl53l5cx_api.cpp line 318
0x40201438: SparkFun_VL53L5CX_IO::isConnected() at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_IO.cpp line 34
0x40201460: SparkFun_VL53L5CX_IO::begin(unsigned char, TwoWire&) at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_IO.cpp line 27
0x40202d54: Print::write(char const*) at /home/richard/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Print.h line 59
0x40201786: SparkFun_VL53L5CX::startRanging() at /home/richard/Arduino/libraries/SparkFun_VL53L5CX_Arduino_Library/src/SparkFun_VL53L5CX_Library.cpp line 220
0x40202fc8: Stream::readString() at /home/richard/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Stream.cpp line 248
0x402042c9: __pinMode(uint8_t, uint8_t) at /home/richard/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/core_esp8266_wiring_digital.cpp line 39
0x402010ab: setup() at /tmp/arduino_modified_sketch_534223/Example1_DistanceArray.ino line 41
0x40203634: user_rf_pre_init() at /home/richard/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/core_esp8266_phy.cpp line 353
0x40100db1: realloc(void*, size_t) at /home/richard/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/umm_malloc/umm_malloc.cpp line 1113
Since it looks like an issue between the library and ESP32, file an issue here https://github.com/sparkfun/SparkFun_Qw … 5CX/issues which will alert the engineer to the problem 
Thanks, done.
I do not have an ESP8266 board handy but I can suggest you a small attempt to lower the I2C buffer size and see if it works.
You can find it at SparkFun_VL53L5CX_Library_Constants.h on line 16. Try to decrease its size from 32 to 16 and see if the board boots.
I will try to get an ESP8266 board in this meantime and try it for myself.
Thanks for your support and patience,
Ricardo
Changing the I2C buffer size made no difference.
The failure occurs in vl53l5cx_init when it starts to upload the firmware at
status |= WrMulti(&(p_dev->platform), 0, (uint8_t *) &VL53L5CX_FIRMWARE[0], 0x8000 );
I suspect the problem is related to the firmware being declared PROGMEM.
On the Artemis Thing Plus, if I remove the PROGMEM keyword, it still compiles (haven’t tried to run it).
On the ESP, it will not compile without the PROGMEM keyword:
Arduino: 1.8.15 (Windows 10), Board: “NodeMCU 1.0 (ESP-12E Module), 80 MHz, Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for IRAM/PROGMEM, 4MB (FS:2MB OTA:~1019KB), 2, v2 Lower Memory, Disabled, None, Only Sketch, 115200”
c:/users/fried/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.0.4-gcc10.3-1757bed/bin/…/lib/gcc/xtensa-lx106-elf/10.3.0/…/…/…/…/xtensa-lx106-elf/bin/ld.exe: C:\Users\fried\AppData\Local\Temp\arduino_build_462093/Experiment.ino.elf section .rodata' will not fit in region dram0_0_seg’
c:/users/fried/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.0.4-gcc10.3-1757bed/bin/…/lib/gcc/xtensa-lx106-elf/10.3.0/…/…/…/…/xtensa-lx106-elf/bin/ld.exe: address 0x40005608 of C:\Users\fried\AppData\Local\Temp\arduino_build_462093/Experiment.ino.elf section .bss' is not within region dram0_0_seg’
c:/users/fried/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.0.4-gcc10.3-1757bed/bin/…/lib/gcc/xtensa-lx106-elf/10.3.0/…/…/…/…/xtensa-lx106-elf/bin/ld.exe: address 0x40005608 of C:\Users\fried\AppData\Local\Temp\arduino_build_462093/Experiment.ino.elf section .bss' is not within region dram0_0_seg’
collect2.exe: error: ld returned 1 exit status
exit status 1
Error compiling for board NodeMCU 1.0 (ESP-12E Module).
I wonder whether “Use pgm_read macros for IRAM/PROGMEM” is the clue…
With
With the default:
Tools → Non-32-Bit Access: Use pgm_read macros for IRAM/PROGMEM
it segfaults. With
Tools → Byte/Word access to IRAM/PROGME (very slow)
it seems to work, or at least it doesn’t segfault
It’s now working if you set Arduino IDE → Tools → “Byte/Word access to IRAM/PROGME (very slow)”
In addition, disable the software watchdog with ESP.wdtDisable() before if (myImager.begin() == false) and then re-enable it with ESP.wdtEnable(3000)
That’s exciting, thanks!
For what it’s worth, I tried that, got past the initial crash, but could not make my Wemos D1 Mini Pro detect the sensor.
I moved to a Teensy, where it worked fine.
Trying to run Example9_TwoSensors on an ESP32.
First, i always got this error: "“Sensor 2 not found. Check wiring. Freezing…”
In the example code,you are holding the second sensor in reset by pulling the RST pin to LOW and releasing it from reset by pulling the RST pin to HIGH, which is wrong. According to ST’s datasheet it has to be the other way round:
"I2C interface reset pin, active high. Toggle this
pin from 0 to 1, then back to 0 to reset the I2C
slave. Connect to GND via 47 kΩ resistor."
After fixing this, it still doesnt work. I now can connect to both sensors and get the data from the first sensor. But after the data from the first sensor is read, the isDataReady() function for the second sensor always returns FALSE.
I would guess it’s something in the library, but couldn’t find it yet.
Did someone else try this example?
I would appreciate your help. Thank you
friedmanwd:
It’s now working if you set Arduino IDE → Tools → “Byte/Word access to IRAM/PROGME (very slow)”In addition, disable the software watchdog with ESP.wdtDisable() before if (myImager.begin() == false) and then re-enable it with ESP.wdtEnable(3000)
Thank you for digging out this fix friedmanwd!
WeMos ESP8266MOD
I tried this using: Example1_DistanceArray. It worked fine.
Noting the disabling of the watchdog and that Example2_FastStartup stated it was able to do the transfer much quicker, I gave it a try. Theorizing that the quicker load might squeak by the watchdog. Still using the “(very slow)”, but leaving the watchdog disabling code out, it did not work. Trying with the myImager.setWireMaxPacketSize(128); exposed did not work either.
I returned to using Example1_DistanceArray and it FAILED. I had to disconnect the USB and close/reopen the Arduino IDE. Re-compiling again and it worked.
I’m hoping these comments help someone and/or will aide the library developer to improve their library.
Question: The watchdog disabling is no big deal. But what are the ramifications of using this: Byte/Word access to RAM/PROGMEM (very slow) option??? Does this imply significantly slower ESP8266 performance?
The “very slow” probably only applies to a subset of data memory accesses and is probably relative to normal memory access. So while it may slow data access, I haven’t noticed an impact on execution speed.
Note all this works fine on the ESP32 platform, without workaround, so if you have a choice pick that in preference to an ESP8266.