CN117130931A

CN117130931A - Embedded software debugging method and device

Info

Publication number: CN117130931A
Application number: CN202311129500.0A
Authority: CN
Inventors: 朱琳琳; 胡东纯; 翟淑琴; 金银军
Original assignee: Sichuan Kedao Xinguo Intelligent Technology Co ltd
Current assignee: Sichuan Kedao Xinguo Intelligent Technology Co ltd
Priority date: 2023-09-01
Filing date: 2023-09-01
Publication date: 2023-11-28

Abstract

The application relates to an embedded software debugging method and device, and belongs to the field of embedded software development. The application develops the target plugin corresponding to the target chip based on the plugin interface provided by the development environment; the target plug-in performs data interaction with the development environment through the plug-in interface, and is connected with target equipment through a Socket interface; wherein the target device comprises at least: simulating a coprocessor; responding to the development environment entering a debugging state and the target plug-in receiving an embedded software debugging instruction, and acquiring a debugging command interface code through the simulation coprocessor; according to the command type corresponding to the debugging command interface code, debugging data processing is carried out to obtain a debugging processing result; and returning the debugging processing result to the target plug-in, so as to return the data processing result to the development environment through the target plug-in. The application is beneficial to reducing the hardware cost and improving the debugging accuracy.

Description

Embedded software debugging method and device

Technical Field

The application belongs to the technical field of embedded software development, and particularly relates to an embedded software debugging method and device.

Background

Currently, embedded programs run on embedded chips, but development and debugging tools are on general-purpose computers. Because of the great difference between chips and environments of the target machine and the development machine, cross-compiling is required, and embedded programs are usually required to be downloaded to the target machine for running and debugging.

In practice, it is found that the existing chip design manufacturer will develop or delegate the development of an emulator corresponding to the chip, which can establish a connection with a host port (serial port or USB port), on which debug software is installed. The debugging software can communicate with the simulator through a preset protocol (JTAG or BMD, etc.), so as to achieve the purpose of tracking control and realize the debugging function. However, this embedded software debugging method requires the development of an emulator, and has a problem of high hardware cost.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

Therefore, the application provides the embedded software debugging method and the device, which are beneficial to reducing the hardware cost and improving the debugging accuracy.

In order to achieve the above purpose, the application adopts the following technical scheme:

in a first aspect, the present application provides an embedded software debugging method, the method comprising:

developing a target plug-in corresponding to the target chip based on a plug-in interface provided by a development environment; the target plug-in performs data interaction with the development environment through the plug-in interface, and is connected with target equipment through a Socket interface; wherein the target device comprises at least: simulating a coprocessor;

responding to the development environment entering a debugging state and the target plug-in receiving an embedded software debugging instruction, and acquiring a debugging command interface code through the simulation coprocessor;

according to the command type corresponding to the debugging command interface code, debugging data processing is carried out to obtain a debugging processing result;

and returning the debugging processing result to the target plug-in, so as to return the data processing result to the development environment through the target plug-in.

Further, the method further comprises:

synchronously updating the data zone bit in the target plug-in based on the debugging data processing category in the target plug-in; wherein the debug data processing class includes at least a data input and a data output.

Further, before the obtaining of the debug command interface code by the emulation coprocessor, the method further comprises:

and configuring a register through the target plug-in.

Further, configuring a register by the target plug-in includes:

defining a virtual register set in the target plugin;

setting a trigger function corresponding to a virtual address of each virtual register in the virtual register group through the target plug-in;

the trigger function is used for reading and writing data in the virtual address of the virtual register.

Further, the method further comprises:

writing a preset binary image file into a designated address space through the target plug-in;

and in response to receiving a loading instruction for the preset binary image file, determining that the target plug-in receives the embedded software debugging instruction.

Further, the method further comprises:

and modifying the dormant code into the idle operation through a modification instruction provided by the target plug-in.

In a second aspect, the present application provides an embedded software debugging apparatus, the apparatus comprising a target plugin and an emulation coprocessor; the target plug-in is a plug-in which is developed based on a plug-in interface provided by a development environment and corresponds to a target chip, the target plug-in performs data interaction with the development environment through the plug-in interface, and the target plug-in is connected with target equipment through a Socket interface; wherein the target device comprises at least: the simulation coprocessor;

the simulation coprocessor is used for responding to the fact that the development environment enters a debugging state and the target plug-in receives an embedded software debugging instruction to acquire a debugging command interface code;

the simulation coprocessor is also used for performing debugging data processing according to the command type corresponding to the debugging command interface code to obtain a debugging processing result;

the simulation coprocessor is further used for returning the debugging processing result to the target plug-in unit so as to return the data processing result to the development environment through the target plug-in unit.

Further, the target plugin is further configured to:

the registers are configured by the target plugin prior to retrieval of the debug command interface code by the emulation coprocessor.

Further, the target plug-in is specifically configured to:

defining a virtual register set in the target plugin;

Further, the target plugin is further configured to:

writing a preset binary mirror image file into a designated address space;

Further, the target plugin is further configured to:

In a third aspect, the present application provides an electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the first aspect.

In a fourth aspect, the present application provides a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of the first aspect.

In a fifth aspect, the application provides a computer program product comprising a computer program which, when executed by a processor, implements the method of the first aspect.

The application adopts the technical proposal and has at least the following beneficial effects:

according to the application, the target plugin corresponding to the target chip is developed based on the plugin interface provided by the development environment; the target plug-in performs data interaction with the development environment through the plug-in interface, and is connected with target equipment through a Socket interface; wherein the target device comprises at least: simulating a coprocessor; responding to the development environment entering a debugging state and the target plug-in receiving an embedded software debugging instruction, and acquiring a debugging command interface code through the simulation coprocessor; according to the command type corresponding to the debugging command interface code, debugging data processing is carried out to obtain a debugging processing result; and returning the debugging processing result to the target plug-in, so as to return the data processing result to the development environment through the target plug-in. According to the application, software simulation debugging is realized based on the target plug-in and the simulation coprocessor, an additional simulator is not required to be developed, hardware cost is reduced, source codes are not required to be modified, the actual running condition of the embedded chip is reflected to the greatest extent, and thus the debugging accuracy is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart illustrating a method of embedded software debugging according to an exemplary embodiment;

FIG. 2 is a diagram illustrating a target plug-in data flag update for an embedded software debug method, according to an example embodiment;

FIG. 3 is a block diagram of an embedded software debug apparatus, according to an example embodiment;

fig. 4 is a block diagram schematically illustrating a structure of an electronic device according to an exemplary embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail below. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, based on the examples herein, which are within the scope of the application as defined by the claims, will be within the scope of the application as defined by the claims.

Referring to fig. 1, fig. 1 is a flowchart illustrating an embedded software debugging method according to an exemplary embodiment, the embedded software debugging method comprising the steps of:

step S101, developing a target plug-in corresponding to a target chip based on a plug-in interface provided by a development environment; the target plug-in performs data interaction with the development environment through the plug-in interface, and is connected with target equipment through a Socket interface; wherein the target device comprises at least: the coprocessor is emulated.

In this embodiment, the execution body may be an electronic device such as a terminal device or a server for performing embedded software debugging.

The embedded program runs on the embedded chip, but the development and debugging tools are all on the general-purpose computer, and because the chips and environments of the target machine and the development machine are extremely different, cross compiling is needed, and the cross compiling is usually needed to be downloaded to the target machine for running and debugging.

The present application utilizes the pure software simulation function of the standard kernel on the basis, dynamically modifies the nonstandard function after loading the target code, and modifies the value of the register after the external simulation is completed to complete the whole simulation process. In addition, in the process, the source code is not modified, debug version is not needed, the hex file is not modified, and the software simulation debugging is carried out under the actual running condition of the chip as truly as possible, so that a more accurate embedded software debugging effect is achieved.

First, each chip develops its own target plug-in using a plug-in interface provided by the development environment. Assuming the chip model is MySC000, a corresponding target plug-in needs to be developed according to the chip manual, which may be named MySC000.Dll.

The target plug-in can conduct data interaction with the development environment through a plug-in interface, and the target plug-in can be connected with target equipment through a Socket interface. The target device may include, but is not limited to, an analog coprocessor, other various existing test tools, etc., which are not limited in this embodiment.

Wherein, because the bearing capacity of the target plug-in of the development environment is limited, the function is easy to crash when running complex scripts too much. Therefore, the target plug-in is mainly used for carrying out data interaction with the development environment, and other complex functions can transmit tasks to the target device through the Socket interface. As the target equipment can adopt various existing test tools, the embedded software debugging mode can realize flexible expansion, improves the debugging convenience and reduces the development difficulty.

Step S102, responding to the development environment entering a debugging state and the target plug-in receiving an embedded software debugging instruction, and acquiring a debugging command interface code through the simulation coprocessor.

In this embodiment, the development environment can be controlled to enter the debug state based on configuration of engineering options of the development environment. Specifically, the debug interface of the engineering option can be opened to complete the following three configurations: 1. switching hardware debugging to software debugging; 2. check "Run to main"; 3. add "-dmysc000.DLL at Dial DLL: parameter input box. And then, exiting according to OK, so as to realize the configuration of the development environment.

Further, after the configuration of the development environment is completed, the development environment menu Debug- > Start/Stop Debug Session (or click shortcut) can be clicked to enter the Debug state.

Further, the embedded software debugging instruction is triggered by clicking a button 'load file' on the target plug-in, selecting the prepared binary image file and then pressing the binary image file. The target plug-in will then begin simulation reform and then command "GO" to begin running.

The target plug-in and the simulation coprocessor can be both deployed locally, and the simulation coprocessor processes data according to the command type and returns the data to the target plug-in, so that the target plug-in modifies the development environment memory data again. In addition, the simulation coprocessor may forward commands from external tools to the target plugin to cause the target plugin to pass data to the development environment.

Wherein the debug command interface code may be a command code for debugging that emulates user input.

Step S103, according to the command type corresponding to the debugging command interface code, debugging data processing is carried out, and a debugging processing result is obtained.

In this embodiment, the debug command interface code may include at least a command type and command data. After the debug command interface code is acquired by the simulation coprocessor, a command type corresponding to the debug command interface code may be further determined, and debug data processing is performed based on the command type. The debug data processing here may include processing operations of reading and writing data in accordance with a command type or the like. And after the debugging data processing is carried out, a corresponding debugging processing result can be obtained. The debugging process results herein may include, but are not limited to, processed data, processed commands, and the like.

And step S104, returning the debugging processing result to the target plug-in, so as to return the data processing result to the development environment through the target plug-in.

In this embodiment, after the simulation coprocessor processes the debug data, the debug processing result may be returned to the target plugin, and the target plugin interacts with the development environment, so as to return the debug processing result to the development environment.

Further, the method further comprises:

In this embodiment, the target plug-in may be used to simulate the hardware operation of the embedded chip, and coordinate the timing with the debugging software in the development environment. The target plug-in can simulate the data placement mark function of hardware, combines the data placement mark function with a monitoring function, a register reading and modifying interface provided by debugging software in a development environment, simulates the data input and output process, and realizes software simulation debugging.

Referring to fig. 2 together, fig. 2 is a schematic diagram illustrating updating of a flag bit of target plug-in data of an embedded software debugging method according to an exemplary embodiment, and fig. 2 illustrates a process of receiving data. The software side can fetch the cache data to the instruction and control the cache flag to be set empty. Thereafter, if the reception buffer on the software side is empty, it may wait for the reception data. After receiving the received data, the step of fetching the buffered data to the instruction and clearing the buffered flag may be repeated. For the plug-in, the plug-in can judge whether the receiving buffer is empty, if so, the data can be put into the buffer, and meanwhile, the buffer mark is not empty. If it is determined that the receive buffer is not empty, a wait operation may be performed.

and configuring a register through the target plug-in.

In this embodiment, the initialization configuration centralized management of the registers can be unified into the plug-in operation, and no separate configuration is needed, so that development convenience is further improved.

Specifically, after the chip designer takes the core authorization, the chip designer defines its own register according to the requirement, and the first problem encountered when simulating with the standard core is illegal access, and the solution is that when the target code is still stopped at the starting point after loading, a mapping instruction is sent through the command interface of the target plug-in to make the register and the memory legal, for example:

Agsi.ExecuteCommand("MAP 0x40000000,0x400000E0 READ write")

instruction meaning: the execution of the command by the plug-in corresponds to the manual input after the command area prompt ">" of the development environment, and the content in the double quote is input, which means that the space of the addresses 0x40000000 to 0x400000E0 is made readable and writable.

Further, configuring a register by the target plug-in includes:

defining a virtual register set in the target plugin;

In this embodiment, when the register is configured by the target plug-in, since the target plug-in cannot directly acquire the core register, a set of virtual registers, that is, the above-described virtual register set, may be defined in the target plug-in. The address of the virtual register avoids conflict with the standard core and the target chip. Then, for the virtual registers in each virtual register group, a trigger function corresponding to the virtual address of the virtual register can be set in the target plug-in, so that corresponding data read-write operation can be executed from the virtual address of the virtual register through the trigger function.

Based on this, the analog coprocessor can be further modified.

For example, one interface is:

SetKey(ALG_DES,inkey,8,MODE_ECB,flag)；

EncDec(ALG_DES,NULL,source,dest,8)；

each call is compiled into a parameter preparation and call, and the 2 parts of the space are available.

The SetKey call is externally expected to obtain 2 values, i.e., an inkey and a flag, which are respectively placed in the registers R1 and R4, and since the plug-in cannot directly obtain the kernel register, we need to fetch it in an indirect way.

Firstly, a group of virtual registers are defined in the plug-in, addresses are not required to conflict with a standard core and the chip, and are marked as F1, F2, F3 and F4 for convenience of description. A free register is found for storing virtual addresses without destroying the function. In this example, ALG_DES stored in R0 is known as DES, and is not required to be fetched and can be borrowed. An instruction like mov r0, #f1 is written as a machine code. The write trigger of the F1 address is set in the plug-in, and the trigger function is fun1 (). Instructions STR R1, [ R0, #0] are translated into machine code. The instruction stores the address of the inkey in F1, triggering the fun1 function. The value in the read virtual register F1 in the fun1 function is stored in the variable keyaddr. The first 8 bytes of keyaddr are read again to obtain the required key. The same method takes out the flag value and source value.

Triggering fun4 (), when writing the target address dest, the plug-in performs the following operations: the dest address is kept in reserve. All the data obtained before are spliced according to the preset format, the prefix des is added, a socket is used for sending the data to a simulation coprocessor, a waiting sign is set, and the result of the simulation coprocessor is obtained. After receiving the instructions from des, the analog coprocessor starts to decompose the data, calculates the data by using des algorithm and sends the result back to the plug-in unit. After receiving the information of the calculation result, the plug-in stores the result in the buffer memory and sets a completion mark. After the function waiting for the result detects the completion mark, the plug-in writes the result in the cache into the dest address of the code by using the plug-in interface, the monitoring function fun4 () exits, the control right returns to the code to execute the following operation, and the co-processing simulation is completed.

In the process of self-defining coprocessor emulation, on one hand, the original call is removed, but the operation cannot be simply replaced by the idle operation, because the size of the machine code cannot be changed, the data is transmitted out at the interface, and the result is written after external calculation. The technical means is that the interface code is replaced by the monitorable code to transmit the parameters, and simultaneously, the storage address of the result is also transmitted, and the result is put in the appointed position by external calculation, so that the whole co-processing function is completed. Specifically, the user input command can be simulated through the user command interface, and the modification instruction is input to modify the machine code loaded into the memory.

For example: analog input command "e char 0x 1234=0xf1, 0x22,0x12,0x06,0x10,0x60, 0". Assuming that the code address of the original calling write processor is 0x1234, the original calling code has parameter preparation and jump statements, and the meaning of the command is as follows: the calling code at 0x1234 is modified, parameters are passed to monitorable F1 instead, and the original jump code is set to a null statement. This allows switching the call co-processing to external simulation.

Further, the method further comprises:

In this embodiment, the file system may be made as a binary image file for use. For the address space of the file system, a mapping instruction can be triggered based on the target plug-in to realize the mapping of the address space of the file system. And, the preset binary image file can be written into the designated address space through the target plugin. If a loading instruction of a preset binary image file is received, namely, a button 'loading file' on a clicking plug-in is detected, the prepared binary image file is selected and then determined, and then the target plug-in is determined to receive the embedded software debugging instruction.

Further, the method further comprises:

In this embodiment, the dormant code, if not removed, will stop the entire system. When the program stops at the starting position, the assembly code is checked, the address of the dormant code is found, and the address code is modified by a modification command provided by the plug-in.

Assuming the address is 0x00002200, the command parameter is written as "0x00002200 =0, 0", and in the c51 context it will be seen that the instruction is changed to nop, nop, nop, arm, while the core will be changed to:

MOV r0,r0

that is, the sleep code is actually modified to be a null operation, and by replacing it with a null operation, entry into sleep is avoided.

In addition, for the operation of the chip coprocessor, the call interface address is often found through interface call in the encapsulation library, and preliminary transformation and call shielding can be performed in the same way.

Referring to fig. 3, fig. 3 is a block diagram illustrating an embedded software debugging apparatus according to an exemplary embodiment, the embedded software debugging apparatus including a target plug-in and an emulation coprocessor; the target plug-in is a plug-in which is developed based on a plug-in interface provided by a development environment and corresponds to a target chip, the target plug-in performs data interaction with the development environment through the plug-in interface, and the target plug-in is connected with target equipment through a Socket interface; wherein the target device comprises at least: the simulation coprocessor;

Further, the target plugin is further configured to:

Further, the target plug-in is specifically configured to:

defining a virtual register set in the target plugin;

Further, the target plugin is further configured to:

writing a preset binary mirror image file into a designated address space;

Further, the target plugin is further configured to:

The specific manner in which the respective modules perform the operations in the embedded software debug apparatus in the above-described embodiments has been described in detail in the above-described embodiments of the related methods, and will not be described in detail herein.

Referring to fig. 4, fig. 4 is a block diagram schematically illustrating an electronic device according to an exemplary embodiment, and the electronic device 4 includes:

at least one processor 41; and

a memory 42 communicatively coupled to the at least one processor 41; wherein,

the memory 42 stores instructions executable by the at least one processor 41 to enable the at least one processor 41 to perform the associated embedded software debugging method described above.

In practical applications, the electronic device 4 may be a terminal device or a server, and it should be noted that the electronic device 4 is not limited to be embodied in the form of a terminal device or a server. The specific manner in which the processor 41 executes the program in the memory 42 of the electronic device 4 in the above-described embodiment has been described in detail in the embodiment concerning the method, and will not be described in detail here.

Furthermore, the present application provides a non-transitory computer readable storage medium storing computer instructions for causing the computer to execute the above-described related embedded software debugging method.

Wherein the storage medium may be a magnetic Disk, an optical Disk, a Read-only Memory (ROM), a random access Memory (Random Access Memory, RAM), a Flash Memory (Flash Memory), a Hard Disk (HDD), a Solid State Drive (SSD), or the like; the storage medium may also comprise a combination of memories of the kind described above.

Furthermore, the application provides a computer program product comprising a computer program which, when executed by a processor, implements a method of debugging embedded software according to the above.

It is to be understood that the same or similar parts in the above embodiments may be referred to each other, and that in some embodiments, the same or similar parts in other embodiments may be referred to.

It should be noted that in the description of the present application, the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. Furthermore, in the description of the present application, unless otherwise indicated, the meaning of "plurality", "multiple" means at least two.

It will be understood that when an element is referred to as being "mounted" or "disposed" on another element, it can be directly on the other element or intervening elements may also be present; when an element is referred to as being "connected" to another element, it can be directly connected to the other element or intervening elements may be present, and further, as used herein, connection may comprise a wireless connection; the use of the term "and/or" includes any and all combinations of one or more of the associated listed items.

Any process or method description in a flowchart or otherwise described herein may be understood as: means, segments, or portions of code representing executable instructions including one or more steps for implementing specific logical functions or processes are included in the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including in a substantially simultaneous manner or in an inverse order, depending upon the function involved, as would be understood by those skilled in the art of embodiments of the present application.

It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.

Those of ordinary skill in the art will appreciate that all or part of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, where the program when executed includes one or a combination of the steps of the method embodiments.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing module, or each unit may exist alone physically, or two or more units may be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules may also be stored in a computer readable storage medium if implemented as software functional modules and sold or used as a stand-alone product.

The above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, or the like.

In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

While embodiments of the present application have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the application, and that variations, modifications, alternatives and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the application.

Claims

1. An embedded software debugging method, the method comprising:

2. The method according to claim 1, wherein the method further comprises:

3. The method of claim 1, wherein prior to retrieving debug command interface code by the emulation coprocessor, the method further comprises:

and configuring a register through the target plug-in.

4. A method according to claim 3, wherein configuring registers by the target plug-in comprises:

defining a virtual register set in the target plugin;

5. The method according to claim 1, wherein the method further comprises:

6. The method according to claim 1, wherein the method further comprises:

7. An embedded software debugging device, which is characterized by comprising a target plug-in and an analog coprocessor; the target plug-in is a plug-in which is developed based on a plug-in interface provided by a development environment and corresponds to a target chip, the target plug-in performs data interaction with the development environment through the plug-in interface, and the target plug-in is connected with target equipment through a Socket interface; wherein the target device comprises at least: the simulation coprocessor;

8. The apparatus of claim 7, wherein the target plugin is further to:

9. The apparatus of claim 7, wherein the target plugin is further to:

10. The device according to claim 9, wherein the target insert is specifically configured to:

defining a virtual register set in the target plugin;