When designing an embedded project, we typically focus on the actual application but do not pay enough attention to the hardware and software debugging process. Adding the debugging capability to the project requires some strategy. Simple situation: hardware may not be installed but connected to another circuit when needed. So software must support the functionality regardless of whether or not hardware is installed. Another example may be Embedded inboard with multiple temperature sensors. Hardware should detect when the sensor is connected or disconnected without interrupt other sensors’ readings.
One way of debugging is software trace(log) to provide historical information on what was happening if something went wrong. This technique is a good solution for developers who have no ability to use other debugging tools because of the following reasons:
- The bug appears in a customer environment where emulators and debuggers cannot be connected or where emulators would stop critical work. Using debuggers and emulators may disturb normal system work; their fore Live conditions are lost.
- Using LOG traces gives another benefit like Macro History. Embedded systems usually control mechanical devices that can significantly lag between error and event that causes an error. Imagine an engineer sitting and waiting when an error will occur. Emulation is good when error event time is known. According to recorded logs, it is easy then to capture an error and analyze it;
- Another reason why software trace may be useful is limited resources. Smaller chips are limited and may not have debugging capabilities;
- Sometimes emulation may not produce the error because of some hardware problems caused by the connected emulator.
- Lack of physical connections may be another reason why use software trace. In the prototyping phase, there are usually debugging connections used inboard. But when a product goes to mass production, it may not have to debug connections on it, and no emulator can be connected.
- Finally, it is important that sometimes we need that software to correlate with outside events such as motor position, sensor output, or other signal input.
What debugging information can be recorded? Actually, it depends on an embedded system designer. But as a minimum you may track:
- Each entry to interrupt routine;
- Exit from interrupt;
- Execution of major functions;
- Each time a message is passed;
Such data is called action codes. They allow finding a correlation between software execution and real-world events. Action codes may be captured in different ways. One way is to use external hardware where action codes may be sent; another way is to store them in memory for later retrieval.