[riot-devel] Changing Cortex-M PendSV priority and handling in mutex.c
pekka.nikander at aalto.fi
Mon Sep 17 20:12:34 CEST 2018
>> While testing with various options and debugging quite a lot, I've seen the variants of xtimer_*sleep both to crash and block a lot. Hence, I strongly suspect that there are some latent bugs there. But I don't properly understand what is going on there. Most likely some interrupt landing in the middle of the PendSV handler somehow interacts with their mutex use, easily causing blocking and easily also corrupting the stacks.
>> My student had so big problems with xtimer_*sleep related instabilities that he reverted to use xtimer_set_msg instead.
> Unfortunately I sent the message a little bit too early. I still encounter threads, which are using xtimer_usleep, rarely and ramdomly blocking, most probably at the second mutex_lock call in _xtimer_tsleep().
> I don't have right now time to dig deeper into that but will rewrite those threads to use xtimer_set_msg instead.
My situation is worse than I thought. Apparently any thread can get blocked, typically at "bl rx" or "bl mutex" state. Other threads continue normally when this happens. Hence, so far I have always had shell access there. Previously I thought that the threads block since messages get somehow lost, but apparently that is not the case.
For our demo in the next week I don't see any other way than have a watchdog that reboots the system if any of the main threads gets blocked.
In the meanwhile, I have to learn how to use the debugger to get a stack trace of the blocked threads...
More information about the devel