MPU9250 I2C fails with escalating WHOAMI→no-ACK pattern, only power cycle recovers it
Setup: STM32F446RE Nucleo + MPU9250 (I2C1, PB8=SCL/PB9=SDA), breadboard wiring, HAL library, 100kHz standard mode.
Symptom progression: Sensor works intermittently. When it fails, I see two distinct failure signatures that seem to escalate:
- First failure mode:
HAL_I2C_IsDeviceReady()succeeds (device ACKs its address) but the WHOAMI register read returns the wrong value. - After a couple of MCU resets without touching hardware: escalates to the device not ACKing its address at all (
IsDeviceReadyfails outright).
What I've tried:
- Implemented the STM32 I2C "clear busy flag erratum" workaround (ST-documented fix for the analog filter/BUSY-flag lockup bug — the 15-step GPIO bit-bang + SWRST sequence). This did NOT reliably fix it — worked on some boots, failed on others, no clear pattern.
- A full power cycle (not just MCU reset — actual power removal) temporarily restores it to working.
- Reseated all breadboard connections (SDA, SCL, VCC, GND) multiple times — no change in behavior.
What this rules out (I think): Since a software/peripheral reset (MCU reset via erratum routine) doesn't consistently recover it, but a full power cycle does, this doesn't look like a pure STM32-peripheral-side busy-flag glitch. It looks more like either (a) the MPU9250 itself is getting into a bad internal state that only its own power-on-reset clears, or (b) a marginal physical connection whose state happens to change with power cycling but not with reseating alone.
What I haven't yet done: Haven't scoped SCL/SDA on a logic analyzer specifically at the moment of a WHOAMI-fail or ADDRESS-fail event (only during the erratum routine itself, not during actual failure). Haven't checked VCC stability at the sensor pins during failure. Haven't tried moving the sensor off breadboard entirely (direct soldered wires) to rule out contact resistance.
Question: Given a failure signature that degrades from "wrong data, valid ACK" to "no ACK at all" across resets, and that's only cleared by a full power cycle (not MCU reset, not reseating connections) — what's the most likely root cause, and what's the fastest way to conclusively isolate it (MPU9250 fault vs. bus/power fault vs. breadboard contact)?
