i2c device not detected? The 7-step checklist
An i2c device that won't answer fails for a short list of reasons, and they're cheap to check in the right order. Work down this list — most buses come back to life by step 4.
1. Swap SDA and SCL
The single most common fault, and free to test. Labels lie, especially on bare modules and dupont-wire rigs — and note that Gravity and Grove order their pins differently from Qwiic. Cross the two data wires and rescan.
2. Verify power at the device
Measure VCC-to-GND at the breakout, not at the host. A wrong rail (3.3 V board fed nothing because the jumper selects 5 V), a broken cable crimp, or a shared ground that isn't actually shared all read as "device missing." Anything below the chip's minimum in the datasheet counts as off.
3. Run a proper scan
Don't debug your application code and the wiring at the same time — a scanner takes the driver out of the equation. If the scan sees the device, your wiring is fine and the problem is software: wrong address in the constructor, wrong bus number, wrong driver.
4. Check the pull-ups
No pull-up resistors, no bus — the lines can never return high. Most breakouts include them, but bare chips, some clone modules and long chains (where parallel pull-ups combine below the 1 kΩ floor) all break the rule. 4.7 kΩ from SDA and SCL to the bus voltage is the fix and the test.
5. Confirm the address
The device may be alive at a different address than your code expects: an address-select jumper, a variant chip, or a datasheet quoting the 8-bit form. The scan from step 3 tells you where it actually lives; the address list tells you what that address usually is. Two devices claiming the same address? That's the conflict guide.
6. Check the voltage story
A 5 V host talking to a 3.3 V-only device can work "sort of" before it fails — or damage the device outright. Confirm each end's logic level and put a level shifter between mismatched rails; the compatibility checker flags exactly when a given connector pairing needs one.
7. Simplify, slow down, then look at the wire
Strip the bus to one device on a short cable and drop the clock to 100 kHz or lower. If that works, add pieces back until it breaks — you've found the culprit (often cable length or a clock-stretching device; see clock stretching if the host is a Pi). And when nothing above explains it, stop guessing: a $10 logic analyzer shows the actual waveform — missing ACKs, lazy edges and stretch events are all obvious on screen.
Questions
Troubleshooting FAQ
i2cdetect shows nothing at all — most likely cause?
Swapped SDA/SCL or missing pull-up resistors. Those two account for the majority of dead buses. Swap the data lines first (it's harmless), then check that something on the bus provides pull-ups.
My device works on Arduino but not on Raspberry Pi. Why?
Three Pi-specific suspects: the i2c interface isn't enabled, the sensor relies on clock stretching (the Pi's hardware controller mishandles it), or the sensor is 5 V-only while the Pi is strictly 3.3 V. Enable the bus, then try lowering the baudrate to test the stretching theory.
The device appears in a scan but reads return garbage or zeros.
Presence without sane data usually means marginal signal quality (pull-ups too weak for the wire length), a wrong register map (BMP280 driver talking to a BME280, for example), or voltage levels at the edge of tolerance. A logic analyzer shows which in one capture.
It works for a while, then drops off the bus.
Think power and heat: brownouts from a weak supply reset devices mid-transaction, long cables pick up noise, and some sensors go unresponsive after an error until power-cycled. Shorten the chain, fatten the supply, and add a retry-with-bus-reset in software.