Hi Felipe, Thanks for the detailed report and for tracking this down with JTAG ― that's a solid repro.
I've submitted a revert: https://github.com/apache/nuttx/pull/20041 A bit of context on why this slipped through: lckfb-szpi-esp32s3 and esp32s3-devkit use the same module (ESP32-S3-WROOM-1), which is what the nxinit switch was actually boot-tested on before being rolled out to the rest of the esp32s3 boards. The Seeed XIAO ESP32-S3, however, does not use a standard WROOM/WROVER module, so there may well be a board-specific difference involved that the lckfb testing didn't cover. I don't have this board locally, so I wasn't able to reproduce or bisect the hang myself. I've ordered one and it's on its way; once it arrives I'll continue digging into the root cause you found. Thanks again for catching this and for offering to help test. Best regards, Jianyu ________________________________ From: Felipe Moura Oliveira <[email protected]> Sent: Tuesday, September 1, 2026 10:48 PM To: [email protected] Subject: [External Mail][Request] Revert 7cc6707a76b ("boards/esp32s3-xiao: switch defconfigs to nxinit entrypoint") ― hangs boot on real hardware [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 Hi all, I'd like to propose temporarily reverting commit 7cc6707a76b ("boards/esp32s3-xiao: switch defconfigs to nxinit entrypoint", by wangjianyu3) while we investigate further. On real esp32s3-xiao hardware (Seeed XIAO ESP32-S3 Sense, chip rev v0.2), this commit hangs the board during boot before any console output is produced. It affects both defconfigs the commit touches (usbnsh and combo) identically. The board never enumerates on USB during a normal reset ― it only responds when forced into ROM download mode via the BOOT strap pin, i.e. the app image never actually runs. The commit's own message notes it wasn't boot-tested on this board ("this board has no hardware attached for a flash/boot pass in this session"), only build-verified here and boot-verified on a different board (lckfb-szpi-esp32s3). Evidence: attaching over the ESP32-S3's built-in JTAG (OpenOCD + GDB) shows the core statically stuck at the same PC and call stack across independent halts, on both defconfigs: pc 0x40041a79 #0 0x40041a79 (rsr.ccount-based busy-wait, ROM address range) #1 0x40047b51 #2 0x4004397f #3 0x40043c36 #4 0x40034c48 All five frames are in the 0x40034000-0x40048000 ROM range ― nx_start itself lives at 0x42011068 (.flash.text) in this build, a completely different region. So the hang happens inside the chip's boot ROM, before NuttX's own init code ever runs. Reverting just this commit's two defconfig changes on top of current master fixes it: the board boots normally to an interactive nsh prompt. *I can help to solve and / or test solutions in real hardware later, but for now I want to propose a temporary PR revert.* *--Felipe Moura de Oliveira* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
