What this error means
For each net, ERC collects the electrical type of every pin. A pin typed Input requires a driver: at least one pin on the same net whose type is Output, Bidirectional, Tri-state, Power output, or Passive. If the net has an input pin and none of those, the check fails. A no-connect flag anywhere on the net suppresses it.
Two details follow directly from that list. Open collector and open emitter are not in it, so a line driven only by an open-collector pin fails even though the circuit is fine. And Passive is in it, so any resistor or connector pin on the net counts as a driver.
This check covers ordinary signal nets only. If the net contains a
Power input pin anywhere, the stricter power rule applies (only
Power output drives it) and failures are reported as
power_pin_not_driven instead. Only one marker is placed per undriven
net, so one fix can silence several input pins.
Common causes
1. The net does not actually reach its driver
The most common case. The output that should drive this input exists
on the schematic, but a label typo (EN vs EN1), a wire that stops
short of the pin, or a bus member that was never unfolded splits the
net in two. The half with the input pin has no driver, and ERC is
reporting a real wiring bug.
2. The driving pin's electrical type is wrong in the symbol
Hand-drawn and third-party library symbols often type every pin Input or Unspecified. ERC decides purely on the declared electrical type, not on what the part actually does, so a real driver with a mistyped pin does not count.
3. The line is driven by an open-collector or open-emitter pin
Those two types are deliberately not counted as drivers, because an open-collector line floats unless something pulls it up. If the pull-up is inside the receiving chip, on a different net, or nowhere yet, the error fires.
How to fix it
Trace the net and reconnect it to its driver
- Hover the flagged pin and press the highlight-net key (backtick) to see how far the net really extends.
- If the highlight stops before the driving pin, look for a label typo, a wire ending one grid step short, or a bus member that was never unfolded to a wire.
- Reconnect or rename until driver and input light up together, then re-run ERC (Inspect → Electrical Rules Checker).
Use when: The driver exists on the schematic. If the highlighted net is smaller than you expected, this is your case.
Fix the pin's electrical type in the symbol
- Right-click the symbol whose pin really drives the net → Edit Symbol.
- Double-click the driving pin and set Electrical type to Output (or Bidirectional / Tri-state, whatever the datasheet says).
- Save, update the symbol in the schematic, and re-run ERC.
Use when: The net is one piece but every pin on it is typed Input, Passive-less connector, or Unspecified. Only edit symbols you maintain; for unmodifiable third-party symbols, excluding the individual violation is the lesser evil.
Put the pull-up on the same net as the open-collector line
- Place the pull-up resistor and wire one leg directly to the flagged net.
- Re-run ERC; a Passive pin counts as a driver, so the resistor clears the error.
Use when: An open-collector or open-drain output drives the line. The resistor the circuit needs anyway is also what satisfies ERC, provided it is wired to this net and not to a lookalike label.
When it’s safe to exclude
Rarely, and almost never in bulk. The one honest case is a third-party symbol whose output pin is mistyped Input and which you must keep bit-identical to the vendor library. Exclude that single marker (right-click the marker → Exclude this violation) rather than downgrading the check in Schematic Setup → Electrical Rules → Violation Severity; downgrading hides the split-net case, a genuine wiring bug that produces no other error. An input pin that is intentionally unused wants a no-connect flag (press Q), not an exclusion; the flag documents the intent and suppresses this check.
Gotchas
- Passive counts as a driver. Any resistor on the net satisfies this check, so an input that floats behind a series resistor passes ERC without comment. The check guards pin types, not your bias network.
- A completely unconnected input pin trips both
pin_not_connectedand this error: two markers, one floating pin. Fixing the connection clears both; excluding one of them clears half your problem. - If any pin on the net is typed Power input, the net is judged by the
stricter power rule and the report shows
power_pin_not_driveninstead. Retyping a pin can therefore move the error, not remove it.
Minimal reproduction
Wire two Input pins together with nothing else on the net and run ERC. The net reports:
[pin_not_driven]: Input pin not driven by any Output pins
; error
The checked-in file data/erc/samples/pin_not_driven.kicad_sch
reproduces this with two embedded one-pin input symbols sharing a net.
Because the file embeds its own symbols, ERC also emits two
lib_symbol_issues warnings about the missing repro library; those
are an artifact of the self-contained repro, not part of this error.
Retyping either pin to Output — or to Passive, the pull-up case — drops
the error count to zero, which is the fix in miniature.
Related errors
- Input Power pin not driven by any Output Power pins
- Pin not connected
- Conflict problem between pins (reference page coming soon)
FAQ
Why is the input pin 'not driven' when it's connected to an open-collector output?
KiCad only counts Output, Bidirectional, Tri-state, Power output, and Passive pins as drivers, and open collector is deliberately not on the list because the line floats without a pull-up. Wire the pull-up resistor to the same net and the error clears, since a Passive pin counts as a driver.
The pin is connected through a bus. Why does ERC still say it isn't driven?
Bus members connect through the labels on the wires at each end; the bus line and its 45-degree entries are graphical. A typo in one member label, or a pin wired to the bus without a label, leaves the input's net separate from the driver's net. Highlight the net at the flagged pin to see where the connection actually stops.
Can I drop a PWR_FLAG on the net to clear the error?
It works mechanically, because PWR_FLAG carries a Power output pin and that type counts as a driver. On a signal net it is still the wrong tool: it asserts "power originates here" on a logic line and hides whatever left the net undriven. Fix the connection or the pin type; keep PWR_FLAG for power rails.