ESP32 Development

Treat the board, attached circuit, firmware, and host toolchain as one system. An ESP32 task is complete only when the intended behavior is observed at the hardware boundary, not when compilation or flashing alone succeeds.

Operating contract

1. Identify the exact board, SoC family, module, flash/PSRAM size, USB transport, power source, and board revision. Do not transfer a pin map between ESP32, S2, S3, C2, C3, C5, C6, H2, or P4 variants.
2. Read the board schematic or pinout, the matching SoC/module datasheet, and every attached component datasheet before choosing pins or voltage levels.
3. Start with read-only host and USB discovery. Opening a serial monitor may toggle DTR/RTS and reset the target; use a no-reset option when the running state matters.
4. Choose one framework based on the product constraint. Reuse its project generator, examples, drivers, build system, flasher, monitor, and debugger before writing wrappers.
5. Bring up one layer at a time: power and boot, serial log, one GPIO, one bus, bus scan or loopback, device identity register, raw readings, calibration, then application behavior.
6. Before the first flash or hardware mutation, confirm the target port, chip family, image/partition layout, rollback or reflashing path, and electrical safety. Never guess a flash offset.
7. Preserve calibration controls for real sensors, clocks, ADCs, PWM devices, and actuators. Physical variation is expected.

Pre-response evidence gate

Complete this gate before drafting a non-trivial plan or recommendation: