Embedded software and hardware collaborative testing method and system

Abstract

The invention discloses an embedded software and hardware collaborative testing method and system, and relates to the field of software and hardware collaborative testing, and the method comprises the following steps: an upper computer sends a code segment and a data segment to be tested to embedded equipment by using a memory writing command; after receiving an application program starting command, the embedded equipment keeps the context of the current operating system, loads the context of the application program, executes an application program code, stores the context of the current application program when executing a preset function, loads the most recently stored context of the operating system to a register, and executes the application program code; skipping to a context of the kernel to execute a program of an operating system; the embedded device obtains system calling information according to the context of the application program stored last time; obtaining output data corresponding to the system calling information by utilizing the upper computer; and after the embedded device receives the corresponding output data, enabling the operating system to load the context of the application program stored last time, and continuing to execute the application program. According to the invention, the test efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software and hardware collaborative testing, and in particular to an embedded software and hardware collaborative testing method and system. Background Art

[0002] Currently, programs on embedded devices are run mainly in the following two ways:

[0003] The first method: The program is solidified in the embedded device flash. When the system starts, the bootloader loads the execution code from the flash to the corresponding memory location and then executes it.

[0004] The second method: The program communicates with a personal computer (PC) through the bootloader, receives executable file data sent from the PC host computer, and then jumps.

[0005] The second method is more flexible than the first one, but the second method has a characteristic that once a program is loaded and run, the host computer cannot obtain the results of the software running, and the bootloader also loses control of the system. If you need to re-run the next program, you need to restart the embedded device, which cannot meet the needs of system automation testing.

[0006] On the other hand, many software require the use of file reading and writing (IO) functions. However, in the early stages of chip and hardware design, the entire hardware system has not yet been designed, and file functions cannot be provided for software use, which imposes many restrictions on software development.

[0007] At the same time, in embedded software systems, application layer program codes are usually compiled together with operating system (OS) kernel codes. This results in the writing of application programs being dependent on specific platforms, which results in a relatively large amount of software porting work for embedded systems. Summary of the invention

[0008] The purpose of the present invention is to provide an embedded software-hardware collaborative testing method and system to improve the testing efficiency.

[0009] To achieve the above object, the present invention provides the following solutions:

[0010] An embedded software-hardware collaborative testing method, comprising:

[0011] The host computer sends the code segment and data segment to be tested to the embedded device using a write memory command; the operating system kernel to be tested is deployed in the embedded device;

[0012] The host computer sends a command to start the application program to the embedded device;

[0013] After receiving the command to start the application program, the embedded device switches the system exception handling entry of the operating system to the application exception handling entry, maintains the context of the current operating system, loads the context of the application program, and executes the application program code;

[0014] When the embedded device executes the application code, when executing to the preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program;

[0015] The embedded device obtains system call information according to the context of the application program saved most recently;

[0016] The embedded device packages the system call information, and sends the packaged data and the system call request to the host computer in the polling state, and the operating system of the embedded device enters the data waiting state;

[0017] After receiving the system call request, the host computer parses the packaged data to obtain system call information, obtains output data corresponding to the system call information, and sends the output data corresponding to the system call information to the embedded device;

[0018] After receiving the output data corresponding to the system call information, the embedded device enables the operating system to load the context of the application program saved most recently, and continues to execute the application program using the output data corresponding to the received system call information.

[0019] Optionally, the command to start the application includes an application entry address.

[0020] Optionally, the system call information includes the type of system call, parameters of the system call and a memory address used by the system call.

[0021] Optionally, the host computer and the embedded device use universal asynchronous receiver-transmitter, universal serial bus and high-speed serial computer expansion bus standards for data transmission.

[0022] Optionally, before executing the host computer to send the code segment and the data segment to be tested to the embedded device by using a write memory command; the embedded device is deployed with an operating system kernel to be tested, the step further includes:

[0023] The host computer sends a command to query whether the device is online to the embedded device;

[0024] After receiving the command to query whether the device is online, the embedded device sends online confirmation information to the host computer.

[0025] Optionally, after receiving the system call request, the host computer parses the packaged data to obtain system call information, and when the system call information is an exit() system call, the program ends.

[0026] The present invention also discloses an embedded software-hardware collaborative testing system, comprising: a host computer and an embedded device;

[0027] The host computer is used to send the code segment and data segment to be tested to the embedded device using a write command; the operating system kernel to be tested is deployed in the embedded device;

[0028] The host computer is used to send a command to start the application program to the embedded device;

[0029] The embedded device is used to switch the system exception handling entry of the operating system to the application exception handling entry after receiving the command to start the application, maintain the context of the current operating system, load the context of the application, and execute the application code;

[0030] When the embedded device is used to execute application code, when executing a preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program;

[0031] The embedded device is used to obtain system call information according to the context of the application program saved most recently;

[0032] The embedded device is used to package the system call information, and send the packaged data and the system call request to the host computer in the polling state, and the operating system of the embedded device enters the data waiting state;

[0033] The host computer is used to parse the packaged data to obtain the system call information when receiving the system call request, obtain the output data corresponding to the system call information, and send the output data corresponding to the system call information to the embedded device;

[0034] The embedded device is used to enable the operating system to load the context of the application program saved most recently after receiving the output data corresponding to the system call information, and to continue executing the application program using the output data corresponding to the received system call information.

[0035] According to the specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0036] An operating system is deployed on the embedded device of the present invention. Through communication between a host computer and the embedded device, the host computer is used to execute part of the application program, and the application program execution result is returned to the embedded device. The embedded device continues to execute the application program according to the received application program execution result, thereby realizing unmanned automated testing of the embedded device and improving testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0038] Figure 1 A schematic diagram of a flow chart of an embedded software-hardware collaborative testing method provided by an embodiment of the present invention;

[0039] Figure 2 A schematic diagram of the upper computer workflow provided by an embodiment of the present invention;

[0040] Figure 3 A schematic diagram of an embedded device workflow provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] The purpose of the present invention is to provide an embedded software-hardware collaborative testing method and system to improve the testing efficiency.

[0043] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0044] Example 1

[0045] like Figure 1 As shown, this embodiment provides an embedded software-hardware collaborative testing method, which includes the following steps.

[0046] Step 101: The host computer sends the code segment and data segment to be tested to the embedded device using a write memory command; the operating system kernel to be tested is deployed in the embedded device.

[0047] Step 102: The host computer sends a command to start the application program to the embedded device.

[0048] Step 103: After receiving the command to start the application program, the embedded device switches the system exception handling entry of the operating system to the application exception handling entry, maintains the current operating system context, loads the application program context, and executes the application program code.

[0049] Step 104: When the embedded device executes the application code, when executing the preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program.

[0050] System calls include open, readwrite and other file operating system calls defined by POSIX.

[0051] Step 105: The embedded device obtains system call information according to the context of the application program saved most recently.

[0052] Step 106: The embedded device packages the system call information, and sends the packaged data and the system call request to the host computer in the polling state, and the operating system of the embedded device enters the data waiting state.

[0053] Step 107: After receiving the system call request, the host computer parses the packaged data to obtain system call information, obtains output data corresponding to the system call information, and sends the output data corresponding to the system call information to the embedded device.

[0054] The output data corresponding to the system call information is the output data after the host computer executes the program corresponding to the system call information.

[0055] Step 108: After receiving the output data corresponding to the system call information, the embedded device causes the operating system to load the context of the application program saved most recently, and continues to execute the application program using the output data corresponding to the received system call information.

[0056] The command to start the application program includes an application program entry address.

[0057] The system call information includes the type of system call, parameters of the system call and the memory address used by the system call.

[0058] The host computer and the embedded device use Universal Asynchronous Receiver / Transmitter (UART), Universal Serial Bus (USB) and high-speed serial computer expansion bus standards for data transmission (Peripheral Component Interconnect Express, PCIE).

[0059] Before executing step 101, the method further includes:

[0060] The host computer sends a command to query whether the device is online to the embedded device;

[0061] After receiving the command to query whether the device is online, the embedded device sends online confirmation information to the host computer.

[0062] After receiving the system call request, the host computer parses the packaged data to obtain system call information. When the system call information is an exit() system call, the program ends.

[0063] The technical effects of the present invention are as follows:

[0064] First, the present invention realizes automated testing of embedded devices with high efficiency:

[0065] Limited by the characteristics of embedded systems, it has always been difficult to implement unattended automated testing on embedded systems. The present invention dynamically deploys executable programs to embedded devices through a host computer running on a PC and a bootloader running on the embedded device, meeting the needs of automated testing of embedded devices.

[0066] The present invention develops a bootloader with operating system kernel function, which can realize dynamic loading of application programs for running and obtain application execution results.

[0067] Second, seamless application migration improves the speed of application development and verification:

[0068] Applications developed based on libc can be easily ported to other hardware platforms by simply implementing the corresponding Portable Operating System Interface (POSIX) interface on the corresponding platform.

[0069] Embedded application development and driver development can be carried out in parallel.

[0070] The remote syscall function provides a complete application development and testing environment. Application development can precede hardware and does not need to rely on the specific implementation of hardware.

[0071] Example 2

[0072] This embodiment provides an embedded software and hardware collaborative testing method, which mainly includes three functions, namely, embedded device communication control function, embedded device test operating system function and remote system call simulation function. The workflow of the host computer is as follows: Figure 2 As shown, the workflow of embedded devices is as follows Figure 3 shown.

[0073] First, the specific workflow of the embedded device communication control function is as follows:

[0074] Step 1: Define a new protocol for communication between PC host computer and embedded devices. The new protocol abstracts embedded devices into PC peripherals and defines several basic communication primitives such as reading memory, writing memory, clearing memory and running programs.

[0075] Step 2: The embedded device is powered on and the operating system completes the initialization of the device.

[0076] The single-task operating system embedded in the embedded device will complete the board-level initialization process, and then initialize the hardware for communication with the host computer, and can use UART, USB, and PCIE for data transmission. Then the operating system will enter the command receiving state.

[0077] Step 3: The PC first sends a ping packet to query whether the device is online (device online query command).

[0078] Step 4: After receiving the query packet sent by the host computer, the embedded device replies with an OK message (confirming online information).

[0079] Step 5: The host computer reads the information related to the Executable and Linkable Format (ELF) file and obtains the addresses and sizes of all code segments and data segments in the ELF file.

[0080] Step 6: Based on the information obtained in step 5, use the write memory command to send all code segments and data segments to the embedded device.

[0081] Step 7: After receiving the corresponding memory data (code segment and data segment), the embedded device checks the legality of the address where the corresponding memory data is written. If it is legal, the corresponding memory data is written to the corresponding memory address.

[0082] Step 8: After all code segments and data segments are sent, the host computer finds the stack information of the application sent to the embedded device, and then sets the argc and argv of the application. After setting, the corresponding memory data is sent to the embedded device.

[0083] The stack is the memory address of temporary variables during code execution. argc indicates how many parameters are passed to the application when it is executed, and argv indicates the address where these parameters are stored.

[0084] Step 9: The host computer sends a start application command to the embedded device and carries the application entry address and other information, so that the embedded device starts to execute the application code. At the same time, the host computer enters the polling state to poll the request sent by the device.

[0085] The code during program execution will be stored in the code segment, and the data used during code execution will be stored in the data segment.

[0086] Second, the specific workflow of the embedded device testing operating system function is as follows:

[0087] After the host computer sends the application data, it will enter the polling mode to receive system call requests from the embedded device.

[0088] Step 1: After the embedded device receives the polling (RUN) command from the host computer, it switches the system exception handling entry to the application exception handling entry, then saves the current operating system context to the memory, then loads the application context, and finally jumps to the application code execution.

[0089] Step 2: Execute the application code logic.

[0090] The application is written based on standard C library functions. When the open / read / write functions are executed, a system call will be triggered, and the system will jump to the exception handling entry.

[0091] Step 3: The operating system on the embedded device captures and processes the application request.

[0092] At the entrance of the system exception handling, the operating system will save the context of the application, load the last saved kernel context (operating system context) into the register, and then switch the system exception handling entrance to the kernel exception handling entrance. Finally, it jumps to the last kernel context execution. At this time, the execution flow of the entire system is switched back to the operating system.

[0093] The exception handling entry is the CPU exception vector table. When an exception occurs, the CPU will jump to a fixed address to execute code.

[0094] Step 4: The operating system obtains the type and parameters of the system call based on the application context.

[0095] Third, the specific workflow of the remote system call simulation function is as follows:

[0096] After receiving the system call request from the application, the operating system will enter the remote system call simulation function.

[0097] Step 1: The operating system packages the corresponding information (system call information) according to the system call information obtained in step 4 of the specific workflow of the embedded device testing operating system function, and then sends the packaged data to the host computer program in the polling state through the corresponding transmission method. At the same time, the operating system enters the data waiting state.

[0098] Step 2: When the host computer program receives the system call request, it will parse the packaged data, extract the required information, and obtain the system call information.

[0099] The system call information includes: the type of system call, the parameters of the system call, and the memory address used by the system call.

[0100] Step 3: Determine whether the system call is legal and execute the system call.

[0101] If the system call request is a legal request, the host computer will call the same system call on the PC system to obtain the data that the device wants to obtain (the output data corresponding to the system call information).

[0102] Step 4: After the host computer obtains the data, it packages the data and then sends it to the embedded device. At the same time, the host computer enters the data polling mode again.

[0103] Step 5: After receiving the data, the embedded device verifies it. If the data requested by the system call is too large, it needs to be sent to the host computer in several requests.

[0104] Step 6: After all data is acquired, the operating system loads the saved application context into the CPU and then jumps back to the application execution.

[0105] Step 7: Repeat the above steps until the operating system receives an exit() system call from the application.

[0106] The exit system call marks the end of the application execution. At this time, the operating system will send the received application exit code to the host computer and enter the data polling state again, waiting for the command sent by the host computer.

[0107] Step 8: After receiving the exit system call, the host computer prints the execution status of the application and exits.

[0108] At this point, a complete embedded application execution process is completed.

[0109] The technical effects disclosed by the present invention are as follows:

[0110] (1) Simplify the embedded system development and testing process, and can conveniently and flexibly support micro-architecture testing and application testing without implementing IO-related codes such as file systems, and provide a standard POSIX-compatible verification environment. It is particularly suitable for early chip verification, embedded system verification, and embedded system automated testing.

[0111] (2) The operation is directly offloaded to the host, which simplifies the test process. Data does not need to be copied from the device to the host computer (host computer), which improves verification efficiency.

[0112] (3) Compatible with a large number of POSIX test cases, and the test cases can be reused in x86issfpga.

[0113] (4) It can adapt to various resource-constrained embedded environments.

[0114] (5) Flexible and scalable, it can simulate various peripherals and facilitate the porting of embedded applications.

[0115] (6) Supports real-time collection of test case performance data and visual display of the data.

[0116] The present invention defines a new communication protocol between a host computer and an embedded device according to the specific characteristics of an embedded system. Based on the new communication protocol, a host computer running on a PC uses a write memory command to send a code segment and a data segment of an application program to be tested to an embedded device. After receiving a command to start an application program, a small operating system kernel on the embedded device saves the context of the current operating system kernel, loads the context of the application program, and prepares a suitable execution environment for the application program, then jumps to the application program code entry, and executes the application program code. When an application program calls a system call, a CPU triggers an exception and returns to the exception handling entry of the kernel. At the exception handling entry, a save operation is performed on the context of the application program, the context of the current application program is saved, and the context of the kernel saved most recently is restored, and the kernel is jumped to the place where the kernel was last executed. At this time, the kernel obtains parameter information of the system call from the context of the application program saved most recently. At the same time, the system call parameter information is forwarded to the host computer, so that the host computer executes a specific system call request, and returns the execution result to the application program. After the embedded device receives the corresponding system call execution result, the operating system kernel loads the context of the application program saved most recently, and continues to execute the application program. The present invention forwards some files and device operation requests on the embedded device to the host computer through the idea of ​​combining software and hardware. At the same time, the host computer acts as a test agent, which can realize the automatic deployment of application programs and realize IO functions without real hardware on the embedded device, greatly improving the testing efficiency of the embedded system.

[0117] Example 3

[0118] This embodiment provides a method for embedded device software to implement remote system calls in an embedded software-hardware collaborative testing method. The method for embedded device software to implement remote system calls specifically includes:

[0119] Step 1: Use standard POSIX interface functions when developing applications, and use standard file IO interfaces to read and write files.

[0120] Step 2: The application requests kernel services through standard system (POSIX system call standard) calls.

[0121] In the process of calling the standard interface, a hardware system call is triggered. At this time, the control of the system will be transferred to the operating system kernel on the embedded device, and the kernel here is xboot.

[0122] Step 3: When the CPU in the embedded device captures the system call instruction, it jumps to the system exception handling entry.

[0123] This system exception handling entry is set by the operating system, at which point the control of the system is transferred from the application to xboot.

[0124] Step 4: The operating system processes the system call, saves the application context, loads the kernel context saved by the last operating system, and jumps to the last interrupt location.

[0125] Step 5: The operating system can extract the system call information through the application context saved in the previous step, and then convert the system call into a data packet and forward it to the PC host program through the defined protocol.

[0126] Step 6: After receiving the system call, the host computer executes the corresponding request on the PC. At the same time, the device will continue to wait for the result of the execution of the host computer.

[0127] Step 7: After the device obtains the result of the execution of the host computer, it writes the result to the corresponding register or memory, and then returns the controller to the application. The whole process is completed.

[0128] Example 4

[0129] This embodiment provides a method for implementing automated testing of an embedded device in an embedded software-hardware collaborative testing method. The method for implementing automated testing of an embedded device specifically includes:

[0130] Step 1: Add some functions to libc library and xboot to support embedded applications that do not rely on the operating system (OS) or boot loader (bootloader) and can be independently developed and compiled. The added functions are:

[0131] When the application starts, a special system call is used to install an exception and interrupt handling hook function. This hook function receives the exception and interrupt information passed from xboot, and then jumps to the exception and interrupt handling function registered by the application to run.

[0132] When the system has an exception or interrupt, xboot can capture the type of exception.

[0133] xboot will detect whether the application has a hook function registered for interrupt exception handling. If not, xboot will directly handle the interrupt or exception.

[0134] If the application registers an exception handling hook function, xboot will create a new context on the current application stack. The entry point of the context is the registered hook function, and the return address of this context will be set to the address of the next instruction when the exception occurs.

[0135] Then xboot will jump back to the application, which is equivalent to converting the exception into a function call.

[0136] Step 2: Implement a unified application entry function _start(crt0.S) and a unified application exit processing function __exit__(intcode) in the libc library. These two functions will be responsible for the application exit processing, and code represents the status value of the application exit.

[0137] When the system starts, xboot will set the processor's exception handling entry. If the application is developed based on libc, the application will not modify this setting, so the system exceptions and interrupts will be captured by xboot.

[0138] After xboot hands over the system control to the application, the _start function will save the exception handling entry set by xboot to the application's memory. If a system-level software is running, the exception handling entry function can be overwritten at this time.

[0139] When the system exits, the __exit__ function will restore the exception handling entry saved at startup, then call the exit system call, and return control of the system to xboot.

[0140] Step 3: For applications developed based on the standard libc library, the program execution needs to exit in the main function or call the exit() function to exit. Both exit methods will eventually call the __exit__(int code) function.

[0141] Step 4: In the __exit__(intcode) function, some necessary exit operations will be performed, and finally the control of the system will be returned to xboot through the standard exit system call.

[0142] Step 5: After receiving the application's exit request, xboot passes the corresponding application's execution result and some status information to the PC host computer. After that, xboot will keep waiting for new requests from the host computer.

[0143] Step 6: After receiving the application execution result sent by xboot, the PC host computer can display or save the application execution result and then execute the next application. This method can realize the automatic deployment of applications on embedded devices.

[0144] Example 5

[0145] This embodiment provides an embedded software-hardware collaborative testing system, which includes a host computer and an embedded device.

[0146] The host computer is used to send the code segment and data segment to be tested to the embedded device by using a write command; the operating system kernel to be tested is deployed in the embedded device.

[0147] The host computer is used to send a command to start the application program to the embedded device.

[0148] The embedded device is used to switch the system exception handling entry of the operating system to the application exception handling entry after receiving the command to start the application, maintain the context of the current operating system, load the context of the application, and execute the application code.

[0149] When the embedded device is used to execute application code, when executing a preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program.

[0150] The embedded device is used to obtain system call information according to the context of the application program saved most recently.

[0151] The embedded device is used to package the system call information, and send the packaged data and the system call request to the host computer in the polling state, and at the same time, the operating system of the embedded device enters the data waiting state.

[0152] The host computer is used to parse the packaged data to obtain the system call information when receiving the system call request, obtain the output data corresponding to the system call information, and send the output data corresponding to the system call information to the embedded device.

[0153] The embedded device is used to enable the operating system to load the context of the application program saved most recently after receiving the output data corresponding to the system call information, and to continue executing the application program using the output data corresponding to the received system call information.

[0154] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0155] The principles and implementation methods of the present invention are described in this article using specific examples. The description of the above embodiments is only used to help understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. An embedded software and hardware collaborative testing method, It is characterized in that include: The host computer uses the write memory command to send the code segment and data segment to be tested to the embedded device; An operating system kernel to be tested is deployed in the embedded device; The host computer sends a command to start the application program to the embedded device; After receiving the command to start the application program, the embedded device switches the system exception handling entry of the operating system to the application exception handling entry, maintains the context of the current operating system, loads the context of the application program, and executes the application program code; When the embedded device executes the application code, when executing to the preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program; The embedded device obtains system call information according to the context of the application program saved most recently; The embedded device packages the system call information, and sends the packaged data and the system call request to the host computer in the polling state, and the operating system of the embedded device enters the data waiting state; After receiving the system call request, the host computer parses the packaged data to obtain system call information, obtains output data corresponding to the system call information, and sends the output data corresponding to the system call information to the embedded device; After receiving the output data corresponding to the system call information, the embedded device enables the operating system to load the context of the application program saved most recently, and continues to execute the application program using the output data corresponding to the received system call information.

2. The embedded software-hardware collaborative testing method according to claim 1, It is characterized in that The command to start the application program includes an application program entry address.

3. The embedded software-hardware collaborative testing method according to claim 1, It is characterized in that The system call information includes the type of system call, parameters of the system call and the memory address used by the system call.

4. The embedded software-hardware collaborative testing method according to claim 1, It is characterized in that The host computer and the embedded device use universal asynchronous receiver-transmitter, universal serial bus and high-speed serial computer expansion bus standards for data transmission.

5. The embedded software-hardware collaborative testing method according to claim 1, It is characterized in that The host computer uses the write memory command to send the code segment and data segment to be tested to the embedded device; Before the step of deploying the operating system kernel to be tested in the embedded device, the method further includes: The host computer sends a command to query whether the device is online to the embedded device; After receiving the command to query whether the device is online, the embedded device sends online confirmation information to the host computer.

6. The embedded software-hardware collaborative testing method according to claim 1, It is characterized in that After receiving the system call request, the host computer parses the packaged data to obtain system call information. When the system call information is an exit() system call, the program ends.

7. An embedded software and hardware collaborative testing system, It is characterized in that include: Host computer and embedded devices; The host computer is used to send the code segment and data segment to be tested to the embedded device using a write command; An operating system kernel to be tested is deployed in the embedded device; The host computer is used to send a command to start the application program to the embedded device; The embedded device is used to switch the system exception handling entry of the operating system to the application exception handling entry after receiving the command to start the application, maintain the context of the current operating system, load the context of the application, and execute the application code; When the embedded device is used to execute application code, when executing a preset function, it jumps from the application exception handling entry to the system exception handling entry, uses the operating system to save the context of the current application, and loads the most recently saved operating system context into the register, switches the system exception handling entry to the kernel exception handling entry, and jumps to the kernel context to execute the operating system program; The embedded device is used to obtain system call information according to the context of the application program saved most recently; The embedded device is used to package the system call information, and send the packaged data and the system call request to the host computer in the polling state, and the operating system of the embedded device enters the data waiting state; The host computer is used to parse the packaged data to obtain the system call information when receiving the system call request, obtain the output data corresponding to the system call information, and send the output data corresponding to the system call information to the embedded device; The embedded device is used to enable the operating system to load the context of the application program saved most recently after receiving the output data corresponding to the system call information, and to continue executing the application program using the output data corresponding to the received system call information.

Images