Static/dynamic integrated debugging mode for embedded LINUX system

                  In the existing embedded LINUX system development process, all engineers are tired of using two different debugging modes to debug the system kernel and application separately. First, configure and start the LINUX system through a JTAG debugging tool; after the embedded LINUX system is running normally, it is necessary to continue debugging through GDB.

LAUTERBACH combines these two traditional debugging techniques to provide a new LINUX debugging technology.

This article takes the development of LINUX system on ARM architecture as an example to introduce and compare the implementation and application of these three different debugging modes.

Static Debug Mode

Tools for software debugging via the JTAG debug interface can only work in static debug mode. Both the processor and the entire system must be suspended at the same time. The debug tool then retrieves and displays the current state of the processor and target system through the JTAG interface (as shown in Figure 1).

static debug mode has the following advantages:

static debug mode only environmental needs is the target system must support the standard JTAG debugging, the debugging mode of the biggest advantages is that we can support from reset Vector table starts debugging;

As long as the debugging tool supports LINUX and MMU debugging, debugging of LINUX kernel and process out of bounds can be realized;

If the software is abnormal, the processor can be suspended at any time. , check the current error code and system status;

Because the processor is in a suspended state, the kernel and other processes will not cause any interference to the system.

However, the static debug mode has its drawbacks. Once the processor is suspended, all communication interface processes are terminated at the same time. The result is that all external devices that communicate with the processor via an interface such as Ethernet, Bluetooth, or CAN will be disconnected because they wait for a response timeout. Therefore, when debugging in static mode, even if you only debug one of the processes or functions, it is possible to change the state and configuration of the entire system; then continue to run and debug the program, the system integrity and continuity cannot be guaranteed, so Subsequent debugging may not make any sense.

Dynamic Debug Mode

GDB Debug Mode is a general-purpose dynamic debug mode for embedded LINUX systems. In this mode, it is possible to suspend only the current process, and the kernel of the system and all other processes continue to be running.

However, GDB is a pure software debugging tool and requires the following software environment:

There must be active GDB Server LINUX processes on the target system

Host end have corresponding debugging software, such as the TRACE32 (FIG. 2)

TRACE32 GDB Server via a state with the RS232 or Ethernet communication interface, the collection process is currently suspended. However, to implement the dynamic debugging mode, it must be based on the following two conditions:

The target system has been properly initialized and started correctly

GDB Server is always active Status —— that is, the communication interface has been run correctly, the processor or GDB Server will not be suspended by other program errors

In summary, both debug modes have their own advantages and disadvantages, static The debugging mode is relatively easy to implement, and the operation is relatively simple, but the continuity and integrity of the system cannot be guaranteed; the dynamic debugging mode environment requires more complicated environments. Therefore, LAUTERBACH provides debugging tools that can implement the above two debugging modes, fully exploiting their respective advantages while fully overcoming their respective defects, and realizing the leap of embedded LINUX debugging technology.

Integrated static and dynamic debug mode

For embedded LINUX systems, the TRACE32 debug tool that supports integrated static and dynamic debug modes works as follows (shown in Figure 3):

1. The TRACE32 debug tool enters the static debug mode via the JTAG interface. In the static mode, the environment configuration of the hardware and dynamic debugging mode (GDB) of the target system is first completed.
2. If the target system initialization and startup program is the focus of debugging, use the static debugging mode for debugging.

3. After the target system is properly booted, TRACE32 can be switched to dynamic debug mode for dynamic debugging of the application.

4. If you are in the process of dynamic debugging, you need to re-configure and initialize the system. TRACE32 also supports switching the system to static debug mode at any time.

At the same time, due to the implementation of the integrated static and dynamic debugging modes, many of the following new properties have also been added to the dynamic debugging mode.

For ARM architecture-based processors, you can use the debug communication channel (DCC) as the information communication interface for dynamic debug mode. This requires only one JTAG interface to support integrated static and dynamic debug modes.

Simultaneous debugging of two or more processes.

Using DCC as a communication interface

Under the ARM architecture, the DCC communication interface is already included in the JTAG interface. When the application is running on the target processor, it is completely feasible to implement the following two inter-module information communication through DCC.

Debugging software on the host side

Any application on the target system — via GDB Server

Therefore, if TRACE32 uses DCC as the interface for communication with GDB Server, Additional communication interfaces are needed to support dynamic debug mode (as shown in Figure 4).

debug multiple processes at the same time

In the actual debugging process, often need to debug multiple processes simultaneously. To implement this property, LAUTERBACH provides the T32Server module for dynamic debugging mode. If the T32Server is started as a LINUX process from the terminal window, the following commands and operations can be implemented:

Startup process (TASK.RUN)

Select the running process (TASK.SELECT)

stop the process (TASK.KILL)

when a process is started and checked, T32Server will be assigned a separate GDB Server for each process (As shown in Figure 5), with the above three TASK operation commands, you can achieve simultaneous modulation of multiple processes. The user can view the current process information through the command (TASK.LIST).