Debugging a QNX Embedded System

About debugging embedded systems

Many embedded systems require that you use a hardware debugger to troubleshoot problems. A hardware debugger is a physical device that uses a JTAG (Joint Test Action Group) interface to connect to the target hardware.

The hardware debugger is needed to troubleshoot drivers (and in some cases, user applications) on embedded systems systems, because on these systems the drivers and user applications are linked into the same memory space as the OS kernel. If a driver or application crashes, it may crash the kernel as well, bringing down the entire system.

Because software debuggers depend on the system running, they are of little use when the OS kernel has crashed. Thus, a hardware debugger is required when the system is not running.

Debugging a QNX system

The QNX Neutrino microkernel architecture makes it easier to use a software debugger for most of your troubleshooting, but it also imposes some limitations on the use of hardware debuggers:

• All QNX Neutrino applications (including drivers) run in their own memory-protected virtual address space. This architecture increases system fault tolerance and dependability, but it prevents you from using hardware debuggers that rely on decoding physical memory addresses. When you debug user applications based in a virtual memory environment, a hardware with built-in QNX Neutrino awareness (for example, Lauterbach Trace32 In-Circuit Debugger) is required (see Using hardware debuggers).
• QNX Neutrino lets you develop multi-threaded applications, which hardware debuggers generally don't support.

For QNX Neutrino, you typically use:

• a hardware debugger for the IPL and the startup code
• a software debugger for the rest of the software (i.e. drivers, user applications)

In other words, you rarely have to use a JTAG hardware debugger, especially if you're using a QNX BSP (see the chapter Working with QNX BSPs).

The pdebug software debugging agent

QNX provides a software debugging agent called pdebug that makes it easier for you to debug system drivers and user applications. This agent runs on the target system and communicates with the host debugger over a serial or Ethernet connection.

For more information, see “The process-level debug agent” in the Compiling and Debugging chapter of the QNX Neutrino Programmer's Guide.

Using hardware debuggers

To use the pdebug software agent, the OS kernel must be running, so you need a hardware debugger to troubleshoot the IPL and the startup code. These run with the CPU in physical mode, so you can use conventional hardware debuggers, such as a JTAG debugger to troubleshoot them.

You can also use a hardware debugger to debug applications:

• You can examine registers and view memory while the kernel and applications are running, if you know the physical addresses for the applications you want to troubleshoot.
• If you have a hardware debugger with built-in QNX Neutrino awareness (for example, Lauterbach Trace32 In-Circuit Debugger), you can use JTAG to debug applications. These debuggers can interpret kernel information, as well as perform the translation between virtual and physical memory addresses to allow you to view application data.

Producing debug symbol information for the IPL and startup code

When you use a hardware debugger to debug QNX Neutrino IPLs and startup programs and do not provide any extra information, you're limited to assembly-level debugging, and assembler symbols such as subroutine names aren't visible

To perform full source-level debugging, provide the hardware debugger with the symbol information and the C source code.

This section describes how to generate the symbol and debug information required by a hardware debugger for source-level debugging. The examples assume that you're logged in on the development host with root privileges.