mirror of
https://github.com/meshtastic/firmware.git
synced 2026-11-07 23:04:49 -05:00
Jonathan BennettandClaude Opus 5
5e2acd13a6
Before: a board whose variant does not define BUTTON_NEED_PULLUP enters deep
sleep with the wake pad set to plain INPUT and no pull on it, while ext1 is
armed to wake on a low level on that same pin. Nothing holds the line. On the
~40 ESP32 and ESP32-S3 variants whose BUTTON_PIN is GPIO0 that pin is also the
download-mode boot strap, and the reset that ends a deep sleep makes the ROM
read it again: a floating GPIO0 can bring the chip up in ROM download mode
("boot:0x0 (DOWNLOAD(USB/UART0))", "waiting for download") instead of booting
the firmware, which clears only when power is physically removed. A pad with no
pull is also a wake source that can fire on its own, so the board need not stay
asleep at all.
After: the pin ext1 wakes on keeps an internal pull at its idle level for the
whole sleep - a pull-up for a low-level wake, a pull-down where the variant
arms ESP_EXT1_WAKEUP_ANY_HIGH. A BUTTON_PIN that is not the wake pin keeps the
old pull-less INPUT, since gpio_hold_en() latches it.
The pull is applied in both register sets on purpose. The digital pull covers
the window before the sleep; the RTC pull is the one that still holds once the
RTC domain owns the pad, which is the state the ROM's strap read sees.
How: doDeepSleep() picks INPUT_PULLUP or INPUT_PULLDOWN for the wake pad rather
than INPUT, and cpuDeepSleep() asserts the matching pull unconditionally on the
pin it is about to arm. Two existing defects go with it: that pull-up was
previously gated on BUTTON_NEED_PULLUP and applied to BUTTON_PIN even when
config.device.button_gpio or DEEP_SLEEP_WAKE_PIN had moved the wake pin
elsewhere, and gpio_hold_en() skipped BUTTON_PIN on a DEEP_SLEEP_WAKE_PIN board
although it is not the pin being woken on. The wake-pin choice moves to the top
of cpuDeepSleep(), out of the SOC_RTCIO_HOLD_SUPPORTED block that the ext1 mask
below it was already reading it from.
An internal pull is a few hundred nA, less than the leakage the pull-less INPUT
was there to avoid.
Co-Authored-By: Jonathan Bennett <jbennett@incomsystems.biz>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GTiifXrVc4YdonmLRCeWhw
Meshtastic Firmware
Overview
This repository contains the official device firmware for Meshtastic, an open-source LoRa mesh networking project designed for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware supports various hardware platforms, including ESP32, nRF52, RP2040/RP2350, and Linux-based devices.
Meshtastic enables text messaging, location sharing, and telemetry over a decentralized mesh network, making it ideal for outdoor adventures, emergency preparedness, and remote operations.
Get Started
- 🔧 Building Instructions - Learn how to compile the firmware from source.
- ⚡ Flashing Instructions - Install or update the firmware on your device.
Join our community and help improve Meshtastic! 🚀
Stats
