Anindya Dutta and Tridib RoychowdhuryJune 01, 2009 One of the challenges in real'time systems, especially in multitasking OS based implementations, is defect fixing. To resolve the defect one has to be aware of the program flow during the defect or faulty condition. Normally, this is done by using in-circuit emulators (ICE) along with the break point feature available in the environment of the emulator. However, the ICE support may not always be available for the system under consideration. Considering the case that ICE is available for the system under consideration, and the ICE hits a breakpoint, then the dynamics of the system is lost. All the interactions the system was having with some networks or other systems/modules are stopped at once. Therefore it again may be difficult to reproduce the defect or anomaly exactly.
Though some makes of ICE provides a feature of real-time trace function, but that is also limited by the ICE memory. At times it is required to stop the system in some logical trigger, so that the condition of the system can be analyzed at that point.
This feature is also not common in normal debugging systems. Finally some development systems from WindRiver, tools like WindView offer powerful debugging mechanism.
Here you can download the Power System Software VTU Notes Pdf - SS Pdf VTU of as per VTU Syllabus. Below we have list all the links as per the modules. User Interface, Editor Structure, Interactive Debugging Systems – Debugging Functions and Capabilities, Relationship With Other Parts Of The System, User-Interface Criteria. Link: Unit 5.
This mechanism allows user to track code flow and task/interrupt scheduler switching in a GUI based interface. However, the development system should have support for deploying this debugging feature. The method that we propose in this article overcomes numerous such problems with no extra investments. This requires some amount of free memory on board for both code/data and substantial amount of processing capability. The function trace re-useable component The method we have developed can be applied to debug the software/firmware of any type of real-time system and is named as 'Function Trace' (FT).
In this method, all the functions in the program are uniquely coded and as the function is executed the unique code is noted. These values are stored in a circular array in round-robin fashion. This is called as function code logging. The array contains the program flow information which can be used for debugging purposes. The basic requirement of employing this method is to have moderate speed processor with some free memory. Thus 32-bit processors are the best choice for applying this method of debugging. Depending on the processor speed this debugging method may be looked upon as an over head for low speed / low end systems.
The tracking capability of the functions executed in the system makes it best suitable for both OS based multi-thread system and as well as OS less systems. Function Trace can also be deployed in multiple locations within a given function to figure out about the program flow within a function just as we might use it for program flow within a module / thread / task. Function Trace can also be added on with time stamp provided the system considered has a counter or a Real Time Clock on board.
This enables us to figure out not only the program flow but also the time taken in various functions / modules within the system. One of the important feature of this debugging method is that it allows the user to trace only the function(s) which they intended to trace. Therefore this mechanism eliminates tracing functions which are not required, resulting into optimal usage of memory for storage of tracing data. Therefore this helps the developer to focus on the required sections of the code. Function Trace's basic operating principles The Function Trace feature ( Figure 1 below) creates an execution log of every function call defined in the application firmware. As any application-defined function is called, an entry for the current task/interrupt context (for multi-tasking system) and function called is generated in the log with the help of a unique 32-bit identifier code.
Figure 1: The Concept of Function Trace The identifier can be generated by concatenating a function code and file code, where the function is defined. To control the logging of function trace better, the functions can be divided into various levels thus allowing the control of execution flow log.
The entire application might be, for example, divided into numerous small applications. The smaller applications might be divided into modules and further into units. Thus one might think of tracing at the module level functions, some might think of module level or unit level functions for zooming into the problem area. To implement this control, a function level flag is used. All the functions are categorized into some levels. Based on the flag (set/ reset) the function will be logged to the trace for a given level. The logged data shall be stored in RAM within the embedded system, therefore the user of this method has to plan a way to retrieve the function trace data through communication ports or ICE connectivity or any other method suitable for the system under debug.
After the data is extracted, further analysis can be done upon the sequence of execution of the code during the faulty condition.
A debugger or debugging tool is a computer program that is used to test and debug other programs (the 'target' program). The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered but which will typically be somewhat slower than executing the code directly on the appropriate (or the same) processor. Some debuggers offer two modes of operation - full or partial simulation, to limit this impact. A 'crash' happens when the program cannot normally continue because of a programming bug. For example, the program might have tried to use an instruction not available on the current version of the CPU or attempted to access unavailable or protected memory. When the program 'crashes' or reaches a preset condition, the debugger typically shows the position in the original code if it is a source-level debugger or symbolic debugger, commonly now seen in integrated development environments. If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly (unless it also has online access to the original source code and can display the appropriate section of code from the assembly or compilation).
Typically, debuggers also offer more sophisticated functions such as running a program step by step ( single-stepping or program animation), stopping ( breaking) (pausing the program to examine the current state) at some event or specified instruction by means of a breakpoint, and tracking the values of some variables. Some debuggers have the ability to modify the state of the program while it is running, rather than merely to observe it. It may also be possible to continue execution at a different location in the program to bypass a crash or logical error. The importance of a good debugger cannot be overstated. Indeed, the existence and quality of such a tool for a given language and platform can often be the deciding factor in its use, even if another language/platform is better-suited to the task. The absence of a debugger, having once been accustomed to using one, has been said to 'make you feel like a blind man in a dark room looking for a black cat that isn’t there'.
However, software can (and often does) behave differently running under a debugger than normally, due to the inevitable changes the presence of a debugger will make to a software program's internal timing. As a result, even with a good debugging tool, it is often very difficult to track down runtime problems in complex multi-threaded or distributed systems. The same functionality which makes a debugger useful for eliminating bugs allows it to be used as a software cracking tool to evade copy protection, digital rights management, and other software protection features.
It often also makes it useful as a general testing verification tool test coverage and performance analyzer, especially if instruction path lengths are shown. Most current mainstream debugging engines, such as gdb and dbx provide console-based command line interfaces. Debugger front-ends are popular extensions to debugger engines that provide IDE integration, program animation, and visualization features. Some early mainframe debuggers such as IBM OLIVER (CICS interactive test/debug) and SIMON (Batch Interactive test/debug) provided this same functionality for the IBM System/360 and later operating systems, as long ago as the 1970s. Contents.
Language dependency Some debuggers operate on a single specific language while others can handle multiple languages transparently. For example if the main target program is written in COBOL but CALLs Assembler subroutines and also PL/1 subroutines, the debugger may dynamically switch modes to accommodate the changes in language as they occur. Memory protection Some debuggers also incorporate memory protection to avoid storage violations such as buffer overflow. This may be extremely important in transaction processing environments where memory is dynamically allocated from memory 'pools' on a task by task basis.
Hardware support for debugging Most modern microprocessors have at least one of these features in their CPU design to make debugging easier:. hardware support for single-stepping a program, such as the trap flag. An instruction set that meets the Popek and Goldberg virtualization requirements makes it easier to write debugger software that runs on the same CPU as the software being debugged; such a CPU can execute the inner loops of the program under test at full speed, and still remain under the control of the debugger.
In-System Programming allows an external hardware debugger to re-program a system under test (for example, adding or removing instruction breakpoints). Many systems with such ISP support also have other hardware debug support. Hardware support for code and data breakpoints, such as address comparators and data value comparators or, with considerably more work involved, page fault hardware. JTAG access to hardware debug interfaces such as those on ARM architecture processors or using the Nexus command set. Processors used in embedded systems typically have extensive JTAG debug support.
Debugging Functions And Capabilities In System Software
Microcontrollers with as few as six pins need to use low pin-count substitutes for JTAG, such as BDM, Spy-Bi-Wire, or DebugWire on the Atmel AVR. DebugWire, for example, uses bidirectional signaling on the RESET pin. List of debuggers. Winpdb debugging itself.