I2C Bringup Diagnostician
Use this skill when the sensor or device should be on the bus, but the I2C path
is still not trustworthy.
Resources
references/bringup-flow.md - ordered I2C fault-isolation workflowreferences/scanner-vs-library.md - what to do when the scanner finds the device but the library still failsreferences/esp32-and-board-quirks.md - ESP32-family and board-specific caveats../../docs/board-support/uno-r4-family.md - Uno R4 family board notes when relevant
When to Use
Use this skill when the request includes:
- "no I2C devices found"
- scanner finds the address but the library cannot initialize the device
- two I2C devices conflict or one disappears
- ESP32 pin, bus, or second-channel confusion
- pull-up, wire-length, or voltage-level questions
- obviously wrong sensor values after basic detection succeeds
Workflow
- Establish the basic failure shape:
- no scanner detection -> open
references/bringup-flow.md
- scanner detects but library fails -> open
references/scanner-vs-library.md
- ESP32-family multi-bus or pin issue -> open
references/esp32-and-board-quirks.md
- Confirm the electrical basics before library swapping:
- power
- common ground
- SDA and SCL mapping
- pull-ups
- logic level compatibility
- Only after the bus is electrically plausible, check address, device mode, and
library expectations.
- If the board is Uno R4 family and the failure involves board-specific I2C or
support questions, also open
../../docs/board-support/uno-r4-family.md.
Core Rules
- Scanner success does not prove the library is using the device correctly.
- Library failure does not prove the sensor is dead.
- Bus voltage, pull-ups, and pin mapping must be explicit before changing code
blindly.
- For ESP32-family boards, pin choices and multi-bus assumptions are not always
portable across variants.
Verification
- Confirm whether the scanner sees the expected address.
- Confirm whether a minimal register or identification read works.
- Confirm whether the failing behavior tracks a board family, bus instance, or
library rather than the sensor alone.
- Confirm whether the final fix survives repeated scans and actual sensor reads.
Integration
- Pair with
circuit-debugger for deeper hardware isolation.
- Pair with
datasheet-interpreter when the correct address, power, or timing
details are not known.
- Pair with
arduino-code-generator when the user needs a minimal test sketch or
a cleaned-up bus probe.
Shared Output Contract
Use the shared Arduino skill contract:
state assumptions, required tools and versions, implementation steps,
tests/evidence by proof stage, known limitations, and recovery/security notes.
1---
2name: i2c-bringup-diagnostician
3description: Use when users need to diagnose I2C bring-up failures on Arduino or ESP32-class boards, including no devices found, wrong readings, address conflicts, scanner-detects-but-library-fails cases, pull-up problems, or board-family-specific bus quirks.
4metadata: {triggers: "I2C failure, address conflict, pull-up, scanner, bus bring-up"}
5---
6
7# I2C Bringup Diagnostician
8
9Use this skill when the sensor or device should be on the bus, but the I2C path
10is still not trustworthy.
11
12## Resources
13
14- `references/bringup-flow.md` - ordered I2C fault-isolation workflow
15- `references/scanner-vs-library.md` - what to do when the scanner finds the device but the library still fails
16- `references/esp32-and-board-quirks.md` - ESP32-family and board-specific caveats
17- `../../docs/board-support/uno-r4-family.md` - Uno R4 family board notes when relevant
18
19## When to Use
20
21Use this skill when the request includes:
22
23- "no I2C devices found"
24- scanner finds the address but the library cannot initialize the device
25- two I2C devices conflict or one disappears
26- ESP32 pin, bus, or second-channel confusion
27- pull-up, wire-length, or voltage-level questions
28- obviously wrong sensor values after basic detection succeeds
29
30## Workflow
31
321. Establish the basic failure shape:
33 - no scanner detection -> open `references/bringup-flow.md`
34 - scanner detects but library fails -> open
35 `references/scanner-vs-library.md`
36 - ESP32-family multi-bus or pin issue -> open
37 `references/esp32-and-board-quirks.md`
382. Confirm the electrical basics before library swapping:
39 - power
40 - common ground
41 - SDA and SCL mapping
42 - pull-ups
43 - logic level compatibility
443. Only after the bus is electrically plausible, check address, device mode, and
45 library expectations.
464. If the board is Uno R4 family and the failure involves board-specific I2C or
47 support questions, also open `../../docs/board-support/uno-r4-family.md`.
48
49## Core Rules
50
51- Scanner success does not prove the library is using the device correctly.
52- Library failure does not prove the sensor is dead.
53- Bus voltage, pull-ups, and pin mapping must be explicit before changing code
54 blindly.
55- For ESP32-family boards, pin choices and multi-bus assumptions are not always
56 portable across variants.
57
58## Verification
59
60- Confirm whether the scanner sees the expected address.
61- Confirm whether a minimal register or identification read works.
62- Confirm whether the failing behavior tracks a board family, bus instance, or
63 library rather than the sensor alone.
64- Confirm whether the final fix survives repeated scans and actual sensor reads.
65
66## Integration
67
68- Pair with `circuit-debugger` for deeper hardware isolation.
69- Pair with `datasheet-interpreter` when the correct address, power, or timing
70 details are not known.
71- Pair with `arduino-code-generator` when the user needs a minimal test sketch or
72 a cleaned-up bus probe.
73
74## Shared Output Contract
75
76Use [the shared Arduino skill contract](../../docs/arduino-skill-contract.md):
77state assumptions, required tools and versions, implementation steps,
78tests/evidence by proof stage, known limitations, and recovery/security notes.
wedsamuel1230