Electronics Design AUI2C bus scan finding nothing — NACK on every address despite pull-ups
Asked by stale_biscuit_03 ·
Working through my first proper I2C project — hooking up a BME280 temp/humidity sensor to an ESP32 devkit. Wired SDA to GPIO21 and SCL to GPIO22 (the defaults), added 4.7 kΩ pull-up resistors to 3.3V on both lines, sensor VCC and GND connected.
Running a standard I2C scanner sketch and it comes back blank. Not "wrong address" — genuinely nothing on the bus, NACK on every address from 0x01 to 0x7F.
Things I've tried:
- 100 kHz and 400 kHz clock speeds
- Confirmed 3.3V on the sensor with a multimeter
- Swapped to a second BME280 module in case the first was dead
- Checked the GPIO pin numbers three times
Both modules behave exactly the same way, which makes me think it's something in my setup rather than a faulty part. No logic analyser available to see what's actually on the lines. Anyone been through this?
3 Replies
Most likely the address pin.
BME280 has an SDO pin (sometimes labelled ADDR) that sets the least-significant bit of the I2C address. Pull it to GND: device answers at 0x76. Pull it to VDDIO: device answers at 0x77. Leave it floating: undefined — the scanner won't find it at either address because the device itself doesn't know which one it should respond to.
Breakout boards vary. Some tie SDO to GND by default, some leave it unconnected. The datasheet treats it as a logic input, not a default-low pin, so you can't assume. Measure the voltage at that pin and find out what your board actually does.
Second thing to check: bus idle state. With power on, SDA and SCL should both sit at around 3.3V at rest. If either is stuck low, you have a bus lockup — leftover from a previous incomplete transaction. Best fix at this stage is a full power cycle of everything on the bus. There's a software workaround (manually toggle SCL nine times to release a stuck device) but power cycling is simpler and more reliable when you don't yet know what's locked.
If I2C addressing is still fuzzy, our I2C explainer covers how the ACK/NACK signalling works and where the 7-bit address comes from — worth reading alongside this.
The 4.7 kΩ pull-ups at 100 kHz on short wires are fine. That's not your problem.
Systematic check if you want to eliminate variables one at a time:
- Measure idle voltage on SDA and SCL with a multimeter, power on, before running any scan. Both should read ~3.3V. Anything significantly below that is a bus lockup or a short — diagnose that before touching the sensor wiring.
- Verify address pin logic level directly — measure the voltage at the SDO/ADDR pin on the sensor itself, not where you think the trace goes. Floating can read as either level depending on parasitic capacitance and varies between power cycles.
- Drop the scan clock to 50 kHz. More tolerant of higher bus capacitance and marginal rise times than 100 kHz.
- Plug in a different known-good I2C device (an SSD1306 OLED, any sensor you've used before) on the same wiring. If that shows up at its expected address, the bus and GPIO configuration are ruled out. If it also disappears, the problem is upstream of any sensor.
Step 4 is worth doing early — rules out an entire category of issue before you start changing sensor-side things.
One physical thing worth knowing for breadboard setups: if your pull-up resistors are placed far from the MCU end (i.e. long jumper wires before the resistors), you can get extra capacitance on those lines that slows down rise times. At 100 kHz it's rarely dramatic enough to cause complete silence — you'd usually see intermittent NACKs or corrupted data rather than nothing at all — but dropping to 50 kHz as whateverlol88 suggests does help flush this out if it's a factor.
Also worth a quick check: are SDA and SCL on separate breadboard rows from anything switching quickly nearby? I2C is reasonably noise-tolerant but the pull-up resistors are not strong drivers — a noisy rail running alongside can confuse things in ways that look like addressing problems.
The fact that two separate modules behave identically does point to the setup rather than the sensors, which soggy_waffle42 has covered well. Address pin is the one to nail down first.
Related Discussions
SPI reads all returning 0xFF — logic analyser shows MISO activity, W25Q32 not responding to commands
Been staring at this one for a day and a half. I'm trying to read the JEDEC ID from a W25Q32JV SPI flash chip on a custom STM32L432 board. T
STM32F401 UART printing garbage after switching to 84 MHz PLL — same 115200 baud in CubeMX and PuTTY
Got a WeAct Black Pill (STM32F401CCU6) project that's been running happily on the default HSI clock at 16 MHz. Using USART1 on PA9/PA10 thro
STM32 USB not detected by Windows after jumping to bootloader mode
Working on a custom STM32F411 board, trying to jump into the built-in USB DFU bootloader from application code instead of holding BOOT0 on p