Make sure systimer period is loaded and reset #322
Closed
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.
This fixes some obscure problem that was first reliably discovered in #300 but I think I also have seen it on ESP32-C3's static-ip example (but there it magically disappeared)
While I cannot really explain what is happening (I thought the problem was the scheduler starting to switch tasks while not all needed interrupts were enabled - which is not the problem) this seems to reliably eliminate the problem and is also an improvement generally
Turned out
alarm0.set_period
only sets the period in systimer's registers but doesn't load them by writing totimer_compX_load
.(Probably something that should be addressed ultimately in the HAL)
When a
yield_task
is executed, this means that the switched to task might not be given a full time-slice and also triggers the bug seen in the linked PR.This PR additionally disables interrupts globally until all the interrupts are configured (which on itself already would fix the problem)
I also found a way to reproduce the problem on current
main
(at the time of writing):#[cfg(coex)]
cargo run --release --example ble --features=ble,wifi