Do not enter wfi when SBA access would not work#4782
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses an issue where RISC-V ESP32 CPUs entering WFI (Wait For Interrupt) prevented debuggers from reading memory via SBA (System Bus Access) when SYSTEM_CPU_WAIT_MODE_FORCE_ON is disabled. The solution applies a workaround from esp-idf that checks if a debugger is connected before entering WFI mode.
Changes:
- Created a unified
wait_for_interrupt()function inesp_hal::interruptfor both RISC-V and Xtensa architectures - Removed architecture-specific
idle_hook()implementations from task modules and replaced them with a unified version that callswait_for_interrupt() - Added RISC-V-specific logic to skip WFI when a debugger is connected and
cpu_wait_mode_force_onis disabled
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| esp-hal/src/interrupt/riscv.rs | Added wait_for_interrupt() function with debugger detection logic and cpu_wait_mode_on() helper |
| esp-hal/src/interrupt/xtensa.rs | Added simple wait_for_interrupt() function wrapping waiti 0 instruction |
| esp-rtos/src/task/mod.rs | Added unified idle_hook() using esp_hal::interrupt::wait_for_interrupt() |
| esp-rtos/src/task/riscv.rs | Removed RISC-V-specific idle_hook() implementation |
| esp-rtos/src/task/xtensa.rs | Removed Xtensa-specific idle_hook() implementation |
| esp-hal/CHANGELOG.md | Added changelog entry for the new function |
| esp-rtos/CHANGELOG.md | Added changelog entry for the idle hook fix |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Interesting - I remember I stumbled upon Nice find! |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
should we align that? |
|
Eventually yes, I imagine saving power is better than not saving power 😅 But this code comes from depths of C hell. |
bjoernQ
left a comment
There was a problem hiding this comment.
LGTM
We probably want to create an issue to set SYSTEM_CPU_WAIT_MODE_FORCE_ON to a defined state?
|
@MabezDev I'd like this backported as latest probe-rs needs it |
|
Created backport PR for
Please cherry-pick the changes locally and resolve any conflicts. git fetch origin backport-4782-to-esp-hal-1.0.x
git worktree add --checkout .worktree/backport-4782-to-esp-hal-1.0.x backport-4782-to-esp-hal-1.0.x
cd .worktree/backport-4782-to-esp-hal-1.0.x
git reset --hard HEAD^
git cherry-pick -x 3d68e27485e56aeeadc76ebe494a8bfd89579545
git push --force-with-lease |
In a recent probe-rs PR I've fixed a bunch of issues that caused RISC-V CPUs to be halted when they otherwise don't need to be. This, however, caused some issues with RTT: on a C3, if the CPU entered WFI, probe-rs was no longer able to read the RTT buffer (originall reported here).
Turns out this issue has been worked around in esp-idf long ago. I'm applying that workaround to esp-hal here.
All RISC-V CPUs are affected, it just doesn't look like that, because we accidentally have
SYSTEM_CPU_WAIT_MODE_FORCE_ONenabled on some of them.