Why LLMs Hallucinate PCB Pin Numbers—and How to Stop It

A language model is not a component database

An LLM generates the next likely token from its context. It can reproduce many common pinouts and reason over supplied documents, but it does not inherently perform a database lookup keyed by exact manufacturer, orderable part number, package, and datasheet revision.

Pin tables are unusually hostile to approximate recall. One product family may have six packages. Pin 5 can be ground in one variant and an input in another. A module and its underlying IC may use similar names but completely different numbering. Manufacturers may publish a top-view pin diagram beside a bottom-view package drawing. A plausible answer assembled from these fragments can be wrong by one package, one revision, or one mirror operation.

Fluency makes the failure dangerous. The model may render a clean Markdown table, include believable alternate functions, and give a confident explanation. Formatting is not evidence.

Why pinouts trigger specific failure modes

Family names are ambiguous

Asking for “the pinout of the XYZ100” may omit the suffix that selects QFN-24, TSSOP-20, WLCSP, fixed-function, or automotive variants. Even when the logical functions match, physical numbers often do not. Use the exact MPN matching process before asking any pin question.

Tables and diagrams lose structure

Datasheet PDFs mix text, multi-column tables, vector drawings, footnotes, and repeated headers. Text extraction can reorder cells. An OCR process can drop bars over active-low names, confuse 0 with O, or detach a footnote that says a pin is package-specific.

View direction is easy to miss

A top-view pin diagram and bottom-view land pattern are mirror images. Humans make this error too. A model that sees cropped artwork without its caption may infer the wrong perspective while preserving a perfectly sequential numbering pattern.

Context rewards completion

When the prompt requests a complete table, a model is pushed toward filling gaps. Unless “unknown” is explicitly acceptable and the system is grounded to retrieved source text, it may interpolate missing rows from related parts.

Training data can be stale or secondary

Search snippets, hobby schematics, distributor listings, and old revisions can conflict. The most repeated answer is not necessarily the current manufacturer definition.

Establish a pin contract from primary evidence

Start with the manufacturer’s current product page and download the datasheet for the complete orderable part. Record:

manufacturer: "Example Semiconductor"
mpn: "ABC1234-QFN24-R"
datasheet_revision: "Rev 2.1, 2026-04"
package_code: "QFN24-4x4-0.5P"
pin_diagram_view: "top view"
package_drawing: "ABC-QFN24"
source_pages: [5, 42, 43]

Then transcribe the pin table with a source reference on every row or group:

Pad,Name,Type,RequiredConnection,SourcePage,ReviewedBy
1,VIN,power input,3.3 V rail,5,AB
2,EN,input,pull high through R3,5,AB
EP,GND,power,solid ground and thermal vias,43,AB

The values above are illustrative, not a real part. The important feature is provenance. A pin contract makes package, view, and source revision explicit, and it gives another reviewer a finite artifact to check.

For complex microcontrollers, include every power pin, ground pin, reset/boot pin, exposed pad, no-connect, reserved pin, and alternate-function decision. Do not collapse duplicate supply pins into one row.

Use the LLM as a checker with bounded evidence

If an LLM helps extract the table, supply the exact datasheet pages and ask it to return uncertainty rather than guess. A useful instruction is:

Use only the attached manufacturer pages. Identify package and view direction.
For each pad, return the printed name and page. If a cell is unreadable or
package-dependent, return UNKNOWN. Do not infer from related devices.

This reduces risk but does not constitute approval. Compare the result manually against both the pin-description table and package diagram. Two sections of the same primary document provide a stronger cross-check than two websites copying one another.

Ask a second reviewer to check the mapping without seeing the first reviewer’s conclusions. For high-pin-count parts, automate set comparisons, but still inspect semantic details such as active-low names, power domains, and DNC versus NC.

Verify the KiCad symbol and footprint separately

In Symbol Editor, check each symbol pin number, name, and electrical type against the contract. Multi-unit symbols and hidden power pins deserve special attention. In Footprint Editor, check each pad number, pin-1 marker, exposed pad, and package view against the mechanical drawing.

Then verify the bridge:

symbol pin 17 → net USB_D+ → footprint pad 17

The guide to symbols versus footprints explains why a correct-looking schematic and correct-looking land pattern can still map incorrectly.

Run ERC after the symbol review:

kicad-cli sch erc \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o build/erc.rpt \
  design.kicad_sch

ERC can catch unconnected power inputs or incompatible electrical types. It cannot know that the library author assigned VDD to pad 8 when the datasheet says pad 9. That is why the source-backed pin contract must precede ERC.

Treat these pins as high risk

Apply extra review to:

• exposed or centre pads, especially when unnumbered in one drawing;
• NC, DNC, reserved, and “do not connect” pins, which are not interchangeable;
• boot straps and mode pins sampled at reset;
• multiple analogue and digital supply domains;
• USB, Ethernet, LVDS, and differential polarity;
• connectors shown from mating face versus PCB face;
• BGAs whose alphanumeric grid omits letters such as I or O;
• package variants with depopulated pins;
• symbols split into several units with hidden power pins.

Use the layout-focused datasheet reading checklist to capture exposed-pad, keepout, and external-component requirements that a pin list alone misses.

Gate generated libraries before release

Store the pin contract, datasheet hash or archived revision, reviewer, and library commit with the project. Reject generated symbols with missing MPNs, ambiguous packages, or unsupported rows. Include the reviewed-library identity in the manufacturing gate.

The robust rule is not “never ask an LLM about pins.” It is “never accept an ungrounded pin number.” Let the model accelerate extraction, comparison, and review preparation. Let primary documentation and independent verification decide what reaches copper.