Vibecode a CAN Bus Node PCB with AI and Gate Checks Guide

MakeIRL's generator treats a CAN bus node prompt as a self-contained project board. Current status: in envelope needs block.

Low-speed logic and controller carrier may fit, but the catalog lacks verified CAN controller/transceiver/protection/termination blocks. It cannot infer automotive or industrial robustness.

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.

1. CAN 2.0/FD, bit rates, cable/topology, termination location, common-mode, connector and CAN_H/L/ground convention
2. MCU CAN capability or controller, exact transceiver/protection, standby/wake, isolation, oscillator, and firmware recovery
3. Supply and transients, enclosure, shield/ground, termination option control, mounting, test harness, and compliance context

Block plan:

• Cataloged controller/module with supported CAN peripheral or verified external controller
• Verified CAN transceiver/protection/termination block
• Verified connector and low-voltage protected power block

Interfaces: CAN controller logic, CAN_H/CAN_L field bus, GPIO standby/wake/status. Power plan: Low-voltage bench/SELV scope within 12 V/2 A; automotive load-dump or isolated power requires separate out-of-scope evidence.

• Keep transceiver and TVS at the connector, route the pair together over a return, minimize stubs, and separate bus surge return from logic reference.
• 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. Verify CAN_H/L/ground pinout, transceiver voltage and controller pins, oscillator need, termination DNP, TVS net/polarity, standby default, and connector view.
2. S1Catalog and exact-MPN provenance. Every CAN bus node 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.

• Review CAN variant, common mode, automotive/industrial transients, isolation, cable shield, termination topology, wake/sleep, EMC, and connector ecosystem.
• 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:

• A clean pair route cannot fix the wrong transceiver voltage, missing controller clock, incompatible CAN FD speed, or termination populated at the wrong node.
• 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:

• Test at target and edge bit rates over real cable, vary termination and ground offset, inject bus faults safely, verify wake/standby, and inspect error counters.
• 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.

• Refuse automotive safety/load-dump claims, mains/isolated power invention, unsupported CAN blocks, or missing bus/version data.
• A generic CAN request is not enough to choose controller, transceiver, protection, termination, or qualification.

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.