Introduction to three interrupt debugging methods of ARM

Aguilera

Introduction to three interrupt debugging methods of ARM [Copy link]

1 Embedded Software Development Process Refer to the embedded software development process. Step 1: Project establishment and configuration. Step 2: Edit source files. Step 3: Project compilation and linking. Step 4: Software debugging. Step 5: Execution file solidification. In the whole process, the user first needs to establish a project and make preliminary configurations for the project, including configuring the processor and configuring the debugging device. Edit the project files, including the assembly and C language source programs written by yourself, as well as the link script files that need to be written when the project is compiled. During the debugging process, you need to write storage area image files and command script files, as well as the startup program files for the program running entry during power-on reset. It is very important to understand the latter four files. Their functions are explained as follows: (1) Link script file: It works when the program is compiled. This file describes the relevant information of code link positioning, including code segment, data segment, address segment, etc. The linker must use this file to correctly locate the code of the entire system. The link script files for debugging programs in SDRAM, debugging in FLASH, or running after solidification should be distinguished. (Use the extension *.ld in the IDE development environment) (2) Command script file: It works when debugging programs in SDRAM. When the integrated environment is connected to the target, during the software debugging process, and after the target board is reset, the integrated environment is sometimes required to automatically complete some specific operations, such as resetting the target board, clearing the watchdog, masking the interrupt register, and mapping the storage area. These operations can be completed by executing a set of command sequences. The text file that saves a set of command sequences is called a command script file (uses the extension *.cs in the IDE development environment). (3) Storage area map file: It works when debugging programs in SDRAM. Accessing illegal storage areas during software debugging will cause exceptions on some processors and target boards. If the exceptions are not handled, the software debugging process will not be able to continue. In order to prevent the above problems and adjust the emulator access speed to the most appropriate level, a file called a storage area map file (uses the extension *.map in the IDE development environment) is provided to describe the properties of each storage area. During the debugging process of the program, you can choose to use the storage area image file *.map and the command script file *.cs to cooperate with the debugging of the program. (4) Startup file: It mainly completes some hardware-related initialization work to prepare for the application. Generally, the first step of the startup code is to set the interrupt and exception vector; the second step is to complete the register configuration required for system startup; the third step is to set the watchdog and some peripheral circuits designed by the user; the fourth step is to configure the storage area used by the system to allocate address space; the fifth step is variable initialization; the sixth step is to set the stack pointer for each working mode of the processor; the last step is to enter the high-level language entry function (Main function). 2 Interrupt Program Design In terms of interrupt debugging, you can use a dynamic processing method similar to vector interrupt. Let the fixed address code corresponding to the interrupt be transferred to the fixed address of RAM, and define a function pointer to point to the fixed address. You can then dynamically change the interrupt handling function at any time by replacing the code at the fixed address of RAM. The specific method is: (1) Define the interrupt source function pointer at a relatively fixed address in RAM and establish an interrupt vector table; (2) In the program, call the interrupt processing function of a specific interrupt source; For example: SetInterrupt(IIC_INT,IICWriteIsr); /* Declare the IIC interrupt processing function, where IIC_INT is the IIC interrupt source number, and IICWriteIsr is the IIC write interrupt processing function*/ (3) In the IRQ at 0x18 or the FIQ interrupt entry function at 0x1C, obtain the interrupt source, clear the interrupt pending flag, and enter the user's specific interrupt processing program through the defined interrupt source function pointer. By adopting a dynamic interrupt processing method, when there are many interrupt sources, the interrupt response time and program performance are optimized. In addition, in terms of debugging, this processing method has the advantage of being easy to track and debug, and the interrupt processing function can be easily changed as needed. 3 Interrupt debugging Software debugging can be performed in SDRAM or FLASH. In SDRAM, reading and writing are convenient and the access speed is fast. Generally, software debugging should be completed in RAM, but when the RAM space is smaller than the FLASH program space, the program can only be run and debugged in FLASH, or when the user wants to understand the actual running status of the program in FLASH, the program can be debugged in FLASH. When performing interrupt debugging, it should be noted that the interrupt entry is located at 0x18 or 0x1c in SDRAM or FLASH, and the link script file must correctly locate the code of the entire system at the beginning of 0x0, but the link script file and project configuration corresponding to SDRAM or FLASH should be distinguished. (1) The program runs in SDRAM Debug in SDRAM and use the link script file corresponding to SDRAM. The debugging process requires the following steps: compile and link the project; connect the emulator and the circuit board; download the program (use the extension *.elf in the IDE development environment); debug. Before downloading the program, you must start the command script file to complete some of the above-mentioned specific operations. The command script file is automatically started when the emulator is connected. The storage area mapping should be the same as when the program runs in SDRAM to ensure that the code of the entire system is correctly located at the beginning of 0x0. The starting address of the downloaded program is also 0x0. After the download is successful, debugging can be carried out. (2) The program runs in FLASH Debug in FLASH and use the link script file corresponding to FLASH. The debugging process requires the following steps: compile and link the project; connect the emulator and the circuit board; program format conversion (*.elf to *.bin); solidify the *.bin program; debug. After connecting to the emulator, there is no need to download the program. The storage area mapping is completed by running the startup file in the project itself, and no command script file is required. During the debugging process in this environment, two hardware breakpoints can be set. (3) The program is transferred from FLASH to SDRAM for execution In some applications, when the program running speed is emphasized, it is hoped that the program will run in SDRAM. In this way, the program stored in FLASH needs to be moved to a certain space location in SDRAM after the system is powered on, and then run automatically. This so-called Bootloader technology is often used in DSP systems. The debugging process is divided into two steps: (a) First, debug the user program in SDRAM, and then fix the *.bin file to a non-0 sector address space in FLASH; (b) Debug the Bootloader transfer program written by yourself and transfer the Bootloader.The bin file is fixed to the 0 sector address space of FLASH. After the system is powered on, the transport program will move the program stored in a non-0 sector address space of FLASH in (a) to the same space location in SDRAM debugging, so as to achieve the purpose of running the program in SDRAM. Also note that because the user's actual program interrupt entry must be located at the 0x18 or 0x1c address of FLASH, the Bootloader transport program should also have the jump function of the interrupt entry, that is, to turn the PC pointer to the interrupt program entry table in the SDRAM space, which is the location where the entire user program is moved to SDRAM.