-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix an infinite loop in interrupt executors #1936
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
f0d278f
Add failing test
bugadani 7c3a860
Fix interrupt executor looping
bugadani b7758e3
Fix formatting
bugadani cd20ed2
Fix changelog reference
bugadani 8feb39e
Move changelog to the right crate
bugadani b35d9f5
Remove dead code
bugadani File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,66 @@ | ||
//! Test that the interrupt executor correctly gives back control to thread mode | ||
//! code. | ||
|
||
//% CHIPS: esp32 esp32c2 esp32c3 esp32c6 esp32h2 esp32s2 esp32s3 | ||
//% FEATURES: integrated-timers | ||
|
||
#![no_std] | ||
#![no_main] | ||
|
||
use embassy_sync::{blocking_mutex::raw::CriticalSectionRawMutex, signal::Signal}; | ||
|
||
macro_rules! mk_static { | ||
($t:ty,$val:expr) => {{ | ||
static STATIC_CELL: static_cell::StaticCell<$t> = static_cell::StaticCell::new(); | ||
#[deny(unused_attributes)] | ||
let x = STATIC_CELL.uninit().write(($val)); | ||
x | ||
}}; | ||
} | ||
|
||
#[embassy_executor::task] | ||
async fn interrupt_driven_task(signal: &'static Signal<CriticalSectionRawMutex, ()>) { | ||
loop { | ||
signal.wait().await; | ||
defmt::info!("Received"); | ||
} | ||
} | ||
|
||
#[cfg(test)] | ||
#[embedded_test::tests] | ||
mod test { | ||
use defmt_rtt as _; | ||
use esp_backtrace as _; | ||
use esp_hal::{ | ||
clock::ClockControl, | ||
interrupt::Priority, | ||
peripherals::Peripherals, | ||
system::{SoftwareInterrupt, SystemControl}, | ||
}; | ||
use esp_hal_embassy::InterruptExecutor; | ||
|
||
use super::*; | ||
|
||
#[init] | ||
fn init() -> SoftwareInterrupt<1> { | ||
let peripherals = Peripherals::take(); | ||
let system = SystemControl::new(peripherals.SYSTEM); | ||
let _clocks = ClockControl::boot_defaults(system.clock_control).freeze(); | ||
system.software_interrupt_control.software_interrupt1 | ||
} | ||
|
||
#[test] | ||
#[timeout(3)] | ||
fn run_interrupt_executor_test(interrupt: SoftwareInterrupt<1>) { | ||
let interrupt_executor = | ||
mk_static!(InterruptExecutor<1>, InterruptExecutor::new(interrupt)); | ||
let signal = mk_static!(Signal<CriticalSectionRawMutex, ()>, Signal::new()); | ||
|
||
let spawner = interrupt_executor.start(Priority::Priority3); | ||
|
||
spawner.spawn(interrupt_driven_task(signal)).unwrap(); | ||
|
||
signal.signal(()); | ||
defmt::info!("Returned"); | ||
} | ||
} |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting ... docs could be a bit better at explaining the meaning of the result 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I agree, as far as I understand it's along the lines of "true: a timer has been set and will trigger a tick if needed; false: the next alarm is in the past, do a re-poll".
IMO set_alarm shouldn't even be called when I experience the error but I expect getting this changed in embassy is a larger task. And I don't know if the current state of things is caused because some time drivers may handle u64::MAX as a valid alarm value?
cc @Dirbaio do you have an opinion whether we can change embassy-executor to not call set_timer if there is no valid next expiration value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason it calls
set_alarm(u64::MAX)
is to cancel an existing timer from a previous poll if any. This can happen if on a previous poll a task was waiting on a timer, and then on this poll it's not anymore. This can happen if you cancel the timer, for example if it was before waiting on either a gpio event or a timer, and now is waiting on a gpio event only.Not calling
set_alarm(u64::MAX)
would do one "useless" poll when the stale timer expires.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this piece of code would ideally unset the alarm, not just "do nothing, return true".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've posted embassy-rs/embassy#3255 which clarifies this, please let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an interesting assumption that we have any active alarms, but the explanation makes sense and I guess it points at the current PR being incomplete. Thank you.