A flash and hardware interrupt based rom patching method and system

Abstract

The application discloses a ROM patching method and system based on Flash and hardware interruption. The method comprises the following steps: writing a patch program and configuration parameters into the Flash; reading the configuration parameters by a CPU and writing the configuration parameters into a digital module register; configuring an enabling bit of the digital module register by the CPU and starting the digital module; monitoring a current PC value in real time by the digital module, judging whether the current PC value is equal to a PC value triggered by the patch function or not; generating an interruption signal by the digital module; entering an interruption service program according to the interruption signal and detecting whether the digital module register indicates that the current patch is triggered or not; searching for a patch program address corresponding to the current patch trigger and starting to execute the patch program; and ending the execution of the patch program and restoring the normal operation of the ROM program. The application breaks through the dependence of the traditional software patching method on the function calling mode by the architecture of the hardware monitoring combined with the interruption hijacking, and provides an efficient, universal and extendable scheme for the embedded system.

Description

Technical Field

[0001] This invention relates to a ROM patching method based on Flash and hardware interrupts, and also to a ROM patching system for implementing this method, belonging to the field of firmware update technology. Background Technology

[0002] In the field of embedded systems, reducing chip costs and improving hardware reliability are among the core design goals. To achieve this, traditional solutions often embed the core program code in read-only memory (ROM). ROM, with its non-volatility, high reliability, and low cost, has become an ideal choice for storing basic firmware. For example, in industrial control chips, automotive electronic MCUs, and consumer electronics processors, ROM is used to store critical code such as bootloaders, underlying driver protocols, and security authentication algorithms. This code has undergone rigorous verification before chip mass production to ensure the stability of system initialization and basic functions.

[0003] From a hardware implementation perspective, ROM eliminates the need for additional writing circuitry, significantly reducing chip area. This is particularly beneficial for cost-sensitive mass-produced chips, where using ROM to store core code can reduce per-chip costs by 20-30%. Furthermore, the immutability of ROM code provides tamper resistance, effectively mitigating malicious code attacks in security-sensitive scenarios (such as financial IC cards and medical devices) and meeting industry compliance requirements. Despite ROM's advantages in cost and reliability, its immutability remains a bottleneck restricting system upgrades.

[0004] Chinese invention patent CN 101799763B discloses a method for online kernel patching. This solution involves setting a breakpoint at the beginning of the original function's execution during kernel runtime. When a thread reaches this breakpoint, a breakpoint exception is generated, and the return address of the breakpoint is modified to the target address of the patched function, thus making the patched function effective. However, this solution relies on the operating system, and indirect calls require rewriting upper-level functions, significantly impacting system operation. Summary of the Invention

[0005] The primary technical problem to be solved by this invention is to provide a ROM patching method based on Flash and hardware interrupts.

[0006] Another technical problem to be solved by the present invention is to provide a ROM patching system based on Flash and hardware interrupts.

[0007] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution:

[0008] According to a first aspect of the present invention, a ROM patching method based on Flash and hardware interrupts is provided, comprising the following steps:

[0009] S1: Develop corresponding patch programs according to requirements, set the PC value for triggering the patch function and the return address after the patch program ends;

[0010] S2: Write the patch and configuration parameters to Flash;

[0011] S3: The CPU reads the configuration parameters and writes them into the digital module register;

[0012] S4: The CPU configures the enable bit of the digital module register and starts the digital module;

[0013] S5: The digital module monitors the current PC value in real time through the monitoring bus and determines whether the current PC value is equal to the PC value triggered by the patch function; if they are not equal, monitoring continues; if they are equal, proceed to step S6.

[0014] S6: The digital module generates an interrupt signal;

[0015] S7: The CPU enters the interrupt service routine based on the interrupt signal and checks whether the digital module register indicates that a patch has been triggered. If no patch has been triggered, the interrupt service routine is exited and the ROM code is returned to continue execution. If a patch has been triggered, the process proceeds to step S8.

[0016] S8: Locate the address of the patch program that triggers the current patch and start executing the patch program;

[0017] S9: The patch program has finished executing. The patch program needs to jump to the end of the problematic code. The patch function is complete, and the ROM program resumes normal execution.

[0018] Preferably, if a new patch trigger address is triggered during the execution of the patch program, the digital module remains operational and generates an interrupt, nesting steps S7 to S9.

[0019] Preferably, the interrupt service routine achieves the jump by modifying the interrupt stack return address.

[0020] Preferably, in the patch program, the PC value triggered by the patch function is the PC value of the starting address of the problematic code; the return address after the patch program ends refers to the PC value of the ending address of the problematic code.

[0021] Preferably, the digital module includes: a patch total status register, a patch individual status register, a patch enable register, and a patch trigger address register, used to manage the patch trigger status and monitoring range;

[0022] The external master control device configures a patch enable register to enable monitoring of specific patches; the patch trigger address register stores the PC value that needs to be matched; when the digital module detects that the CPU's PC value matches a certain enabled patch trigger address, the corresponding bit will be set in the patch's respective status register, and may also set the patch overall status register.

[0023] Preferably, the digital module supports the configuration of multiple patch trigger addresses, and an interrupt will be generated when any address is triggered, and nested execution of patch programs is supported.

[0024] Preferably, each bit in the status register of each patch corresponds one-to-one with the jump target of each trigger address in the patch trigger address register.

[0025] Preferably, the configuration parameters in step S2 also include interrupt enable configuration, which is used to control whether the digital module generates an interrupt when the address is matched.

[0026] Preferably, in step S7, the interrupt service routine determines the triggered patch number by reading the patch total status register and the patch individual status register.

[0027] According to a second aspect of the present invention, a ROM patching system based on Flash and hardware interrupts is provided, comprising a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, which, when executed by the processor, causes the processor to implement the above-described method.

[0028] Compared with existing technologies, this invention breaks through the dependence of traditional software patching methods on function call methods by combining hardware monitoring with interrupt hijacking through an innovative architecture. It provides an efficient, universal and scalable dynamic upgrade solution for embedded systems, which is especially suitable for cost-sensitive scenarios that require long-term maintenance. Attached Figure Description

[0029] Figure 1 This is a flowchart of a ROM patching method based on Flash and hardware interrupts in the first embodiment of the present invention;

[0030] Figure 2 This is a schematic diagram of the structure of the digital module in the first embodiment of the present invention;

[0031] Figure 3 This is a schematic diagram of the structure of a ROM patching system based on Flash and hardware interrupts in the second embodiment of the present invention. Detailed Implementation

[0032] The technical content of the present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0033] First Embodiment

[0034] like Figure 1 As shown, the first embodiment of the present invention provides a ROM patching method based on Flash and hardware interrupts, which includes at least the following steps:

[0035] S1: Develop corresponding patch programs according to requirements, set the PC value (Program CounterValue) for triggering the patch function and the return address after the patch program ends.

[0036] S2: Write the patch and configuration parameters to Flash.

[0037] S3: The CPU reads the configuration parameters and writes them into the digital module register.

[0038] S4: The CPU configures the enable bit of the digital module register and starts the digital module.

[0039] S5: The digital module monitors the current PC value in real time through the monitoring bus and determines whether the current PC value is equal to the PC value triggered by the patch function; if they are not equal, monitoring continues; if they are equal, proceed to step S6.

[0040] S6: The digital module generates an interrupt signal.

[0041] S7: The CPU enters the interrupt service routine based on the interrupt signal and checks whether the digital module register indicates that a patch has been triggered. If no patch has been triggered, the interrupt service routine is exited and the ROM code is returned to continue execution. If a patch has been triggered, the process proceeds to step S8.

[0042] It's important to note that when an interrupt service routine detects a patch trigger, it doesn't resume execution from the interrupted program counter (PC) location. Instead, it modifies the interrupt stack return address to achieve a jump. Taking a Cortex CPU as an example: after the CPU finishes executing the interrupt service routine, it returns to the address of the interrupting PC. This interrupting PC address is stored on the hardware stack when the interrupt is triggered. Therefore, this invention modifies the value of the interrupting PC address stored on the hardware stack, causing the interrupt service routine return instruction to return to the modified address. This modified value is the address of the patch stored in Flash.

[0043] S8: Locate the address of the patch program that triggers the current patch and start executing the patch program.

[0044] S9: The patch program has finished executing. The patch program needs to jump to the end of the problematic code. The patch function is complete, and the ROM program resumes normal execution.

[0045] Preferably, the patch program can perform nested operations, that is, if a new patch trigger address is triggered during the execution of the patch program, the digital module remains in working state and generates an interrupt, and nested execution steps S7 to S9 are performed.

[0046] In one embodiment of the present invention, the PC value triggered by the patch function in step S1 is the PC value of the starting address of the problematic code; the return address after the patch ends refers to the PC value of the ending address of the problematic code. The return address after the patch ends is stored and recorded by the patch itself.

[0047] The PC value (Program Counter Value) refers to the program counter value, which is the value stored in the CPU's critical internal register—the program counter—and is used to indicate the memory address of the instruction that the processor is currently executing or is about to execute.

[0048] During CPU instruction execution, the PC value is automatically updated, and the specific update method depends on the instruction execution mode:

[0049] Sequential execution: When the CPU executes instructions sequentially, the PC value is updated according to the rule "PC = PC + instruction length". Taking ARMThumb mode as an example, if the instruction length is 2 bytes, the PC value will increase by 2 bytes.

[0050] Jump execution: When a function call, interrupt response, or other situation occurs that requires a jump execution instruction, the PC value will be directly updated to the target address.

[0051] In this invention, the PC value is the core criterion for triggering the patch, specifically in two aspects:

[0052] Patch trigger point: When the PC value reaches the preset problem code start address, such as 0x4000, the digital module will trigger an interrupt (refer to steps S5 to S6).

[0053] Execution flow control: After the patch is executed, in order to resume ROM execution, the PC value needs to jump to the end address of the problematic code, such as 0x4022 (refer to step S9).

[0054] In this invention, such as Figure 2 As shown, the digital module includes: a patch overall status register, patch individual status registers, patch enable registers, and patch trigger address registers, which are used to manage patch trigger status and monitoring scope.

[0055] The external master control device configures a patch enable register to enable monitoring of specific patches. The patch trigger address register stores the PC value that needs to be matched. When the digital module detects that the CPU's PC value matches a certain enabled patch trigger address, the corresponding bit is set in the patch's respective status register, and may also set the overall patch status register.

[0056] The overall patch status register indicates whether a patch process has been triggered using one bit (1 indicates triggered, 0 indicates not triggered); the individual patch status registers 1 to X are used for one bit corresponding to each trigger address to mark the patch status; each bit of the patch enable registers 1 to X controls whether the corresponding patch trigger address register is monitored (1 indicates enabled monitoring, 0 indicates disabled); the patch trigger address registers 1 to N are used to store the addresses of the code to be replaced in the ROM.

[0057] Each bit in the status register of each patch corresponds one-to-one with the jump target of each trigger address in the patch trigger address register 1 to N. When the bit is 1, it means that the corresponding register has triggered the patch process.

[0058] In one embodiment of the present invention, the configuration parameters in step S2 refer to the configuration values ​​of the digital module registers and the management parameters of the patch program. Specifically, the configuration values ​​of the digital module registers refer to the PC value and interrupt enable for triggering the patch function; the management parameters of the patch program refer to the mapping between the patch sequence number defined in the digital module and the patch program.

[0059] The patch is distributed as a `const` array, which specifies a particular Flash address. Integrating this array into the application code during compilation generates the latest patch-supporting program; alternatively, the specific Flash address can be erased using a chip-supported programming device (or boot programming interface), and the array can then be programmed into it.

[0060] After being written to Flash, the patch's configuration parameters and program are stored in Flash and will not be lost after power failure. However, the digital module registers are lost after the chip loses power, so they need to be read from the patch's configuration parameters and reconfigured every time the chip is powered on.

[0061] In one embodiment of the present invention, the digital module in step S5 has an independent IP core, its bus interface type is AHB bus, and its register bit width is 32 bits.

[0062] It's important to note that when the digital module checks for PC matching by monitoring the bus, a special case exists. For example, in Cortex CPUs with a pipeline concept, the CPU prefetches instructions from the bus, but if it's still executing previously prefetched instructions and hasn't actually reached the PC yet, triggering a patch interrupt in this situation is incorrect. The correct approach is for the CPU to prefetch the pipeline, and when the digital module detects a PC match, it triggers an interrupt when the CPU fetches the next instruction. This is accurate. This places requirements on the selection of the trigger address. First, the address must be 4-byte aligned, as CPU buses are typically 32-bit. For a 64-bit bus, 8-byte alignment is required. Second, there cannot be any jump instructions within the four bytes preceding the selected trigger address. If jump instructions are present, the pipeline will be flushed, and a patch interrupt should not be triggered in this case. Since the digital module doesn't monitor the CPU core, it cannot know if jump instructions are present. Therefore, operators need to pay attention to this when selecting the trigger address.

[0063] The above method will be explained in detail below:

[0064] First, patch development and critical address localization are performed. Patch development is the foundation for dynamic ROM code upgrades and requires systematic design to address functional defects or scenario-specific requirements of the ROM program in the embedded system. Developers first use disassemblers to analyze the binary image of the ROM program, generating an assembly-level code view. Combined with the single-step tracing and breakpoint setting functions of a simulator debugger, they accurately locate the start and end addresses of the code segment causing the fault. This process requires comprehensive consideration of processor architecture characteristics. For example, in the ARM Cortex-M series, the program counter (PC) always points to the address of the instruction following the currently executed instruction, and Thumb instructions are in 2-byte units. Therefore, when an instruction address is located at 0x4000, its starting PC value is 0x4000. If the end address is 0x4020 (the address of the last instruction), then the end PC value needs to be calculated as 0x4022 (pointing to the next instruction).

[0065] After determining the address, the initial PC value needs to be used as the critical threshold for patch triggering and written into the trigger register group of the digital module through a dedicated configuration process. This register group is typically designed as a multi-channel structure, supporting the simultaneous storage of trigger addresses and corresponding sequence numbers for multiple patches. For example, in a system supporting 8 patches, 8 groups of 32-bit registers can be configured, with the high 24 bits of each group storing the trigger address and the low 8 bits identifying the patch sequence number for quick identification during subsequent interrupt responses. The end PC value serves as critical metadata for the patch program and needs to be embedded in the program header or a specific data segment through the linker script during the patch program development phase to ensure that the program can accurately jump back to the end position of the original ROM code after execution.

[0066] Patches are not limited to bug fixing; they can also dynamically adjust system strategies, such as modifying peripheral control logic, optimizing communication protocol stacks, or adding sensor driver algorithms. Their software architecture must adhere to modular design principles, including an address resolution module (reading the pre-stored end address), a function execution module (implementing specific logic replacement), and a return control module (completing process transitions via hardware jump instructions). During development, it is crucial to ensure complete compatibility between the toolchain and the ROM program, including instruction set architecture, memory mapping rules, and compilation optimization levels, to avoid patch execution errors due to environmental differences.

[0067] Secondly, the patch program and configuration parameters are written to the Flash memory. Flash media can be divided into two categories: internal and external. Internal Flash is directly accessed through the chip's internal bus and has high-speed read and write characteristics, making it suitable for rapid updates of small-capacity patches. External Flash (such as the W25Q series with QSPI interface) supports larger storage capacity and can be expanded through a serial interface, making it suitable for scenarios that require storing multiple sets of patches.

[0068] The configuration parameters consist of two core parts: first, the register configuration values ​​of the digital module, including the trigger address and interrupt enable flag for each patch, which must be organized into a continuous binary data stream according to the register address order; second, the patch management parameters, which define the mapping relationship between patch numbers and Flash storage addresses, usually stored in a specific sector of the Flash (such as the boot sector) in the form of an index table for easy lookup and updates. Write operations must strictly follow the physical operation timing of the Flash. For example, for NOR Flash, sector erasure (usually in 4KB units) must be performed first, followed by page programming commands to write data page by page. After each write operation, the status register must be waited for the operation to complete (the BUSY bit is cleared) to avoid incomplete data writing.

[0069] The patch trigger address is a 4-byte aligned address; 2-byte aligned address triggering is not supported. In other words, when extracting the starting address of the problematic code, a 4-byte aligned address must be selected as the trigger address. If 2-byte aligned address triggering is required, a digital module needs to monitor the CPU core, which places high demands on chip design capabilities.

[0070] Bits 0 and 1 of the trigger address register are always 0 and cannot be rewritten. Their purpose is to prevent writing to non-4-byte aligned addresses.

[0071] To address the risks of complex electromagnetic environments and power fluctuations, the system needs to integrate power monitoring and data verification mechanisms: write operations are only permitted when the power supply voltage stabilizes within the rated range (e.g., 3.3V ± 5%). Simultaneously, verification algorithms such as CRC32 are used to perform real-time verification of the written data. If verification fails, a retry mechanism is automatically triggered (usually limited to 3 times). If the retry still fails, a fault log is recorded and the system enters safe mode to prevent system crashes caused by erroneous patches. Furthermore, because the digital module's registers are based on volatile memory, data is lost after power failure. Therefore, configuration parameters must be reread from Flash memory each time power is restored to ensure the correctness and consistency of the patch triggering logic.

[0072] Next, the CPU reads the configuration parameters and initializes the digital module. The process of the CPU reading configuration parameters from Flash and initializing the digital module via the system bus is a crucial step in the hardware-software collaboration. First, the CPU locates the configuration data storage area based on the preset address offset in the boot code (e.g., Flash base address + 0x1000), and reads the index table and register configuration data in one burst transfer mode, storing it in a designated buffer in the internal static random access memory (SRAM). Subsequently, the system parses the index table, establishing a mapping between patch numbers and Flash storage addresses, typically managed using an array or linked list structure for quick lookup during subsequent interrupt responses.

[0073] During the register initialization phase, the CPU needs to write parameters such as the trigger address and interrupt enable bit into the corresponding registers according to the register address mapping relationship of the digital module. For example, for the first patch, its trigger address is 0x4000, and the interrupt enable bit is set to enable triggering. The CPU writes the corresponding configuration value to the specific register address of the digital module through bus transactions. This process must follow the bus timing specifications (such as the write cycle of the APB bus being two clock cycles) and register access permissions (such as some registers only supporting word-aligned writes).

[0074] Interrupt system initialization is another core part of this step: the CPU needs to map the interrupt requests from the digital modules to the interrupt controller and assign them appropriate priorities (usually higher than ordinary peripheral interrupts and lower than hard-core error interrupts; if the ROM program also has an interrupt service routine, and if the routine needs to be patched, the interrupt priority configuration of the patch must be able to preempt the interrupt service routine in the ROM). Simultaneously, the CPU registers the entry address of the interrupt service routine in the interrupt vector table. In multi-patch scenarios, the CPU can configure the trigger parameters of each patch sequentially through a loop, ensuring that the trigger address, interrupt enable state, and priority settings of each patch are accurate. Furthermore, by disabling global interrupts or using a bus locking mechanism, the atomicity of the configuration process is guaranteed, avoiding configuration data corruption caused by interrupt nesting. Alternatively, the CPU can share a single interrupt signal and use the same interrupt service routine, with the software mapping the corresponding patch routine within the interrupt service routine; this also enables patch nesting.

[0075] Next, the digital module is activated and real-time monitoring is performed. As the hardware core for patch triggering, the digital module's design must balance detection accuracy, response speed, and power consumption control. The digital module has the function of monitoring the PC value and comparing it with various trigger address registers.

[0076] To avoid false triggering due to circuit noise or transient interference, the digital module integrates multiple anti-interference designs: the PC value needs to be synchronized through multiple levels of registers to eliminate metastability risks; the trigger signal needs to pass through a delay filtering circuit (e.g., valid for 5 consecutive clock cycles before triggering is confirmed); and it also supports address mask configuration (only comparing the valid high-order bits of the address, ignoring low-order bit fluctuations). When the interrupt encoding logic detects a valid trigger, it generates the corresponding patch sequence number through the priority encoder and sends an interrupt request signal to the CPU. After the interrupt controller determines the priority, it triggers the CPU response at an appropriate time.

[0077] The power management mechanism of the digital module enables it to dynamically adjust energy consumption in different working states: when no patch is enabled, the clock signal of the comparator array is turned off through clock gating technology, and the power consumption is reduced to the microampere level; in the active state, a pipeline architecture is adopted to accelerate the comparison process, ensuring that a full-channel comparison is completed in each clock cycle, the response latency is controlled at the nanosecond level, and it does not occupy the CPU's computing resources, realizing "zero-awareness" monitoring of the ROM program execution flow.

[0078] Next, once the digital module detects that the PC value matches the trigger address of a patch and passes the validity verification, it immediately sends an interrupt request to the CPU through the interrupt controller. After the current instruction is completed, the CPU responds to the interrupt, automatically performs context protection (such as pushing the program status word, program counter, link register, and general-purpose registers onto the stack), and jumps to the interrupt service routine entry point.

[0079] The interrupt service routine first reads the status register of the digital module to obtain the triggered patch number. If the number is invalid (e.g., 0 or outside the preset range), it exits directly; otherwise, it enters the patch processing flow. To ensure the atomicity of interrupt handling, the interrupt service routine typically disables global interrupts first to avoid nested interrupts interfering with the current operation. During the context protection phase, in addition to the registers automatically pushed onto the stack by the hardware, the interrupt service routine also needs to manually save non-volatile registers (such as floating-point registers and coprocessor state) to ensure that the system state is consistent before and after the patch execution.

[0080] Next, in the interrupt service routine, the system looks up the address of the corresponding patch by the patch sequence number. This process relies on a pre-established patch index table. The index table typically uses a linear storage structure or a hash table structure: linear storage is suitable for scenarios where the number of patches is fixed and the sequence numbers are consecutive, and the address offset can be directly calculated from the sequence number; hash tables are suitable for scenarios where patches are dynamically loaded, and the patch address can be quickly located using a hash function, reducing lookup time.

[0081] After locating the patch's address, the system needs to force the program flow to jump to the patch by modifying the interrupt return address. The specific implementation principle is as follows: In the processor's interrupt stack mechanism, the return address stored in the stack determines the execution path after the interrupt return. By replacing this address with the patch's entry address, the CPU can directly jump to the patch for execution upon interrupt return. This process relies on the processor's low-level register manipulation capabilities to ensure the atomicity and accuracy of the address replacement, avoiding stack structure corruption or program crashes due to improper operation.

[0082] After the jump is complete, the patch runs in the CPU's user mode or thread mode, inheriting the current task's context (such as memory management unit configuration and peripheral access permissions), without requiring additional context switching overhead. To ensure the patch's execution efficiency, its code typically uses the same optimization level as the ROM program and avoids programming structures that may lead to uncontrollable timing, such as dynamic memory allocation and recursive functions.

[0083] Next, the patch execution must strictly adhere to timing constraints and resource management rules to ensure that the function replacement is completed and the program returns correctly within a limited time. After the program starts, it first reads the end address of the original ROM code from the pre-stored area (i.e., the return address after patch execution) and initializes necessary local variables and peripheral configurations. The function execution module implements logic replacement according to specific requirements, such as fixing algorithm vulnerabilities, adjusting control parameters, or adding a communication protocol parsing branch. Its code must undergo rigorous testing and verification to ensure logical correctness and complete boundary condition coverage.

[0084] The core of the return logic is to accurately jump the program execution flow to the end address of the original ROM code. This process is implemented through the processor's jump instructions, such as the "jump to register specified address" instruction (e.g., ARM's BX instruction, RISC-V's jr instruction). To ensure the validity of the jump address, the system needs to pre-verify whether the address is within the valid range of the ROM code segment and is greater than the starting address of the patch trigger, to avoid the program getting stuck in an invalid memory area due to address errors.

[0085] During the patch's execution, the system monitors its running status in real time, for example, by using a hardware timer to limit the execution time and prevent the system from hanging due to program infinite loops. After execution, the patch returns to the original ROM code via a jump instruction, at which point the CPU continues to execute subsequent instructions from that address. The entire process must ensure that register values, memory data, and peripheral states are consistent with the patch design expectations, achieving a seamless upgrade of the ROM program.

[0086] Finally, after the patch returns to the original ROM code, the system enters the recovery phase, which requires operations such as status verification, resource reclamation, and module reset. First, the system verifies the values ​​of key registers, memory data checksums, and peripheral status to ensure that the patch execution has not caused any unexpected impact on the system. If an anomaly is found, a rollback mechanism is triggered (such as loading a backup patch or restoring factory settings).

[0087] During this phase, the digital module performs self-calibration and reset operations: clearing all interrupt flags, resetting the comparator array to its initial state, turning off the module clock to reduce power consumption, and releasing register resources occupied by patch execution. In multi-patch scenarios, the system uses the write protection mechanism of the Flash storage medium (such as setting sector protection bits) to prevent the patch program from being accidentally modified, and at the same time uses the Least Recently Used (LRU) algorithm to manage Flash space, automatically cleaning up long-unused patches to release storage resources.

[0088] To enhance system security, during the recovery phase, hardware encryption modules (such as an AES encryption engine) can be enabled to perform integrity verification on the patch program, ensuring it has not been maliciously tampered with. Furthermore, the system updates the interrupt vector table and patch index table to prepare for the next possible patch trigger, ultimately entering normal operation and achieving dynamic upgrades and continuous stable operation of the ROM program.

[0089] Second Embodiment

[0090] Based on the above method, the second embodiment of the present invention provides a ROM patching system based on Flash and hardware interrupts. For example... Figure 3As shown, the ROM patching system includes one or more processors and a memory. The memory stores one or more programs, which, when executed by the one or more processors, are used to implement the ROM patching method in the above embodiments.

[0091] The processor controls the overall operation of the ROM patching system to complete all or part of the steps described above. The processor can be a central processing unit (CPU), graphics processing unit (GPU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), digital signal processing (DSP) chip, etc. The memory stores various types of data to support the operation of the ROM patching system. This data may include, for example, instructions for any application or method operating on the ROM patching system, as well as application-related data. The memory can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, etc.

[0092] In one exemplary embodiment, the ROM patching system may be implemented by a computer chip or entity, or by a product with certain functions, to perform the above-described methods and achieve the same technical effects as described above. A typical embodiment is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interface device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0093] In another exemplary embodiment, the present invention also provides a computer-readable storage medium including program instructions that, when executed by a processor, implement the steps of the method in any of the above embodiments. For example, the computer-readable storage medium may be the memory including the program instructions described above, which can be executed by a processor to complete the above method and achieve the same technical effects as the above method.

[0094] It should be noted that the above embodiments are merely illustrative examples, and the technical solutions of each embodiment can be combined, all of which are within the protection scope of this invention.

[0095] The ROM patching method and system based on Flash and hardware interrupts provided by this invention have been described in detail above. Any obvious modifications made by those skilled in the art without departing from the essence of this invention will constitute an infringement of the patent rights of this invention and will incur corresponding legal liability.

Claims

1. A ROM patching method based on Flash and hardware interrupts, characterized in that... Includes the following steps: S1: Develop corresponding patch programs according to requirements, set the PC value for triggering the patch function and the return address after the patch program ends; S2: Write the patch and configuration parameters to Flash; S3: The CPU reads the configuration parameters and writes them into the digital module register; S4: The CPU configures the enable bit of the digital module register and starts the digital module; The digital module includes: a total patch status register, individual patch status registers, a patch enable register, and a patch trigger address register, used to manage patch trigger status and monitoring range; wherein, the external master control device configures the patch enable register to enable monitoring of specific patches; the patch trigger address register stores the PC value that needs to be matched; when the digital module detects that the CPU's PC value matches a certain enabled patch trigger address, the corresponding bit in the individual patch status register will be set, and the total patch status register will be set at the same time; S5: The digital module monitors the current PC value in real time through the monitoring bus and determines whether the current PC value is equal to the PC value triggered by the patch function; if they are not equal, monitoring continues; if they are equal, proceed to step S6. S6: The digital module generates an interrupt signal; S7: The CPU enters the interrupt service routine based on the interrupt signal and checks whether the digital module register indicates that a patch has been triggered. If no patch has been triggered, the interrupt service routine is exited and the ROM code is returned to continue execution. If a patch has been triggered, the process proceeds to step S8. S8: The interrupt service routine finds the address of the patch program corresponding to the current patch trigger, and modifies the return address that is automatically saved by the hardware in the interrupt stack to the address of the patch program; S9: Execute the interrupt return instruction of the interrupt service routine, causing the CPU to start executing the patch program outside the interrupt context based on the tampered return address; after the patch program finishes execution, the patch program jumps to the end of the problematic code, the patch function is completed, and the ROM program resumes normal execution.

2. The ROM patching method as described in claim 1, characterized in that... In the patch program, the PC value triggered by the patch function is the PC value of the starting address of the problematic code.

3. The ROM patching method as described in claim 1, characterized in that... The digital module supports the configuration of multiple patch trigger addresses. When any address is triggered, an interrupt will be generated, and nested execution of patch programs is supported.

4. The ROM patching method as described in claim 3, characterized in that... Each bit in the status register of each patch corresponds one-to-one with the jump target of each trigger address in the patch trigger address register.

5. The ROM patching method as described in claim 1, characterized in that... The configuration parameters mentioned in step S2 also include interrupt enable configuration, which is used to control whether the digital module generates an interrupt when the address is matched.

6. The ROM patching method as described in claim 1, characterized in that... In step S7, the interrupt service routine determines the triggered patch number by reading the overall patch status register and the individual status registers of each patch.

7. A ROM patching system based on Flash and hardware interrupts, characterized in that... It includes a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, which, when executed by the processor, causes the processor to implement the ROM patching method according to any one of claims 1 to 6.

Images