Simulator supporting multiple debugging permissions

Abstract

The invention discloses a simulator supporting multiple debugging permissions. According to the embodiment of the invention, the simulator supporting multiple debugging permissions comprises a simulator management module which comprises a configuration unit, and the configuration unit is used for configuring the debugging permissions; a storage unit of the simulator hardware module is divided into a safe area and a non-safe area; the security area is used for storing security data, the non-security area is used for storing non-security data, and the debugging permission comprises a security mode and a limited mode; in the security mode, allowing access to the security area and the non-security area; and in the limited mode, the access to the safe area is prohibited, and the access to the non-safe area is allowed. According to the emulator supporting the multiple debugging permissions, debugging requirements of different security levels can be effectively distinguished, and flexible access control is provided for development and maintenance while data security is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of chip emulator technology, and in particular to an emulator that supports multiple debugging permissions. Background Technology

[0002] This emulator, based on FPGA (Field-Programmable Gate Array) chip simulation capabilities, enables chip function debugging via a JTAG / SWD interface. Users download programs to the emulator hardware through the emulator's IDE (Integrated Development Environment) interface and then debug the program in the IDE's debugging interface. Users can set the program counter (PC) value or execute program calls, causing the program to jump to the corresponding instruction entry point. If an assignment command is being executed, the emulator hardware executes the current instruction and returns CPU status information; the IDE debugging interface then stops at the next instruction and updates the current debugging window. If a function call is being executed, the IDE debugging interface stops at the first instruction of the function after a single-step debugging command and updates the debugging window. Using the IDE's single-step debugging command, users can easily analyze the program execution flow, discover anomalies, and quickly locate and resolve problems in the program design.

[0003] However, in existing financial applications and SE (Secure Element) chip development, due to the high security requirements of these products, the development of chip emulators necessitates protecting their respective security algorithms and configuration processes. This allows unauthorized users to call secure algorithm API programs, but prohibits them from stepping into these API functions via single-step debugging commands to analyze API function data and algorithm flows. Especially with current CPU cores offering higher security levels (hardware support for Secure and Non-Secure access restrictions), if the chip hardware and software are developed by the same company, secure debugging protection may not be necessary. However, in actual chip application development, the COS (Chip Operating System) may need to be developed by different companies (A_COS and B_COS), and the algorithms and security data from these different companies require access protection during software debugging.

[0004] Therefore, there is a need for a new emulator that supports multiple debugging permissions and can overcome at least one of the above problems. Summary of the Invention

[0005] In view of the above problems, the purpose of this invention is to provide an emulator that supports multiple debugging permissions, thereby effectively distinguishing debugging needs of different security levels, and providing flexible access control for development and maintenance while ensuring data security.

[0006] According to one aspect of the present invention, an emulator supporting multiple debugging permissions is provided, comprising:

[0007] The emulator management module includes a configuration unit, which is used to configure debugging permissions.

[0008] The simulator hardware module has a storage unit divided into a secure area and a non-secure area; the secure area is used for storing secure data, and the non-secure area is used for storing non-secure data.

[0009] The debugging permissions include a secure mode and a restricted mode; in the secure mode, access to the secure zone and the non-secure zone is allowed; in the restricted mode, access to the secure zone is prohibited, but access to the non-secure zone is allowed.

[0010] Optionally, the emulator management module is a software module; the emulator management module configures different debugging permissions by loading FLM files with different permission levels;

[0011] The debugging permissions also include a chip management mode; in the chip management mode, debugging of the entire program area is allowed.

[0012] In the secure mode, debugging of programs in both the secure zone and the insecure zone is permitted;

[0013] In the restricted mode, debugging of programs in the secure zone is not allowed, but debugging of programs in the non-secure zone is allowed.

[0014] The security data includes at least one of the following: algorithms selected from chip manufacturers, algorithms from security users, and sensitive data.

[0015] Optionally, in the restricted mode, step-by-step debugging and data viewing are allowed for the program in the non-secure area, while step-by-step debugging is prohibited for the program in the secure area, and obtaining the instruction content of the program in the secure area through the debugging interface is prohibited.

[0016] Optionally, the simulator management module is connected to the simulator hardware module to implement program loading and debugging functions, and sends at least one command selected from mode setting command, single-step debugging command, and other control commands to the simulator hardware module through an interface.

[0017] The simulator hardware module also includes a debug path unit, a processor unit, a debug control unit, and an access control unit;

[0018] The debugging path unit is connected to the simulator management module to receive and respond to configured debugging permissions and debugging commands; the debugging path unit is connected to the processor unit through an interface to transmit debugging instructions; the debugging path unit is connected to the debugging control unit to realize debugging mode selection and program debugging control.

[0019] The access control unit is connected to the processor unit to control the access permissions of the currently executed instructions of the processor unit; the access control unit is connected to the storage unit to obtain the current instructions and determine their debugging permissions, and output the corresponding instruction debugging control signals.

[0020] The storage unit supports access to secure zone programs and non-secure zone programs; the secure zone programs are stored in the secure zone, and the non-secure zone programs are stored in the non-secure zone.

[0021] Optionally, the processor unit outputs a current instruction access status signal to indicate the access security during the execution of the current instruction; when the secure area program accesses a secure area address, it outputs a status signal indicating secure access; when the secure area program accesses a non-secure area address, it outputs a status signal indicating insecure access; when the non-secure area program accesses a secure area address, it outputs a status signal indicating insecure access and triggers a security exception; when the non-secure area program accesses a non-secure area address, it outputs a status signal indicating insecure access.

[0022] Optionally, the debug control unit outputs a debug enable signal; when the debug enable signal is enabled, the instruction at the current address can be debugged step by step, and the debug site data is uploaded through the debug path unit; when the debug enable signal is disabled, the instruction at the current address cannot be debugged step by step, and the uploaded debug site data is invalid data.

[0023] Optionally, the debugging path unit outputs a debugging mode selection signal to indicate the current debugging permission level of the simulator;

[0024] The debugging permission level includes at least one of the following: prohibiting all program debugging, supporting debugging of programs in both safe and unsafe zones, supporting debugging of programs in only unsafe zones, and supporting debugging of programs in all zones.

[0025] Optionally, the access control unit determines whether debugging is allowed based on the instruction information read from the storage unit, and outputs a current instruction debugging control signal; when the current instruction debugging control signal is allowed, the corresponding instruction supports single-step debugging; when the current instruction debugging control signal is disabled, the corresponding instruction does not support single-step debugging.

[0026] Optionally, after the simulator hardware module is powered on, it executes a boot program, first entering the safe zone to perform initialization operations, and then jumping to the non-safe zone program execution, so as to support restricted users to perform single-step debugging and data viewing of the non-safe zone program;

[0027] The emulator hardware module clears the programs and data in the safe zone after a power outage; after power is restored, the emulator management module reloads the programs and data using an FLM file.

[0028] Optionally, encryption is used when transmitting data, and the encrypted data is decrypted in the static random access memory of the simulator hardware module; after the program is loaded, the plaintext data in the static random access memory is cleared.

[0029] The present invention provides a simulator that supports multiple debugging permissions. The configuration unit of the simulator management module configures debugging permissions, including a secure mode and a restricted mode. In the secure mode, access to the secure area and the non-secure area is allowed. In the restricted mode, access to the secure area is prohibited, but access to the non-secure area is allowed. This can effectively distinguish the debugging needs of different security levels and provide flexible access control for development and maintenance while ensuring data security.

[0030] Furthermore, the emulator management module is a software module that configures different debugging permissions by loading FLM files with different permission levels. The configuration of debugging permissions is simple and can avoid the risk of cracking caused by directly modifying debugging permissions at the hardware level.

[0031] Furthermore, the security data in the secure zone includes at least one of the following: algorithms selected from chip manufacturers, algorithms from secure users, and sensitive data. When the emulator defines a restricted debugging mode, users cannot debug programs in the secure zone, nor can they disassemble or perform single-step tracing analysis of programs in the secure zone. This ensures that the core code and sensitive information in the secure zone are not leaked, effectively preventing reverse engineering and illegal debugging.

[0032] Furthermore, the emulator hardware module clears the programs and data in the secure area after a power outage; upon power restoration, the emulator management module reloads the programs and data via an FLM file. This mechanism ensures that sensitive information cannot be physically extracted without power, greatly enhancing the system's resistance to attacks.

[0033] Furthermore, encryption is used during data transmission, and the encrypted data is decrypted in the static random access memory of the simulator hardware module. After the program is loaded, the plaintext data in the static random access memory is cleared. This design prevents plaintext data from residing in the storage medium for a long time and effectively prevents information leakage caused by reading residual data in the memory through physical means.

[0034] Furthermore, this application mainly involves the collaborative division of the emulator into a secure zone and a non-secure zone using both hardware and software. The chip manufacturer's (and the secure user's) algorithms and sensitive data are stored in the secure zone. The emulator implements chip management mode, secure user mode, and restricted user mode through different permission FLM configurations. Through the permission settings of the restricted user mode, the algorithm flow and sensitive data of different users can be protected. Attached Figure Description

[0035] The above and other objects, features and advantages of the present invention will become more apparent from the following description of embodiments of the invention with reference to the accompanying drawings, in which:

[0036] Figure 1 A schematic diagram of a simulator supporting multiple debugging permissions according to Embodiment 1 of the present invention is shown;

[0037] Figure 2 A schematic diagram of the structure of a simulator supporting multiple debugging permissions according to Embodiment 2 of the present invention is shown;

[0038] Figure 3 A schematic diagram of the debugging process of an emulator supporting multiple debugging permissions according to an embodiment of the present invention is shown;

[0039] Figure 4 A schematic diagram of the startup process of an emulator supporting multiple debugging permissions according to an embodiment of the present invention is shown. Detailed Implementation

[0040] Various embodiments of the invention will now be described in more detail with reference to the accompanying drawings. In the various drawings, the same elements are indicated by the same or similar reference numerals. For clarity, the various parts in the drawings are not drawn to scale. Furthermore, certain well-known parts may not be shown in the drawings.

[0041] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. Many specific details of the invention, such as the structure, materials, dimensions, processing techniques, and methods of the components, are described below to provide a clearer understanding of the invention. However, as those skilled in the art will understand, the invention may be implemented without following these specific details.

[0042] It should be understood that when describing the structure of a component, when referring to a layer or region as being "above" or "on top of" another layer or region, it can mean that it is directly above the other layer or region, or that it contains other layers or regions between it and the other layer or region. Furthermore, if the component is flipped over, that layer or region will be located "below" or "under" the other layer or region.

[0043] Figure 1 A schematic diagram of a simulator supporting multiple debugging permissions according to Embodiment 1 of the present invention is shown. Figure 1 As shown, the emulator supporting multiple debugging permissions according to Embodiment 1 of the present invention includes an emulator management module 100 and an emulator hardware module 200.

[0044] Specifically, the simulator management module 100 includes a configuration unit 110. The configuration unit 110 is used to configure debugging permissions.

[0045] The simulator hardware module 200 includes a storage unit 210. The storage unit 210 is divided into a secure area 211 and a non-secure area 212. The secure area 211 is used for storing secure data, and the non-secure area 212 is used for storing insecure data.

[0046] Debugging permissions include secure mode and restricted mode. In secure mode, access to both secure and insecure zones is allowed; in restricted mode, access to secure zones is prohibited, but access to insecure zones is allowed.

[0047] In an optional embodiment of the present invention, the emulator management module 100 is a software module. The emulator management module 100 configures different debugging permissions by loading configuration files with different permission levels. Optionally, the emulator management module 100 configures different debugging permissions by loading FLM (Flash Loader Module) files with different permission levels. The FLM file contains permission configuration information, and parsing this file can activate the corresponding debugging mode.

[0048] Debugging permissions also include chip management mode. In chip management mode, debugging of all program regions is allowed. In secure mode, debugging of programs in both secure and insecure areas is allowed. In restricted mode, debugging of programs in secure areas is not allowed, but debugging of programs in insecure areas is allowed. Security data includes at least one of the following: algorithms from the chip manufacturer, algorithms from secure users, and sensitive data.

[0049] In an optional embodiment of the present invention, in restricted mode, step-by-step debugging and data viewing are allowed for programs outside the secure area, while step-by-step debugging of programs in the secure area is prohibited, and obtaining the instruction content of programs in the secure area through the debugging interface is prohibited.

[0050] Figure 2 A schematic diagram of a simulator supporting multiple debugging permissions according to Embodiment 2 of the present invention is shown. Figure 2 As shown, the emulator supporting multiple debugging permissions according to Embodiment 2 of the present invention includes an emulator management module 100 and an emulator hardware module 200.

[0051] The simulator management module 100 contains a debug permission FLM file. This debug permission FLM file is stored, for example, in the settings unit.

[0052] The simulator hardware module 200 includes a storage unit (program storage area module) 210, a debug path unit (module) 220, a debug control unit (module) 230, a (CPU) processor unit (module) 240, and an access control unit (module) 250. Among them, the storage unit 210 is divided into a secure area 211 and a non-secure area 212.

[0053] The simulator management module 100 is connected to the simulator hardware module 200 to realize simulator program loading and program debugging functions. The simulator management module 100 sends mode setting commands, single-step debugging commands and other control commands to the simulator hardware module 200 through the SWD_MODESEL interface.

[0054] The debug path module 220 is connected to the emulator management module 100 to configure debug permissions and receive and respond to debug commands. The debug path module 220 is also connected to the CPU processor module 240, transmitting debug commands to it via the SWD interface. Finally, the debug path module 220 is connected to the debug control module 230 to select the emulator's hardware debug mode and control program debug execution.

[0055] Access control module 250 is connected to CPU processor module 240 to implement CPU current instruction execution and access control. Access control module 250 is also connected to program storage module 210, which acquires the current instruction, determines the debugging permission of the current instruction, and outputs a debugging control signal for the current instruction. Program storage module 210 is used to implement access and storage of programs in the secure area and non-secure area.

[0056] Specifically, in combination Figure 2As shown, in a specific embodiment of the present invention, the emulator management module 100 uses FLM files with different debugging permissions to implement different levels of user debugging permission management. When the emulator management module 100 sets the emulator hardware to CMS (Chip Management System) permissions, the emulator hardware supports program debugging in all areas of the chip. When the emulator management module 100 sets the emulator hardware to secure user permissions, the emulator hardware supports program debugging in both secure and non-secure areas.

[0057] The emulator management module 100 sets the emulator hardware to a restricted debug mode. When the emulator management module 100 executes a program that calls the safe zone, the user cannot step into the safe zone program or view the safe zone program instructions through the debug window. When the emulator management module 100 executes a program outside the safe zone, the user can perform step-by-step debugging of the instructions and view the program outside the safe zone in the debug window.

[0058] The CPU processor module 240 outputs the current instruction access status CURR_INST_STAT signal. When a program accesses a secure address, the access is secure and the CURR_INST_STAT signal is low. When a program accesses a non-secure address, the access is insecure and the CURR_INST_STAT signal is high. When a program accesses a secure address, the access is insecure, the CPU processor generates a security exception and outputs the CURR_INST_STAT signal high. When a program accesses a non-secure address, the access is insecure and the CURR_INST_STAT signal is high.

[0059] The emulator's debug control module 230 outputs a debug enable signal DBG_EN. When DBG_EN is high, the current address instruction can be single-stepped, and debug field data can be uploaded through the debug path module. When DBG_EN is low, the current address instruction cannot be single-stepped, and all debug field data uploaded by the debug path module is 0. Optionally, the debug permissions in the debug control module refer to the hardware default permissions when the emulator is powered on, and debug permissions can be reconfigured through the emulator management module.

[0060] The debug path module 220 in the emulator outputs the debug mode selection signal DBG_MODE_SEL. When the DBG_MODE_SEL signal is 0x00, it indicates that the current emulator only supports the SWD interface program data loading function and does not support program debugging in all regions. When the DBG_MODE_SEL signal is 0x01, it indicates that the current emulator supports program debugging in both the safe and unsafe areas. When the DBG_MODE_SEL signal is 0x10, it indicates that the current emulator supports program debugging in the restricted unsafe area. When the DBG_MODE_SEL signal is 0x11, it indicates that the current emulator has CMS privileges and supports program debugging in all regions of the emulator.

[0061] The access control module 250 in the simulator reads instructions from the program storage module 210, performs access permission checks, and outputs the current instruction debugging control signal CURR_INST_CTRL. When the CURR_INST_CTRL signal is high, it indicates that the current instruction supports single-step debugging. When the CURR_INST_CTRL signal is low, it indicates that the current instruction does not support single-step debugging.

[0062] In an optional embodiment of the present invention, the emulator hardware module 200 executes a boot program after power-on, first entering the safe zone to perform initialization operations, and then jumping to the non-safe zone to run the program, so as to support restricted users to perform single-step debugging and data viewing of the non-safe zone program. The emulator hardware module 200 clears the program and data in the safe zone after power failure. After power-on, the emulator management module 100 reloads the program and data using the FLM file.

[0063] In an optional embodiment of the present invention, encryption is used during data transmission, and the encrypted data is decrypted in the static random-access memory (SRAM) of the emulator hardware module 200. After the program is loaded, the plaintext data in the SRAM is cleared. Optionally, encryption is performed according to the Triple Data Encryption Standard / Algorithm (TDES).

[0064] This invention provides an emulator supporting restricted debugging, relating to the fields of chip simulation and secure debugging technology. When the emulator management module configures the emulator hardware in restricted debugging mode, the user can only debug programs outside the secure area and cannot debug programs in the secure area. When the emulator management module sends a debugging command, if the current command is a non-secure area instruction, the emulator hardware module executes the instruction, and then the emulator management module stops at the next instruction in the non-secure area. If the current command is a secure area instruction, the emulator hardware module continues executing secure area instructions until it returns to the non-secure area, at which point the emulator management module stops at the non-secure area instruction. The emulator provided by this invention allows users to debug programs outside the secure area only, prohibiting restricted users from single-step debugging and tracing secure area algorithm flows and process data, thus protecting software intellectual property rights.

[0065] Figure 3 A schematic diagram illustrating the debugging process of an emulator supporting multiple debugging permissions according to an embodiment of the present invention is shown. Figure 3 As shown, the emulator supporting multiple debugging permissions according to an embodiment of the present invention executes single-step debugging and non-debuggable single-step processes respectively based on the program area permissions during single-step debugging. Specifically, it includes the following steps:

[0066] In step S101, the command begins;

[0067] In step S102, the software management module sends a debug command;

[0068] The emulator management (software management) module sends debugging commands, which are transmitted to the emulator hardware module via the SWD interface.

[0069] In step S103, the debugging module performs command parsing;

[0070] The debug path module in the simulator hardware module parses debug commands and passes single-step debug instructions to the CPU processor module.

[0071] In step S104, the CPU processor performs a current instruction permission check;

[0072] During the instruction fetching process of the CPU processor module, the permission control module performs permission checks on the current instruction.

[0073] In step S105, it is determined whether it is a safe zone command;

[0074] If the current instruction is determined to be in the safe zone, then proceed to step S106; if the current instruction is determined to be in the non-safe zone, then proceed to step S107.

[0075] In step S106, the CPU processor executes a single-step instruction;

[0076] After the CPU processor module finishes executing the single-step instruction, it jumps to step S104 to continue the permission check for subsequent instructions.

[0077] In step S107, the CPU processor executes a single-step instruction;

[0078] After the CPU processor module executes the single-step instruction, it then executes step S108.

[0079] In step S108, the software management module updates the debug window information;

[0080] The CPU status information is returned to the emulator management module, which then updates the window display information, completing the single-step debugging command.

[0081] In step S109, the command ends.

[0082] Figure 4 A schematic diagram illustrating the startup process of an emulator supporting multiple debugging permissions according to an embodiment of the present invention is shown. Figure 4 As shown, when the emulator supporting multiple debugging permissions according to an embodiment of the present invention starts, it includes the following steps:

[0083] In step S201, the simulator is powered on;

[0084] In step S202, the simulator hardware is powered on and reset, and the software management module sends a reset command;

[0085] The emulator hardware executes a power-on reset procedure (or the emulator management module sends a hard reset command);

[0086] In step S203, the emulator performs a hard reset;

[0087] In step S204, the emulator hardware begins the BOOT program;

[0088] The emulator hardware executes the BOOT program and boots into the safe zone for program execution;

[0089] In step S205, the CPU processor executes the secure zone COS program and then jumps to the non-secure zone COS program;

[0090] After the CPU processor initializes global variables and interface devices, it jumps to the non-safe zone to execute the program.

[0091] In step S206, the CPU processor stops at the beginning address of the program in the non-secure area;

[0092] The CPU processor stops at the beginning address of the program in the non-safe zone, supporting restricted user debugging functions, allowing step-by-step debugging of the program in the non-safe zone and viewing its data.

[0093] In step S207, the software management module updates the debug window information;

[0094] In step S208, single-step debugging is performed.

[0095] Perform step-by-step debugging.

[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0097] As described above, these embodiments of the present invention do not exhaustively cover all details, nor do they limit the invention to the specific embodiments described. Clearly, many modifications and variations can be made based on the above description. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to effectively utilize the invention and its modifications. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. An emulator supporting multiple debugging permissions, comprising: an emulator management module, the emulator management module comprising a configuration unit configured to configure a debugging permission; an emulator hardware module, a storage unit of the emulator hardware module being divided into a secure area and a non-secure area; the secure area being configured to store secure data, and the non-secure area being configured to store non-secure data, wherein the debugging permission comprises a secure mode and a restricted mode; in the secure mode, the secure area and the non-secure area are allowed to be accessed; in the restricted mode, the secure area is prohibited to be accessed, and the non-secure area is allowed to be accessed.

2. The emulator of claim 1, wherein, The emulator management module is a software module; the emulator management module implements configuration of different debugging permissions by loading FLM files of different permission levels; The debugging permission further comprises a chip management mode; in the chip management mode, all program regions are allowed to be debugged; In the secure mode, programs in the secure area and the non-secure area are allowed to be debugged; In the restricted mode, programs in the secure area are not allowed to be debugged, and programs in the non-secure area are allowed to be debugged, wherein the secure data comprises at least one of an algorithm selected from a chip vendor, an algorithm of a secure user, and sensitive data.

3. The emulator of claim 1, wherein, In the restricted mode, single-step debugging and data viewing of programs in the non-secure area are allowed, single-step debugging operation of programs in the secure area is prohibited, and instruction contents of programs in the secure area are prohibited to be obtained through a debugging interface.

4. The emulator of claim 1, wherein, The emulator management module is connected with the emulator hardware module, and is configured to implement loading and debugging functions of programs, and send at least one command selected from a mode setting command, a single-step debugging command, and other control commands to the emulator hardware module through an interface; The emulator hardware module further comprises a debugging channel unit, a processor unit, a debugging control unit, and an access control unit; The debugging channel unit is connected with the emulator management module to receive and respond to the configured debugging permission and debugging command; The debugging channel unit is connected with the processor unit through an interface to transfer a debugging instruction; The debugging channel unit is connected with the debugging control unit to implement selection of a debugging mode and control of program debugging; The access control unit is connected with the processor unit to control an access permission of a currently executed instruction of the processor unit; The access control unit is connected with the storage unit to obtain a current instruction and determine a debugging permission thereof, and output a corresponding instruction debugging control signal; The storage unit supports access to secure area programs and non-secure area programs; The secure area programs are stored in the secure area, and the non-secure area programs are stored in the non-secure area.

5. The emulator of claim 4, wherein, The processor unit outputs a current instruction access state signal to indicate the access security when the current instruction is executed; outputs a state signal indicating safe access when the secure area program accesses a secure area address; outputs a state signal indicating non-safe access when the secure area program accesses a non-secure area address; outputs a state signal indicating non-safe access when the non-secure area program accesses a secure area address, and triggers a secure exception; and outputs a state signal indicating non-safe access when the non-secure area program accesses a non-secure area address.

6. The emulator of claim 4, wherein, The debugging control unit outputs a debugging enable signal; when the debugging enable signal is in an allowed state, the instruction at the current address is allowed to be single-stepped, and the debugging field data is uploaded through the debugging channel unit; When the debugging enable signal is in a forbidden state, the instruction at the current address is not allowed to be single-stepped, and the uploaded debugging field data is invalid data.

7. The emulator of claim 4, wherein, The debugging channel unit outputs a debugging mode selection signal to indicate the debugging permission level of the current emulator; The debugging permission level includes at least one selected from the group consisting of forbidding all program debugging, supporting secure area and non-secure area program debugging, supporting only non-secure area program debugging, and supporting all region program debugging.

8. The emulator of claim 4, wherein, The access control unit determines whether debugging is allowed according to the instruction information read from the storage unit, and outputs a current instruction debugging control signal; when the current instruction debugging control signal is allowed, single-step debugging is supported for the corresponding instruction; and when the current instruction debugging control signal is forbidden, single-step debugging is not supported for the corresponding instruction.

9. The emulator of claim 1, wherein, The emulator hardware module executes a boot program after power-on, first enters the secure area to perform initialization operations, and then jumps to the non-secure area program for execution to support single-step debugging and data viewing of the non-secure area program by a restricted user; The emulator hardware module clears the programs and data in the secure area after power-off; and after re-powering on, the emulator management module reloads the programs and data through an FLM file.

10. The emulator of claim 1, wherein, An encryption method is used when data transmission is performed, the encrypted data is decrypted in a static random access memory of the emulator hardware module; and after program loading is completed, the clear data in the static random access memory is cleared.

Images