Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 117 of 189

l c:r. 0 to replace it, the watchdog will be ren- dered tooth les ·. The simplest way for a device to do a start-up self-test is to allow the watchdog to timeout, causin g a processor reset. To avoid looping infinite ly in this way, it is necessary to d istingui sh the power-on case from the watchdog reset case. If the reset was due to a power-on , then perform this test, but if th e reset was due to a watchdog bite, th en we may already be runn ing th e test. Usua lly you will want to write a value in RAM that will be prese rved through a reset, so you can check if the reset was due to a watchdog test or to a real fai lure. A counte r should be incremented while waiting for th e reset. Mter the reset, ch eck the counte r to see how long you had to wait for the timeout, so you are sure that th e watchdog bit after the cor- rect interval. If you are counting the number of watchdog resets in order to decide if the system should give up trying, then be sure that you do not inadvertently count the watchdog test reset as one of those. Multitasking A watchdog strategy has four objec- tives in a multitasking system: IJ= PS~ Download Free software today, and configure your embedded design with your mouse! designers needing to integrate programmable logic along with high density Flash and SRAM into embedded designs. Unlike all other opt.ions, PSDs form an integrated system level solution that saves time, power, and costs. Wafcrscale's software development/ prngramming tools ... PSDsoft Express and the new PSDsoft 2000, provide an easy to use, point and click user interface in which an engineer can accomplish in a couple of hours what may have, in the past, taken several days. Visit our website roday to learn more about EasyFLASH PSDs and to download your free copy of PSDsoft Express! r - "0et¥.dopment Kits starll11g a / S99 ( 1/!{l i/(lb/(! 1/0l/J . www. E ~re;;c'iii:co;;;' Waferscale-USA • Tel. 800-832-6974 • Fax 510-657-5916 • • The extra code added to the nor- mal tasks (as distinct from a task created for monitoring tasks) must be small , to reduce the likelihood of becoming prone to errors itself • The amount of system resources used, especially CPU cycles, must be reasonable 116 NOVEMBER 2000 Embedded Systems Programming • To detect an operating system fail- ure that is preventing some or all of the tasks from running • To detect an infinite loop in any of the tasks • To detect deadlock involving two or more tasks • To detect if some lower priori ty tasks are not getting to run because higher priority tasks are hogging the CPU Typically, not enough timing infor- mation is available on the possible paths of any given task to check for a minimum execution time or to set the time limi t on a task to be exactly the time taken for the longest path. Therefore, while all infini te loops are detected, an error that causes a loop to execute a number of extra itera- tions may go undetected by the watch- dog mechanism. A number of other considerations have to be taken in to account to make any scheme feasible:

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12