ESP32 Bit Pirate

ESP32-S3 I2C protocol debugging

Scan I2C devices and read registers with ESP32

ESP32 Bit Pirate turns a compatible ESP32-S3 board into an I2C scanner and bus debugging workbench. Use it to find unknown addresses, read registers, open the dedicated EEPROM shell for 24XX/AT24C chips and recover common SDA/SCL lockups before writing target firmware.

Explore the ESP32 Bit Pirate site index Open the GitHub project
I2C bus debugging visual with an ESP32 board and target modules

Quick I2C workflow

Start with the smallest read-only checks. Once the bus responds, move to the recipe that matches the device or failure mode you are investigating.

  1. 01

    Connect GND, SDA and SCL.

  2. 02

    Start I2C mode on ESP32 Bit Pirate.

  3. 03

    Scan the bus to find responding 7-bit addresses.

  4. 04

    Identify the device or compare the address with the datasheet.

  5. 05

    Read known registers or open the EEPROM shell for 24XX/AT24C chips, then continue with a monitor or recovery recipe.

mode i2c
scan
identify 0x68
regs 0x68 16
eeprom 0x50

Example CLI flow. See the I2C wiki for exact syntax and firmware-specific options.

I2C workflows covered by ESP32 Bit Pirate

Use this overview to choose the right I2C workflow before opening a detailed recipe.

Scan

ESP32 I2C scanner

Find devices that acknowledge on an unknown I2C bus and use the detected 7-bit addresses as the first clue for deeper inspection.

Inspect

I2C register reader

Read known registers from sensors, RTCs, controllers and other I2C peripherals after the address and wiring are confirmed.

Dump

I2C EEPROM dump

Work with common 24XX / AT24C-style EEPROM devices through the dedicated eeprom [addr] shell, where chip probing, addressing width, page size and backup order matter before any write operation.

Recover

Stuck I2C bus recovery

Debug buses where a target holds SDA low, transactions hang, or a previous controller left the bus in a bad state.

Monitor

I2C traffic and register changes

Observe changing values over time and decide whether the problem is wiring, power, timing, address selection or device behavior.

Automate

Repeatable I2C checks

Move from manual serial debugging to repeatable checks when scans, reports or validation runs become part of a lab workflow.

When an ESP32-S3 I2C workbench helps

I2C debugging often starts before firmware integration. A small external tool can answer whether the bus is alive, which address responds and whether the target behaves like the expected part.

Unknown board

Before writing a driver

Use an external I2C scan and simple register reads to confirm power, ground, SDA, SCL and pull-ups before writing device-specific firmware.

Repair bench

Before modifying memory

For EEPROM work, the safe path is to scan the bus, open eeprom [addr], probe/analyze the chip and back up data before writes, erase actions or board-level experiments.

Bring-up

Before blaming software

Many I2C failures come from swapped SDA/SCL, missing common ground, weak pull-ups, wrong voltage levels or address format confusion.

I2C hardware reminders

These notes are intentionally short. The detailed command references live in the project documentation and firmware repository.

Pull-ups

SDA and SCL need pull-ups. Some modules already include them, while bare boards and EEPROM chips often depend on the surrounding circuit.

Voltage levels

ESP32 GPIO is 3.3 V; choose level adaptation before I2C tests on 1.8 V or 5 V hardware.

Address format

I2C scans usually report 7-bit addresses. Datasheets sometimes present shifted 8-bit read/write addresses.

Safe probing

Start read-only, confirm common ground, avoid powering unknown boards blindly and back up memory devices before writes.

Common I2C problems

Most I2C failures are electrical, addressing or bus-state problems. Check these before changing target firmware.

No address found

Check common ground, SDA/SCL order, pull-ups and target power.

Wrong address

Compare 7-bit scan results with datasheet addresses that may be shown as 8-bit read/write values.

Bus stuck low

Disconnect targets one by one, then try the I2C bus recovery workflow.

Unstable reads

Check pull-up strength, cable length, target voltage and whether another controller is driving the bus.

EEPROM dump fails

Confirm address pins, then use the EEPROM shell probe/analyze flow to verify page size, addressing width and read range before assuming the chip is dead.

Detailed I2C recipes

These pages are the task-level I2C workflows. This overview keeps the protocol-level guidance here, while each recipe covers wiring, commands and troubleshooting in detail.

Useful I2C references

This page is a protocol overview. Use the site index for the full web experience, or GitHub for source code, firmware documentation and the I2C command reference.

Flash ESP32 Bit Pirate

Flash a supported ESP32-S3 board before testing I2C mode from the browser.

Open Web Flasher

ESP32 Bit Pirate GitHub

Check firmware source, issues and releases that affect I2C support.

Open GitHub repository

I2C debugging FAQ

Short answers for common questions before moving into a detailed workflow.

Can ESP32 Bit Pirate scan an unknown I2C bus?

Yes. ESP32 Bit Pirate can scan a bus, show responding addresses and give you a starting point for device identification.

Can ESP32 Bit Pirate help with a stuck I2C bus?

Yes. Use the recovery-oriented I2C workflow when a target holds SDA low or a bus stops responding after a failed transaction.

Is ESP32 Bit Pirate only an I2C tool?

No. I2C is one part of the ecosystem. The same project also covers other wired buses, browser tools, firmware workflows and hardware documentation.