portugalfuturista/sistemas-cibernetico-fisicos
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
sistemas-cibernetico-fisicos/docs/v2.9_mitigation_plan.md
Fábio Cunha 0a39905348 docs(hw): add v2.9 hardware mitigation plan
2026-05-18 12:36:41 +01:00

5 KiB
Raw Blame History

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.