269: [v0.4.x] CI: pin to an older nightly r=korken89 a=japaric
to workaround compiletest-rs being broken on recent nightlies
this is a backport of #267 and it's required to land #265
I'm not backporting #268 (compiletest -> trybuild) because this branch has compile-pass tests which depend on compiletest and can't be ported to trybuild
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
263: [v0.4.x] CI: do not build docs r=korken89 a=japaric
The docs for the v0.4.x releases are now being built and uploaded by the master
branch
addresses #262
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
186: [backport] unlock the DWT, if locked, when using the timer queue r=korken89 a=japaric
**HEADS UP** this PR targets the branch v0.4.x
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
225: A fix that stops panics from the old MaybeUninit impl r=korken89 a=korken89
Sometimes when running in debug mode the current implementation of `MaybeUninit` would panic, an example can be found here: 2bb89427fa/examples/rtfm-uarte-interrupts/src/main.rs (L106)
On debug this line will always panic, on release all is fine.
The issue seemed to be the manual `MaybeUninit` implementation, so I have merged the two implementations together.
Please have a look and see if my fix is unsound (it does however work, but not sure on UB).
cc @japaric @TeXitoi
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
On cold boot, the DWT unit is off, which means our attempts to clear and
disable the cycle counter in pre-init don't work. This seems to result
in access to CYCCNT always returning 1073741824, which delays tasks
scheduled in init by that many cycles (~15s at 72 MHz).
Fixes#196.
This commit fixes a ceiling bug where the ceiling of a ready queue will be
incorrectly computed. The analysis was not including the priority of the system
timer interrupt (`SysTick`) in the analysis resulting in a priority ceiling
lower than what's required for memory safety which led to data races.
The bug can be observed in the following program:
``` rust
#[rtfm::app(device = /* .. */)]
const APP: () = {
#[init]
fn init() {
// ..
}
#[task(priority = 2)]
fn foo(x: i32) {
// ..
}
#[task(priority = 1, spawn = [foo], schedule = [foo])]
fn bar() {
// ..
}
extern "C" {
fn EXTI0();
fn EXTI1();
}
};
```
Here the framework chooses a priority of `2` for the `SysTick` interrupt
(because it matches the priority of the `schedule`-able task `foo`).
Both `SysTick` and `bar::Spawn.foo` need to access the ready queue (which, in
this case, stores the messages sent to task `foo`) but the framework doesn't
account for the priority of `SysTick` (`2`) and chooses a priority ceiling of
`1` for the ready queue (because it matches the priority of task `bar` which can
spawn `foo`).
The result is that `bar::Spawn.foo` modifies the ready queue *without* a
critical section (because `bar`'s priority matches the priority ceiling of the
ready queue) which is wrong because `SysTick` (priority = `3`) can also modify
the ready queue.
170: check task priority at compile time r=TeXitoi a=japaric
before we were checking the priority at runtime. The compile time error message
when the priority is too high is kind of awful though.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
158: implement RFC #128: #[interrupt(binds = ..)] r=korken89 a=japaric
closes#128
r? @korken89 or @TeXitoi
suggestions for tests are welcome! (2 of the 3 tests I added hit bugs in my implementation)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
