Debugging Technology for 32-bit ARM Embedded Processors

With the increasing demand for high processing power, real-time multitasking, network communication, and ultra-low power consumption, traditional 8-bit machines can no longer meet the requirements of new products. High-end embedded processors have entered the field of vision of domestic developers and have been widely valued and applied in China. The ARM core series processors are system-level chips developed by the British ARM company and licensed to other chip manufacturers for production. At present, they have reached a 70% share in the embedded 32-bit processor market. In the process of debugging Samsung's ARM7 chip technology, the author summarized the debugging technology of these high-end embedded systems.

Traditional debugging tools and methods have the disadvantages of over-reliance on chip pins, inability to work properly under high-speed operation of the processor, occupying system resources and unable to track and hardware breakpoints in real time, and being too expensive. At present, the use of embedded high-end processors is becoming more and more popular. These processors often run at 100MHz, and some internal control and internal memory bus signals are not reflected on external pins. This development trend of system on chip (System on Chip), deep embedding, and complex software has brought great challenges to traditional debugging tools and inconvenience to the work of embedded processor development engineers, which requires more advanced debugging technologies and tools to match. This article will introduce in detail several on-chip debugging technologies (on-chip debugger) used in ARM processors. These on-chip debugging technologies can reduce costs by adding debugging modules to the hardware logic of the chip, realize the functions of traditional online emulators and logic analyzers, and realize real-time tracking and analysis under certain conditions to optimize software code.

1 Boundary Scan Technology (JTAG)

Boundary scan technology is adopted by the IEEE1149.1 standard to meet the needs of today's deep embedded system debugging. The full name is Standard Test Access Port and Boundary Scan Architecture. JTAG follows the 1149.1 standard and is a user-oriented test interface. It is the basis for ARM processor debugging. The ARM E-TRACE debugging mode mentioned in this article is actually an enhanced version of JTAG. The debugging methods of some other 32-bit embedded processors also basically follow this standard. This user interface generally consists of 4 pins: test data input (TDI), test data output (TDO), test clock (TCK), test mode selection pin (TMS), and some also add an asynchronous test reset pin (TRST). Its architecture is shown in Figure 1.

The so-called boundary scan is to connect all the pins inside the chip through the boundary scan unit (BSC), introduce from the TDI of JTAG, and lead out from TDO. The boundary scan chain inside the chip is composed of many BSCs, and many functions of online emulators can be realized through these scan units. According to the provisions of 1149.1, the on-chip debugging logic in the chip usually includes a test access interface controller (TAP). It is a 16-state finite state machine and test instruction registers, data registers, bypass registers and chip identification registers. In normal mode, these test units (BSC) are invisible. Once entering the debugging state, the debugging instructions and data enter from TDI, along the test chain through the test unit to the various pins and test registers of the chip, and different test functions are completed through different test instructions. Including external modes for testing external electrical connections and peripheral chip functions and internal modes for chip internal functional testing (for chip manufacturers), you can also access and modify CPU registers and memory, set software breakpoints, single-step execution, download programs, etc. Its advantages are as follows:

The electrical connection of the entire board can be tested through boundary scan operation, which is convenient for surface mount components;

Sampling of each pin signal, and forced pin output to test peripheral chips;

· Software can be downloaded, executed, debugged and controlled, providing a path for complex real-time tracking and debugging;

It can debug multi-core and multi-processor boards and chips, and provide chip manufacturers with a way to produce and test chips through serial connection (as shown in Figure 2).

Although JTAG debugging does not occupy system resources and can debug chips without external buses at a very low cost, JTAG transfers data sequentially through the serial port, which is slow and can only perform debugging at the software breakpoint level. It cannot perform complex debugging functions such as real-time tracking and multiple event triggering. Therefore, there are several enhanced versions with more complete functions.

2 Real-time debugging solution for ARM chips (E-TRACE)

ARM's core chip uses E-TRACE on-chip debugging mode. It is actually an upgraded version of JTAG, which completes real-time debugging through enhanced auxiliary on-chip debugging hardware and solves many problems that are difficult to solve with traditional debuggers.

Figure 2 Debugging for multiple cores and multiple processors

Its real-time debugging solution is solved in three ways:

EmbeddedICE hard logic;

Real-time monitoring;

Real-time tracking.

The EmbeddedICE logic unit exists in the ARM7TDMI, ARM9TDMI, ARM9E and ARM10 cores. It adds hardware breakpoint registers and comparators on the basis of the JTAG port. The hardware breakpoints can be set through the values ​​of the breakpoint registers. Not only the address but also the complex trigger control settings of the data and control bus signals can be performed, instead of just interrupting at the instruction level (such as soft interrupts), so as to meet the interrupt response to specific events, greatly increasing flexibility. At the same time, breakpoints and observation points can be set in ROM, which greatly facilitates debugging. Its schematic diagram is shown in Figure 3. [page]

Real-time monitoring is a further improvement in ARM9E and ARM10. It changes the disadvantage of EmbeddedICE entering debug mode and stopping the kernel operation after triggering an interrupt, and enters a very small interrupt monitoring program, and quickly transfers control to the previous task after obtaining the required information (this is the biggest difference from the remote monitor). In the monitoring program, the processor can completely receive external interrupts and other trigger events instead of stopping operation. This method combines the advantages of JTAG and remote debugging, and it can add the following two benefits:

Debugging the foreground task (i.e. the task that was running when the interrupt occurred) without disabling interrupts;

Memory can be read, written, and modified without stopping the processor (very important for electromechanical devices).

Even more powerful is ARM's real-time trace solution, which consists of three parts:

Embedded tracing microkernel;

Tracking analyzer;

·Tracing and debugging software.

These three tools can achieve complete real-time tracing. The trace microcore exists in the chip. It can monitor the information of the chip bus in real time without stopping the CPU. It sends all the information within the set trigger range to the external trace analysis instrument in a compressed manner while the CPU is running. The analysis and tracing instrument receives information from the outside of the chip through the trace port (another interface different from JTAG). Because it is compressed data, the analyzer does not need to use the same speed as the real-time tracing of the trace microcore. This greatly reduces the cost of analysis and increases the storage capacity. The PC-side trace software reorganizes the data from the analyzer to reproduce the historical state and data of the processor and the program flow. At the same time, the execution code can be linked to the source code, allowing the debugger to quickly understand the trace data. ARM's approach solves many drawbacks of traditional online emulators (ICE) and logic analyzers through real-time tracing hardware inside the chip and low-cost analysis instruments. Its schematic diagram is shown in Figure 4.

3 Nexus Standard

Since the JTAG IEEE1149.1 standard came out, more and more high-end embedded chip manufacturers have begun to adopt this standard. However, the 1149.1 standard can only provide a static debugging method, such as starting and stopping the processor, software breakpoints, single-step execution, and modifying registers, but cannot provide information when the processor is running in real time. Therefore, each manufacturer has strengthened and expanded the original basic functions of JTAG on its own chips, such as the aforementioned E-TRACE, background debugging mode BDM (Background Debugging Mode) and on-chip emulation OnCE (On-Chip Emulation), etc., to perform real-time debugging without stopping the processor.

Because these enhanced JTAG versions are different from each other, and even different products from the same manufacturer are different, some chip manufacturers and debugging tool development companies established the Nexus 5001 Forum in 1998 to propose a unified standard for embedded processor scheduling based on JTAG.

Nexus divides debugging development into four levels. Starting from the first level, the complexity of each level increases, and the upper level functions cover the lower level. The first level uses simple static debugging of JTAG; the second level supports programming tracking and real-time multi-task tracking, and welcomes users to use I/O pins as multiplexed auxiliary debugging ports; the third level includes data write tracking during processor operation and memory read and write tracking; the fourth level adds storage replacement and triggers complex hardware breakpoints. Starting from the second level, Nexus specifies a variable auxiliary port. The auxiliary port uses 3 to 16 data pins to help other auxiliary debugging tools such as emulators and analyzers. Its schematic diagram is shown in Figure 5.

The Nexus standard can solve the following problems:

Debugging processors whose internal buses are not exposed, such as chips with on-chip memory;

High-speed debugging that cannot be achieved with traditional in-circuit emulators;

Deep pipelines and chips with on-chip caches that can detect which specific instructions are fetched and ultimately executed;

·Multi-core processor debugging can be performed stably.

4. Outlook of Debugging Technology

From the above analysis, it can be seen that the current debugging technology can play its advantages when the frequency is 100MHz, the internal bus is not visible to the outside, and real-time tracking is required, making up for the shortcomings of traditional remote debuggers and online emulators, and the cost is very low.

At the same time, debugging technology is still developing. At present, the IEEE1149.4 standard has been produced. It mainly uses the boundary scan structure to debug mixed analog and digital chips. Nexus has also completed the formulation of standards and some manufacturers have begun to provide Nexus debugging hardware modules on chips. However, whether these standards will be adopted by various chip manufacturers still needs to wait for the right time. In particular, the two major core companies ARM and MIPS each use their own unique core debugging technology. ARM uses E-Trace based on the JTAG version, while MIPS uses EJTAG - enhanced JTAG technology. Their attitude towards Nexus is also to wait and see.