232202 - EverTag Connectivity Module Base PCB WIFI¶


Article Number	232202
Name	EverTag Connectivity Module Base PCB WIFI
Base PCB	232200 Base Std
Added Feature	ESP32-C5 WiFi gateway
Status	Active

Delta Document

This document describes only the differences from the 232200 Base Std. For all shared functionality (MCU, NFC, USB-C connector, service button, TC2030-CTX-NL J1 debug, PCB design notes), refer to the base PCB documentation. This WiFi variant adds a TC2030 (6-pin) footprint at J2 for ESP32 programming, using a TC2030-FTDI-DTR cable with integrated USB-UART and auto-reset. J1 uses 470 ohm on SWD/UART pads (pins 2, 3, 4, 6); J2 uses 470 ohm on DTR/RXD/TXD/RTS for misconnection protection. Both LED1 (system) and LED2 (gateway status) are populated -- LED2 indicates WiFi/gateway connectivity.

1. Overview¶

The 232202 adds an Espressif ESP32-C5 WROOM WiFi gateway module to the base 232200 connectivity module. This enables the EverTag Station to function as a Wirepas-to-WiFi gateway, bridging the Wirepas Mesh network to IP infrastructure via the customer's existing WiFi network. For gateway applications, the ESP32 is the system master (WiFi, web UI, reboot policy); nRF54 keeps NFC, LEDs, Wirepas, and nRF54 flash config as on anchor boards — see System Architecture.

Key Features (Delta from 232200)¶

ESP32-C5 WROOM module -- dual-band 2.4 GHz + 5 GHz, WiFi 6
Single UART1 interface using Wirepas Dual-MCU API (gateway data + control/config)
3-wire PTA coexistence GPIO traces routed (MPSL-ready for nRF Connect SDK / BLE builds; custom arbiter FW TBD for Wirepas; 5 GHz WiFi recommended as primary mitigation)
Dedicated 3.3V LDO for ESP32 power
Castellated module -- no RF tuning required on base PCB
Separate ground stitching around ESP32 RF domain

2. Block Diagram (Delta)¶

graph TB
    subgraph power [Power Supply - Extended]
        VIN["5V Input from Power Base"] --> BUCK["TPS62160 Buck Converter"]
        BUCK --> RAIL["3.3V Rail"]
        RAIL --> LDO["Dedicated LDO"]
        LDO --> WIFI_PWR["3.3V WiFi Rail"]
    end

    subgraph mcu_block [MCU / Radio Module]
        PAN611["PAN611 - nRF54L15"]
    end

    subgraph wifi_block [WiFi Gateway Module]
        ESP32["ESP32-C5 WROOM"]
    end

    RAIL --> PAN611
    WIFI_PWR --> ESP32

    PAN611 <-->|"UART1: Dual-MCU API"| ESP32
    ESP32 -->|"COEX REQUEST"| PAN611
    PAN611 -->|"COEX GRANT"| ESP32
    PAN611 -->|"ESP32 RESET"| ESP32
    ESP32 -->|"READY"| PAN611

Interconnect¶

The nRF54 and ESP32-C5 communicate via a single UART (Wirepas Dual-MCU API) plus coexistence and control signals:

Interface	Pins	Purpose	Bandwidth
UART1	P0.03 (TX), P0.04 (RX)	Wirepas Dual-MCU API (gw data + config + status)	115200 (up to 921600)
3-Wire COEX	P2.00 (REQ in), P2.01 (PRI in), P2.02 (GRANT out)	Hardware coexistence arbitration	Signal
ESP32 RESET	P1.10	nRF54 controls ESP32 boot/reset	Signal
ESP32 READY	P2.08	ESP32 signals boot complete	Signal

Coexistence — Firmware Dependent

The 3-wire PTA GPIO traces are routed to support both firmware paths: (1) nRF Connect SDK / BLE builds can use Nordic MPSL directly, (2) Wirepas builds require a custom arbiter (FW TBD) or software coex via Dual-MCU API. Primary mitigation for Wirepas: recommend 5 GHz WiFi. See Coexistence Architecture.

3. Schematics (Delta)¶

3.1 ESP32-C5 WROOM Module¶

Parameter	Value
Manufacturer	Espressif
Module	ESP32-C5 WROOM
WiFi	802.11ax (WiFi 6), 2.4 GHz + 5 GHz dual-band
Core	RISC-V single-core
Supply	3.3V (dedicated LDO)
Package	Castellated SMT module

Design notes:

Castellated module -- no external RF matching or antenna trace routing on base PCB
Module contains integrated antenna for both 2.4 and 5 GHz bands
5 GHz band preferred for gateway data to avoid 2.4 GHz congestion with Wirepas

3.2 Dedicated LDO (ESP32 Power)¶

Parameter	Value
IC	AP2112K-3.3TRG1 (Diodes Inc)
Input	Power-path diode-OR output (~4.7V on AC, ~3.0--3.6V on battery)
Output	3.3V (WiFi rail)
Max Current	600 mA
Dropout	~200 mV @ 300 mA typical
Package	SOT-23-5
Est. Price	~$0.10 @ 10k
Sourcing	LCSC (C51118), DigiKey, Mouser

The LDO is fed from the power-path diode-OR output -- the same node that feeds the TPS62160 buck converter. This creates two independent 3.3V domains that are both battery-backed:

TPS62160 (buck converter) → 3.3V for nRF54, NFC, LEDs, sensors
AP2112K (LDO) → 3.3V for ESP32 WiFi module only

graph LR
    VIN["5V from Power Base"] --> PPM["Power-Path<br/>Diode-OR"]
    BAT["LiFePO4<br/>(battery variants)"] -.-> PPM
    PPM --> BUCK["TPS62160"]
    BUCK --> RAIL_NRF["3.3V nRF54 Rail"]

    PPM --> LDO["AP2112K-3.3"]
    LDO --> RAIL_WIFI["3.3V WiFi Rail"]

Why a Separate LDO Instead of Shared Rail?

During WiFi TX bursts the ESP32-C5 draws up to ~350 mA in sharp transients. If both MCUs shared a single 3.3V rail, ESP32 current spikes would create supply noise that degrades the nRF54's sensitive radio receiver. The separate LDO provides power supply isolation -- the two 3.3V rails are independent.

Battery Behaviour (232203)

On battery variants, when AC power is lost the power-path switches to LiFePO4 battery (~3.0--3.6V). The AP2112K continues to power the ESP32:

Charged battery (3.4--3.6V): LDO regulates normally, ESP32 runs at 3.3V.
Nominal battery (3.2V): LDO enters dropout, ESP32 gets ~3.0V. Functional (ESP32-C5 min VDD = 3.0V).
Depleted battery (<3.0V): ESP32 browns out. At this point nRF54 is also near shutdown.

The gateway remains fully operational on battery -- nRF54 continues in gateway mode and ESP32 maintains the WiFi uplink. Firmware monitors battery voltage (P1.06 / AIN2) and performs a graceful shutdown of both MCUs before the battery reaches the brown-out threshold. See the Firmware Architecture section in firmware-compatibility for details.

3.3 UART1 Interface (Wirepas Dual-MCU API)¶

A single UART carries all nRF54↔ESP32 communication: Wirepas gateway data packets, config/status commands, and management using the Wirepas Dual-MCU API protocol.

Signal	nRF54 Pin	ESP32-C5 Pin	Direction	Notes
UART1_TX	P0.03 (3)	GPIO8 (pin 10)	nRF54 → ESP32	Dual-MCU API: gw packets + config push
UART1_RX	P0.04 (4)	GPIO9 (pin 11)	ESP32 → nRF54	Dual-MCU API: status + Web UI config

Baud rate: 115200 8N1 (upgradable to 921600 for higher throughput). The Wirepas Dual-MCU API uses SLIP-encoded framing to multiplex data and control on a single UART. See nRF54 to ESP32 Communication Protocol for details.

UART1 on Former SPI Pins

UART1 TX/RX are assigned to P0.03/P0.04 (formerly SPI CLK/MISO on 230220). ESP32_RESET is on P1.10 (formerly SPI MOSI). These reassignments free SAADC-capable pins P1.11/P1.13/P1.14 for future sensor use (e.g. on 232204 Bat+Radar). Directions are preserved: P0.03 output→output, P0.04 input→input, P1.10 output→output. P1.08 (formerly SPI CS) remains unassigned on this board.

3.5 ESP32 Control Signals¶

Signal	nRF54 Pin	ESP32-C5 Pin	Direction	Notes
ESP32_RESET	P1.10 (A2)	EN (pin 3)	nRF54 → ESP32	Active high enable. nRF54 controls ESP32 boot.
ESP32_READY	P2.08 (20)	GPIO24 (pin 23)	ESP32 → nRF54	ESP32 asserts after boot (reused from ACC.INT1)

3.6 3-Wire Coexistence (Reserved — Firmware TBD)¶

Signal	nRF54 Pin	nRF54 Direction	ESP32-C5 Pin	Function
COEX_REQUEST	P2.00 (C4)	Input	GPIO6 (pin 8)	ESP32 requests 2.4 GHz airtime
COEX_PRIORITY	P2.01 (E4)	Input	GPIO10 (pin 12)	ESP32 indicates priority level
COEX_GRANT	P2.02 (D4)	Output	GPIO23 (pin 21)	nRF54 grants airtime

MPSL Not Available in Wirepas — MPSL-Ready for nRF Connect SDK

Nordic MPSL is a Zephyr/nRF Connect SDK component and is not available in the Wirepas stack. Wirepas runs its own radio scheduler.

PCB action: 3-wire PTA traces are routed to support two firmware scenarios:

Wirepas firmware (FW TBD): Custom arbiter via Wirepas application-layer code or Dual-MCU API software commands over UART1. Primary mitigation: recommend 5 GHz WiFi to eliminate 2.4 GHz contention.
nRF Connect SDK firmware (BLE gateway): MPSL is available and the PTA traces work directly with Nordic's built-in coexistence driver — no custom firmware needed.

This dual-use compatibility ensures the gateway PCB supports both Wirepas and BLE application firmware.

Why nRF54 Remains the Arbiter (When Implemented)

Wirepas Mesh uses strict TDMA time slots. Missing a slot causes mesh desynchronization. If ESP32 were the RF arbiter, long WiFi TX bursts could starve Wirepas. By making nRF54 the gatekeeper, Wirepas timing is never compromised. ESP32-IDF supports external coex GRANT signals. This is coexistence scheduling, separate from gateway system master (ESP32 owns application policy — see System Architecture). See Coexistence Architecture.

3.7 Optional nRF54 nRESET from ESP32 (0 Ω NM)¶

Optional engineering / recovery path: ESP32 GPIO27 (WROOM module pin 18, per Espressif pin table) connects to nRF54 nRESET through a 0 Ω chip jumper (NM = not mounted on default production BOM). No series resistor — reset is driven directly when the jumper is fitted.

Refdes (example)	Value	Footprint	Default	Notes
R0_ESP_NRF_RST	0 Ω	0402	DNP (NM)	Fit only when lab or field recovery needs ESP32 to hard-reset nRF54

Schematic net: ESP32_IO27 → R0_ESP_NRF_RST → NRF54_nRESET (module pin 23, active low, existing 100k pull-up on nRF54 side).

Silkscreen: at the 0 Ω site, mark “0R NM” or “FIT 0R: ESP→nRST (eng only)”.

Firmware (when 0 Ω is fitted): configure GPIO27 so nRF54 is not held in reset at ESP32 chip reset (GPIO27 is a strapping pin on ESP32-C5; default weak pull-up is compatible with SPI boot when GPIO26/GPIO28 are high — verify against ESP32-C5-WROOM datasheet and keep the pin high or input until intentionally pulsing nRESET).

Pin-pick: GPIO27 is unused by UART1, coexistence, J2, USB, or the LTE B2B map (GPIO0,1,3,4,5,15,25). Implementation: SYS_RESET over UART1 is the production reset path when R0 is DNP.

4. Pin-Out (Delta)¶

Additional GPIO requirements beyond 232200 base pin-out. Four pins are required for the ESP32 interface (UART + control). Three pins are routed for coexistence (firmware TBD). One optional ESP32 GPIO connects to nRF54 nRESET via 0 Ω (NM) only. SPI pins are not connected to ESP32.

Pin	GPIO	Function	Direction	Source	Notes
3	P0.03	UART1 TX → ESP32	Output	Reused from SPI CLK (230220)	Wirepas Dual-MCU API + config
4	P0.04	UART1 RX ← ESP32	Input	Reused from SPI MISO (230220)	Wirepas Dual-MCU API + status
A2	P1.10	ESP32_RESET	Output	Reused from SPI MOSI (230220)	nRF54 actuates EN (boot + cooperative reset)
20	P2.08	ESP32_READY	Input	Reused from ACC.INT1	ESP32 boot complete (same direction)
C4	P2.00	COEX_REQUEST	Input	Available pool	Routed, FW TBD (ESP32 requests airtime)
E4	P2.01	COEX_PRIORITY	Input	Available pool	Routed, FW TBD (ESP32 priority signal)
D4	P2.02	COEX_GRANT	Output	Available pool	Routed, FW TBD (nRF54 grants airtime)
--	--	(ESP32 only) nRESET strap	Output	ESP32 GPIO27 (pin 18)	Optional 0 Ω (NM) → nRF54 pin 23 nRESET. See §3.7.

5. Component Selection (Delta)¶

5.1 WiFi Module -- ESP32-C5 WROOM¶

Parameter	Value
Manufacturer	Espressif
Part Number	ESP32-C5 WROOM
WiFi Standard	802.11ax (WiFi 6)
Bands	2.4 GHz + 5 GHz (dual-band)
Antenna	Integrated (PCB antenna in module)
Core	RISC-V single-core
Package	Castellated SMT module
Est. Price	~3--4 USD @ 10k volume
Datasheet	ESP32-C5 WROOM-1 & WROOM-1U Datasheet

Rationale:

Dual-band (2.4 + 5 GHz) -- 5 GHz band avoids interference with Wirepas 2.4 GHz mesh
WiFi 6 -- improved throughput and power efficiency vs. WiFi ⅘
Castellated module -- no RF tuning required on base PCB, reducing design complexity and manufacturing risk
Modular FCC/CE certification -- pre-certified module reduces regulatory cost and time
Low cost -- competitive with other WiFi SoC modules
Good long-term availability from Espressif ecosystem

Supplier Link: Espressif ESP32-C5

5.2 LDO Regulator (WiFi Power)¶

Parameter	Value
IC	Diodes Inc AP2112K-3.3TRG1
Package	SOT-23-5
Input	3.3V main rail
Output	3.3V filtered (low-noise for ESP32)
Max Current	600 mA (sufficient for ESP32-C5 peak ~500 mA)
Dropout	250 mV typ @ 600 mA
Quiescent	55 µA typ
PSRR	70 dB @ 1 kHz
Est. Price	~$0.15 USD

Rationale: The AP2112K-3.3 is a widely available, low-dropout, low-noise LDO in a compact SOT-23-5 package. Its 600 mA output covers the ESP32-C5 peak current with margin. High PSRR (70 dB) provides clean power for WiFi RF performance. The SOT-23-5 footprint is standard and supported by all EMS partners.

Supplier Links:

Source	Part Number	Notes
DigiKey	AP2112K-3.3TRG1DICT-ND	Western
Mouser	621-AP2112K-3.3TRG1	Western
LCSC	C51118	Asian

Datasheet: Diodes Inc AP2112

Application circuit: standard — 1 µF ceramic (X5R/X7R) on input, 1 µF ceramic on output, both placed close to IC pins. Enable pin tied to input (always on).

6. PCB Design Notes (Delta)¶

6.1 ESP32-C5 Module Placement¶

Place ESP32-C5 module with antenna area extending to PCB edge (no copper under antenna)
Keep ESP32 module as far as practical from PAN611 module to minimize RF coupling
Maintain RF clearance zones per Espressif module datasheet

6.2 Ground Stitching¶

Separate ground stitching vias around the ESP32-C5 RF domain
Connect ESP32 ground to main ground plane at a single point (star ground topology in RF area)
Ground stitching fence between PAN611 and ESP32 module areas

6.3 Signal Routing¶

UART traces: controlled impedance not required (low frequency), but keep short and away from RF areas
Coexistence signals: short, direct route between modules
No high-speed clock signals crossing between module domains
P0.03/P0.04/P1.10 now carry UART1 and ESP32_RESET -- route from PAN611 to ESP32 module pads
P1.08 (formerly SPI CS) remains unconnected on this board

For base PCB design notes, see 232200 PCB Design Notes.

7. Test Points & Programming (Delta)¶

Additional test points beyond 232200 test points:

J2: TC2030 with TC2030-FTDI-DTR Cable (ESP32 Programming / Debug)¶

A TC2030 (6-pin) footprint is used for direct ESP32-C5 programming and debug console. J2 uses the same footprint family as J1 (both TC2030). 470 ohm series resistors sit on the SWD/UART signal pads of J1 (pins 2, 3, 4, 6) and on the J2 signal pads (DTR, RXD, TXD, RTS). +3.3V and GND pads have no series resistor. J2 is rotated 180° relative to J1 as an additional physical keying measure.

Misconnection Protection: Series Resistors

Both J1 (nRF54 SWD) and J2 (ESP32 UART) use TC2030 footprints. Since the cables are physically compatible with either footprint, 470 ohm series resistors on the signal lines limit fault current if a cable is mated to the wrong header (about 7 mA per contested pin at 3.3 V). Pin 1 is +3.3V on both J1 and J2, so mis-mating the FTDI cable to J1 does not connect 3V3 to an nRF54 GPIO at pin 1; protection remains essential on pins 2, 3, 4, 6. SWD and UART function normally through 470 ohm at the speeds used in this design.

Parameter	Value
Footprint	J2: TC2030 (6-pin pogo, no-legs), rotated 180° relative to J1
Cable	TC2030-NL-FTDI-C232HD-DDHSP-0-DTR (3.3V, FT232H-based, integrated USB-to-UART, DTR on pin 2)
Interface	ESP32 UART boot + debug console (U0TXD / U0RXD)
BOM Cost	~$0.03 (auto-reset circuit ~$0.02 + series resistors ~$0.01; pogo pads are $0)

J2 Pin Assignment (per TC2030-NL-FTDI-C232HD-DDHSP-0-DTR cable wiring):

Pin	Signal	Direction	FT232H Pin	ESP32-C5 Pin	Notes
1	3V3	Power	VCC (Red)	3V3	Power reference from WiFi LDO (no series R)
2	DTR	Host output	DTR (Gray)	Via R + Q2 → GPIO26/28	Auto-reset circuit: controls BOOT (470Ω series R)
3	RXD (ESP→host)	ESP32 → Host	RXD (Yellow)	GPIO11 (U0TXD, pin 13)	UART data from ESP32 (470Ω series R)
4	TXD (host→ESP)	Host → ESP32	TXD (Orange)	GPIO12 (U0RXD, pin 14)	UART data to ESP32 (470Ω series R)
5	GND	--	GND (Black)	GND	Ground (no series R)
6	RTS	Host output	RTS (Green)	Via R + Q1 → EN	Auto-reset circuit: controls RESET (470Ω series R)

Auto-Reset Circuit (BOOT / RESET Sequencing)¶

The FT232H DTR and RTS signals are converted into the correct ESP32 BOOT/RESET sequence via a standard Espressif-style auto-reset circuit. This enables esptool.py --before default_reset to automatically enter download mode -- the same workflow as any ESP32 DevKit. The 470 ohm series resistors on the TC2030 pads are upstream of the auto-reset transistors.

graph LR
    subgraph TC2030-FTDI-DTR Cable
        DTR["DTR (pin 2)"]
        RTS["RTS (pin 6)"]
    end

    subgraph Series Protection
        R_DTR["470Ω"]
        R_RTS["470Ω"]
    end

    subgraph Auto-Reset Circuit
        C1["C1: 10nF"]
        C2["C2: 10nF"]
        Q1["Q1: NPN (BC847)"]
        Q2["Q2: NPN (BC847)"]
    end

    subgraph ESP32-C5
        EN["EN (RESET)"]
        BOOT["GPIO26 + GPIO28 (BOOT)"]
    end

    RTS --> R_RTS --> Q1
    Q1 -->|"collector"| EN
    DTR --> R_DTR --> C1 -->|"AC-coupled"| EN

    DTR --> R_DTR
    R_DTR --> Q2
    Q2 -->|"collector"| BOOT
    RTS --> R_RTS
    R_RTS --> C2 -->|"AC-coupled"| BOOT

Auto-reset circuit + protection BOM:

Ref	Component	Value / Part	Package	Notes
Q1	NPN transistor	BC847 / S8050	SOT-23	Base = RTS (via 470Ω), Collector = EN, Emitter = GND
Q2	NPN transistor	BC847 / S8050	SOT-23	Base = DTR (via 470Ω), Collector = GPIO26+GPIO28 (BOOT), Emitter = GND
C1	Capacitor	10 nF	0402	Series between DTR and EN (AC-coupling for reset pulse)
C2	Capacitor	10 nF	0402	Series between RTS and GPIO26+GPIO28 (AC-coupling for BOOT)
R7	Pull-down	10k	0402	GPIO7 pull-down to GND (JTAG strapping pin, see note below)
R_J2_1..4	Series resistor	470 ohm	0402	On J2 signal pads (DTR, RXD, TXD, RTS) -- misconnection protection

The cross-wiring (DTR drives Q2 for BOOT while RTS drives Q1 for RESET, capacitors cross to the opposite signal) produces the correct timing sequence when esptool.py toggles DTR and RTS. The capacitors ensure RESET gets a brief pulse while BOOT is held low long enough for the chip to sample during reset release.

ESP32-C5 Strapping Pins

The ESP32-C5 uses two strapping pins for boot mode selection:

GPIO26 (pin 24) and GPIO28 (pin 26): Together determine boot mode. Both must be LOW at reset for download mode (UART boot). Both default HIGH via internal pull-ups for normal SPI flash boot. Tie both to the Q2 collector in the auto-reset circuit.
GPIO7 (pin 9): Selects JTAG signal source. Must be LOW at reset for normal operation (JTAG from GPIO). Add a 10k pull-down resistor (R7) to GND. Without this pull-down, GPIO7 may float high and select eFuse-based JTAG, preventing UART boot.

These strapping pins are only sampled during reset; after boot they can be used as normal GPIOs if needed.

Circuit Is Inert When Cable Not Attached

When no TC2030-FTDI cable is mated, the pogo pads are open. The transistor bases float (no drive through the 470 ohm series resistors), so Q1 and Q2 are off. The 10k pull-up resistors on EN and GPIO26/28 (BOOT) maintain normal boot. The auto-reset circuit has zero effect on normal operation.

ESP32 Programming Workflow

Production: Connect TC2030-NL-FTDI-C232HD-DDHSP-0-DTR cable to J2 pogo pads. Run esptool.py --port /dev/ttyUSBx --before default_reset write_flash ... -- the auto-reset circuit handles BOOT/RESET sequencing automatically. Program nRF54 via J1 TC2030 in SWD mode. Both J1 and J2 are TC2030 pads on the same PCB side for a single dual-head production jig.

Debug console: After programming, the same TC2030-FTDI-DTR cable serves as the ESP32 debug console. Open a terminal at 115200 baud (idf.py monitor, minicom, screen) on the same USB port to view ESP-IDF log output.

Field updates: Can also program ESP32 via nRF54 UART bridge (dfu esp32 CLI command on J1) for field updates without needing J2.

Design notes:

Place J2 near J1 (nRF54 TC2030), both on top side of PCB Rotate J2 180° relative to J1 (physical keying -- forces deliberate cable rotation for cross-mating)
Maintain fixed spacing between J1 and J2 for production jig compatibility (two TC2030 heads)
J2 is only populated/needed on WiFi variants (232202, 232203)
470 ohm series resistors on all J2 signal pads (DTR, TXD, RXD, RTS) -- placed between TC2030 pads and auto-reset / ESP32 circuit
BOOT (GPIO26 + GPIO28, tied together) and EN (RESET) need 10k pull-up resistors to 3V3 (BOOT high = normal boot, BOOT low = download mode)
GPIO7 needs a 10k pull-down resistor to GND (JTAG source strapping pin)
Place auto-reset components (Q1, Q2, C1, C2) and series resistors close to J2 pogo pads
Clear silkscreen label: "J2: ESP32 UART" (distinct from J1: "nRF54 SWD")

J3: Internal USB-C Connector (ESP32 USB-Serial/JTAG — Dev/NPI Only, DNP in Production)¶

An internal USB-C receptacle (J3) connects to the ESP32-C5 native USB pins, providing USB-Serial and USB-JTAG via a single standard USB cable. This enables GDB debugging during firmware development, significantly reducing iteration time compared to log-based debugging.

Parameter	Value
Connector	GCT USB4085-GF-A
Manufacturer	GCT (Global Connector Technology)
Type	USB Type-C 2.0 receptacle, mid-mount SMD
Footprint	J3: USB-C receptacle (mid-mount, internal to enclosure)
ESP32 Pins	GPIO13 (USB_D-), GPIO14 (USB_D+)
Interface	ESP32-C5 built-in USB Serial/JTAG controller
Capabilities	USB-CDC serial console + USB-JTAG (GDB via OpenOCD)
Population	DNP in production — populated only during dev/NPI phase
BOM Cost (production)	$0.00 (DNP — pads routed, connector not populated)

Dev/NPI vs Production

Development & NPI: Populate J3. Connect a standard USB-C cable for ESP32 serial console and JTAG debugging (GDB via openocd + gdb). This eliminates the need for a TC2030-FTDI cable during active firmware development.

Production: Do not populate J3 (DNP). Use J2 TC2030 for flash programming via esptool.py (faster cycle time on production jig). The USB D+/D- traces remain on the PCB but add zero BOM cost.

Design notes:

Place J3 inside the enclosure, accessible only when the enclosure is open (not externally visible)
Route USB D+/D- as a 90 ohm differential pair, keep traces short (< 50 mm)
Add ESD protection (e.g. USBLC6-2SC6) on USB D+/D- lines — shared with J3
GPIO7 10k pull-down (JTAG strapping pin, see J2 section) is required for USB-JTAG to function
Clear silkscreen label: "J3: ESP32 USB (DEV)" with "DNP" marking

Individual Test Points¶

TP #	Signal	Expected Value	Notes
TP20	WIFI_3V3	3.3V ± 3%	Dedicated WiFi LDO output
TP21	UART1_TX	Logic	nRF54 → ESP32 (P0.03)
TP22	UART1_RX	Logic	ESP32 → nRF54 (P0.04)
TP23	ESP32_NRF_nRST	Logic	ESP32 GPIO27 / strap to nRESET (open when 0 Ω NM DNP)

WiFi-Specific Tests¶

8. Revision History¶

Revision	Date	Author	Changes
Rev A	TBD	TBD	Initial prototype

232200 Base Std -- Base PCB (all shared functionality)
232203 Base Bat+WIFI -- Combined battery + WiFi variant
Sales Articles -- Products using this PCB: 232003 (EU), 232012 (US)

232202 - EverTag Connectivity Module Base PCB WIFI¶

1. Overview¶

Key Features (Delta from 232200)¶

2. Block Diagram (Delta)¶

Interconnect¶

3. Schematics (Delta)¶

3.1 ESP32-C5 WROOM Module¶

3.2 Dedicated LDO (ESP32 Power)¶

3.3 UART1 Interface (Wirepas Dual-MCU API)¶

3.5 ESP32 Control Signals¶

3.6 3-Wire Coexistence (Reserved — Firmware TBD)¶

3.7 Optional nRF54 nRESET from ESP32 (0 Ω NM)¶

4. Pin-Out (Delta)¶

5. Component Selection (Delta)¶

5.1 WiFi Module -- ESP32-C5 WROOM¶

5.2 LDO Regulator (WiFi Power)¶

6. PCB Design Notes (Delta)¶

6.1 ESP32-C5 Module Placement¶

6.2 Ground Stitching¶

6.3 Signal Routing¶

7. Test Points & Programming (Delta)¶

J2: TC2030 with TC2030-FTDI-DTR Cable (ESP32 Programming / Debug)¶

Auto-Reset Circuit (BOOT / RESET Sequencing)¶

J3: Internal USB-C Connector (ESP32 USB-Serial/JTAG — Dev/NPI Only, DNP in Production)¶

Individual Test Points¶

WiFi-Specific Tests¶

8. Revision History¶

Related Documents¶