Crank Up The Clock |
 |
 |
 |
| Written by Graham Stoney |
|
One of the classic hard-to-find failure modes of any embedded system is when the real time clock interrupt occurs in a critical section causing an unexpected context switch, or simply adding to the latency in the current task causing something to fail. During testing, it's good to deliberately try to induce this failure mode by cranking up the real time clock rate to see what happens. Often by doing this you'll flush out a bug or two that would otherwise cause an intermittent failure in the field, and be extremely difficult to find. If you're smart and have derived all your timing values in the software from a single clock frequency or period value using macros, all you need do is change one value and recompile to preserve all the timing characteristics at the artificially higher clock speed. If the designer has done a good job, the performance of the system will degrade gracefully before the system eventually locks up because it's too busy servicing clock interrupts to do anything else. Often the rate of the real-time clock is programmable so you can do this in software; other times you might need a function generator connected to the timer interrupt input.Try running the regression test suite with the clock cranked up, and check the point at which things fail. This will also give you an idea of how much spare CPU power you have. You still need to design the code not to have critical sections that will fail in this manner, since you aren't guaranteed to hit all the failure windows; but you will hit failure windows that you didn't know about a lot faster with the clock interrupt going an order of magnitude or two quicker than you designed the system for. Social Bookmark this page:          |