Fix thread_yield() on MSP430 platforms #1618
Conversation
|
With this PR, |
|
Rebase to resolve the license problem. |
|
OK, with only this PR, the |
|
You may need #1619 too: it corrects a problem with hwtimer_spin going in an infinite loop... |
|
|
|
But this really is about #1617, right? |
|
Hm, no, with only #1617 it does still fail. |
|
@LudwigOrtmann Actually, #1617 only allows us to manage correctly timers with less than 32 significative bits. The PR that actually reduce the MSP430 timer to 16 significative bits is #1619: the former prepares the terrain to the latter, which is the bug buster. You need all of #1617, #1618 and #1619 to get the MSP430 platforms robust. But I see that your tests are now passing; great! |
that is: before the newly selected thread's context is totally restored
of thread_yield(), i.e.: just after SR(R2) was pushed but before the rest of the suspended thread's context was pushed!
|
Rebased on master. |
| { | ||
| __restore_context_isr(); | ||
|
|
||
| /* we want to enable if appropriate IRQs *just after* |
|
@LudwigOrtmann If you're happy with this PR, maybe could we reassign it to OlegHahm? |
|
I am definitely and back from vacation. :) |
|
Looks good |
Fix thread_yield() on MSP430 platforms
Avoid race conditions that can cause crash on MSP430 platforms, when interruptions prevent thread context switching from being correctlty done.
It fixes the biggest cause of failure for the hwtimer_wait test on MSP430 (see issue #426), the other cause being fixed by #1619.