Skip to content

Rev B1 ECN-14 — Charge path (B3) self-gating from +5V0 (default off) (draft)

Draft — EverTag Station battery variants

Make the charge-path ideal-diode enable (B3 EN) self-gating from the +5V0 rail so the charge path is on only when mains is present and off (reverse-blocked) on battery, with no firmware in the safety loop. Not approved. Fix targets the B1 Altium release. Does not apply to Tag (230220).

No charge-topology change in B1 — keep B1/B2/B3 (MAX40200) and MCP73123 as drawn. This ECN only changes what drives B3 EN.

Ships in the same B1 respin as Rev B1 ECN-01 — GPIO remap.

Background — what actually overheated B3

The severe B3 overheating / damage seen on the A-series first article was primarily reversed battery polarity — see ECN-15, now confirmed on the bench (B3 stays cool once the cell is connected the correct way). ECN-15 is the primary fix for that fault.

This ECN addresses a separate, secondary robustness weakness in how B3 is enabled, which adds reverse stress on AC loss and made the polarity fault worse:

The charge input uses ideal diode B3 (MAX40200): +5V0 → MCP73123 VDD, EN = CHARGE_ENABLE. The MAX40200 only blocks reverse current when EN is low; with EN high it conducts both ways. On A-series the CHARGE_ENABLE net has a 10k pull-up to +3V3, so B3 is enabled by default regardless of firmware. On AC loss the cell can then back-drive the charger through an enabled B3 into the dead +5V0 rail → reverse current and mild heating, independent of firmware timing.

What changes

Drive B3 EN from +5V0 directly — exactly as B1 already does (B1 EN = +5V0). B3 then self-gates with mains:

A-series (as built) B1 (proposed)
B3 EN source CHARGE_ENABLE net, 10k pull-up to +3V3 (B3 on by default) +5V0 (B3 on only while mains present)
AC loss behaviour B3 stays on → reverse stress +5V0 = 0 → B3 EN low → reverse-blocked, instantly, no firmware
nRF54 role in charging drives CHARGE_ENABLE (in the control loop) reads status only (DC_PRESENT, CHARGE_STATUS, BAT_VOLTAGE)
CHARGE_ENABLE / P2.05 charge-path enable output freed — no longer needed for B3 (available GPIO)
B3 / MCP73123 / B1 / B2 — Unchanged

This mirrors the proven B1/B2 power-path OR (each ideal diode self-enabled by its own input), so the whole charge/backup path becomes firmware- independent and has no cook-window. The MCP73123 already manages CC/CV, end-of-charge, and thermal regulation autonomously, so firmware charge-enable control is not required.

EN voltage

Follow B1's precedent (EN tied to +5V0). MAX40200 operates 1.5–5.5 V; if +5V0 can exceed 5.5 V on any supply, gate EN through the same divider/clamp scheme used for B1. Confirm in Altium.

Alternative (weaker) — pulldown + firmware control

If keeping CHARGE_ENABLE under nRF54 control is preferred for some reason, the minimum change is to swap the +3V3 pull-up for a 10k pull-down to GND so B3 defaults off, and have firmware drive it high only when DC is present. This still leaves firmware in the safety loop (must drive low on AC loss; small poll-latency window) and is not recommended over the +5V0 self-gating above.

Rationale

Topic A-series problem B1 intent
Safe default Pull-up → B3 on without/against MCU +5V0 gate → B3 on only with mains
AC loss B3 stays on → reverse stress / heat EN follows +5V0 → instant reverse block
Firmware dependency Must win fight vs pull-up; slow P2 poll None — HW self-gates; nRF54 reads only
Scope of change — B3 EN source only — no new gates, no charger swap

Rev-A interim (firmware)

Existing A-series boards keep the +3V3 pull-up. The shipped firmware works around it by driving CHARGE_ENABLE = DC_PRESENT (50 ms poll) so B3 is forced off on battery — bench-verified to keep B3 cool with a correctly-connected cell. This is an interim for rev A only; B1's +5V0 gating removes the firmware dependency entirely.

A-series 232201 / 232203: treat as mains-only until B1 — do not rely on battery backup (see Rev A interim handling).

Scope

Item B1 change
232201 Base Bat B3 EN ← +5V0; remove CHARGE_ENABLE pull-up; P2.05 freed
232203 Base Bat+WiFi Same shared layout
232204 Base Bat+Radar Same shared layout (battery populate)
232200, 232202 Footprint/net on shared PCB — DNP / not used on non-battery BOMs
230220 Tag No change
B1, B2, B3, IC1 (MCP73123), J3 No topology change

Altium implementation (after design approval)

  1. Reroute B3 EN to +5V0 (follow B1's EN connection exactly, incl. any divider/clamp if +5V0 may exceed 5.5 V).
  2. Remove the +3V3 pull-up on the old CHARGE_ENABLE net.
  3. Free P2.05 — no longer drives B3; leave as available GPIO (or DNP net).
  4. BOM — applies on battery variants; not used on 232200/232202.
  5. Gerber lock — verify B3 EN is tied to +5V0, not to a +3V3 pull-up.

Firmware (after B1)

  • Charging is autonomous (B3 self-gated by +5V0; MCP73123 manages the cycle). Firmware does not drive a charge-enable.
  • nRF54 reads status only: P1.13 DC_PRESENT (ECN-01, GPIOTE), CHARGE_STATUS, BAT_VOLTAGE.
  • Remove the rev-A CHARGE_ENABLE poll workaround for B1 builds.
  • Update 232201 pin table and battery sections (CHARGE_ENABLE no longer a charge control).

Verification (assembly / QA)

  • Mains absent (board off or on battery): B3 EN ≈ 0 V, B3 off, no reverse current into +5V0 (current / thermal spot-check)
  • Mains present: B3 EN ≈ +5V0, MCP73123 charges (STAT behaviour per 232201 §7)
  • AC loss with correct-polarity cell: B3 stays cool, board holds up on battery (B2 → V_PP), no firmware action required
  • DC_PRESENT on P1.13 tracks mains (status only)
  • Non-battery variants unaffected

Open items

# Question Owner Status
1 Confirm B3 EN can tie directly to +5V0 (level vs MAX40200 5.5 V max) or needs the B1-style divider Altium Pending
2 Re-run full battery-only hold-up test (B2 → V_PP) after B3 self-gating — also check buck headroom brownout (V_PP ≈ 3.2 V vs 3.3 V out) Bench Pending
3 Remove CHARGE_ENABLE charge-control from firmware + docs for B1 FW + HW docs Pending

Rev A interim (until B1)

Aspect Handling on rev A
HW patch remove R30 (CHARGE_ENABLE +3V3 pull-up) so B3 is not held enabled
Firmware drive CHARGE_ENABLE = DC_PRESENT (50 ms poll) → B3 forced off on battery
Verified B3 stays cool on battery with a correctly-connected cell (232204, 2026-06-16)
Limitation poll-latency window remains; treat battery variants as mains-only for delivery. Requires correct battery polarity (ECN-15)

See the Rev A bringup reference for the cross-ECN table.