>> 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... --Pekka _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
