Hardware and Software Debugging

Debugging:

Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.

Debugging is one of the cumbersome and tiring tasks for any programmer. The debugging skill of the programmer is probably the biggest factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the programming language used and the available tools, called as debuggers. Debuggers are software tools which facilitate the programmer to monitor the execution of a program, stop it, re-start it, set breakpoints, change values in memory and even, in some cases, go back in time. At times term debugger can also refer to the person who is doing the debugging.

Debugging Issues:

Symbian OS, a powerful, purpose-built mobile platform that has a variety of tools and techniques associated with it to enable successful application debugging. Debugging can be done on emulator or on the target hardware. There are differences between them that can be important when developing an application.

When we work on the emulated environment, software platform affects how the applications that depend on process behavior and resources that processes consume run such as scheduling activity and memory consumption. There are times when this behavior affects an application, and debugging must be done on a device instead.

All ports the emulator simulates as connected to the emulated device are PC ports. The timing and performance of these ports are dependent on the PC’s hardware and the configuration of Microsoft Windows, so those ports may differ in behavior from ports on a device. Because the host PC manages the input/output (I/O) ports, it makes real-time I/O management very difficult to simulate. Any kind of application that depends on the timing or performance of the device will not be accurate on the emulator. Any device-specific hardware, such as audio output, camera, or device buzzer, can only be generally emulated on a PC, if at all, so the emulator may exhibit different behavior from a device. Any application that depends on a hardware/software interface, such as communication modules, can be debugged only on hardware. Applications are more likely to be affected by the differences between the heap and stack sizes on the emulator and target. The heap size is typically much more generous on the emulator than it is on the target device. It is possible that when run on the platform with the tighter restrictions, the application may expose errant OOM handling behavior that did not show up on the emulator. The ARM processor on the target device imposes restrictions on address alignment that the processor running the emulator typically does not require. For the ARM processor, a 16-bit value can only be accessed at an even address, and a 32-bit value can only be accessed at an address that is an exact multiple of four. The compiler does some work behind the scenes in order to help developers to comply with these restrictions

Emulator and Hardware Debugging:

When we do debugging using emulator for IDE like Codewarrior and Carbide IDE techniques like stepping, setting breakpoints or watchpoints, viewing variable, memory, and register values, even modifying those same values, as well as many other debugging techniques are commonly used to debug programs. Programmers use various debug macros like _UHEAP_MARK and __UHEAP_MARKEND, __UHEAP_MARKENDC() , __UHEAP_CHECK , _ENABLE_DEBUG_MONITOR_ , _UHEAP_CHECKALL(). A useful aspect of macro-pairs is that they can be embedded, or nested, within each other. Developers may wish to nest macro pairs as a general debugging strategy.

Programmers point of view hardware debugging is best in all sense because in many cenarios things noramally works fine on emuator and when we check on the target device we get some crash or some different behaviour. Hardware debugging can be done through IDE like Codewarrior or Carbide or even help of these IDEs.

Metrowerks’ Target Resident Kernel (TRK) and GNU Debugger (GDB) are two beautiful Hardware debugging tools that can be used by the programmer, TRK required IDE where as GDB can work without IDE.

CodeWarrior/Carbide Debugger uses a program called MetroTRK (Metrowerks’ Target Resident Kernel) to debug a target program on the target device from the host computer. The MetroTRK program is a debug monitor that resides on the embedded system (along with the target application) and communicates with the debugger using a serial connection. Through this serial communication, MetroTRK acts as the interface between the debugger and the target board. It communicates with the debugger to service requests like the request for a register or memory value and to notify you of runtime events or exceptions as they occur on the target board. In doing so, MetroTRK supplies all the target-side services necessary to provide various levels of debugging. You control MetroTRK, and through it the target program, using the CodeWarrior debugger on the host computer. In addition, the Symbian OS supports several types of programs, including executables, application user interfaces, static and dynamic libraries, and many more. Fortunately, the CodeWarrior debugger in cooperation with MetroTRK can debug them all using the processes we’ll show you later. Therefore, once you are familiar with debugging one type of program on a target device, all the others come along free.

While powerful, the CodeWarrior/Carbide debugger does have some limitations with regard to the Symbian OS. The major one being that it cannot debug the Symbian OS kernel or any DLL’s running in kernel space.

Where possible, debugging on the emulator should be preferred; however, behavioral discrepancies between the emulator and target machine may sometimes necessitate on-target investigation target debugging using the GNU debugger (GDB) may be more beneficial.

GDB is GNU’s debugger; it facilitates debugging on a target device. The GNU debugger offers a range of features that parallel those debugging features found in most contemporary development environments. One relative drawback is that unless using a development environment that supports and integrates with GDB, the debug session is run from a command prompt — thereby limiting the normal view of the code context available in IDE debugging. However, it does always supply the file name and the line number being worked on. With this information, it is easy to follow along in parallel using the IDE
Everyone knows that debugging is twice as hard as writing a program in the first place; finally we can say that Debug tools are important as compilers while developing Symbian applications.
GDB and TRK are two beautiful tools which helped me a lot while working on different projects and lots of information regarding these tolols are present on internet and IDE documentation.
One more point i would like to add here is, for TRK you or your organisation has to pay for license where as GDB is an open source.