makeIRLPCB engineering field guide

Vibecode AI hardware guides

Generate an RP2350 Carrier Board with AI: Scope and Gates

Plan a future RP2350 carrier only from an exact package and verified flash, power, clock, USB, boot and security block; current V2 cannot invent or validate it.

Practical PCB integration · KiCad 9 · Manufacturing gate

Vibecoding a RP2350 carrier: what the generator can and cannot do

MakeIRL's generator treats a RP2350 carrier prompt as a module carrier. Current status: refused.

RP2350 has no catalog block and package variants can introduce dense fan-out and security/boot complexity. It is outside the current checked demo and may exceed two-layer rules.

Refuse the RP2350 bare-chip carrier. Consider a future complete module carrier after exact module connector, power, boot, and low-speed interface evidence is verified.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

What the prompt must specify

  1. Exact RP2350 package/variant and revision, boot/security mode, external flash, clock, USB, debug, GPIO banks, firmware, and lifecycle
  2. All rails/decoupling, current, package escape, stackup/vias, flash/clock constraints, USB, ESD, and thermal behavior
  3. Module versus bare chip, outline, connectors, mounting, assembly/X-ray, programming/recovery, test fixture, and verification ladder

Block plan:

  • No bare RP2350 block today
  • Possible future verified complete RP2350 module carrier
  • Bare-chip package, flash, clock, USB, security, and fan-out require a dedicated physically verified block

Interfaces: USB Full-Speed when verified, debug/programming, low-speed GPIO/I²C/UART/SPI. Power plan: Unknown until exact package/module is selected; no power design can be inferred from the family name.

Layout priorities and gate checks

  • Package escape, flash/clock, decoupling, USB return, debug, and security/boot pins must be co-designed from the exact variant.
  • Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

  1. S1Generated connectivity and schematic parity. Current output is refusal. Future checks need exact package/ball map, all rails, flash/clock, USB, boot/security, debug, and assembly stackup evidence.
  2. S1Catalog and exact-MPN provenance. Every RP2350 carrier block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
  3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

Human review, failure modes, and validation

  • Review primary RP2350 documentation, silicon/package revisions, boot/security policy, flash/clock, SI/PI, assembly, firmware recovery, and physical validation.
  • A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

  • Treating RP2350 as a drop-in RP2040 update can miss different packages, pins, power, boot/security, and layout constraints.
  • ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

  • A future block needs physical boot/flash/clock, USB, debug/recovery, all rails, GPIO banks, security mode, current, thermal, and lot-to-lot evidence.
  • Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

Refusal boundary and generator envelope

  • Refuse bare RP2350, unknown package/variant, dense BGA/HDI, or unverified security/boot design.
  • Do not reuse RP2040 blocks or claims merely because the product families are related.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.

Generate a gated candidate, not a blind board

Try a RP2350 carrier prompt in the generator and review every gated artifact before ordering.

Generate a carrier board