# PCB v2.9 Hardware Mitigation Plan

This document outlines the required hardware architecture changes for PCB version 2.9. These changes address critical flaws discovered in previous versions (v2.7 and v2.8), specifically regarding UART conflicts, device flashing, and field recovery of "bricked" devices.

---

## 1. Context and Problem Statement

### 1.1 The v2.7 Flaws
In v2.7, the reed switch and power-hold mechanisms were directly tied to the primary UART pins (`TX0_AP_BTN` on GPIO43, and `RX0_EN_REG3.3` on GPIO44).
* **Impact:** This created severe conflicts during programming and debugging. Using the reed switch would pull the UART TX/RX lines, introducing garbage into the serial monitor or outright blocking USB-to-UART firmware flashing.

### 1.2 The v2.8 Flaws
To fix the v2.7 UART conflicts, v2.8 isolated the reed switch by connecting it to a PCAL9538A I/O Expander, and implemented an "Always-On Power" architecture by hardwiring the 3.3V regulator `EN` pin to `VSYS`.
* **Impact 1 (Loss of Wake-Up):** The I/O Expander cannot wake the ESP32-S3 from Deep Sleep, nor can it pull the strapping pins required for entering Download Mode. The reed switch became purely a software input.
* **Impact 2 (Bricking Risk):** Due to the Always-On power, if the firmware enters an infinite loop or crashes, a power cycle is impossible without opening the sealed casing and disconnecting the battery. The device becomes "bricked" in the field.

---

## 2. Proposed Hardware Mitigations for v2.9

The following changes must be implemented in the v2.9 schematic to guarantee field reliability and developer accessibility.

### 2.1 Reed Switch Relocation to RTC GPIO
**Action:** Disconnect the reed switch from the PCAL9538A I/O Expander and connect it to a dedicated **RTC GPIO** on the ESP32-S3 (e.g., `GPIO4`, `GPIO5`, or similar non-strapping RTC pin).

**Rationale:**
* Bypasses the I/O Expander, restoring direct hardware access to the MCU.
* RTC GPIOs support native `EXT1` wake-up, allowing the device to enter true Deep Sleep (saving battery) and wake instantly when the magnet is swiped.
* Avoids the UART conflicts present in v2.7 because the pin is dedicated to this function.

### 2.2 Hardware Hard-Reset via Magnet (Un-Brick Mechanism)
**Action:** Introduce a hardware delay circuit that monitors the reed switch state and overrides the system to pull the `CHIP_PU` (`EN`) pin LOW if the magnet is held continuously for a long duration (e.g., > 10 seconds).

**Implementation Options:**
1. **Supervisor IC (Recommended):** Use a dedicated push-button reset IC (like the LTC2950 or a standard watchdog/reset IC). This guarantees precise timing and reliable reset behavior regardless of temperature or battery voltage.
2. **RC Delay Circuit:** A passive Resistor-Capacitor circuit tied to a voltage comparator/MOSFET. While cheaper, this requires careful tuning to ensure the capacitor only discharges the `EN` pin after a long hold.

**Rationale:**
* A quick swipe (< 5 seconds) acts as a normal GPIO input for firmware logic (e.g., toggling power state or AP mode).
* A long hold (> 10 seconds) bypasses software completely and forces a hard reset. This completely eliminates the "bricking" risk of v2.8 by allowing technicians to reboot locked-up devices without opening the enclosure.

### 2.3 Power Architecture Adjustment (Soft-Latch)
**Action:** Remove the hardwired connection between the 3.3V regulator `EN` pin and `VSYS`. Implement a soft-latch power circuit (using discrete MOSFETs or a dedicated load switch).

**Rationale:**
* "Always-On Power" drains the battery faster if the ESP32-S3 fails to enter deep sleep. 
* A soft-latch allows the firmware to intentionally cut power to the 3.3V rail (Zero-Power mode) when shutting down, while still allowing the reed switch to reactivate the latch and boot the system.

### 2.4 Developer Accessibility (Tactile Buttons)
**Action:** Add physical tactile switches for `RESET` (tied to `CHIP_PU`/`EN`) and `BOOT` (tied to `GPIO0`) directly onto the PCB.

**Rationale:**
* In v2.8, flashing required using tweezers to manually short header pins. Physical buttons eliminate this friction, greatly speeding up factory programming and bench debugging.

---

## 3. Summary of v2.9 Architecture

| Feature | v2.7 Implementation | v2.8 Implementation | v2.9 Target Architecture |
| :--- | :--- | :--- | :--- |
| **Reed Switch Pin** | `GPIO43` (TX0) | P5 on I/O Expander | Dedicated RTC GPIO (e.g. `GPIO4`) |
| **Deep Sleep Wake** | Yes (via UART conflict) | No | Yes (via EXT1) |
| **Hard-Reset** | Cut Power (Regulator) | None (Always-On + I/O Expander) | Hardware Delay Circuit to `EN` |
| **Flashing Support** | Blocked by reed switch | Tweezers required | On-board tactile BOOT/RESET buttons |

## 4. Next Steps
1. Update the EasyEDA schematics incorporating the soft-latch and delay-reset circuit.
2. Select a suitable delay supervisor IC (or RC components) and update the BOM.
3. Validate the selected RTC GPIO against the ESP32-S3 datasheet to ensure it has no internal pull-up/pull-down conflicts during boot.