Based on ARM7 kernel (PLA Information Engineering University) Wang Jinglin Su Jie Zhan Zhao Summary: This article discusses embedded application debugging technology based on ARM7 kernel, for the difficult point of which: How to adjust the curing in the ROM Code, how to use the software simulator to simulate external devices. Keywords: ARM, debugger, simulator The debugging of embedded application based on ARM7 core Wangjinglin SujieZhanhengkong (Information Engineering University) Abstrct: This article discussed the debugging of embedded appliction based on ARM7 core. Simulating Peripheral With The SIMULATOR AND SOURE Analyzed in detail.keywords: arm7, debugger, Software Simulator Introduction: Embedded processor is a complex high-tech system, to master and develop in a short time All functions are very difficult, and market competition requires a product to be available quickly, this contradiction requires the embedded processor to be able to easily master and use the development tool platform. Improve users and programmers - investment return. In the military products such as PDA, STB, DVD and military products such as GPS, aviation, exploration, and measurement have a wide application of ARM processors with a perfect development tool platform, including Software development provided by ARM and third parties. Toolkit, software simulator, target board monitor, an online real-time emulator based on JTAG interface, and an evaluation board and development board for different microcontrollers (User kernels), providing users with different options. The debugging of embedded applications runs through the development process of the entire system, providing the basis for correcting the performance of the software and hardware error improvement system, and effectively uses the debugging tool to improve efficiency, shorten the development cycle, and enhance product market competitiveness. This article provides a solution for debugging in the development process of ARM7.
1. ARM debugging tool Introduction ARM debugging tool includes angel, software simulator armulator, online real-time emulator multi_ICE or EmbedDice. (1) Angel system includes debuggers running on the host and Monitor running on the target, with serial communication, basic debugging, communication, task management, exception behavior processing, etc., supports the C library. The disadvantage is that it is necessary to take up target machine system resources, such as serial port, ROM, RAM, etc., the advantages are low cost. (2) Armulator is independent of the processor hardware, is an effective source program inspection and test tool. However, it is worth noting that the simulator is a processor to simulate another processor in one processor, which is likely to have considerable differences with the actual processor in terms of instruction execution time, interrupt response, timer, etc.. In addition, it cannot be the same as the ICE (online real-time emulator), the actual implementation of the embedded system in the application system. (3) MULTI_ICE or EmbeddDice is coupled to the target system through the JTAG port, but the price is expensive, but the method is simple, the debugging is quick and convenient, and there is no need to take up system resources. It can set real-time addresses and data independent breakpoints, single-step execution, complete access and control of the ARM core, fully access, full memory access (read / write), complete I / O system access ( Read / write). EmbedDedice and Multi-Ice also allow embedded microprocessors to access peripherals of host systems, such as displays, keyboard input, and disk drive memory. Serial port or parallel port JTAG port
2. Debugging process debugging should solve three problems: Does applications exhibit expected behavior in many minimal user events? Is the application execution reliable? Whether the application meets the design requirements? Therefore, the debugging is divided into three phases: the fast constitutive phase, the verification phase, and the validity confirmation phase. (1) Quickity makes programmers familiarize themselves with application behavior, and determines whether the program works in many minimal user events meets the expectations. (2) The following issues should be detected by the verification phase emulator: an algorithm error (such as pointers overflow, except 0), dead source code, queue overflow, dead lock, live lock. Note: A message stream will become uncertain if there is no other event to stop this loop's message flow around a closed object, and the message flow will become uncertain. This state is called a lock. Although the lock is watched system resources, it may not hinder the system's continued work, so when a life is locked, it is possible to create an illusion of design correctly. (3) The validity confirmation phase is whether the behavior of the application is always in accordance with the expected (effectiveness), whether or not the violation of the rules is generated, which is especially important for real-time systems.
3. Debugging Difficulties 3.1 Using Software Simulator Simulates the software simulator provided by External Devices Armulator-ARM, which is a program that simulates various ARM kernel structures and instruction sets. It is coupled to the ARM debugger, providing an environment for developing ARM software on a PC host system and supported workstations, which is hardware independent. The following is a method for simulating external devices using the software emulator as an example. Armulator includes 4 components: (1) ARM processor kernel model: Processing all communication between the ARM kernel and the debugger does not allow users to modify. (2) Memory interface: Pass data between the ARM model and the memory model or memory management unit model. (3) Coprocessor interface: Treat communication between ARM cores and associations. (4) Operating system interface: Provide a program operating environment. The Armulator core can express the kernel and caches of the processor, but the memory system described in the C source code can be set to any target system model. The interface between the Armulator core and the memory model reflects the pin interface of the ARM kernel, including the ability to generate an interrupt to the NFIQ and NIRQ pins for the memory model. The user can almost simulate all ARM processor-based systems by modifying or rewriting the default models to debug hardware related code. When analog peripherals, users need Armulator to simulate the occurrence of external events, providing two routine secondary event scheduling for this armbulator: ARM_TIME is used to return to the current time tablet; armul_schedulevevt allows calls after a certain time A program. The specific method is illustrated below by an example of an emulation parallel port, requiring the parallel port to generate an interrupt, then read a character from a text file into the memory. The implementation steps are as follows: (1) Establish a new memory model. First copy a memory model of Armulator, make a corresponding modification, create a parallel.c file, add two variables: interrupt generation flag and pointer to the text file to be accessed, add a new program Parallel_set_irq to trigger an interrupt and set an interrupt generation The logo is 1. (2) Modify modvels.h and makefile. Add MEMORY (Parallel) in Models.h as the root entry of the new memory model. Compile Parallel.c Generate the target file to the list of target files in the makefile. (3) Add a new model to armulator and use Microsoft's Visual C on the PC to rebuild "armulated.dll", generating new Armulator. (4) Modify Armul.cnf and select the memory model. When an application accesses a specific memory address (such as 0x123450), the arMul_scheduleevent function is activated. The armul_scheduleevent function calls parallel_set_irq after 20,000 time films, resulting in an interrupt service request, the system enters the interrupt service program (installed by the application settings interrupt vector), the interrupt service program is read from another predefined location (eg 0x123460) A character, and clear the interrupt source of the parallel port, return to the application. This approach does not matter to the ARM debugger used by the user, because it is part of the software simulator and does not belong to the debugger. This is a very useful technology that can be extended to establish a model for the entire system with C language. For example, it may simulate a PDA system, including keyboard, timer, parallel interface, liquid crystal display, and the like.
3.2 The target file in the source code-level debug ROM is increasing in the current embedded application complexity, and the code capacity is getting bigger and larger, and the code in the domestic embedded system reaches 1M byte. When developing an embedded application system, it is usually loaded to run debug in RAM, which will take up a large amount of memory space to improve system cost. EmbedDedice or Multi-Ice, with the ARM debugger to join the EmbedDedice logic circuit of the ARM core via the JTAG port, enabling the user to debug code in the ROM. In order to use the source code-level symbol debug information debugging the ROM code (set breakpoint, single-step running, etc.), the user needs to generate two files: (1) binary file for cure, in the EPROM or downloaded to the user system Flash. The binary file does not contain any debugging information. (2) Files generated by the same code are loaded into the debugger through the "File-> Load Symbol Only" instruction of the window debugger menu or the "ReadSyms" instruction of the symbol debugger. When you use the emulator to debug the program in the ROM, pay attention to two questions: (1) First set the $ Vector_CATCH set to the debugger to zero, disable vector capture and semi-host software interrupt. Since the emulator can control these areas (0x00-0x1c, interrupt vector table address) that can capture abnormal behavior. The capture exception behavior is to cover the original value of the interrupt vector by overwriting the interrupt vector by using a useless binary value 0xdeeeeeeeeeeeeeeeeeeee, the debugger stores the original value of the interrupt vector. As long as the binary value is extracted and reaches the execution phase of the pipeline, the debugger will call its own SWI (software interrupt) service program to handle exception behavior, then inform the user, so that the user will not debug your own interrupt service program. (2) For the ARM7XDI kernel, users can only set up to two breakpoints because the EmbedDedice macro unit has only two real-time observation units, which can be set to breakpoints or observation points. For example: hardware breakpoints in two ROMs, or hardware breakpoints in a ROM with software breakpoints in multiple RAMs, while software breakpoints can only be located in RAM. Conclusion: Software Simulator and Target Monitor provide an economic debugging means that is enough for many designs. But there are also many occasions that need to be used to find program errors. Regardless of which occasion, both the emulator can reduce the debugging time, simplify the system integration, increase reliability, and optimize the test steps, thereby value. More common situations are engineers using software simulators and emulators at different stages of the project, especially in large development projects.
