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
The System and Thread Viewer displays system state information and running threads for an RTOS application, see: www.keil.com/.../uv4_db_dbg_systhread_viewer.htm
Also, the Event Viewer displays thread, interrupt, and exception execution over time, see: www.keil.com/.../uv4_db_dbg_event_viewer.htm
FYI - there is also be a very nice feature implemented with our latest version of MDK-ARM V5.22, the Event Recorder, see: http://www.keil.com/support/man/docs/uv4/uv4_db_dbg_evr.htm
Also take a look at our Application Notes at: http://www.keil.com/appnotes/list/arm.htm
AppNotes 209 might be helpful, as it explains "Cortex-M3 and Cortex-M4 Fault Exceptions", see: http://www.keil.com/appnotes/docs/apnt_209.asp
@R. Kopsch,
It could be interesting to see, per thread, the value of its PC...
Hello R. Kopsch,
thanks for your replies.
My intention is to observe the threads inside application code running on a microcontroller and not to watch debug information with uVision. System and thread viewer, the event viewer and the event recorder only offers debug informations to a connected debug probe and are not usable for application code. Is this correct?
Indeed, I have a requirement to monitor third party software components. I need an indicator that the component is running correctly (no deadlock). In case of network component it is perhaps more applicable to use the loop back interface (localhost) to verify that the network component is working correctly. In my opinion, this would be a good self-test of the network component. How could I check the USB component in such a way?
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.