Problem description:
We are seeing a hard I2C bus lockup involving an ISM330 IMU and an IIS2MDC magnetometer on the same bus.
The failure mode is that SDA is driven low permanently, and the bus cannot be recovered by standard I2C recovery procedures (9–20 SCL pulses with SDA released).
This occurs both immediately after MCU firmware is flashed and during nominal runtime, seemingly at random.
Once the condition occurs, a full MCU reset does not recover the bus. On a bench setup we confirmed by probing that SDA is physically held low.
Hardware configuration:
MCU: STM32 acting as I2C master
Devices on bus:
- ISM330 (IMU)
- IIS2MDC (magnetometer)
These are the only slaves on the bus.
Standard I2C pull-ups are used, with no level shifting.
I've done additional testing to try to find the problematic device by removing devices and reconfiguring connections (auxiliary I2C), see results below.
Observed behavior by configuration:
- ISM330 only on I2C: no issues
- ISM330 and IIS2MDC directly on MCU I2C: SDA eventually stuck low and not recoverable
- IIS2MDC only on I2C: no issues
- ISM330 and IIS2MDC via auxiliary I2C (SDx and SCx): same failure occurs, but sometimes recoverable by clocking
During failure, probing shows both main SDA and SDx (when using auxiliary I2C) are held low
In the direct-connection case, forced SCL clocking (9–20 pulses) does not release SDA.
In the auxiliary I2C case, forced clocking sometimes recovers the bus, but the fault still occurs.
Key observation:
- Based on the testing, having the combination of both devices directly on the I2C bus causes lock up.
- Neither of the devices alone ever locks up the bus.
- When both devices are present, the bus can be locked up until devices are power cycles.
Questions for ST engineering:
- Is IIS2MDC known to hold SDA low under any fault condition such as mid-transaction reset, brownout, internal state machine stall, or clock stretching related issues?
- What exactly does the ISM330 sensor hub do on SDx when a downstream slave is stuck? Does it actively generate clocks, reset the I2C state machine, or tri-state the SDx line?
- Is auxiliary I2C expected to be more tolerant of a misbehaving slave than direct I2C connection?
- Is there a documented or recommended recovery sequence, such as register writes, reset commands, or power cycling order, to force IIS2MDC to release SDA once it is stuck?
