INA219 Current Measurement Audit

P

piero789

AUDIT AND FIX ONLY THE PCB ROUTING AROUND Q2 INPUT REVERSE-POLARITY PROTECTION.
Context: The schematic has just been corrected:
  • Q2:D -> VIN_FUSED
  • Q2:S -> VIN_PROTECTED
  • Q2:G -> VIN_GATE
  • D6:K -> VIN_PROTECTED
  • D6:A -> VIN_GATE
  • R5 from VIN_GATE to GND
  • R6 between VIN_PROTECTED and VIN_GATE
Task:
  1. Review the PCB layout only around Q2, F2, D3, D6, R5, R6, C7, FB2, and the nets VIN_RAW, VIN_FUSED, VIN_PROTECTED, VIN_GATE, GND.
  2. Remove any stale traces caused by the Q2 source/drain swap.
  3. Reroute Q2 input-protection traces so the physical PCB matches the corrected schematic.
  4. Keep the current protection sequence: J1 P1 -> F2 -> VIN_FUSED -> Q2 -> VIN_PROTECTED -> D3/C7/FB2 -> VIN_FILTERED.
  5. Keep Q2, D3, C7, and FB2 routing reasonably short and direct.
  6. Do not modify ESP32, relay, INA219, buck output, RELAY_OUT, or dry-contact nets.
  7. Do not perform a full board redesign yet.
After fixing:
  • Run DRC.
  • Confirm there are no airwires in the Q2/F2/D3/D6/R5/R6/C7/FB2 input-protection area.
  • Confirm there are no dangling traces in the Q2 input-protection area.
  • Report the exact physical routing path from J1 P1 to U1 VIN after the fix.
  • Confirm again that reverse-polarity input cannot energize VIN_PROTECTED or 5V.

flux

I've made a plan and started work on it.

Started implementing a plan

#Goal

- Audit and fix the PCB routing around the Q2 input reverse-polarity protection stage based on the schematic correction, concentrating only on Q2, F2, D3, D6, R5, R6, C7, FB2 and nets VIN_RAW, VIN_FUSED, VIN_PROTECTED, VIN_GATE, and GND. The goal is to remove stale traces from the Q2 source/drain reversal and reroute the protected input path so that it physically follows the path: J1 P1 -> F2 -> VIN_FUSED -> Q2 -> VIN_PROTECTED -> D3/C7/FB2 -> VIN_FILTERED, while ensuring the routing remains short and direct without impacting other nets (ESP32, relay, INA219, buck output, RELAY_OUT, dry-contact).

#Implementation plan

1. **Audit and Cleanup**

1. Inspect the existing PCB layout in the Q2 input reverse-polarity area to identify stale traces and artifacts from the old Q2 source/drain swap.

2. Remove or sever stale traces that connect the Q2 source/drain paths from previous routing.

2. **Reroute Input-Protected Path**

1. Reroute the protected input path to ensure the physical trace follows: J1 P1 -> F2 -> VIN_FUSED -> Q2 -> VIN_PROTECTED -> D3/C7/FB2 -> VIN_FILTERED.

2. Maintain a short and direct routing while connecting the nets correctly.

3. Preserve the integrity of other nets and components including ESP32, relay, INA219, buck output, RELAY_OUT, and dry-contact.

3. **DRC Verification and Reporting**

1. Run a targeted Design Rule Check (DRC) focusing on the audited area to ensure clearance and connectivity rules are met.

2. Document and report the exact physical routing path and confirm that the reverse-polarity protection works as intended (i.e. reverse-polarity does not pass through VIN_PROTECTED into the remainder of the circuit).

#Success criteria

- All stale traces from the Q2 source/drain swap are removed without affecting other board areas.

- The physical routing path exactly follows J1 P1 -> F2 -> VIN_FUSED -> Q2 -> VIN_PROTECTED -> D3/C7/FB2 -> VIN_FILTERED, ensuring short and direct routing.

- DRC reports no violations in the scoped area and confirm reverse-polarity behavior as expected.

- The protected input path prevents undesired conduction during reverse polarity events.

Task unable to complete.

2:13

Thought for 16 sec — Identifying necessary skills
Looking up PCB routing cleanup stale traces Q2 reverse polari....
Checking 5 design areas.
Reading schematic details for J1, F2, Q2 and 7 more.
Completed 5 design checks — found 39 issues.
Checking 5 design areas... (28 sec)
Reading layout details for Q2, F2, D3 and 5 more.

flux

Work done
  • Audited the scoped Q2 input-protection area and verified the corrected schematic connectivity.
  • DRC still reports scoped layout problems: VIN_FUSED airwire between F2:P2 and Q2:D, VIN_PROTECTED airwires involving Q2:S, D6:K, and R6:P2, plus stale/dangling trace remnants and an overlap at Q2:D.
  • Created the detailed status file: Q2 Input Protection Routing Remediation Status.
Success criteria review
  • ❌ Stale traces were identified but not removed in this run.
  • ❌ The physical path is not yet fully routed as J1 P1 -> F2 -> VIN_FUSED -> Q2 -> VIN_PROTECTED -> D3/C7/FB2 -> VIN_FILTERED.
  • ❌ DRC is not clean in the scoped area; airwires/dangling/overlap issues remain.
  • ✅ The corrected schematic topology still supports reverse-polarity blocking, but the PCB must be cleaned/rerouted before fabrication.
Next steps
Perform the physical trace cleanup/reroute in the PCB editor for the listed scoped items, then rerun DRC to confirm the Q2 input-protection area is clear.
Locate routing issues
Fix Q2 remnants
Route VIN_PROTECTED
Run targeted DRC
Sign up to send

Files

Schematic

Layout

Preview

U2
U6
R3
Resistance
4.7kΩ
R4
Resistance
4.7kΩ
RSHUNT
Resistance
0.22 Ω
R5
Resistance
100kΩ
R6
Resistance
100kΩ
R1
Resistance
1kΩ
FB2
C5
Capacitance
100nF
RELAY_OUT
D3
D2
J1
C3
Capacitance
100nF
C4
Capacitance
100nF
C7
Capacitance
100nF
D1
Q1
K1
L1
Inductance
68uH
D6
Q2
C2
Capacitance
100uF
R2
Resistance
10kΩ
F2
C1
Capacitance
100uF
U1
ESP32 DevKit Power Interface Back-Power Audit
Date: 2026-05-11
Scope: Audit only. No schematic, PCB, component, net, or layout changes were made.
Project: 12-24 -> esp controller
Summary
Result: FAIL
Back-power risk level: HIGH
The carrier PCB 5V rail is directly connected to the ESP32 DevKit EXT_5V / 5V pin through net 5V. No jumper, diode, ideal-diode/load-switch, fuse, removable link, or other isolation element was found between the buck 5V output and the DevKit 5V input. Because the DevKit physically includes onboard USB, this creates a credible bidirectional 5V back-power conflict whenever DevKit USB and carrier-board 5V are used at the same time or in opposite power states.
Evidence from schematic
1. PCB 5V directly connected to ESP32 DevKit 5V/EXT_5V
PASS / confirmed direct connection.
Schematic net 5V contains:
  • U2:EXT_5V
  • L1:2 — buck output after inductor
  • U1:FEEDBACK
  • C2:1 — output bulk capacitor positive
  • C4:P1 — output 100nF bypass capacitor
  • D1:cathode — relay flyback diode high side
  • U6:IN+
  • RSHUNT:P1
So the buck-derived regulated 5V rail and the ESP32 DevKit external 5V pin are the same electrical node.
2. Isolation / removable link between BUCK_5V and ESP32_EXT_5V
FAIL.
No series isolation component was found between the buck output and U2:EXT_5V. Specifically, there is no detected:
  • jumper
  • solder bridge
  • diode
  • ideal-diode controller
  • load switch
  • fuse / PPTC
  • ferrite bead
  • zero-ohm resistor
  • removable link
D2 is not in the ESP32 5V feed path. D2 is on BUCK_SW as the LM2596 catch diode path, with D2:Cathode on BUCK_SW and D2:Anode on GND.
Back-power scenarios
3. USB plugged into DevKit while PCB 5V rail is also powered
Risk: HIGH.
Since U2:EXT_5V is directly tied to the carrier 5V rail, if the DevKit USB 5V is internally connected to the DevKit 5V rail, current can flow between the USB 5V source and the carrier buck 5V rail. The project schematic contains no carrier-side element to prevent that interaction.
4. PCB power off, USB connected to DevKit
Risk: HIGH.
If DevKit USB energizes the DevKit 5V rail, it can also energize carrier net 5V through U2:EXT_5V. That means the carrier-side 5V net can be back-powered, including these loads/branches:
  • C2 output bulk capacitor
  • C4 100nF capacitor
  • U1:FEEDBACK
  • U6:IN+
  • relay-coil high side through RSHUNT:P1 -> RSHUNT -> RELAY_COIL_HIGH_SENSE -> K1:A1
  • relay flyback diode high side at D1:cathode
Whether the relay actually actuates depends on the low-side transistor drive state, but the carrier 5V copper and connected loads can become energized.
5. PCB 5V on, USB connected to PC
Risk: HIGH.
If the carrier buck is powered and the DevKit USB is connected to a PC, the carrier 5V net can drive into the DevKit EXT_5V pin. If the DevKit board does not fully isolate USB VBUS from the 5V header path, this can back-feed the PC USB port. The carrier PCB currently provides no isolation to prevent that condition.
Exact schematic paths
Carrier buck 5V to ESP32 DevKit
U1:OUTPUT -> BUCK_SW -> L1:1 -> L1 -> L1:2 -> 5V -> U2:EXT_5V
The same 5V node also connects to U1:FEEDBACK, C2:1, C4:P1, U6:IN+, RSHUNT:P1, and D1:cathode.
ESP32 DevKit ground to carrier ground
U2:GND1 / U2:GND2 / U2:GND3 -> GND
Carrier GND also includes U1:GROUND, U1:GND_TAB, C2:2, C4:P2, J1:P2, D2:Anode, U6:GND, and other board returns.
PCB/layout observations
The layout data confirms U2 is placed on the PCB and has an EXT_5V pad, but no separate series part exists between U2:EXT_5V and the 5V net. The direct netlist connection is therefore reflected as a direct board-level connectivity requirement.
Because there is no isolation component to place, route, or label, the layout currently cannot enforce the intended programming/field-power separation.
Required schematic fix
Use the preferred prototype-safe solution:
Add removable 2-pin jumper / solder bridge
Insert a removable link between the buck 5V rail and the ESP32 DevKit external 5V pin:
BUCK_5V / carrier 5V -> JP_ESP32_5V pin 1 -> removable shunt/solder bridge -> JP_ESP32_5V pin 2 -> ESP32_EXT_5V / U2:EXT_5V
Recommended label:
JP_ESP32_5V — install for field operation, remove when programming via DevKit USB
Net naming after fix
Recommended split:
  • BUCK_5V or 5V_BUCK: LM2596 output side, output capacitors, relay shunt source, INA219 high-side source as appropriate.
  • ESP32_EXT_5V: only the DevKit external 5V input side of the jumper.
The jumper should be the only intentional connection between these two nets.
Robustness notes
A removable jumper/solder bridge is preferred for this prototype because it is simple, visible, low-cost, and does not add USB circuitry to the carrier PCB. For a later production design, a diode OR-ing or ideal-diode/load-switch solution could make simultaneous USB/programming and field power safer without relying on manual jumper removal, but the preferred jumper solution is adequate and clear for prototype use.
Final checklist result

Table

CheckResultNotes
PCB 5V directly connected to U2 EXT_5VPASSConfirmed on net 5V.
Jumper/diode/fuse/load-switch/removable link presentFAILNone found between buck 5V and U2:EXT_5V.
USB + PCB 5V simultaneous conflict possibleFAILCarrier has no isolation against DevKit USB 5V interaction.
USB can back-power carrier when PCB power is offFAILPossible through direct U2:EXT_5V -> 5V connection.
Buck can back-feed PC USB portFAILPossible if DevKit USB VBUS is not isolated onboard; carrier provides no protection.
Recommended fix available without carrier USB connectorPASSAdd JP_ESP32_5V removable 2-pin jumper/solder bridge.
PASS/FAIL
FAIL — back-power protection is missing.
The schematic should be corrected before prototype use where DevKit USB programming and external 12V–24V carrier power may both be used.

  • Summary

  • Evidence from schematic

  • 1. PCB 5V directly connected to ESP32 DevKit 5V/EXT_5V

  • 2. Isolation / removable link between BUCK_5V and ESP32_EXT_5V

  • Back-power scenarios

  • 3. USB plugged into DevKit while PCB 5V rail is also powered

  • 4. PCB power off, USB connected to DevKit

  • 5. PCB 5V on, USB connected to PC

  • Exact schematic paths

  • Carrier buck 5V to ESP32 DevKit

  • ESP32 DevKit ground to carrier ground

  • PCB/layout observations

  • Required schematic fix

  • Add removable 2-pin jumper / solder bridge

  • Net naming after fix

  • Robustness notes

  • Final checklist result

  • PASS/FAIL