Skip to main content
The EVCore D1 revision 0.9 hardware handoff defines the current design direction for the diagnostic brick. It is a requirements and design-intent document, not a reviewed schematic or netlist. The PCB developer remains open to hardware changes, and the firmware treats the baseline as provisional while keeping pin assignments and electrical assumptions explicit.

​
Design authority and change policy

Use this handoff as the hardware baseline while recognizing that the PCB developer is open to changes. Keep any change explicit and explain its firmware impact. Do not silently change MCU family, pin assignments, or electrical assumptions. The document contains tasks directed at the PCB engineer, such as layout reviews and fabrication deliverables. Those are source requirements, not instructions to modify PCB files or order boards.

​
Document-grounded baseline

​
Source ambiguities to retain

  • Section 13 selects USB4105-GF-A and explicitly supersedes the Amphenol 12402012E212A; the archived component table on p. 7 still lists Amphenol. Use USB4105-GF-A as the current baseline, while allowing a reviewed change.
  • The p. 7 ADuM4160 row is labeled “Isolated USB to UART/SPI”. That label alone does not establish a UART/SPI bridge or USB firmware stack. Confirm actual topology and functions from the corrected schematic or device documentation.
  • The p. 10 reference table ties MCU ground and some output returns to HV_BAT_NEG, while sections 8, 13, 14, and 22 leave grounding/isolation open. Do not adopt that reference connection as a final grounding decision.
  • Section 19 is an archived HV prototype purchasing/research BOM, not a mandate to install every module. It cannot override the normal 24 V instrument-power architecture or establish final ADC/shunt scaling.
  • Resistors listed for dividers, output current limits, LM317 current, comparator thresholds, and AD8226 gains are explicitly provisional; none become firmware constants in this review.

​
Firmware gaps exposed by the handoff

  1. External energy versus commanded OFF: off_confirmed currently checks Brick output state. It does not independently prove absence of DUT battery voltage or motor-generated voltage. hv_conflict exists as a logical input, but a fresh, operation-specific board permission is needed for every relevant route transition and current-source enable. Tests must inject external voltage before starting, while waiting for routing, and between measurements.
  2. Shutdown ordering: fault handling must remove excitation independently of measurement-relay movement. The correct response when external voltage is present (which contacts may safely open or change) needs explicit board approval. A blanket command to open every relay is not proof of compliance with the document’s hot-switch restriction.
  3. Passive phase observation: the current back-EMF demo reuses the generic switched-route test runner. That is only a simulation. The physical design calls for independent protected phase sensing, so passive acquisition should not require switching Kelvin contacts under back-EMF.
  4. Master relay meaning: the document describes a master Kelvin-current relay. The generic EV_OUT_MASTER bit appears in sensor-power demo masks too. Do not map it blindly to that relay. Distinguish logical output permission, sensor power switching, and the physical current-source master in the board adapter.
  5. Kelvin route meaning: four distinct logical IDs in the current Kelvin checker are lead identifiers, not four different motor phases. FORCE and SENSE leads may terminate on the same physical phase; the 13-relay mapping needs a phase/polarity/path model before implementing a board driver.
  6. Analog completeness: add gain-path metadata, sample saturation handling, actual stimulus current, reference health and calibration identity. A direct simulated resistance value does not exercise AD8226/ADS1115 acquisition.
  7. Control completeness: local and USB APIs still need voltage-mode, termination, adapter-ID, per-channel acquisition/calibration, and hardware-latch operations where implemented. Unsupported capability must remain explicit.
These are tracked design and implementation gaps, not claimed fixes. This review does not change firmware behavior or reinterpret passing host tests as hardware proof.

​
Next hardware and firmware interface decisions

Specify logical signals and capabilities first: power-good, STOP, latch arm/clear and status, external voltage validity and switching permission, independent rail faults, master-current enable/feedback, phase and Kelvin paths, gain and ADC selection, USB role and isolation, bus modes and termination, adapter detection, display and encoder. For each, record direction, safe state, validity and freshness, failure response, and whether permission is enforced independently in hardware. Pins, polarities, thresholds and deadlines stay unresolved until supplied or approved.