I2C access hanging after firmware upload; since certain esp-hal commit

[lure23]

Out of the esp-hal releases:

• 0.22.0 works
• 0.23.{01} don't

Symptoms

Running the tof/vl53l5cx_uld example gets stuck in the middle of an I2C write, if code >= commit f9203dc523e4b8fe6e6312ec18bb924453f2f7a6 (21-Nov-24) is used. This effectively means, I cannot develop the library for the particular sensor, other than by remaining on version 0.22.0.

When working ok:

# in `ZOO/tof/vl53l5cx_uld`:
$ FEATURES=esp-hal-0_22 DEFMT_LOG=trace make -f Makefile.dev m3
[...]
18.323900 [INFO ] Init succeeded
[...]
19.058630 [INFO ] .reflectance:      [[[0, 42, 59, 90], [0, 14, 69, 86], [4, 11, 37, 80], [5, 4, 21, 79]], [[0, 0, 0, 0], [0, 0, 0, 0], [7, 5, 0, 0], [0, 9, 16, 0]]]
[...]
19.122374 [INFO ] End of ULD demo

That's a successful run. The device firmware gets initialized, some data is collected, and the whole hardware is shut down.

When NOT working:

# in `ZOO/tof/vl53l5cx_uld`:
$ FEATURES=esp-hal-0_22 DEFMT_LOG=trace make -f Makefile.dev m3
[...]
18.323900 [INFO ] Init succeeded
18.323981 [TRACE] Writing: 0x7fff <- [0x00]

Execution stops (within esp-hal method), and never resumes. very strange?

Requirements

Unfortunately, to replicate one needs to have a VL53L5CX distance sensor, and wire it to the devkit. I have some of these around, so can send to a person if there's a need and it'd help understand the problem.

• ESP32-C6 devkit (I'm using ESP32-C6-DevKitM-1)
• VL53L5CX SATEL board
• some wiring
• Ubuntu Linux

Steps

1. Set up the ZOO repo

2. $ cd tof/vl53l5cx_uld

3. Check the README and a) install clang, bindgen CLIs, b) download the vendor ULD C library.

4. build & run

   $ FEATURES=esp-hal-0_22 DEFMT_LOG=trace make -f Makefile.dev m3
   ...
   

To compile for:

0.22 API	FEATURES=esp-hal-0_22 as shown
0.23 API (released versions)	use no FEATURES
latest main	use FEATURES=esp-hal-next

Also, you'll likely need to fiddle with the Cargo.toml to get the right versions.

Analysis

I really don't know why the firmware writes (and reads) are perfectly fine and reliable, but the first thing after them either fails, or succeeds, only based on the version of esp-hal I'm using.

I'd expect an error of some sort, from esp-hal. That it simply freezes seems something... I'm not currently able to explain.

I found the culprit commit by using git bisect. Will next have a look at the changes within it.

[lure23]

Studied the effects of logging policy in detail here. It's a fork of bjoernQs repo on VL sensor usage.

The implications likely are:

• supporting C3 only for the tof/vl* subprojects
• turning to use espflash on them