Debugging QNX Embedded Systems

QNX SDP8.0Building Embedded SystemsConfigurationDeveloper

The microkernel architecture of QNX OS means that debugging QNX embedded systems can be different from debugging other 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 sometimes, user applications) on embedded 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.

Through the QNX Momentics IDE, you can perform hardware debugging using the Lauterbach TRACE32® In-Circuit Debugger, which supports the JTAG interface. Instructions on setting up and using this debugger are given in the JTAG: Debugging with Lauterbach TRACE32 chapter of the QNX Momentics IDE User's Guide.

The QNX OS design makes it easier to use a software debugger for most of your troubleshooting, and also imposes some limitations on the use of hardware debuggers:
  • All applications (including drivers) run in their own memory-protected virtual address space. This design increases system fault tolerance and dependability, but it prevents you from using hardware debuggers that rely on decoding physical memory addresses. When you debug applications based in a virtual memory environment, a hardware debugger with built-in QNX OS awareness (such as the Lauterbach Trace32 In-Circuit Debugger) is required.
  • QNX OS lets you develop multi-threaded applications, which hardware debuggers generally don't support.

For QNX OS, you typically use a hardware debugger for the IPL and the startup code, and a software debugger for the rest of the software (i.e., drivers, user applications). In other words, you rarely have to use a 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 information about configuring and using it for debugging, see the QNX Momentics IDE User's Guide.

Using hardware debuggers

To use the pdebug software agent, the OS kernel must be running. If you're experiencing problems with the kernel crashing or not being started, you need a hardware debugger to troubleshoot the IPL and startup code. These run with the CPU in physical mode, so you can use conventional hardware debuggers, such as JTAG debuggers, 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 OS awareness (e.g., the Lauterbach Trace32 In-Circuit Debugger), you can use JTAG to debug applications. The debugger can interpret kernel information, and translate 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 OS IPLs and startup programs and you don't 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, you must provide the hardware debugger with the symbol information and the C source code.

The sections that follow describe how to generate the debug symbols required by a hardware debugger for source-level debugging. The examples assume that you're logged in on the development host with root privileges.

Page updated: