FelipeMdeO opened a new pull request, #20226:
URL: https://github.com/apache/nuttx/pull/20226
## Summary
Arming a pin as a light-sleep wake source destroyed whatever it was
configured as, permanently.
`esp_pm_gpio_wakeup_prepare()` has to reconfigure each masked pin to plain
`INPUT` and hand it to `gpio_wakeup_enable()`, because the wakeup path only
supports level triggering. It then never put anything back. A pin that
was also a normal peripheral interrupt — a sensor's data-ready line —
came out of the first light sleep with its trigger mode gone and never
interrupted again. Nothing failed loudly; the device just went silent.
Two additions:
* `esp_getconfiggpio()` (new public function, `esp_gpio.c`/`.h`): mirrors
the `attr` last applied to a pin via `esp_configgpio()` in a small
static table, so a caller that must temporarily reconfigure a pin can
read back what it was and restore it later.
* `esp_pm_gpio_wakeup_restore()`: saves each masked pin's attr before
`esp_pm_gpio_wakeup_prepare()` overwrites it, and puts it back as soon
as `esp_pm_light_sleep_start()` returns.
Tied to the physical sleep/wake cycle deliberately, not to PM state
transitions. An earlier attempt used a board-level `pm_register()`/
`notify()` callback and never fired at all, because a board that stays in
PM_STANDBY without transitioning back to PM_NORMAL never generates the
state change to hang the restore on. The return from
`esp_pm_light_sleep_start()` is the one event guaranteed to happen exactly
once per sleep.
Depends on #20225 ("espressif/esp_pm.c: stop double-counting light sleep
in the system clock") — that commit is included here too since it has not
merged yet, so the diff currently shows both. Once #20225 merges, this
branch will be rebased onto master and only its own commit will remain.
## Impact
* Is new feature added? Adds one new public function,
`esp_getconfiggpio()`, to `arch/xtensa/src/common/espressif/esp_gpio.h`.
No new user-facing Kconfig or behavior beyond the fix itself.
* Is existing feature changed? No — pure bug fix for
`CONFIG_PM_GPIO_WAKEUP` users; a pin not used as a wake source is
unaffected.
* Impact on hardware? Every espressif board combining `CONFIG_PM_GPIO_WAKEUP`
with a masked pin that is also a peripheral IRQ line.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host: Ubuntu 24.04, x86_64, `xtensa-esp-elf-gcc`.
* Target: Xtensa, Seeed XIAO ESP32-S3 (esp32s3-xiao),
`CONFIG_PM_GPIO_WAKEUP=y`
with GPIO3 (LSM6DS3TR-C INT1, FIFO watermark) as the wake source.
Reproduction before the fix: one light sleep cycle, and the sensor's INT1
line never interrupts again — `esp_pm_gpio_wakeup_prepare()` had reset it
to plain `INPUT`. After the fix, validated over 12 h 25 of continuous
operation: FIFO-watermark interrupts continued firing correctly across
thousands of sleep/wake cycles.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
