v4 USB-PD Failure Diagnosis (front-end datasheet review)

Ranked root-cause candidates for the v4 (0.4.0) PD failure, verified against the real netlist and the ST datasheets, plus a bench discrimination procedure for the dead v4 boards.

The v4 (0.4.0) board still fails USB-PD even though the v3 pin-18 bug is fixed and the NVM is programmed for 15 V. This page ranks root-cause candidates for the v4 failure from a datasheet-aware review of the USB-PD front end (usb-pd-input.kicad_sch), and gives a bench procedure that discriminates between the candidates on the dead v4 boards.

Method. Every connectivity claim below was generated from the real KiCad netlist (kicad-cli sch export netlist --format kicadxml, exported 2026-07-05 from this repo), never from symbol screen positions. Datasheet claims cite ST DS12499 Rev 4 (STUSB4500) and the ST USBLC6-2 datasheet; USB Type-C spec values are labeled for verification where the primary table could not be fetched.

The v4 symptom set collapses to one observable

Reported v4 symptoms: no PD negotiation, VBUS_EN_SNK never asserts, all rails dead.

The NVM on the v4 boards was programmed with POWER_ONLY_ABOVE_5V = 1 (see NVM Programming Setup). Per DS12499 Rev 4 Table 10 ("VBUS_EN_SNK pin behavior"), with POWER_ONLY_ABOVE_5V = 1b the VBUS_EN_SNK pin stays Hi-Z at 5 V even in Attached.SNK, and only asserts (open-drain pulls low) when VBUS operates under PDO2 or PDO3. VBUS_EN_SNK is active-low open-drain (DS12499 Table 1, pin 16): asserted = pulled low = Q1 P-FET on.

Therefore "VBUS_EN_SNK never asserts" and "rails dead" are the expected downstream consequences of a single failure: no 15 V contract is ever established (or never survives). The diagnosis only has to explain the missing/collapsing 15 V contract.

Verified front-end topology (from the 2026-07-05 netlist export)

Net table — USB-PD Input sheet (front-end nets)

Block diagram

Ranked root-cause candidates

1. External Rd in parallel with the powered chip's internal Rd — CC termination out of spec the moment U1 boots

Severity: blocker (design defect, present on every board). Symptom fit: high, charger-dependent.

Net evidence. Net-(J1-CC1) = J1.A5 D4.1 R17.1 with R17.2 on GND (5.1 kΩ), and Net-(U1-CC1) = D4.6 U1.2 — the external Rd and U1's CC1 pin sit on the same electrical node (through D4's flow-through). Same for CC2 via R18. CC1DB/CC2DB are grounded through R19/R20 (0 Ω), so dead-battery mode is disabled and the external resistors are the only termination while U1 is unpowered.

Datasheet basis. DS12499 Rev 4 §7.3 Table 22: the STUSB4500 presents Rd = 5.1 kΩ ±10% pull-down on the CC pins in operation (RINCC = 200 kΩ applies only with "Terminations off", i.e. during reset — §2.2.1 "CC1 and CC2 are HiZ during reset"). The STUSB4500 is an auto-run sink controller; internal Rd cannot be disabled by NVM. So once VBUS powers VDD (U1.24 is tied to VBUS_IN directly) and the chip loads its NVM (TLOAD = 30 ms, Table 22), the source sees 5.1 kΩ ∥ 5.1 kΩ ≈ 2.55 kΩ — below the USB Type-C sink Rd window of 5.1 kΩ ±20% (4.08–6.12 kΩ; verify against USB Type-C spec R2.0 §4.11.2 / Table 4-33). The v2 debug page itself computed this case and marked it "below spec" — see the re-examination section below.

Failure mechanism. Source-perspective CC detection windows (USB Type-C R2.0 Table 4-36 — values below reconstructed from implementation datasheets, e.g. onsemi FUSB3307 places its source-side Ra-vs-Rd comparator for 3 A Rp between 0.75 and 0.85 V; label: verify against the spec table):

Sequence on every cold plug: the unpowered board presents a clean 5.1 kΩ → the source debounces, attaches, applies vSafe5V → U1's VDD comes up, and ~30–50 ms later the internal Rd lands in parallel → the source's CC voltage drops by half, right when the source is about to send Source_Capabilities. A source whose comparator now reads "Rd removed / Ra" treats the sink as detached or invalid: it never negotiates, or removes VBUS — which unpowers U1, restores 5.1 kΩ, and re-attaches in a loop. Because 0.84 V sits inside a 100 mV undefined band, resistor and Rp tolerances make the outcome charger-dependent and even board-dependent — consistent with a design that fails across multiple revisions while looking "almost right".

Note the sink side is marginal too: U1's own attach threshold VTH0.2 (min CC voltage for a connected sink) is 0.15–0.25 V (Table 22), so on a default-Rp charger (0.20 V at the chip) even U1's source-detection is a coin flip.

Why v3's "stable 5 V + live I2C" does not contradict this. The programming sessions used USB-A-to-C or dumb 5 V chargers (per the NVM setup page), which supply VBUS without sink-detection gymnastics. The failure window only opens on a spec-compliant PD source.

2. D4 (USBLC6-2SC6) VBUS pin on the 15 V rail — absolute-rating violation at the exact moment a contract succeeds

Severity: blocker (hard datasheet violation). Symptom fit: high if negotiation ever completes; also explains permanently-dead boards afterward.

Net evidence. VBUS_IN = ... D4.5 ... — the USBLC6-2's VBUS pin (pin 5) sits directly on the receptacle VBUS rail, which carries 15 V after a successful contract.

Datasheet basis. ST USBLC6-2 datasheet (Rev 2 text verified; later revisions list 5.25 V): reverse stand-off voltage VRM = 5 V, breakdown VBR = 6 V min at 1 mA between VBUS and GND, clamping 12 V at 1 A (8/20 µs). The functional diagram (Figure 1) shows a zener between pin 5 (VBUS) and pin 2 (GND). This part is designed for 5 V USB — it is never rated for a 15 V rail.

Failure mechanism. The instant the source transitions VBUS to 15 V, D4's VBUS-GND zener goes into hard breakdown (15 V ≫ 6 V), sinking whatever the source can deliver (up to 3 A). The source hits overcurrent protection within ms and shuts down, hiccups, or hard-resets the port. On a DMM this reads as "no negotiation, rails dead" (see the warning above). Depending on the energy delivered, D4 dies short (VBUS_IN then loaded even at 5 V → the board looks completely dead on subsequent plugs) or survives to repeat the cycle. Boards already tested against a 15 V charger may therefore carry a damaged D4 right now — the bench procedure checks this first.

Note the interaction with candidate 1: if candidate 1 blocks negotiation on a given charger, 15 V never arrives and D4 survives — the two candidates mask each other, which is why the bench order below lifts D4 pin 5 before any test that could produce 15 V.

3. CC continuity through D4's internal flow-through — the netlist relies on a part-internal join

Severity: blocker if broken (as-built defect, not a schematic defect). Symptom fit: complete if present.

Net evidence. Net-(U1-CC1) = D4.6 U1.2 and Net-(U1-CC2) = D4.4 U1.4 — two-pin nets. The only path from connector CC to U1's CC pins runs through D4's package-internal pin 1↔6 and 3↔4 connections. The USBLC6-2 datasheet Figure 1 (functional diagram) does show pins 1/6 and 3/4 as internally common nodes (flow-through routing), so the schematic is electrically valid — but any substitution, rotation, or footprint mismatch at D4 silently opens both CC lines to the chip while leaving the connector-side external Rd intact.

Failure mechanism. With the flow-through open: the source still sees R17/R18 (connector side) → attaches → applies 5 V → U1 powers via VDD and I2C works — but U1's CC pins float, it never sees the source's BMC signaling, never answers Source_Capabilities, and the source falls back to Type-C 5 V-only. Every v3/v4 observation (stable 5 V, live I2C, no contract, VBUS_EN_SNK stays Hi-Z because POWER_ONLY_ABOVE_5V = 1) is reproduced exactly. The v2 boards measured 0 Ω across D4 pins 1↔6 (see PCBA v2 Debug Report), but v4 is a different assembly run — re-verify. (The as-built part-substitution audit is a separate task; here only the electrical validity and the bench check are in scope.)

4. NVM configuration on the failed boards — SNK_PDO_NUMB / POWER_ONLY_ABOVE_5V read-back

Severity: marginal (shapes symptoms rather than blocking PD). Symptom fit: partial but cheap to eliminate.

Evidence. Not a netlist item. The intended configuration is SNK_PDO_NUMB = 2, PDO2 = 15 V/3 A, POWER_ONLY_ABOVE_5V = 1 (NVM Programming Setup). Two failure shapes worth eliminating by read-back on the dead boards:

• The setup page itself warns POWER_ONLY_ABOVE_5V "sometimes doesn't save on the first write". Other bits can fail the same way. A partial write (e.g. SNK_PDO_NUMB still 1, or PDO2 voltage not 15 V) produces a sink that negotiates a 5 V-only PD contract — with POWER_ONLY_ABOVE_5V = 1 the result is symptom-identical to "no negotiation" on a DMM (VBUS_EN_SNK stays Hi-Z per DS12499 Table 10).

• VBUS monitoring windows (DS12499 §3.4.1, Table 22: VMONUSBH/VMONUSBL, default −20%/+15% at attach) are NVM-programmable; a corrupted shift coefficient could make the chip reject valid VBUS. Default values are safe — verify they are still default.

5. Re-confirmed items — verified OK in this pass (no action)

Re-examination of the v2 "CC1DB chip-internal short" conclusion

The entire external-Rd topology (candidate 1) exists because of the v2 diagnosis (PCBA v2 Debug Report): CC1 measured 0 Ω to GND on two boards, the empty pad measured open after hot-air removal of U1, and the conclusion was "CC1DB internally shorted — batch defect", fixed by grounding the DB pins and adding external Rd. Re-reading that evidence against DS12499:

What holds up. The asymmetry was real on those chips: CC2 (wired CC2DB↔CC2 in v2) measured 5.1 kΩ unpowered while CC1 measured 0 Ω, and removing U1 removed the short. Something genuinely differed between pin 1 and pin 5 on those two v2 chips.

What does not hold up.

• The 5.1 kΩ read on CC2 was not "chip-internal Rd works" as the v2 page says — an unpowered STUSB4500 presents no Rd on CC2 itself. What was measured was the dead-battery termination through CC2DB behaving exactly as designed (DS12499 §3.5: the DB path "presents a pull-down termination on its CC pins ... even if the device is not supplied").

• A dead-battery termination is an unpowered depletion-type pull-down, characterized only by its behavior at Rp currents (80–330 µA). Its small-signal resistance under a DMM's test current is not specified by ST — a low-ohms reading on an unpowered DB pin is not, by itself, proof of a defect. The v2 measurement never recorded DMM test polarity or current, never compared a known-good reference chip measured the same way, and never confirmed the "short" at operating conditions. "0 Ω" on an autoranging DMM can be anything below tens of ohms.

• Even granting a genuine CC1DB defect on that one LCSC batch, the v3 response traded an unproven single-batch defect for a permanent spec violation: the v2 page's own table computes "good chip + ext 5.1 kΩ → 2.55 kΩ — below spec" and even states the proper fix is to remove the external Rd once the chip's Rd is known healthy. The v3/v4 chips demonstrably run (I2C alive, NVM programmable), so their internal Rd is active, and 2.55 kΩ is the operating condition on every powered attach — candidate 1.

• DS12499 §3.5 says dead-battery mode "is also used in systems that are powered through the VBUS only" — i.e. ST's intended topology for exactly this board is CCxDB↔CCx with no external Rd (as used by the SparkFun board, STEVAL-ISC005V1, and datasheet Figure 10). For a VBUS-only sink, "ground the DB pins" (the no-dead-battery option) plus external Rd is structurally self-contradictory: the external Rd is mandatory for the unpowered attach, but out of spec the moment the chip runs.

Verdict: the v2 chips may or may not have been defective — the evidence is inconclusive — but the redesign built on that conclusion is itself a defect. The v5 fix should return to the ST reference wiring (CC1DB↔CC1, CC2DB↔CC2, no external Rd, optionally keeping DNP footprints for R17/R18 as rework insurance), pending the bench result of test B4 below.

Bench discrimination procedure (dead v4 boards, cheapest first)

Equipment: DMM with diode mode, fine probes, soldering iron + hot air, a scope (≥10 MHz is plenty for attach dynamics; CC BMC bursts just need to be seen, not decoded), the 15 V/3 A PD charger that failed, a USB-A-to-C cable, the NVM programming rig (NVM Programming Setup).

Stage A — unpowered continuity and damage survey (DMM only, 10 minutes)

Stage B — powered observation (USB-A-to-C first, then scope the PD attach)

B3 branch table (assuming the charger idles with 3 A Rp; scale by the table in candidate 1 for other Rp values):

Stage C — bodge tests (only after A/B, in this order)

What this pass can and cannot catch

This was a static netlist-plus-datasheet review. It can catch: wrong-net wiring, missing/parallel terminations, component ratings violated by design voltages, pin-role misunderstandings, and invalid bench tests. It cannot catch: as-built substitutions or rotations (only bench A1/A2 and the separate assembly-audit task can), solder defects, whether the NVM on the dead boards actually contains what the docs say it does (B2), actual charger behavior inside the CC undefined bands (implementation-specific by definition), chip authenticity, or dynamic/protocol-timing failures. The USB Type-C Table 4-36 window values above were cross-checked only against implementation datasheets, not the spec text itself — verify before treating a marginal reading as in- or out-of-window. Candidates 1 and 2 are verified defects; whether each is the defect that produced the observed v4 symptoms is exactly what Stages A–C decide.

References

• ST DS12499 Rev 4, STUSB4500 datasheet — Table 1 (pin list; pin 16 "active low"; pin 18 "From VBUS, receptacle side"), §2.2.1/§2.2.2 (CC HiZ during reset; DB warning), §3.4.1–3.4.3 + Table 10 (VBUS monitoring, discharge, VBUS_EN_SNK behavior vs POWER_ONLY_ABOVE_5V), §3.5 (dead-battery mode, VBUS-only systems), §7.3 Table 22 (Rd 5.1 kΩ ±10%, RINCC, VTH0.2, IDISUSB 50 mA via external resistor, VMONUSB, TLOAD) — st.com PDF

• ST USBLC6-2 datasheet — Table 3 (VRM 5 V, VBR 6 V min at 1 mA VBUS-GND, VCL 12 V at 1 A; later revisions list VRWM 5.25 V), Figure 1 (functional diagram: 1↔6 / 3↔4 flow-through, VBUS-GND zener) — st.com PDF

• USB Type-C Cable and Connector Specification R2.0 — §4.11.2 (Rd 5.1 kΩ ±20%), Table 4-36 (source-perspective CC windows; verify — reconstructed here via the onsemi FUSB3307/FUSB301 datasheets' source comparator bands)

• PCBA v2 Debug Report — the original CC1DB evidence re-examined above

• v3 USB-PD Failure Diagnosis — pin-18 root cause, fixed in v4 and re-confirmed here

• NVM Programming Setup — programmed values, read-back procedure

• STUSB4500 pinout guide — pin-by-pin reference