Self-Testing in Embedded Systems is an important phase in the development of products that not only reduce bugs but also help to get rid of failure of Systems. Embedded systems have found their way to all areas of electronics, including power electronics where computer control has started to replace analog circuitry in modern industry-level power supply units.
Clients are demanding increasingly complicated and more complex control and monitoring features that have created a requirement for including microprocessors and embedded systems on power electronics products. Thus software has eventually become an important part of product development process in power electronics.
Issues that Led to Error with Embedded Product Development
As the demand for these embedded product development services become more which also carry the possibilities of failure also. Predicting a failure in embedded systems is tough, as this requires knowledge of the nature of the bug that leads to the failure and, if that knowledge were available, the bug would have been repaired easily.
There are two types of errors coming in this system, data corruption and code looping. I am going to discuss both for your help that how to overcome these errors.
Data corruption
The best feature of the C language is also the most common cause of errors and faults called pointers. Data is most likely to become corrupt if it is written via a pointer. The problem is there is no easy way to detect an invalid pointer. If the pointer is NULL, so it makes the results in a trap, so ensuring the suitable trap handler installation as a start. A similar trap can handle the situation where non-existent memory address is presented by a pointer. However, if the address is valid but incorrect, random errors may occur.
Stack Overflow/Underflow and Array Bound Violation
Stack Overflow
Stack space allocation is something of a black art. Although there are static analysis tools around that can help but careful testing during development is wise. This may involve filling the stack with a “fingerprint” value, and then looking at utilization after some period of code execution, or write access breakpoints may be employed.
Array Bound Violation
Access to arrays is carefully controlled so that accesses can only occur validly within their allocated memory space. One reason why there is normally no checking in C is that this would introduce a runtime overhead every time an array element if accessed, which is likely to be unacceptable. This could be implemented in C++ by overloading the operator.
Code Looping
Testing of code logic should eliminate all situations where the execution might get stuck in a loop. However, this is difficult to do with total proficiency, particularly to do embedded applications testing, as the termination of a loop may be dependent on some event that is external to the code under test.
Ideally, careful design means that timeouts are included in any context where the code might get stuck, but this is not always possible and may be overlooked. The best way to ensure that code is not stuck is to employ a watchdog timer.
This is some simple hardware that needs periodical addressing to stop it from “biting”. If the present delay is exceeded and the watchdog bites, an interrupt or reset will result. Watchdog refresh code needs to be included at strategic points in the execution flow. A watchdog task may simply use a bank of event flags, all of which it sets to 1 and other task requires to clear a specific flag down to 0 periodically. If the watchdog task observes an unclear flag, the action is taken.
