portugalfuturista/sistemas-cibernetico-fisicos
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
sistemas-cibernetico-fisicos/docs/v2.8_hardware_analysis_and_fixes.md

3.8 KiB
Raw Blame History

PCB v2.8 Hardware Analysis & Fixes

1. Analysis of v2.8 Hardware Bugs

The "Bricking" & Flashing Issue

In v2.8, the 3.3V regulator EN pin is hardwired to VSYS, meaning the board is "Always-On" as long as a battery is connected. Simultaneously, the reed switch was moved to the PCAL9538A IO Expander (Port P5). This combination created two major problems:

  1. Unrecoverable Crashes: If the firmware deadlocks, the device cannot be manually reset because the IO Expander cannot hard-reset the MCU, and power cannot be cut.
  2. Flashing Friction: To enter Download Mode over Native USB, GPIO0 must be pulled LOW during a reset. Because the reed switch is on the IO Expander, it cannot pull GPIO0 LOW, forcing technicians to open the sealed box and use tweezers on the CON header to flash the device.

Loss of Deep Sleep Wake-Up (v2.7 Regression)

In v2.7, passing the magnet could wake the device or boot it cleanly. Because v2.8 routed the reed switch through an I2C IO Expander, the ESP32-S3 can no longer use the reed switch to wake from Deep Sleep (EXT0/EXT1 wakeups require direct RTC GPIOs).

2. Immediate Fixes for Current v2.8 Boards (No New Components)

To achieve the goal of controlling the device and flashing it via USB while sealed in its plastic box, we will use a single bodge wire to restore v2.7 functionality.

Hardware Modification (Bodge Wire)

  1. Cut the trace connecting the Reed Switch to the IO Expander (P5).
  2. Solder a bodge wire from the Reed Switch directly to GPIO0 (accessible at Pin 5 of the CON header: IO0_LCD_RST).

How This Fixes All Problems:

  • Un-brickable Native USB Flashing: If the device crashes or needs an update, plug in the USB and hold the magnet against the box. The ESP32-S3's hardware Task Watchdog Timer (TWDT) will reset the chip after 10 seconds of deadlock. When the chip reboots, the magnet is physically holding GPIO0 LOW, forcing the ROM Bootloader to start. The device instantly enumerates over USB and can be flashed (idf.py flash) without opening the box.
  • Restored Deep Sleep Wake-up: GPIO0 is an RTC GPIO (RTC_GPIO0). The firmware can now be put into true Deep Sleep and instantly woken via esp_sleep_enable_ext1_wakeup() when the magnet is swiped, exactly like v2.7.
  • Software-Triggered Safe Boot: If the firmware is healthy, holding the magnet for 5 seconds can trigger esp_restart() in software. Because the magnet holds GPIO0 LOW during the restart, it drops cleanly into Download Mode.

Warning

Firmware Adjustment Needed for v2.8:
Because GPIO0 is shared with the LCD Reset (HW_LCD_RST), applying the magnet will hardware-reset the display. The firmware must simply re-initialize the LCD (re-send the ST7701S SPI init sequence) whenever the magnet is released.

3. Changes for Next Version (PCB v2.9)

For the next PCB revision, we can permanently solve these issues at the schematic level without adding any new components (no supervisor ICs or MOSFETs needed, keeping the BOM cost identical).

Schematic Updates:

  1. Permanent Reed Switch Routing: Route the Reed Switch directly to GPIO0 (with standard pull-up). This permanently embeds the "Un-brickable USB Flashing" and "Deep Sleep Wake-up" functionality into the board.
  2. Swap LCD Reset to IO Expander: To prevent the magnet from blanking the screen, move the LCD Reset trace from GPIO0 to the IO Expander (e.g., Port P5, which is now free). The LCD reset is only needed during initial boot and is not time-critical, making the IO Expander the perfect place for it.
  3. Retain Always-On Power: With the GPIO0 + Watchdog recovery mechanism guaranteed to work, the "Always-On" power architecture (Regulator EN tied to VSYS) is now completely safe. We do not need to add complex soft-latch power circuits or MOSFETs. The ESP32-S3 simply manages power by entering Deep Sleep.