Jump control method and device, equipment and storage medium

Abstract

The invention discloses a jump control method, device and equipment and a storage medium, the method is applied to embedded equipment, the embedded equipment comprises a bootstrap program area and an application program area, and the method comprises the following steps: after the bootstrap program area executes starting, reading a plurality of groups of flag bits in a nonvolatile memory; based on the multiple groups of flag bits, determining a target jump decision according to a preset priority rule; if the target jump decision indicates to jump to the application program area, performing integrity verification on a target code of the application program area; and after the verification is passed, dynamically redirecting the base address of the interrupt vector table to the initial address of the application program area, and skipping to the application program area from the bootstrap program area for execution. According to the method and the device, the target jump decision is determined based on the multiple groups of flag bits, the integrity check is performed before the application program area is jumped, and the base address of the interrupt vector table is dynamically redirected to the initial address of the application program area, so that compared with the prior art, the reliability and the safety of the jump process are improved.

Description

Technical Field

[0001] This invention relates to the field of embedded systems, and more particularly to a jump control method, apparatus, device, and storage medium. Background Technology

[0002] Embedded systems are widely used in industrial control, smart terminals, and automotive electronics. Their software typically consists of two parts: a bootloader (IAP, In-Application Programming) and an application program (APP). The bootloader is responsible for initial system startup, firmware upgrades, and managing transitions to the application program. In-Application Programming (IAP) technology allows the firmware in the application area to be updated during system operation via a communication interface, greatly improving the flexibility and convenience of device maintenance.

[0003] Currently, traditional IAP jump control methods mostly employ a single flag trigger mechanism. For example, an upgrade flag is set at a fixed address in the Flash memory, and the jump path is determined by reading the status of this flag (such as "upgrade" or "normal") during system startup. However, this approach has several limitations in practical applications. First, a single flag is susceptible to bit flipping due to electromagnetic interference, Flash write / erase errors, etc., leading to misjudgments in the jump logic, such as "false upgrade" or "upgrade stall," severely impacting system reliability. Second, traditional solutions have deficiencies in interrupt handling. Most methods only configure the interrupt vector table base address during application initialization, without considering the nested interrupt transition requirements that may occur during the jump from the bootloader to the application. If there are unresponsive interrupt requests during the jump, it may lead to abnormal interrupt response or even system crash. Furthermore, existing solutions generally lack a robust code integrity verification mechanism. The target code is often not verified before the jump; if corrupted or incomplete firmware is loaded, it will directly cause the application to fail. It is evident that existing IAP jump methods have shortcomings in terms of flag decision reliability, interrupt transition smoothness, and code security, resulting in low reliability and security of the jump process.

[0004] Therefore, there is an urgent need for a jump control method that can improve the reliability and safety of the jump process. Summary of the Invention

[0005] The main objective of this invention is to provide a jump control method, apparatus, device, and storage medium, which aims to solve the technical problem of low reliability and security in the jump process in the prior art.

[0006] To achieve the above objectives, the present invention provides a jump control method, which is applied to an embedded device. The embedded device includes a bootloader area and an application program area. The method includes the following steps: After the bootloader area is started, multiple sets of flag bits are read from the non-volatile memory. These multiple sets of flag bits include upgrade flag, version flag, verification flag, and exception flag. Based on the multiple sets of flag bits, a target jump decision is determined according to a preset priority rule; If the target jump decision indicates a jump to the application area, then the target code in the application area is subjected to integrity verification. After the verification is successful, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution is switched from the bootloader area to the application area.

[0007] Optionally, the step of determining the target jump decision based on the multiple sets of flag bits according to a preset priority rule includes: Determine whether the anomaly flag indicates the existence of a historical jump anomaly; If the anomaly flag indicates the existence of a historical jump anomaly, then the target jump decision is determined to trigger the anomaly recovery process; If the anomaly flag does not indicate the existence of a historical jump anomaly, then it is determined whether the upgrade flag indicates the existence of an upgrade request, and based on the determination result, the target jump decision is to perform an upgrade operation or jump to the application area.

[0008] Optionally, the step of determining whether the upgrade flag indicates an upgrade request, and determining the target redirection decision as either performing an upgrade operation or redirecting to the application area based on the determination result, includes: Determine whether the upgrade flag indicates an upgrade request, and obtain the determination result; If the determination result indicates that the upgrade flag indicates a mandatory upgrade request, then the target jump decision is determined to execute the upgrade operation; If the judgment result indicates that the upgrade flag indicates that there is a user upgrade request, then the current version information indicated by the version flag is read and compared with the target version. Based on the comparison result, the target jump decision is determined to perform the upgrade operation or jump to the application area. If the upgrade flag does not indicate that an upgrade request exists, the verification flag is read, and based on the verification flag, the target jump decision is determined to either jump to the application area or trigger an exception recovery process.

[0009] Optionally, before the step of performing integrity verification on the target code of the application area, the method further includes: Save the interrupt enable state in the current interrupt control register and disable global interrupts; Accordingly, after the step of dynamically redirecting the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jumping from the bootloader area to the application area for execution, the method further includes: Restore the interrupt enable state so that the enabled interrupt remains valid after the jump.

[0010] Optionally, before the step of jumping from the bootstrap area to the application area for execution, the method further includes: Obtain the current timeout configuration of the watchdog timer, and extend the timeout period of the watchdog timer to a preset multiple of the current timeout configuration; Accordingly, after the step of jumping from the bootloader area to the application area for execution, the method further includes: When initialization is performed by the application area, the timeout period of the watchdog timer is restored to the current timeout configuration.

[0011] Optionally, after the step of determining that the target jump decision is to trigger the exception recovery process if the exception flag indicates the existence of a historical jump exception, the method further includes: After jumping from the bootloader area to the application area for execution, monitor whether the application area writes a normal running flag within a preset time window; If the normal operation flag is not detected, a system reset is triggered to execute the program in the boot program area and read the historical version firmware from the preset backup firmware area; The historical firmware version is verified for integrity, and after the verification is passed, the historical firmware version is written to the application area. Update the verification flag to indicate that the historical firmware version is valid, and perform a jump to the application area.

[0012] Optionally, the method further includes: Jump audit information is recorded in the log storage area of ​​the non-volatile memory. The jump audit information includes the trigger source identifier, source version identifier, target version identifier, and execution result identifier. Detect the remaining storage space in the log storage area; If the remaining storage space is less than the preset storage threshold, the new jump audit information is written to the earliest recorded storage location in the log storage area using a cyclic overwrite method.

[0013] Furthermore, to achieve the above objectives, the present invention also proposes a jump control method apparatus, which is applied to an embedded device, the embedded device including a boot program area and an application program area, the apparatus comprising: The flag reading module is used to read multiple sets of flag bits in the non-volatile memory after the bootloader area is started. The multiple sets of flag bits include upgrade flag, version flag, verification flag and exception flag. The decision determination module is used to determine the target jump decision based on the multiple sets of flag bits and according to a preset priority rule; The code verification module is used to perform integrity verification on the target code in the application area if the target jump decision indicates a jump to the application area; The jump execution module is used to dynamically redirect the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jump from the bootloader area to the application area for execution.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a jump control method apparatus, the apparatus comprising: a memory, a processor, and a jump control method program stored in the memory and executable on the processor, the jump control method program being configured to implement the steps of the jump control method as described above.

[0015] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a jump control method program, which, when executed by a processor, implements the steps of the jump control method as described above.

[0016] This invention discloses a method for reading multiple sets of flag bits from non-volatile memory after startup in the bootloader area. These flag bits include an upgrade flag, a version flag, a verification flag, and an exception flag. Based on these flag bits, a target jump decision is determined according to a preset priority rule. If the target jump decision indicates a jump to the application area, the target code in the application area undergoes integrity verification. After successful verification, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution jumps from the bootloader area to the application area. Because this invention reads multiple sets of flag bits from non-volatile memory after startup in the bootloader area, determines the target jump decision based on these flag bits, performs integrity verification before jumping to the application area, and dynamically redirects the base address of the interrupt vector table to the starting address of the application area, compared to existing technologies, this invention improves the reliability and security of the jump process. Attached Figure Description

[0017] Figure 1This is a flowchart illustrating the first embodiment of the jump control method of the present invention; Figure 2 This is a flowchart illustrating the second embodiment of the jump control method of the present invention; Figure 3 This is a flowchart illustrating the third embodiment of the jump control method of the present invention; Figure 4 This is a structural block diagram of the first embodiment of the jump control method and apparatus of the present invention; Figure 5 This is a schematic diagram of the device for the jump control method of the hardware operating environment involved in the embodiments of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] This invention provides a jump control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the jump control method of the present invention.

[0021] In this embodiment, the jump control method is applied to an embedded device, which includes a bootloader area and an application program area. The method includes steps S10 to S40: Step S10: After the bootloader area is started, multiple sets of flag bits in the non-volatile memory are read. The multiple sets of flag bits include upgrade flag, version flag, verification flag and exception flag.

[0022] It should be noted that the execution subject of this embodiment can be an embedded device with data processing, network communication, and program execution functions applied in a program jump control scenario, or an electronic device capable of implementing the above functions (such as a jump control method device). The following uses an embedded system (hereinafter referred to as the system) containing a jump control method device as an example to illustrate this embodiment and the following embodiments.

[0023] Understandably, the bootloader area refers to a dedicated storage region within the non-volatile memory of an embedded device used to store the bootloader (often called IAP, or In-Application Programming). This region is typically located at the beginning of the memory address (e.g., 0x08000000). After the device powers on or resets, the central processing unit (CPU) first fetches instructions from this region and executes them. The program in the bootloader area is responsible for performing system initialization, reading flag bits for decision-making, verifying the code in the application program area, and controlling the jump from the bootloader to the application program.

[0024] It should be understood that non-volatile memory refers to storage media in an embedded system that retains stored data even after power failure, such as flash memory. In this implementation, the non-volatile memory is used not only to store the bootloader and application code, but also has a separate area for storing multiple sets of flags, backup firmware, and audit log information. This data is retained after the system loses power and can be read and used during the next power-on startup.

[0025] It should be explained that multiple sets of flag bits refer to a set of independent status indication data stored in a specific address area (such as the flag bit area) in non-volatile memory. Each set of flag bits can be composed of a binary value of a preset length (such as 32 bits) and is used to characterize a specific state of the system or program. These flag bits can be written or modified by the bootloader or application program according to actual events (such as receiving an upgrade instruction or detecting an anomaly) during program execution, and are read by the bootloader when the system starts up as the basis for jump decisions.

[0026] It should be noted that the upgrade flag (app_updata_flag) can be a status flag indicating whether a firmware upgrade is needed. When the application receives an upgrade command, it writes this flag to a specific preset value (such as 0x5A5A5A5A), indicating that an upgrade process needs to be executed after the next reset; if no upgrade is needed, it retains the initial value (such as 0x00000000). This flag is used to distinguish between two different transition scenarios: "normal startup" and "upgrade startup".

[0027] The version flag (version_flag) can be a status flag used to store the current application version number. This flag typically represents the version number in encoded form (such as major version number, minor version number), and is updated to the new target version number during firmware upgrades. By reading this flag, the bootloader can determine the application's version status (e.g., 0x00010000 for V1.0) and use this information to decide whether to perform a version upgrade or a version compatibility check.

[0028] The verification flag (app_effect_flag) can be a status flag indicating whether the application code is valid (e.g., 0x5555AAAA indicates valid application code, 0xAAAA5555 indicates abnormal application code). This flag is typically written to a preset verification reference value (e.g., a characteristic value calculated based on a cyclic redundancy check algorithm) by the bootloader or application after firmware flashing or upgrading. Before each jump, the bootloader recalculates the verification value in the application area and compares it with the preset verification reference value stored in this verification flag to verify the integrity of the application.

[0029] An error flag (error_flag) can be a status flag used to record whether an exception occurred during the last run or jump. When an application runs abnormally (such as failing to respond to the watchdog or write the normal running flag within a specified time) or a jump fails, the system sets this flag to a specific exception value (e.g., 0xEE00EE00 indicates a jump exception, and 0x00EE00EE indicates a runtime exception). The bootloader first checks this flag during startup; if an exception record is found, it will prioritize triggering the exception recovery process instead of executing the normal startup or upgrade process.

[0030] Step S20: Based on the multiple sets of flag bits, determine the target jump decision according to the preset priority rules.

[0031] It should be understood that the preset priority rule refers to a set of decision-making logic sequences that the system pre-sets in order to make a unique and correct judgment in complex and potentially conflicting combinations of flag bits after reading multiple sets of flag bits (upgrade flag, version flag, verification flag, and exception flag). When multiple flag bits simultaneously indicate different or contradictory system needs (for example, there is both an upgrade request and a recorded historical exception), the system prioritizes responding to the highest-level need according to the preset urgency or importance.

[0032] Understandably, target jump decision can refer to the specific subsequent execution action or path determined by the system after comprehensively analyzing multiple sets of flag bits based on the aforementioned preset priority rules.

[0033] It should be noted that after the IAP program starts (i.e., after the bootloader area starts executing), it reads four sets of flags sequentially, according to a preset priority rule: if error_flag is 0xEE00EE00, the exception recovery process is triggered directly; if app_updata_flag is 0x5A5A5A5A and it is a forced upgrade instruction, the upgrade process is executed; if it is a user upgrade request, it determines whether it is a new version based on version_flag and then executes the corresponding logic; if all flags are normal, it reads app_effect_flag to confirm that the target code in the application area is valid, and then jumps from the bootloader area to the application area.

[0034] In its specific implementation, step S20 includes: steps S201~S203: Step S201: Determine whether the anomaly flag indicates the existence of a historical jump anomaly.

[0035] Understandably, a history jump exception refers to an abnormal state in which the target application failed to run properly after the system last jumped from the Introducing Access Point (IAP) to the Application Area (APP). A history jump exception is when the previous jump attempt failed (e.g., the APP crashed, froze, or failed to initialize), and this failure record is saved (stored in an exception flag) so that the system can identify and take remedial measures on the next startup.

[0036] Step S202: If the anomaly flag indicates the existence of a historical jump anomaly, then the target jump decision is determined to trigger the anomaly recovery process.

[0037] It should be noted that when a historical jump anomaly is detected, the system will no longer attempt to start or upgrade normally, but will automatically enter a set of preset fault-tolerant handling procedures to ensure system availability, namely the anomaly recovery process.

[0038] Step S203: If the exception flag does not indicate the existence of a historical jump exception, determine whether the upgrade flag indicates the existence of an upgrade request, and determine the target jump decision as either performing an upgrade operation or jumping to the application area based on the determination result.

[0039] In a specific implementation, the step of determining whether the upgrade flag indicates an upgrade request and determining the target redirection decision as either performing an upgrade operation or redirecting to the application area based on the determination result includes: determining whether the upgrade flag indicates an upgrade request and obtaining a determination result; if the determination result indicates that the upgrade flag indicates a forced upgrade request, then determining the target redirection decision as performing an upgrade operation; if the determination result indicates that the upgrade flag indicates a user upgrade request, then reading the current version information indicated by the version flag and comparing it with the target version, and determining the target redirection decision as either performing an upgrade operation or redirecting to the application area based on the comparison result; if the upgrade flag does not indicate an upgrade request, then reading the verification flag and determining the target redirection decision as either redirecting to the application area or triggering an exception recovery process based on the verification flag.

[0040] It should be noted that upgrade requests include forced upgrade requests and user upgrade requests. Upgrade flags not only indicate whether an upgrade event exists, but also distinguish the trigger source and priority of the upgrade through their different preset values ​​or states.

[0041] It should be understood that a forced upgrade request can refer to an unskippable upgrade mode triggered by internal system security mechanisms or external high-priority instructions (such as production flashing or emergency security patches). Its characteristics include the highest priority, generally not limited by the current application version, and its purpose is to ensure that the system can be forcibly updated to a specified firmware to fix critical flaws or meet compliance requirements.

[0042] Correspondingly, a user upgrade request can refer to a regular upgrade mode triggered by an application during normal operation by receiving user commands or network queries. This requires consideration of version compatibility and user preferences, typically involving version number comparison. Upgrades are only performed if the target version is updated; otherwise, the request may be ignored to avoid unnecessary write operations.

[0043] It should be noted that when a user upgrade request is detected, the bootloader reads the current version information stored in the version flag and compares it with the target version information to be upgraded. If the comparison result shows that the target version number is higher than the current version number, it indicates that there is a valid version update, and the bootloader determines the target jump decision to perform the upgrade operation, that is, to prepare to receive the new firmware through the communication interface and write it to the application area. If the comparison result shows that the target version number is not higher than the current version number (e.g., the same or lower), it indicates that no version update is needed. In order to avoid unnecessary firmware erasure and system interruption, the bootloader will ignore the upgrade request and determine the target jump decision to jump directly to the application area.

[0044] It should be noted that when there are no upgrade requests, the system needs to determine whether the program in the current application area is available. At this time, the verification flag serves as the basis for assessing the integrity of the program. If the read verification flag value is consistent with the preset valid value (e.g., the expected value through CRC check), it indicates that the application area code is complete and valid. In this case, the bootloader determines the target jump decision to jump to the application area. If the read verification flag value is inconsistent with the preset valid value, it indicates that the application area code may be damaged due to tampering, write errors, or power outages. In this case, the bootloader considers the existing program unusable and determines the target jump decision to trigger the abnormal recovery process (e.g., attempt to restore firmware from the backup area or enter safe mode).

[0045] Step S30: If the target jump decision indicates a jump to the application area, then perform an integrity check on the target code in the application area.

[0046] It should be understood that in the actual operating environment of an embedded system, the target code stored in the application area may be corrupted due to various unexpected factors. For example, during firmware download, interference in the communication link (such as wireless signal fluctuations or unstable serial port levels) may cause data bit transmission errors; during firmware storage, long-term use of the Flash memory may cause bit flips, or power fluctuations may lead to incomplete erase / write operations. If the integrity verification step is omitted before the jump, the bootloader will directly execute the corrupted code. When the CPU attempts to extract the corrupted instructions, it may decode illegal opcodes, leading to hardware failures or program crashes, ultimately causing system crashes or unpredictable behavior. Therefore, performing integrity verification before the jump is to block the execution path of corrupted code at the source, ensuring that only code that has been verified to be completely consistent with the original firmware is eligible to gain control of the CPU, thereby improving the security of the jump process.

[0047] In a specific implementation, the step of performing integrity verification on the target code of the application area includes: executing a cyclic redundancy check algorithm on the target code of the application area to generate a first verification value; reading a preset verification reference value stored in the verification flag; comparing the first verification value with the preset verification reference value; if the two are consistent, the verification is determined to pass; if they are inconsistent, the verification is determined to fail.

[0048] Step S40: After the verification is successful, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution is performed from the bootloader area to the application area.

[0049] It should be explained that the base address of the dynamically redirected interrupt vector table refers to the value of the interrupt vector table offset register (SCB->VTOR) in the system control block that is actively and in real time modified by the bootstrap program (IAP area) during the jump from the bootstrap area (IAP area) to the application area (APP area), and is redirected to the starting address of the interrupt vector table in the application area.

[0050] It should be noted that in embedded systems, the interrupt vector table is a list storing the entry addresses of interrupt service routines. When the processor responds to an interrupt, it calculates the offset by adding the interrupt number to the base address indicated by the VTOR register, locates the corresponding interrupt service routine, and executes it. In this embodiment, before executing the jump, the value of VTOR is dynamically modified from pointing to the interrupt vector table in the bootloader area (address A) to pointing to the interrupt vector table in the application area (address B), thus switching the interrupt vector addressing target. By dynamically modifying VTOR to the starting address in the application area before the jump, it is ensured that the interrupt vector addressing mechanism matches the currently executing application code immediately after the jump is completed, thereby ensuring that all interrupts can be handled correctly and promptly by the application, achieving a smooth transition in interrupt handling.

[0051] In a specific implementation, the step of dynamically redirecting the base address of the interrupt vector table to the starting address of the application area includes: determining the physical base address of the starting address of the application area in memory; setting the interrupt vector table offset register in the system control block to the physical base address, so that subsequent interrupt requests can look up the corresponding interrupt service routine from the interrupt vector table of the application area.

[0052] To achieve seamless interrupt migration and improve system stability and reliability, before the step of performing integrity verification on the target code in the application area, the method further includes: saving the interrupt enable state in the current interrupt control register and disabling global interrupts.

[0053] Accordingly, after the step of dynamically redirecting the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jumping from the bootloader area to the application area for execution, the method further includes: restoring the interrupt enable state so that the enabled interrupt remains valid after the jump.

[0054] It's important to explain that the interrupt enable status in the interrupt control register refers to the registers in the NVIC (Nested Vectored Interrupt Controller) used to control the enable status of each interrupt channel, such as the ISER (Interrupt Set-Enable Register). These registers can include enable bits at the interrupt channel level (each bit in these registers corresponds to a specific interrupt source, such as UART receive interrupt, timer overflow interrupt, external pin interrupt, etc. If a bit is 1, it indicates that the interrupt source is enabled in the current system, meaning it can be responded to; if it is 0, it indicates that it is disabled).

[0055] It should be understood that disabling global interrupts during the jump process can prevent reentrancy conflicts and state inconsistencies. Disabling global interrupts is equivalent to establishing a temporary and safe execution environment, ensuring the integrity of the interrupt vector table switching process, and avoiding data corruption or logical chaos caused by asynchronous events.

[0056] It's important to note that by saving the interrupt enable state before the jump and restoring it afterward, this ensures that all interrupts enabled before the jump remain enabled in the application. This avoids the cumbersome process of reinitializing all interrupts due to interrupt configuration loss caused by jumps, a common problem in traditional solutions. It also prevents data loss due to interrupts not being re-enabled in a timely manner. Furthermore, it effectively avoids "Hardfault" or "system crashes" caused by conflicts between interrupt vector table switching and interrupt requests. This is crucial for fields with high reliability requirements, such as industrial control and automotive electronics, ensuring that the system does not crash during program upgrades.

[0057] It's worth noting that, because the interrupt enable state is saved before the jump, the system restores this state after successfully jumping to the app and executing its entry point code (usually in the earliest stages of the app's startup code). The purpose of this mechanism is that all interrupts enabled before the jump (such as running timers, serial port receive interrupts, etc.) can automatically regain their enable state after the jump without requiring reconfiguration by the app. Furthermore, any interrupts suspended during the jump will be immediately responded to and processed by the app after global interrupts are re-enabled, thus achieving a complete migration and smooth transition of the interrupt context.

[0058] To avoid accidental resets during the jump process and ensure the effectiveness of monitoring during the runtime phase, in the specific implementation, before the step of jumping from the bootstrap area to the application area, the method further includes: obtaining the current timeout configuration of the watchdog timer and extending the timeout period of the watchdog timer to a preset multiple of the current timeout configuration.

[0059] Accordingly, after the step of jumping from the bootstrap area to the application area, the method further includes: when the application area performs initialization, restoring the timeout of the watchdog timer to the current timeout configuration.

[0060] It should be understood that the watchdog timer is a commonly used hardware timer module in embedded systems. Its core function is to monitor the system's operating status and prevent the program from getting stuck in an infinite loop or experiencing unpredictable crashes.

[0061] It should be explained that the current timeout configuration refers to the timeout setting currently used by the system during normal operation, before the watchdog timer is adjusted. For example, during the normal operation of the application, a short timeout (such as 100ms) may be set to ensure real-time response to external events and timely fault detection. This "100ms" is the "current timeout configuration". In this embodiment, the bootloader reads this value before the jump and extends it (for example, to 300ms) to use a more lenient timeout window during the jump; after the jump is completed, the application restores the value to the original 100ms to maintain efficient monitoring during the operation phase.

[0062] It should be noted that by dynamically extending the watchdog timeout before the jump (for example, extending it to 3 times the original configuration), sufficient execution window is provided for operations such as flag reading, code verification, and interrupt configuration, ensuring that the entire jump process can be completed completely and stably. This avoids the problem of the watchdog being accidentally reset due to a slightly longer jump time, and significantly improves the reliability of the jump process.

[0063] Furthermore, after the transition is complete, the application restores the watchdog timeout to the configured value required for normal operation. This allows the watchdog to effectively monitor the system with a shorter (i.e., normal) timeout during normal application operation. If the application experiences a deadlock or crashes later, the watchdog can still trigger a reset in a timely manner, thus balancing the stability of the transition process with the monitoring sensitivity during the runtime phase.

[0064] This embodiment discloses a method for reading multiple sets of flag bits from non-volatile memory after startup in the bootloader area. These flag bits include an upgrade flag, a version flag, a verification flag, and an exception flag. Based on these flag bits, a target jump decision is determined according to a preset priority rule. If the target jump decision indicates a jump to the application area, the target code in the application area undergoes integrity verification. After successful verification, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution jumps from the bootloader area to the application area. Because this embodiment reads multiple sets of flag bits from non-volatile memory after startup in the bootloader area, determines the target jump decision based on these flag bits, performs integrity verification before jumping to the application area, and dynamically redirects the base address of the interrupt vector table to the starting address of the application area, this embodiment improves the reliability and security of the jump process compared to existing technologies.

[0065] refer to Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the jump control method of the present invention.

[0066] Based on the first embodiment described above, in this embodiment, after step S202, steps S2021 to S2024 are further included: Step S2021: After jumping from the bootloader area to the application area for execution, monitor whether the application area writes a normal running flag within a preset time window.

[0067] Step S2022: If the normal operation flag is not detected, a system reset is triggered to execute the program in the boot program area and read the historical version firmware from the preset backup firmware area.

[0068] Step S2023: Perform integrity verification on the historical firmware version, and write the historical firmware version into the application area after the verification is passed.

[0069] Step S2024: Update the verification flag to indicate that the historical firmware version is valid, and perform a jump to the application area.

[0070] It should be understood that the preset backup firmware area can refer to a physical storage area within the non-volatile memory (such as Flash) of an embedded system, separate from the bootloader area (IAP area) and the currently running application area (APP area). The main function of this area is to serve as a secure, read-only (or write-protected outside of a specific upgrade process) redundant storage space for storing one or more known, stable copies of firmware. It does not participate in the normal operation of the system; it is only read and restored by the bootloader as a firmware source when the current application area fails, verification fails, or a rollback is required.

[0071] Historical firmware versions refer to one or more firmware versions that are earlier in time than the current firmware running in the application area or the target firmware to be upgraded, and that have been verified by the system to be functional. It is typically a version retained from the last stable system run, or a baseline version pre-installed at the factory. Historical firmware versions are stored in the preset backup firmware area as backup rollback resources in case of anomalies. When the system detects an anomaly in the firmware of the current application area, the bootloader selects a suitable historical firmware version (e.g., the highest version number or marked as the most stable) and copies it to the application area to restore system functionality.

[0072] It should be noted that by loading historical firmware versions, the system can quickly revert to a known stable state, minimizing business interruption time and ensuring the continuity of core functions.

[0073] It should be added that, after the step of performing integrity verification on the historical firmware version, the method further includes: if the integrity verification of the historical firmware version fails, the firmware in the preset backup firmware area is determined to be invalid; the embedded device is controlled to enter a degraded operation mode, in which only the basic operating functions of the boot program area and the availability of the communication interface are maintained.

[0074] It should be understood that in degraded operation mode, although non-core business functions are disabled, the basic operation and communication interfaces (such as UART, I2C, or Ethernet) in the bootloader area are deliberately retained. This allows maintenance personnel or host computers to still establish a connection with the device and re-flash the correct firmware through the original communication channels. This significantly improves the maintainability and on-site recovery capabilities of the device, avoiding the high costs of manual on-site disassembly or factory repair.

[0075] This embodiment discloses that after jumping from the bootloader area to the application area, it monitors whether a normal operation flag is written to the application area within a preset time window. If the normal operation flag is not detected, a system reset is triggered to execute the program in the bootloader area and read the historical firmware version from the preset backup firmware area. The historical firmware version is then subjected to integrity verification, and if the verification passes, the historical firmware version is written to the application area. The verification flag is updated to indicate that the historical firmware version is valid, and the jump to the application area is then executed. Because this embodiment actively monitors the health status of the application after the jump, it can identify problems within the preset time window when a fault occurs and actively trigger a recovery process, rather than passively waiting for the system to crash. Compared with the prior art, this embodiment achieves self-recovery of application faults, greatly improving the robustness of the system.

[0076] refer to Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the jump control method of the present invention.

[0077] Based on the above embodiments, in this embodiment, the jump control method further includes steps S50~S70: Step S50: Record jump audit information in the log storage area of ​​the non-volatile memory. The jump audit information includes the trigger source identifier, source version identifier, target version identifier, and execution result identifier.

[0078] Step S60: Detect the remaining storage space in the log storage area.

[0079] Step S70: If the remaining storage space is less than the preset storage threshold, the new jump audit information is written to the earliest recorded storage location in the log storage area using a cyclic overwrite method.

[0080] It should be noted that the step of recording jump audit information in the log storage area of ​​the non-volatile memory includes: after each jump operation to the application area, obtaining the timestamp information provided by the clock; combining the timestamp information with the trigger source identifier, source version identifier, target version identifier and execution result identifier to form an audit log record; and writing the audit log record into the currently available storage location in the log storage area of ​​the non-volatile memory.

[0081] It should be understood that redirect audit information refers to log data that records key information of each IAP-APP redirect process, used to achieve full-link traceability and monitoring of redirect behavior.

[0082] Understandably, the trigger source identifier can refer to the specific reason or event that caused the jump, such as "user instruction" (upgrade initiated by an external host computer), "abnormal trigger" (automatic recovery jump due to system malfunction), "forced upgrade" (upgrade forcibly executed based on a specific flag), etc. This identifier helps to locate the cause of the jump during subsequent fault analysis. The source version identifier can indicate the version number of the currently running program (usually an APP) before the jump occurred. By recording the source version, the version from which the upgrade or recovery operation started can be traced. The target version identifier can refer to the version number of the target program (such as a new APP or a backup APP) to be run during this jump. Combined with the source version identifier, the version change trajectory can be clearly obtained. The execution result identifier can refer to the final state of this jump operation, such as "success," "APP abnormal" (target program malfunctions after jump), "verification failed" (integrity verification failed), etc. This identifier provides direct results for fault diagnosis.

[0083] It should be understood that the circular overwrite method can refer to a management strategy for the log storage area. Specifically, a fixed-size log storage area (e.g., a separate Flash sector) is pre-allocated in non-volatile memory. When recording jump audit information, the system continuously writes to this area. When the remaining space in this storage area is detected to be less than a preset threshold (e.g., insufficient remaining space to write a new log entry), the system automatically writes the latest audit information to the oldest recorded storage location in that area, i.e., overwriting the oldest data with new data. This mechanism ensures that the log storage space is always reused, preventing the inability to record new jump events due to storage space exhaustion, and also eliminates the need for manual log cleanup, making it suitable for embedded devices with limited storage resources.

[0084] This embodiment discloses recording jump audit information in the log storage area of ​​the non-volatile memory. The jump audit information includes a trigger source identifier, a source version identifier, a target version identifier, and an execution result identifier. The remaining storage space in the log storage area is detected. If the remaining storage space is less than a preset storage threshold, a cyclic overwrite method is used to write new jump audit information to the earliest recorded storage location in the log storage area. Because this embodiment records jump audit information in the log storage area of ​​the non-volatile memory and uses a cyclic overwrite method to write new jump audit information to the log storage area, compared with the prior art, this embodiment improves the maintainability and long-term operational reliability of the system.

[0085] Furthermore, this embodiment of the invention also proposes a storage medium storing a jump control method program, which, when executed by a processor, implements the steps of the jump control method as described above.

[0086] Reference Figure 4 , Figure 4 This is a structural block diagram of the first embodiment of the jump control method device of the present invention.

[0087] like Figure 4 As shown, the jump control method and apparatus proposed in this embodiment of the invention are applied to an embedded device. The embedded device includes a boot program area and an application program area. The apparatus includes: a flag reading module 501, a decision determination module 502, a code verification module 503, and a jump execution module 504.

[0088] The flag reading module 501 is used to read multiple sets of flag bits in the non-volatile memory after the boot program area is started. The multiple sets of flag bits include an upgrade flag, a version flag, a verification flag, and an exception flag.

[0089] The decision determination module 502 is used to determine the target jump decision based on the multiple sets of flag bits and according to a preset priority rule.

[0090] The code verification module 503 is used to perform integrity verification on the target code in the application area if the target jump decision indicates a jump to the application area.

[0091] The jump execution module 504 is used to dynamically redirect the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jump from the bootloader area to the application area for execution.

[0092] The decision determination module 502 is further configured to determine whether the anomaly flag indicates the existence of a historical jump anomaly; if the anomaly flag indicates the existence of a historical jump anomaly, then the target jump decision is determined to trigger the anomaly recovery process; if the anomaly flag does not indicate the existence of a historical jump anomaly, then the upgrade flag is determined to indicate the existence of an upgrade request, and based on the determination result, the target jump decision is determined to perform an upgrade operation or jump to the application area.

[0093] The decision determination module 502 is further configured to determine whether the upgrade flag indicates an upgrade request and obtain a determination result; if the determination result indicates that the upgrade flag indicates a forced upgrade request, then the target jump decision is determined to execute the upgrade operation; if the determination result indicates that the upgrade flag indicates a user upgrade request, then the current version information indicated by the version flag is read and compared with the target version, and the target jump decision is determined to execute the upgrade operation or jump to the application area based on the comparison result; if the upgrade flag does not indicate an upgrade request, then the verification flag is read, and the target jump decision is determined to jump to the application area or trigger an abnormal recovery process based on the verification flag.

[0094] The code verification module 503 is also used to save the interrupt enable state in the current interrupt control register and disable global interrupts.

[0095] The jump execution module 504 is also used to restore the interrupt enable state, so that the enabled interrupt remains valid after the jump.

[0096] The jump execution module 504 is also used to obtain the current timeout configuration of the watchdog timer and extend the timeout of the watchdog timer to a preset multiple of the current timeout configuration.

[0097] The jump execution module 504 is also used to restore the timeout of the watchdog timer to the current timeout configuration when the application area performs initialization.

[0098] This device embodiment discloses that after startup in the bootloader area, multiple sets of flag bits are read from non-volatile memory. These flag bits include an upgrade flag, a version flag, a verification flag, and an exception flag. Based on these flag bits, a target jump decision is determined according to a preset priority rule. If the target jump decision indicates a jump to the application area, the target code in the application area undergoes integrity verification. After successful verification, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution jumps from the bootloader area to the application area. Because this device embodiment reads multiple sets of flag bits from non-volatile memory after startup in the bootloader area, determines the target jump decision based on these flag bits, performs integrity verification before jumping to the application area, and dynamically redirects the base address of the interrupt vector table to the starting address of the application area, compared to existing technologies, this device embodiment improves the reliability and security of the jump process.

[0099] Based on the first embodiment of the jump control method and apparatus of the present invention described above, a second embodiment of the jump control method and apparatus of the present invention is proposed.

[0100] In this embodiment, the decision determination module 502 is further configured to monitor whether a normal operation flag is written to the application area within a preset time window after the jump from the bootloader area to the application area; if the normal operation flag is not detected, the system is triggered to reset to execute the program in the bootloader area and read the historical version firmware from the preset backup firmware area; the integrity of the historical version firmware is verified, and after the verification is passed, the historical version firmware is written to the application area; the verification flag is updated to indicate that the historical version firmware is valid, and the jump to the application area is executed.

[0101] Other embodiments or specific implementations of the jump control method and apparatus of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0102] This application provides a jump control method apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the jump control method in the above embodiment 1.

[0103] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a device suitable for implementing the jump control method of the embodiments of this application. The jump control method device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The jump control method device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0104] like Figure 5As shown, the jump control method device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the jump control method device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the jump control method device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a jump control method device with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0105] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0106] The jump control method and device provided in this application, employing the jump control method in the above embodiments, can solve the technical problem of low reliability and security in the jump process in the prior art. Compared with the prior art, the beneficial effects of the jump control method and device provided in this application are the same as those of the jump control method provided in the above embodiments, and other technical features in this jump control method and device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0107] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0108] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0109] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0110] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0111] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0112] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A jump control method, characterized in that, The method is applied to an embedded device, the embedded device including a bootloader area and an application program area, and the method includes: After the bootloader area is started, multiple sets of flag bits are read from the non-volatile memory. These multiple sets of flag bits include upgrade flag, version flag, verification flag, and exception flag. Based on the multiple sets of flag bits, a target jump decision is determined according to a preset priority rule; If the target jump decision indicates a jump to the application area, then the target code in the application area is subjected to integrity verification. After the verification is successful, the base address of the interrupt vector table is dynamically redirected to the starting address of the application area, and execution is switched from the bootloader area to the application area.

2. The jump control method as described in claim 1, characterized in that, The step of determining the target jump decision based on the multiple sets of flag bits and according to a preset priority rule includes: Determine whether the anomaly flag indicates the existence of a historical jump anomaly; If the anomaly flag indicates the existence of a historical jump anomaly, then the target jump decision is determined to trigger the anomaly recovery process; If the anomaly flag does not indicate the existence of a historical jump anomaly, then it is determined whether the upgrade flag indicates the existence of an upgrade request, and based on the determination result, the target jump decision is to perform an upgrade operation or jump to the application area.

3. The jump control method as described in claim 2, characterized in that, The step of determining whether the upgrade flag indicates an upgrade request, and determining the target redirection decision as either performing an upgrade operation or redirecting to the application area based on the determination result, includes: Determine whether the upgrade flag indicates an upgrade request, and obtain the determination result; If the determination result indicates that the upgrade flag indicates a mandatory upgrade request, then the target jump decision is determined to execute the upgrade operation; If the judgment result indicates that the upgrade flag indicates that there is a user upgrade request, then the current version information indicated by the version flag is read and compared with the target version. Based on the comparison result, the target jump decision is determined to perform the upgrade operation or jump to the application area. If the upgrade flag does not indicate that an upgrade request exists, the verification flag is read, and based on the verification flag, the target jump decision is determined to either jump to the application area or trigger an exception recovery process.

4. The jump control method as described in claim 1, characterized in that, Before the step of performing integrity verification on the target code of the application area, the method further includes: Save the interrupt enable state in the current interrupt control register and disable global interrupts; Accordingly, after the step of dynamically redirecting the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jumping from the bootloader area to the application area for execution, the method further includes: Restore the interrupt enable state so that the enabled interrupt remains valid after the jump.

5. The jump control method as described in claim 1, characterized in that, Before the step of jumping from the bootstrap area to the application area for execution, the method further includes: Obtain the current timeout configuration of the watchdog timer, and extend the timeout period of the watchdog timer to a preset multiple of the current timeout configuration; Accordingly, after the step of jumping from the bootloader area to the application area for execution, the method further includes: When initialization is performed by the application area, the timeout period of the watchdog timer is restored to the current timeout configuration.

6. The jump control method as described in claim 2, characterized in that, After the step of determining that the target jump decision is to trigger the exception recovery process if the exception flag indicates the existence of a historical jump exception, the method further includes: After jumping from the bootloader area to the application area for execution, monitor whether the application area writes a normal running flag within a preset time window; If the normal operation flag is not detected, a system reset is triggered to execute the program in the boot program area and read the historical version firmware from the preset backup firmware area; The historical firmware version is verified for integrity, and after the verification is passed, the historical firmware version is written to the application area. Update the verification flag to indicate that the historical firmware version is valid, and perform a jump to the application area.

7. The jump control method as described in claim 1, characterized in that, The method further includes: Jump audit information is recorded in the log storage area of ​​the non-volatile memory. The jump audit information includes the trigger source identifier, source version identifier, target version identifier, and execution result identifier. Detect the remaining storage space in the log storage area; If the remaining storage space is less than the preset storage threshold, the new jump audit information is written to the earliest recorded storage location in the log storage area using a cyclic overwrite method.

8. A jump control device, characterized in that, The device is used in an embedded device, the embedded device including a bootloader area and an application area, the device comprising: The flag reading module is used to read multiple sets of flag bits in the non-volatile memory after the bootloader area is started. The multiple sets of flag bits include upgrade flag, version flag, verification flag and exception flag. The decision determination module is used to determine the target jump decision based on the multiple sets of flag bits and according to a preset priority rule; The code verification module is used to perform integrity verification on the target code in the application area if the target jump decision indicates a jump to the application area; The jump execution module is used to dynamically redirect the base address of the interrupt vector table to the starting address of the application area after the verification is passed, and jump from the bootloader area to the application area for execution.

9. A jump control device, characterized in that, The device includes: a memory, a processor, and a jump control program stored in the memory and executable on the processor, the jump control program being configured to implement the steps of the jump control method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a jump control program, which, when executed by a processor, implements the steps of the jump control method as described in any one of claims 1 to 7.

Images