SPI-only ESP32-C3 halts on I2C initialization during boot

[Feather-P]

Running an LSM6DSV over SPI on an ESP32-C3. No I2C sensors are defined in the build.

Issue

The board hangs during boot. After tracing the startup logs, I found that it gets stuck in the global I2C reset/initialization path in setup():

• I2CSCAN::clearBus()
• Wire.begin()

From the nearby comment, this code appears to be a workaround for the ESP32-C3 sometimes having its only I2C interface already open for an unknown reason:

// For some unknown reason the I2C seem to be open on ESP32-C3 by default. Let's
// just close it before opening it again. (The ESP32-C3 only has 1 I2C.)

Since this board is not wired for I2C, the initialization path fails or hangs. This seems inconsistent with the bus-aware configuration already supported later by DIRECT_SPI and SensorBuilder.

There is also a FIXME in the codebase that appears to describe the similar problem:

FIXME fix the I2C Scanner so it use the sensor list and not be called when no I2C sensor

Local patch

For now, I am guarding the boot-time I2C calls by checking whether valid I2C pins are configured:

if (PIN_IMU_SDA != 255 && PIN_IMU_SCL != 255) {
    // I2C clear/init logic
}

I have had to add similar checks around several I2C-related calls, not just I2CSCAN::clearBus().

This gets the board through startup, but repeating the same pin check in multiple places feels more like a workaround than a proper fix.

Fix, maybe

I think the startup logic should derive its behavior from the generated sensor configuration rather than assuming that I2C is always present.

1. Gate the I2C startup path

The preprocessor could generate a simple flag such as HAS_I2C_SENSORS from the configured sensor list.

The early startup path could then be gated explicitly:

#if HAS_I2C_SENSORS
    I2CSCAN::clearBus(PIN_IMU_SDA, PIN_IMU_SCL);
    Wire.begin(PIN_IMU_SDA, PIN_IMU_SCL);
#endif

The exact implementation does not necessarily need to use a preprocessor flag, but the decision should ideally come from the same sensor topology represented by SENSOR_DESC_LIST.

2. Make the shared SPI configurable

On the ESP32-C3, routing SPI to non-default pins requires calling SPIClass::begin() with explicit pins:

SPI.begin(sck, miso, mosi, -1);

I currently handle this locally by adding DIRECT_SPI_PINS(...) and passing explicit SCK, MISO and MOSI values into DirectSPIInterface.

Would it make sense to formalize the shared SPI bus pins as board-level definitions, similar to the existing I2C definitions?

PIN_IMU_SCK
PIN_IMU_MISO
PIN_IMU_MOSI

Unused pins could default to 255, as PIN_IMU_SDA and PIN_IMU_SCL already do.

SCK, MISO and MOSI belong to the shared SPI bus, while chip select is specific to each sensor. The current model already passes the CS pin through the accessInterface field of sensorDescEntry(), which also allows different SPI sensors to use different CS pins.

I have the I2C guards and explicit SPI pin handling working locally. 0v0

I am not strongly attached to a particular implementation. If this direction fits the intended architecture, I can clean up the changes and submit a PR. :3

[unlogisch04]

Thats sounds for me more like 2 separate issues (the one with SPI Pins and the other with no i2c pins)

Be aware that:
For now the current guideline is "we're banning all ai-generated code in slimevr. use of ai for debugging, research and questions is allowed. copying code produced by AI is not."

1. No I2C Sensor configured:
   I think even the clearbus could move away from main.h setup. And done during SensorManager. (i did not think trough it) so it clears all the used I2C pins (if there are more than 1). The easy option is to just guard it, and make sure that i2c scan does not get launched.
   Also i have some corrections on ESP32 for i2c scan fix i2c scann stalling on ESP32* boards #538

2. The Additional pins where left out because at the time the HW did not have routing for this SPI pins.
   If you want add the option, it would need to integrate with the https://github.com/SlimeVR/SlimeVR-Tracker-ESP/blob/main/board-defaults.schema.json so it is defined in https://github.com/SlimeVR/SlimeVR-Tracker-ESP/blob/main/board-defaults.json and forwarded in https://github.com/SlimeVR/SlimeVR-Tracker-ESP/blob/main/scripts/preprocessor.py
   If you cant do that you can prepare it. But the behavior without the pins should stay the same.
   For SPI generally you only need to change the CS pin for each module. To have additional a second full SPI Port does probably not make much sense?

[Feather-P]

Thanks, I understand the intended separation now.

I have opened #539 for the configurable SPI bus pin changes, The PR also currently includes this double-free fix.

Although DirectSPIInterface previously stored the SPI instance as an SPIClass&, the interface cache was instantiated as:

 SensorInterface<DirectSPIInterface, SPIClass, SPISettings>

This caused the cache’s get(Args... args) path to copy the global SPIClass object. The reference stored by DirectSPIInterface could then refer to that temporary copy rather than the original global instance, resulting in duplicated ownership of internal SPI resources and a heap double-free.

The PR changes the cache argument from SPIClass to SPIClass* and changes DirectSPIInterface from storing a reference to storing a non-owning pointer. The cache therefore copies only the pointer, while the interface continues to operate on the original global SPI instance.

I included this fix in the same SPI branch because it affects the same initialization path, but I am not sure whether you would prefer it to remain in this PR or be submitted separately. I can split it into another PR if needed.

I’ll clean up the I2C-related changes and submit them separately later.