Hello,
For a safety critical system, I would like to monitor all my threads to identify infinity loops. If an infinity loop is detected a system reset should be performed. I am going to use signals for this purpose. When a signal is missing for a specific time, an infinity loop will be detected and a system reset could be performed.
Is my approach also possible with threads created by Keil's USB and Ethernet middleware?
Thanks for replies
Consider having each thread update individual software timers by regularly setting a new "next timeout" value.
Then have a thread with suitably high priority wake up regularly and check if any software timer has a timeout.
By using indivual timeouts instead of just a flag, you can then have "fast" and "slow" threads. So a "fast" thread might specify that it must wake up and update the timer within the next 10 supervision timer ticks. While a slow thread might only give a promise that it should wake up and refresh the supervision timer within the next 10000 ticks.
Obviously, this concept only verifies that all threads regularly wake up and aren't permanently starved. It doesn't inform if a thread contains a broken state machine making it constantly wake up and stay in the same state even when outside conditions requires it to switch between different states. And it isn't simple to also supervise the state machine state value since it might be likely for a thread to actually stay in the same state for days or weeks while waiting for the condition to start performing something.
You might also consider having threads/interrupts that signals conditions to start a timer to detect starvation. But that isn't so trivial since your original atomic calls to setevent() or postmail() suddenly aren't atomic anymore.
Hello Per Westermark
I agree. A supervisor thread checking counter variables or signals served by other threads does not reliably detect starvation in all cases.
But if using a watchdog to improve the system fault tolerance, the watchdog should monitor the threads created by the middleware, too.
Example: There are several loops which potentially do not exit in the USB driver implementation for STM32F4 devices (USBD_FS_STM32F4xx.c). Maybe I trust the USB stack which have been tested by Keil so far, but I am worried about the device specific implementations.