Application support software for embedded systems has developed rapidly in recent years. Generally, application support software includes window system, database management system and Java virtual machine. The appearance of application support software has greatly changed the development conditions of application software, but also makes the function of application system continuously enhanced.

Embedded system software development platform

The software development method of embedded system is not general development method, but cross development method.

1.1 Cross-platform development environment

The software Development of embedded system adopts Cross Platform Development (CPD) method, that is, software is developed on a common Platform and runs on another embedded target Platform. This common platform for developing embedded software is usually called host system, and the embedded system being developed is called target system.

The Development process when the software execution environment and Development environment are consistent is called Native Development (ND). Figure 1 is a typical cross-platform development environment, usually consisting of three highly integrated parts: (1) powerful cross-development tools and utilities running on both host and target machines. (2) A high-performance, clipable real-time operating system running on the target. (3) A variety of communication methods to connect the host computer and the target computer, such as Ethernet, serial line, ICE (In Circuit Emulator, online Emulator) or ROM Emulator, etc.

1.2 Cross-compilation environment

The basic development tools provided by the host are a cross-compiler, a cross-linker, and a source debugger. An embedded system as a target might provide a dynamic loader, link loader, monitor, a debug agent, and so on. There is a set of connections between the target machine and the host machine through which the linker code image is downloaded from the host machine to the target machine. This set of connections is also used to transfer information between the host machine and the target machine debugging agent.

Embedded system developers need to fully understand how the target system stores program images on the embedded system, how executable images are downloaded into memory and how execution control is transferred to the application, how and when program images are loaded during runtime, and how application systems are developed and debugged crosswically. These aspects affect how the code is developed, compiled, linked, and so on.

Figure 2 is an example of a typical cross-compilation environment, showing how development tools can be used to process various input files and produce the final object file. The cross-compiler generates object files containing binary code and program data from C/C++/Java source code files written by users according to the CPU type of the target machine. During this process, the cross-compiler creates a symbol table containing the symbol names in the resulting object file that point to the address of the image, and when the relocation output is created, the compiler generates an address for each associated symbol.

Often, these object files can also be gathered together into a library using archiving tools.

Finally, the linker takes these object files as input to produce an executable image. Typically, the user first edits a link script file that instructs the linker on how to combine and relocate the pieces of code to produce the final file.

In addition, the linker can combine multiple target files into a larger relocation target file or a shared target file.

At present, COFF (Common Object File Format) and ELF (Executable Linking Format) are commonly used in embedded systems. In addition, some systems require special tools to convert the above format into binary code format.

Generally, an object file contains: (1) general information about the object file, such as file size, startup address, code segment, data segment, etc. (2) Machine architecture-specific binary instructions and data. (3) Symbol table and relocation table. (4) Debugging information.

2 embedded development and debugging

There are obvious differences in software debugging between general purpose system and embedded system. For general-purpose systems, the debugging tool resides on the same computer as the program being debugged, and the debugging tool controls the program being debugged through the debugging interface of the operating system. However, in embedded systems, applications cannot be developed directly due to resource constraints, and the debugging process is usually carried out in a cross-way. In the practical development practice, the debugging methods often used are direct testing method, debugging monitoring method, online simulation method, slice test method and simulator method.

2.1 Direct debugging method

Direct debugging method is to download the object code to the target machine, let it execute, by observing the indicator light to judge the running status of the program.

In the early stage of the development of embedded system, debugging is generally carried out in this way. The basic steps are as follows: (1) write programs on the host computer. (2) Compile and link executable program code of the target computer on the host computer. (3) Write the executable code into the memory of the target machine. (4) Run the program code on the target computer. (5) Judge the operation of the program, correct the mistakes if there are any, and repeat the above steps until they are correct. (6) Solidify the executable code to the target computer and complete the development. This method is the most primitive debugging method, the program running problems, only by checking the source code to solve, so the development efficiency is very low.

2.2 Debugging and monitoring method

Debugging monitoring method is also called pile insertion method. The target machine and the host machine are generally connected through serial port, parallel port or Ethernet. In this way, a functional module needs to be started respectively in the debugger of the host machine and the operating system of the target machine, and then the application program can be debugged through the communication between the two functional modules.

The module added to the target machine is called a peg, also called a debug server or a debug monitor. It has two main functions: first, to monitor and control the program being debugged; Second, communicate with the host machine debugging program, receive control instructions, return results and so on.

During debugging, the debugger on the host machine sends various requests to the debug monitor through the connection line, realizing the target machine memory read/write and register access, program download, single step trace, and setting breakpoints. The request from the host machine and the response from the target machine interact according to a predetermined communication protocol.

When using the peg method as a means of debugging, the basic steps of developing applications are: (1) write the source code of the program on the host. (2) Compile and link the executable program of the target computer in the host computer. (3) Download the executable code of the target computer to the memory of the target computer. (4) Use the debugger for debugging. (5) Locate errors with the help of the debugger. (6) Modify the source code on the host, correct the error, and repeat the above steps until correct. (7) Solidify executable code to the target. Compared with the direct test method, the piling method obviously improves the development efficiency, reduces the difficulty of debugging, shortens the product development cycle, and effectively reduces the development cost.

However, the piling method still has obvious shortcomings, mainly reflected in the following aspects: (1) the development of debugging monitor itself is a technical problem. (2) The debugging monitor occupies certain system resources in the target machine, such as CPU time, storage space and peripheral resources such as serial port or network interface. (3) During debugging, it cannot respond to external interruption and is not applicable to programs with time characteristics. (4) In the debugging process, the program being debugged actually runs in the environment provided by the debugging monitor. This environment may be different from the final running environment of the actual target program, which may lead to the program that passes the debugging still cannot run at last.

In order to overcome the shortcomings of piling method, an improved method, namely ROM simulator method, was introduced.

The ROM emulator can be considered as a hardware device used to replace the ROM chip on the target. One end of the ROM emulator is connected to the host computer, and the other end is connected to the target computer through the pin socket of the ROM chip. The ROM emulator acts like a read-only memory to the embedded processor and a debug monitor to the host machine. The address of the ROM simulator can be mapped to the ROM address space of the target computer in real time, so it can simulate the ROM of the target computer.

The ROM simulator establishes a high-speed information channel between the target computer and the host computer, and its typical application is to combine with the piling method to form a more powerful debugging method. This method has the following advantages: (1) no need to develop debugging monitor. (2) Because it is connected with the host computer through the serial port, parallel port or network interface on the ROM emulator, it does not need to occupy the system resources on the target computer. (3) THE ROM emulator replaces the original ROM on the target, so there is no need to occupy the storage space on the target to save the debugging monitor. (4) In addition, even if the target machine does not own ROM, debugging can still be carried out, and there is no need to use special tools to write programs and data to ROM.

2.3 Online simulation method

ICE is a device used to replace the CPU on the target. To the target computer, the online emulator is its CPU. The online emulator itself is an embedded system with its own CPU, memory, and software.

Online emulator CPU can perform all instructions for the target, there is much more than the average CPU pins and internal signals output to be able to control the target machine, emulator online storage has been mapped to a user space program, as a result, even if there is no target, only using simulators can also be online program debugging.

On-line emulator and host computer are generally connected through serial port, parallel port or Ethernet. When connecting the online emulator and the target system, the ONLINE emulator’s CPU extraction port is used to replace the target’s CPU. When debugging a program with an online emulator, a debugger interface program is run on the host computer, which controls the program running on the target computer according to the user’s operation instructions.

Online emulators can check the state of the processor running the program in real time, set hardware breakpoints, and trace in real time, thus providing stronger debugging capabilities. Online emulator, support for a variety of events trigger breakpoints, such as memory read and write, I/O read and write and interrupt.

Real-time tracking is an important feature of online emulators. There is a large capacity of memory on online emulators to store the information of each instruction cycle. This function enables users to know the precise timing of events, which is especially suitable for debugging real-time applications, device drivers and functional testing of hardware. However, online emulators are generally expensive.

2.4 slice up-regulation test

In Circuit Debugger (ICD) is a functional module In a CPU chip that supports debugging. According to the implemented technology, on-chip Debugging can be divided into imitation Debugging monitor, Background Debugging Mode (BDM), Joint Test Access Group, JTAG) and On Chip Emulation (OnCE).

The ICD chip products of imitated debug monitor include Motorola CPU 16, CPU 32 and ColdFire series, and BDM mainly includes Motorola MPC5xx and MPC8xx series. The OnCE class mainly includes Motorola DSP chip series, and the JTAG class mainly includes PPC6xxx, PPC4xx, ARM7TDMI, ARM9TDMI and Intel1960, etc.

At present, the CPU chip using BDM technology is widely used. This kind of chip has debugging related pins on the outside, and these pins are led out during debugging, forming a debugging interface connected with the outside. This kind of CPU has debugging mode and execution mode two different running modes. When a specific trigger condition is met, the CPU enters debugging mode. In debugging mode, the CPU no longer reads instructions from memory, but reads instructions through its debugging port, through which the CPU can also be controlled to enter and exit debugging mode. In this way, the debugger on the host machine can directly send instructions to the target machine through the debugging port, so that the debugger can read/write the memory and registers of the target machine, control the running of the target program and complete various complex debugging functions.

The main advantages of this approach are:

  1. Does not occupy the target computer communication port and other resources;
  2. The debugging environment is basically consistent with the final program running environment;
  3. It can be carried out without adding any function modules on the target machine.
  4. Support for soft and hard breakpoints;
  5. Support tracking function, can accurately measure the execution time of the program;
  6. Supports temporal logic analysis and other functions.

The disadvantages of this method are:

  1. Real-time performance is not as good as online simulation method.
  2. The application scope is limited. If the target machine does not support debugging on chip, this method is not applicable. The realization technology is diverse, the standard is not completely unified, and the development and use of tool software are not convenient.

2.5 Simulator Method

Simulator is a pure software tool running on the host computer. It can run and debug embedded applications on the host computer by simulating the instruction system of the target computer or the system call of the target computer operating system.

Simulators are suitable for debugging non-real-time applications. Such programs generally do not interact with external devices, and their real-time performance is not strong. The execution process of programs is time-closed, so developers can directly verify the logical correctness of programs on the host. When the confirmation is correct, the program will be written to the target machine can run correctly.

There are two main types of simulators: one is the instruction level simulator, which simulates the instruction system of the target computer in the host computer; The other is the system call level simulator, which simulates the system call of the target operating system on the host.

The instruction level simulator is equivalent to a virtual target machine on the host machine. The processor type of the target machine can be different from that of the host machine. For example, the host machine is the x86 series of Intel, while the virtual machine can be ARM, PowerPC, MIPS, etc. The more advanced instruction level simulator can also simulate the external devices of the target machine, such as keyboard, serial port, network interface, etc.

The system call level emulator is equivalent to installing the operating system of the target machine on the host machine so that applications based on the operating system of the target machine can run on the host machine. The type of target operating system being emulated can be different from that of the host. Compared with the two types of simulators, the operating environment provided by the instruction level simulator is closer to the actual target computer.

The biggest benefits of using an emulator are that you can develop applications for the actual target machine when it doesn’t exist, and use the resources of the host machine to provide more detailed error diagnosis information during debugging, but the emulator has many disadvantages: (1) There is a big difference between the simulator environment and the actual running environment, so it is impossible to guarantee that the application that passes under simulated conditions can also run correctly in the real environment. (2) The simulator cannot simulate all external devices. The embedded system usually contains many peripherals, but the simulator can only simulate a few parts. (3) The real-time performance of the simulator is poor, and the debugging results of real-time applications may not be reliable. (4) Running the simulator requires a higher host configuration. Although the simulator has many shortcomings, its value is immeasurable in the early stage of project development, especially for those applications that are not strong in real time. Simulator debugging does not require special hardware resources, which is a very economical method.