hilink: record module-input voltage measurement and set the next physical gate

devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md

@@ -17,6 +17,14 @@ USB 2.0 EHCI port (`Sstar-ehci-1`).
   high-speed negotiation on this board.
 - **Verified on hardware (2026-10, Piotr):** changing the input supply
   capacity did not improve negotiation. Supply-headroom tuning is ruled out.
+- **Verified on hardware (2026-10, Piotr):** the radio is a custom
+  carrier/module assembly, **not** a drop-in USB dongle: a four-wire host
+  harness/pad connection, two RF pigtails, and visible local regulation on
+  the carrier.
+- **Verified on hardware (2026-10, Piotr):** 5.13 V measured directly at the
+  module input, inside the common 4.75–5.25 V input range. The earlier
+  "3.3 V fed into the 5 V input" hypothesis is therefore ruled out **at
+  module ingress** (upstream of the carrier's local regulation).
 - RF/FEC configuration is not a USB fix and is out of scope for this issue.
 - This document contains no credentials, pairing or RF-access material.
 
@@ -29,13 +37,19 @@ remaining software-adjacent candidates that are cheap to test:
 
 - **Ruled out:** wifibroadcast/OpenIPC configuration, RF/FEC settings,
   ordinary userspace timing, a simple USB-device rebind, a full
-  HCD/UTMI re-initialization (done on hardware, no change), and
+  HCD/UTMI re-initialization (done on hardware, no change),
-  input-supply-capacity tuning (done on hardware, no change).
+  input-supply-capacity tuning (done on hardware, no change), and
+  wrong-voltage-at-module-ingress (measured 5.13 V at the input, within the
+  4.75–5.25 V range).
 - **Remaining fault domain:** the USB **high-speed physical path / signal
-  integrity / rework** — D+/D− routing and symmetry, controlled impedance
+  integrity / rework** — D+/D− routing and symmetry across the carrier,
-  and stubs, series/ESD components on the pair, connector and solder
+  harness/pads and intervening components, controlled impedance and stubs,
+  series/ESD/common-mode components on the pair, connector and solder
   integrity, or PHY-side / device-side silicon-level hardware — exactly the
-  boundary detailed in the hardware section below.
+  boundary detailed in the hardware section below. The supply findings above
+  rule out only those two specific points: power **quality** downstream of
+  the measured input — supply noise/ripple and the carrier's local regulator
+  output — remains untested and stays inside this open fault domain.
 
 Two caveats stay attached to this classification: it does not prove that
 every conceivable undocumented analog register in the vendor PHY block is
@@ -43,6 +57,10 @@ irrelevant (the audited paths cover what the shipped source programs, not
 the full register space), and it does **not** claim any high-speed success —
 the fault is unresolved; only its domain is now sharply bounded.
 
+Operating posture while the fault stands: keep the existing
+4096 kbit/s limit appropriate to full-speed operation; do not raise it on
+the assumption of high-speed throughput until HS is actually demonstrated.
+
 ## Audited sources
 
 Audited 2026-10-02. Everything the firmware ships is stock upstream of this
@@ -205,37 +223,61 @@ All tuning is compile-time; there are no runtime knobs in this repo.
 
 ## HiLink D+/D- hardware / rework investigation boundary
 
+Assembly as observed (2026-10, Piotr): the radio is a custom
+carrier/module — not a drop-in dongle — connected to the host by a
+**four-wire harness/pad** connection, with **two RF pigtails** and visible
+**local regulation** on the carrier. The pad assignments have **not** been
+documented yet; nothing below assumes one.
+
 With the software and software-adjacent candidates ruled out (see the
 conclusion above), the remaining fault domain is the USB **high-speed
 physical path / signal integrity / rework**, explicitly outside software
 scope:
 
-- D+/D- pair routing on the HiLink carrier: continuity and symmetry from the
+- D+/D- pair routing on the HiLink carrier and through the four-wire
-  SSC338Q pads to the module socket; controlled impedance along the pair;
+  harness: continuity and symmetry from the SSC338Q pads to the module
-  stubs or test points hanging off it; series resistors / ESD protection
+  pads; controlled impedance along the pair; stubs or test points hanging
-  parts on the pair; connector and solder joint integrity.
+  off it; series resistors / ESD protection / common-mode chokes or other
+  intervening components; via, connector/harness and solder joint integrity.
 - HS chirp failure with FS working is the classic marginal-analog signature:
   the same pair carries FS traffic fine while the HS chirp (a short,
   amplitude-critical burst at reset) is missed by the host squelch detector.
-- Concrete next hardware diagnostics, cheapest first (1-2 need the port or
-  module to be reachable — the radio is a directly attached module, so this
-  may mean a rework socket or a piggyback cable):
-  1. Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same
-     port. HS on the disk but not on the radio points at the
-     module/device side; FS on both points at the board-side pair.
-  2. Try the **same RTL8812EU module on a different known-good HS host**
-     (a PC). HS there isolates the fault to this board's physical path.
-  3. Measure D+/D- continuity and symmetry against the SSC338Q pads, and
-     inspect series/ESD parts and connector solder under magnification.
-  4. With suitable equipment, capture the HS chirp amplitude/eye at the
-     host-side connector against the USB 2.0 electrical limits.
-- Any board rework (series resistor changes, pair shortening, shielding)
-  invalidates prior software observations; re-verify from the on-device
-  commands below after any hardware change.
 
-Evidence status: the platform-driver re-probe (step 5 below) and the
+**Next physical gate (before any rework):**
-input-supply-capacity change were performed on hardware (2026-10, Piotr) —
+
-both completed with no improvement, recorded above. The register-read
+1. **Macro photographs of both sides** of the carrier/module.
+2. **Identify all four host pads** — determine which are VBUS, GND, D+,
+   D- (the four-wire harness implies the classic set, but the actual
+   assignment must come from tracing, not assumption).
+3. **Trace D+/D- end to end**, identifying every intervening component —
+   series resistors, ESD arrays, common-mode chokes, vias, connectors,
+   harness wires — and where the pair leaves the board.
+
+**Safety rule for all continuity/ohmmeter work:** only with **all power
+removed and rails discharged** (unplug, then verify the rails are at 0 V
+before touching meter probes to pads). No powered measurements are proposed
+at this stage.
+
+Further isolation diagnostics, only **after** the gate above (all of them
+need rework access — the radio is pad-connected, not socketed, so this may
+mean a temporary rework socket or piggyback harness):
+
+- Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same
+  host pads. HS on the disk but not on the radio points at the
+  carrier/module side; FS on both points at the board-side pair.
+- Try the **RTL8812EU carrier on a different known-good HS host** (a PC).
+  HS there isolates the fault to this board's physical path.
+- With suitable equipment, capture the HS chirp amplitude/eye at the host
+  pads against the USB 2.0 electrical limits.
+
+Any board rework (series resistor changes, pair shortening, shielding)
+invalidates prior software observations; re-verify from the on-device
+commands below after any hardware change.
+
+Evidence status: the platform-driver re-probe (step 5 below), the
+input-supply-capacity change, and the module-input voltage measurement were
+performed on hardware (2026-10, Piotr) — none improved negotiation, and the
+ingress voltage is in range; all recorded above. The register-read
 diagnostics (steps 1-4 below) have not been reported yet; no HS negotiation
 has been observed at any point, and this document does not claim any.
 
@@ -272,8 +314,8 @@ number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1`
    devmem 0x1F284880 8                     # UHC+0x40 bit7: 0x00/0x80
    ```
    Expected if healthy: bit7 clear. If bit7 is set, a previous enumeration
-   failure latched FS; replug the module (root-hub reinit clears it) and
+   failure latched FS; disconnect/reconnect the module's power (the
-   repeat.
+   root-hub reinit on disconnect clears it) and repeat.
 3. **Port / line state** (all UHC0 = EHCI bank, `hcd->ehc_base`; bit
    semantics as used by the driver: `hub.c:4998` enable=bit2, `urb.c:532`
    connect=bit0, `message.c:88` csc=bit1, `hub.c:5801-5802` line state)