I keep seeing Pi Zero + MPU-9250 threads where SDA/SCL look right and i2cdetect is empty — or the GPIO dies after a 5V VCC.
Pi GPIO is 3.3V tolerant. Even if the breakout has a regulator, feed VCC from Pin 1 (3.3V), not Pin 2/4 (5V), unless you have confirmed the I2C lines are shifted.
Full pin table and photos (Korean):
https://sunshout.tistory.com/2204
Wiring that actually enumerates
| MPU-9250 | Pi Zero | Physical |
|---|---|---|
| VCC | 3.3V | Pin 1 |
| GND | GND | Pin 6 |
| SDA | GPIO2 / SDA1 | Pin 3 |
| SCL | GPIO3 / SCL1 | Pin 5 |
Leave EDA/ECL/AD0/INT alone for a first bring-up.
Then:
sudo raspi-config # Interface Options → I2C → Enable
sudo reboot
sudo apt install -y i2c-tools
i2cdetect -y 1
You want 0x68. The AK8963 mag on the same package may also show 0x0c.
How to read the grid
- Empty bus: power, Dupont, or I2C not enabled. Almost never
smbus/ Python. - 0x69: AD0 is high. Either tie AD0 to GND or use 0x69 in software.
- UU: a kernel driver already claimed the address. Unload it before userspace.
- 0x68 present, values garbage: supply ripple or a 5V-fed module with unshifted SDA. Check 3.3V at the module under load. A random LM2596 next to a VTX will do this — I use a UBEC for companion Pi power (notes).
If you wanted fused quaternions without running a Kalman filter on the Zero, that is a different part (BNO085, SH-2 on the package): https://sunshout.tistory.com/2205
I do not want the Pi doing fusion while it is also a flight-controller companion.
If your grid shows UU or 0x69, say which — those two are different bugs.
