Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

ESP32: rtc_gpio_hold_en() called on non-RTC GPIO18 during LilyGO repeater shutdown

オープン
#3,586 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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
主要言語
C
スター
3.9k
フォーク
1.5k
平均マージ
19時間 9分
マージ済み PR(30日)
27

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

meshcore-dev/MeshCore のほかの issue

meshcore-dev/MeshCore の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。