boards/esp32s3-xiao: wire up Wi-Fi, guarding PM light sleep during ra… - #20100
Open
FelipeMdeO wants to merge 1 commit into
Open
boards/esp32s3-xiao: wire up Wi-Fi, guarding PM light sleep during ra…#20100FelipeMdeO wants to merge 1 commit into
FelipeMdeO wants to merge 1 commit into
Conversation
Contributor
Author
xiaoxiang781216
approved these changes
Sep 9, 2026
acassis
approved these changes
Sep 9, 2026
…dio init The in-tree esp32s3-xiao board bringup never wires up Wi-Fi at all -- unlike esp32s3-devkit/esp32s3-eye, it has no `#ifdef CONFIG_ESPRESSIF_WIFI` include of esp32s3_board_wlan.h and no call to board_wlan_init(). Add both, mirroring those boards' pattern and placement exactly. On its own this is not enough for a board that also uses CONFIG_PM: Wi-Fi's PHY/RF calibration inside board_wlan_init() cannot tolerate the clock gating of PM_STANDBY (light sleep). If the idle task enters light sleep while phy_init's calibration is still running -- which the greedy governor is free to do the moment the CPU goes idle during driver init -- the calibration hangs forever waiting on a clock that just stopped. Confirmed on real XIAO ESP32-S3 hardware: with CONFIG_PM + CONFIG_ESPRESSIF_WIFI both enabled and no guard, boot got stuck 100% of the time right after the "net80211 rom version" line, before phy_init ever printed, and never reached NSH -- reproducible across repeated flashes, 50s+ waits, not even responding to a UART wakeup keypress (a genuine hang, not quiet sleep). Fixed by holding a stronger PM lock than PM_STANDBY for the duration of board_wlan_init(): pm_stay(PM_IDLE_DOMAIN, PM_IDLE) blocks PM_STANDBY/PM_SLEEP while still allowing normal CPU idle, and pm_relax() releases it immediately after, restoring whatever floor the board's own PM policy holds otherwise. Confirmed fixed on the same hardware: boots clean to NSH with Wi-Fi + PM enabled together, `ps` shows the wifi/netdev-wlan0 kernel threads running, and `wapi scan`/ `ifup wlan0` work normally. esp32c3-devkit and esp32c6-devkit also combine CONFIG_PM with Wi-Fi, but don't need this guard today: both call board_wlan_init() well before esp_pmconfigure() (which is what actually arms the PM governor) runs near the end of bringup, so PM isn't active yet during their Wi-Fi init. This board's PM handling begins earlier in bringup, so the two can race here. Signed-off-by: Felipe Moura <moura.fmo@gmail.com> Assisted-by: Claude:claude-sonnet-5
FelipeMdeO
force-pushed
the
fix/esp32s3-xiao-wifi-pm-race
branch
from
September 9, 2026 21:54
c7985d4 to
2acc4f4
Compare
github-actions
Bot
added
Size: S
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
esp32s3-xiao's board bringup never wires up Wi-Fi at all: unlikeesp32s3-devkit/esp32s3-eye, it has no#ifdef CONFIG_ESPRESSIF_WIFIinclude of
esp32s3_board_wlan.hand no call toboard_wlan_init().This PR adds both, mirroring those boards' pattern exactly.
Wiring it up on its own isn't enough for a board that also uses
CONFIG_PM, though: Wi-Fi's PHY/RF calibration insideboard_wlan_init()cannot tolerate the clock gating ofPM_STANDBY(light sleep). If the idle task enters light sleep while
phy_init'scalibration is still running -- which the greedy governor is free to
do the moment the CPU goes idle during driver init -- the calibration
hangs forever waiting on a clock that just stopped. This PR also adds
a
pm_stay(PM_IDLE_DOMAIN, PM_IDLE)/pm_relax()guard aroundboard_wlan_init()to prevent that race.esp32c3-devkitandesp32c6-devkitalso combineCONFIG_PMwithWi-Fi, but don't hit this today: both call
board_wlan_init()wellbefore
esp_pmconfigure()(which is what actually arms the PMgovernor) runs, near the very end of bringup -- so PM isn't active yet
during their Wi-Fi init.
esp32s3-xiao's PM handling begins earlier inbringup, which is why the two can race here.
Impact
esp32s3-xiao.CONFIG_ESPRESSIF_WIFI, orthat enable it without
CONFIG_PM-- the new code is compiled outentirely in both cases.
CONFIG_PMandCONFIG_ESPRESSIF_WIFItoday (none currently do, onthis board -- Wi-Fi wasn't wired up before this PR).
Testing
Tested on real Seeed XIAO ESP32-S3 hardware (WROOM1-N8R8, 8MB octal
PSRAM), against this branch's
apache/nuttx:masterbase, using aconfig with
CONFIG_ESPRESSIF_WIFI+CONFIG_PMboth enabled (notickless scheduling involved -- this race is independent of it).
Without the PM guard (Wi-Fi wired up,
board_wlan_init()called withno lock around it): boot hangs 100% of the time, reproducible across
repeated flashes with 50s+ waits, right after the
net80211 rom versionlog line and beforephy_initever prints -- never reachesNSH, and doesn't respond to a UART wakeup keypress either (a genuine
hang, not the board just being asleep).
With the fix in this PR, boot log:
psshows thewifiandnetdev-wlan0kernel threads runningnormally alongside the rest of the system:
ifup wlan0andwapi scan wlan0both work normally, finding realaccess points: