When designing robust software, we must determine if each task is running, and also check that the interrupts work properly, especially if an interrupt comes from a "tick" timer.
Detection is made easier if each task is executed in turn and is only executed once through the full sequence of tasks. In most implementations, this is the case, whether you are using an RTOS or a simple "round-robin" scheduler.
I am a little concerned by the comment in Massimo Manca's blog Low-Power Design: MCU Software, in which he says that some RTOSs are moving away from this approach to conserve power. However, I won't consider this possibility at the moment.
Techniques to detect the correct sequence of operation that I have used include assigning a numeric identifier to each task, and each time the task is invoked checking that the calling process has the correct identifier. "Bumping" the identifier to the next task takes place within the current task. Other techniques include checking that the stack level is correct on starting a task, and a return from a single point in all subroutines so the return details can be verified. The last two items are difficult to implement in high-level languages.
I thought more about how to add confidence that tasks execute consecutively. The idea of a Linear Feedback Shift Register (LFSR) popped into my head, and although I have not yet implemented this idea, I share my thoughts so perhaps together we can come up with a new approach. An LFSR is elemental in a CRC (cyclic redundancy check). And it found use in an early microprocessor debugging technique known as "Signature Analysis," in which monitoring a bit stream through a particular node during a fixed period results in a digital "signature." Figure 1 shows the register setup used in a Hewlett Packard HP5004A signature analyzer. I propose we use an LFSR for our thought project, because 16 bits is far more likely to reveal an error than the 256 possibilities for an 8-bit register, despite an extended execution time.
Depending on how we arrange the feedback taps, the sequence can go through each binary combination without repeating. The number of stages in the shift register extends the number of clock pulses it takes for the register to cycle, and the initial setting of the shift register (the seed) coupled with the input data (if there are input data) all affect the result.
I propose five different seed values as part of a lookup table, and for each of them a set of results at fixed clock intervals. There would also be five data words to shift into the LFSR. To start a sequence we load a seed value into the LFSR and load a data word into a public register. Each task reads and rotates the public register one bit and shifts the LSB onto the LFSR. After a full cycle of tasks (or multiple cycles) we compare the value of the LFSR to the expected result. This sequence could extend through several more task cycles. Then we could change the seed and the input data and repeat the process.
Let's extend this a bit further. If we can figure out a fixed timing ratio between the tick interrupt and the cycle of tasks we can get the timer interrupt to execute a rotation cycle for the LFSR as well, thereby confirming its operation and timing. This is somewhat akin to an external windowed watchdog. If everything was fine then you could clock a simple external watchdog. I don't believe that this is superior to some external windowed watchdogs -- you might remember my disillusionment with one particular blog -- because it all boils down to one section of code, and if it executes erroneously, the watchdog would get clocked. Nevertheless, I believe the approach has much merit. What say you?
- "The Ouroboros of the Digital Consciousness: Linear-Feedback-Shift Registers" by Clive "Max" Maxfield, EDN January 4, 1996.
- "Implementing CRCs," by Jack Crenshaw, Embedded Systems Programming, 1993.
- "Pseudo-random connections for 2 through 16 stages," Don Lancaster, The TTL Cookbook, 3rd printing 1975.
- "AN222-4: Guidelines For Signature Analysis- Understanding the Signature Measurement," Hewlett-Packard.