Debugging embedded hardware and software traces

Usually when designing embedded project we typically focus on actual application, but do not pay enough attention to hardware and software debug process. Adding debugging capability to project require some strategy. Simple situation: hardware may not be installed but connected to other circuit when needed. So software must support the functionality regardless of weather or not hardware installed. Another example may be Embedded board with multiple temperature sensors. Hardware should detect when sensor is connected or disconnected without interrupt of other sensors readings.

One way of debugging is software trace(log) to provide history information what was happening if something went wrong. This technique is good solution for developers who have no ability to use other debugging tools because of following reasons:

  • Bug appears in 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 there fore “Live” conditions are lost.

  • Using LOG traces gives another benefit like Macro History. Embedded systems usually control mechanical devices which can have significant lag between error and event that causes an error. Imagine engineer sitting and waiting when 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 analyse;

  • 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 cased by connected emulator.

  • Lack of physical connections may be another reason why use software trace. In prototyping phase there are usually debugging connections used in board. But when product goes to mass production it may not have debugging connections on it and no emulator can be connected.

  • Las but not least important is that sometimes wee need that software could correlate with outside events such as motor position, sensor output or other signal input.

What debugging information can be recorded? Actually it depends on embedded system designer. But as 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 to find 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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.