ESP32: rtc_gpio_hold_en() called on non-RTC GPIO18 during LilyGO repeater shutdown
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 55/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- c
- 领域
- embedded-iot
调研方向
Read src/helpers/ESP32Board.cpp and variants/lilygo_tlora_v2_1/platformio.ini to trace ESP32Board::enterDeepSleep() and confirm the NSS pin definition. Check the ESP-IDF GPIO documentation for the hold API supported by the target ESP32 variant. Done means deep sleep no longer calls an RTC-only API for GPIO18; verify the behavior on the affected hardware if available.
由索引模型根据 Issue 内容生成。
描述
While helping another user troubleshoot a LilyGO LoRa32 V2.1-1.6 repeater (ESP32, 433 MHz variant), I came across an invalid RTC GPIO call in the deep-sleep code.
Observed behavior
A custom Repeater build based on commit a366955cb2f67b8e6842d4f00d2b6a554dddd88a booted successfully, then entered the power-off sequence and produced this log:
Repeater ID: <redacted>
Powering Off
E (5387) RTCIO: rtc_gpio_hold_en(153): RTCIO number error
The build used a different radio frequency and LoRa reset pin, but the NSS pin definition and deep-sleep implementation were unchanged from upstream.
Cause
The LilyGO profile defines:
-D P_LORA_NSS=18
On the original ESP32, ESP32Board::enterDeepSleep() calls:
rtc_gpio_hold_en((gpio_num_t)P_LORA_NSS);
GPIO18 is not RTC-capable on the original ESP32, so rtc_gpio_hold_en() returns ESP_ERR_INVALID_ARG.
The 153 in the error message is an ESP-IDF source line number, not a GPIO number.
The call is also present in the current upstream main branch.
Expected behavior
The deep-sleep code should not call an RTC-only API for a regular GPIO.
If keeping NSS high during deep sleep is required, the appropriate GPIO hold mechanism should be used for the target ESP32 variant.
Scope of testing
I traced the shutdown path in the source and checked it against the captured UART log.
The power-off event itself appears to originate from the GPIO0 long-press handler. Its electrical cause has not been established.
The invalid RTC GPIO call explains the subsequent RTCIO error, not the original power-off event.
I have not reproduced this on an unmodified stock firmware binary or verified a fix on the affected hardware.
References
- [LilyGO board configuration](https://github.com/meshcore-dev/MeshCore/blob/main/variants/lilygo_tlora_v2_1/platformio.ini)
- [ESP32Board.cpp](https://github.com/meshcore-dev/MeshCore/blob/main/src/helpers/ESP32Board.cpp)
- [ESP-IDF GPIO documentation](https://docs.espressif.com/projects/esp-idf/en/v4.4.7/esp32/api-reference/peripherals/gpio.html)
- 主要语言
- C
- 星标
- 3.9k
- 派生
- 1.5k
- 平均合并
- 18 小时 59 分钟
- 30 天内合并 PR
- 28
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
meshcore-dev/MeshCore 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 63/100
meshcore-dev/MeshCore#3622 ·
维护者通常 1 天内回复
-
[Feature Request] Set Australia (Mid) Preset to automatically enable 2 byte default path hash size未关闭
难度 2/5 1-3 小时 新手友好度 62/100
meshcore-dev/MeshCore#3571 · 5 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
meshcore-dev/MeshCore#3567 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
meshcore-dev/MeshCore#3549 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
meshcore-dev/MeshCore#3513 ·
维护者通常 1 天内回复
查看 meshcore-dev/MeshCore 的全部 Issue
相似的 Issue
-
mewencode: base256[] and base128[] are indexed out of bounds by a non-ASCII octet可能已有人在做 @kazu-yamamoto 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
kazu-yamamoto/Mew#276 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 91/100
FujiNetWIFI/fujinet-firmware#2045 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
[Performance]: Qwen-Image-2.1 CPU-only on i5-10500H (6C AVX2, 32 GB): 512x512 in 7.7 min at 8 steps未关闭
难度 1/5 1 小时以内 新手友好度 84/100
维护者通常 1 天内回复
-
area:gates area:gfx found-by:critic kind:gate-defect
难度 2/5 1-3 小时 新手友好度 78/100
InauguralSystems/EigenScript#1825 ·
维护者通常 1 天内回复