Bootloader upgrading method for thermal management domain controller

Abstract

The invention discloses a bootloader upgrading method for a thermal management domain controller, and relates to the technical field of automobile electronic control, and the method mainly comprises the steps: receiving a bootloader upgrading instruction sent by an upper computer and a bootloader file to be written; modifying a starting address of the thermal management domain controller into a storage address of a transition application program, and programming the received bootloader file to a target storage address of the thermal management domain controller by the transition application program; after programming is completed, the starting address of the thermal management domain controller is modified back to the target storage address; and enabling the thermal management domain controller to run the new bootloader file based on the modified starting address through reset operation. According to the method, a double-bootloader redundancy design is completely abandoned, and the whole bootloader upgrading process can be completed only by a single lightweight transition application program, so that the Flash space occupation is reduced by more than 50%, and the method can be adapted to resource-limited embedded scenes such as a thermal management domain controller and the like.

Description

Technical Field

[0001] The present invention relates to the technical field of automotive electronic control, and in particular to a bootloader upgrading method for a thermal management domain controller. Background Art

[0002] In the automotive electronic control field, the thermal management domain controller (TMCU), a new type of integrated control unit, features firmware upgrades that are crucial to system reliability. Current bootloader upgrades for automotive controllers generally utilize a two-stage bootloader solution. This solution requires two complete bootloader programs to be permanently stored in Flash memory: bootloader A, which is responsible for normal power-up and jumps to the official application, and bootloader B, which is specifically used to temporarily boot the system while bootloader A is being upgraded. Specifically, when bootloader A needs to be upgraded, the system first boots from bootloader B, which then erases the bootloader A area and verifies the integrity of the new program. Upon successful upgrade, the system switches back to bootloader A. However, this architecture suffers from three inherent flaws: First, the dual bootloaders require double the Flash memory space, 40-60KB, far exceeding the resource limits of small microcontrollers (such as those commonly used in thermal management domain controllers), making it impractical for implementation in space-constrained embedded environments. Second, if bootloader A contains a fatal flaw, such as a protocol parsing error, bootloader B, which only has the ability to upgrade bootloader A but cannot repair itself or take over permanent boot functions, will cause the system to enter a permanent upgrade deadlock. Third, if a power outage occurs while bootloader B is erasing bootloader A, the bootloader A region will become corrupted. While bootloader B can temporarily boot the official application, the unavailability of bootloader A prevents subsequent power-on processes from properly transitioning to the official application, ultimately requiring a return to the factory for repair. These three major flaws—large space usage, inability to self-repair, and functional degradation after a power outage—severely limit the reliability and maintainability of the thermal management domain controller. Summary of the Invention

[0003] In order to solve the bootloader upgrade problem under the limited storage space of the thermal management domain controller chip, the present invention proposes a bootloader upgrade method for the thermal management domain controller, comprising the steps of: S1: After the thermal management domain controller is powered on, it runs the preset transition application; S2: Determine whether the bootloader upgrade command and the bootloader file to be written sent by the host computer are received. If so, enter S3 step. If not, guide the official application to start through the current bootloader file; S3: Modify the boot address of the thermal management domain controller to the storage address of the transition application, and the transition application burns the received bootloader file to the target storage address of the thermal management domain controller; S4: After the programming is completed, the startup address of the thermal management domain controller is modified back to the target storage address; S5: Through a reset operation, the thermal management domain controller runs the new bootloader file based on the modified startup address.

[0004] The present invention innovatively adopts a transition application-led bootloader upgrade architecture, combined with a boot address dynamic redirection mechanism design, to overcome the long-standing firmware upgrade problem in the field of small in-vehicle controllers.

[0005] Furthermore, in the step S3, if an abnormal power outage occurs during the burning process, the step S3 will be automatically executed after the power is restored to continue burning the unfinished bootloader file.

[0006] Furthermore, when continuing to burn the unfinished bootloader file, the received bootloader file and upgrade instruction status are used.

[0007] Furthermore, the transition application executes the file burning operation by calling a preset writing control module in step S3, and the writing control module includes: An erase unit, used to clear the original data at the target storage address; Verification unit, used to verify the integrity of the bootloader file after burning.

[0008] Furthermore, in the step S3, the startup address is modified to the storage address of the transition application by configuring the startup address register; and in the step S4, the startup address is modified back to the target storage address by updating the startup address register.

[0009] Furthermore, the official application is a business function execution program of the thermal management domain controller.

[0010] Furthermore, the step S5 further includes the following steps: S6: Reconstruct the boot relationship between the new bootloader file and the official application, and guide the official application to start through the new bootloader file after reconstruction.

[0011] Furthermore, before the step S4, the following steps are further included: S40: Calculate the hash value of the new bootloader file after the burning is completed, compare it with the signature issued by the host computer, and clear the burned file and report an error to the host computer if there is any inconsistency.

[0012] Furthermore, the target storage address is located in an external serial Flash memory, and the transition application accesses the external serial Flash memory through an SPI interface to perform a programming operation.

[0013] Compared with the prior art, the present invention has at least the following beneficial effects: (1) The present invention proposes a bootloader upgrade method for a thermal management domain controller, which completely abandons the redundant design of dual bootloaders. Only a single lightweight transition application (usually less than 15KB) is required to complete the entire bootloader upgrade process, reducing the Flash space occupied by more than 50%. It is suitable for resource-constrained embedded scenarios such as thermal management domain controllers. (2) By forcibly locking the boot address to the transition application, it ensures that even if an abnormal power outage occurs during the upgrade process, it can automatically recover to the safe state before the upgrade and continue to execute the unfinished burning task after power is restored, perfectly avoiding the risk of system bricking caused by damage to the bootloader area in traditional solutions; (3) The transition application directly takes over the bootloader burning operation, breaking the dead loop in the traditional solution where the bootloader cannot repair itself, so that fatal bootloader errors caused by protocol defects or compatibility issues can be flexibly repaired through the APP layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A step-by-step diagram of a bootloader upgrade method for a thermal management domain controller. DETAILED DESCRIPTION

[0015] The following are specific embodiments of the present invention and the accompanying drawings to further describe the technical solutions of the present invention, but the present invention is not limited to these embodiments.

[0016] This embodiment uses the thermal management domain controller (TMCU) as the execution body, focusing on how a lightweight transition application can complete a secure bootloader upgrade in a resource-constrained embedded environment through dynamic redirection of the boot address and an exception recovery mechanism. At the same time, it solves the three major defects of the traditional two-level bootloader solution: redundant space usage, irrecoverable power failure, and inability to self-repair. The implementation process covers key technical links such as upgrade command response, external memory access, power-off resuming, and integrity verification. Figure 1 As shown, a bootloader upgrade method for a thermal management domain controller includes the following steps:

[0017] S1: After the thermal management domain controller is powered on, it runs the preset transition application; S2: Determine whether the bootloader upgrade command and the bootloader file to be written sent by the host computer are received. If so, enter S3 step. If not, guide the official application to start through the current bootloader file; S3: Modify the boot address of the thermal management domain controller to the storage address of the transition application, and the transition application burns the received bootloader file to the target storage address of the thermal management domain controller; S4: After the programming is completed, the startup address of the thermal management domain controller is modified back to the target storage address; S5: Reset the thermal management domain controller to run the new bootloader file based on the modified boot address; S6: Reconstruct the boot relationship between the new bootloader file and the official application, and guide the official application to start through the new bootloader file after reconstruction.

[0018] Specifically, after a cold start or reset of the thermal management domain controller, the system hardware initialization process first executes a transition application stored in a separate storage partition, which is physically isolated from the bootloader and official application areas. This transition application, a pre-installed, lightweight temporary tool, is forcibly loaded and executed via the hardware boot loader's (BootROM) fixed jump address mechanism. Its core function is to establish a basic communication stack and monitor the host computer's command channel, creating a secure sandbox environment for subsequent possible bootloader upgrades. This design ensures that regardless of the controller's power-on state, it prioritizes access to this controlled transition program space, completely avoiding the risk of system lockup caused by historical upgrade failures or program crashes. It also provides the underlying execution foundation for dynamically modifying the boot address.

[0019] After the transition application completes initialization, its built-in command listener thread continuously polls a pre-defined communication interface (such as a CAN / LIN bus or Ethernet port), filtering data frames sent by the host computer in real time using proprietary protocol identifiers. If a valid data packet carrying bootloader upgrade instructions is detected, an encrypted handshake process is triggered to verify the host computer's identity. Once verification is successful, a block-by-block transmission channel is established to receive the bootloader file to be written. During this process, the transition application temporarily stores received file fragments in an isolated buffer (disjoint with the official application's memory space) and provides real-time feedback on the reception progress to the host computer. Only when the size and checksum of the received file are completely consistent with the parameters declared by the host computer is the upgrade considered valid, triggering the subsequent boot address modification and flashing process. This multi-factor authentication mechanism prevents illegitimate upgrade requests and ensures file integrity from the transmission source. Furthermore, if no valid data packet carrying bootloader upgrade instructions is received, the official application, which executes the business functions of the thermal management domain controller, is booted using the current bootloader file.

[0020] Once the upgrade conditions are determined to be met, the system first configures the boot address register through atomic operations (indivisible, single-instruction modifications to hardware registers, primarily to ensure the integrity and consistency of boot address switching in a multitasking / interrupt environment). This forcibly locks the controller boot address to the transition application storage area, establishing a physically isolated execution environment from the bootloader area. The transition application then invokes its pre-configured write control module, whose erase unit performs a sector-level erase of the target storage address, ensuring the complete removal of the original bootloader data. During the flash process, the transition application writes the bootloader file from the isolated buffer to the target storage address in a block-by-block manner, updating the flash progress indicator in the non-volatile memory in real time with each completed block. Once all data is written, the verification unit immediately calculates the SHA-256 hash of the flash area and compares it with the digital signature issued by the host computer. If there is a mismatch, a rollback mechanism is triggered to clear the flashed content. The entire flash process is executed within a secure container established by the transition application, ensuring that even hardware anomalies do not affect the data integrity of the official application area.

[0021] During the entire bootloader flash cycle, the system employs a multi-level coordinated protection mechanism to mitigate the risk of unexpected power outages. When the flash process begins, the transition application first writes a sector mapping table to non-volatile memory as a baseline anchor. Subsequently, upon completion of each data block (typically 256B), the transition application simultaneously updates the three-dimensional progress coordinates in the non-volatile memory. These coordinates are composed of the sector number, block sequence number, and a dynamic checksum. The storage capacitor circuit is immediately disconnected for forced discharge, eliminating the risk of data corruption caused by residual charge. A real-time voltage monitoring circuit is implemented at the hardware level. Upon detecting that the vehicle power supply voltage falls below the 9V threshold, the current progress coordinates and temporary session key are frozen within 50μs in ferroelectric RAM (FRAM), ensuring that critical status information is preserved before a complete power outage. Upon powering back on, the transition application prioritizes scanning the non-volatile memory. If valid progress coordinates are found, the transition application automatically determines the breakpoint location and, using the session key stored in the FRAM, recovers the encrypted transmission link, accurately resuming the transmission of any unfinished blocks. If this is the first flash, the entire upgrade process is executed. After all data is written, a deep security check is initiated: the check unit calculates the SHA-256 hash value of the target storage area. If it matches the host computer's signature, the damage scope is determined based on the progress coordinates. If this is the first burn, the target area is completely erased; if it is a continued transfer, the transfer is rolled back to the most recent valid coordinates and restarted. The entire protection system operates under a dual watchdog monitoring architecture (a hardware watchdog controls power sequencing, and a software watchdog monitors thread heartbeats), ensuring that single points of failure do not cause process freezes.

[0022] After the bootloader file is flashed and integrity verified, the system initiates the secure migration protocol for boot address switching. This step first atomically updates the boot address register, precisely resetting the controller's boot address from the transition application memory area to the new bootloader's target memory address. If the target address is in external serial Flash, the address decoding table in the memory controller is simultaneously remapped to ensure consistency between the physical and logical memory spaces. The migration process employs a two-stage confirmation mechanism: in the first stage, a draft address switching instruction is written to non-volatile memory, followed by the actual register update in the second stage. A 10μs hardware delay is inserted between the two stages to ensure power supply stability. If voltage fluctuations (less than a 10V threshold) are detected during this period, the current state is immediately frozen and rolled back to the state before the draft instruction. After the address switch is complete, the system automatically triggers the memory controller to perform an address mapping consistency check, comparing the boot address register value with the base address of the actual physical memory area. If the deviation exceeds ±4 bytes, a hardware exception interrupt is automatically generated, forcing a rollback to the transition application address and sending a calibration request to the host computer. The entire process operates under ECC memory protection, which can correct single-bit address configuration errors and achieve ASIL-D address switch fault tolerance. The reason why the target address is pointed to the external serial Flash is that the external Flash is accessed through the SPI interface and is isolated from the core bus. This can prevent malicious code from tampering with the bootloader through the memory bus. At the same time, the external Flash is powered by a dedicated LDO, which is separated from the main control power supply to avoid data corruption caused by voltage fluctuations during upgrades.

[0023] The migration protocol's triple-layer protection design constitutes a key technical barrier. The first layer of hardware protection relies on the boot address register's write-enable latch, opening the physical write channel only within the stable supply voltage range (10-16V), effectively isolating the system from glitches in the vehicle's power supply. The second layer of logical protection utilizes a draft-validate dual register mechanism. The draft register temporarily stores the target address, while the valid register is updated only after the draft value passes a CRC check, mitigating the risk of bit flips caused by external interference. The third layer of topology protection, targeting external serial Flash memory, triggers a topology self-check of the storage area immediately after the address is updated. This verifies that the machine code of the first instruction in the new bootloader file matches the pre-stored signature, ensuring that the system boots correctly after the address switch. This triple layer of protection reduces the chance of erroneous boot address modifications.

[0024] In the event of an extreme anomaly, the system initiates a gradient recovery strategy. If a voltage drop during address switching interrupts the dual-stage migration, upon power-up, the transition application reads the draft instructions from the non-volatile memory and reinitiates the safe migration process. If the address mapping consistency check fails (e.g., due to physical damage to the external Flash memory), the system automatically switches to the backup storage area (pre-stored with the basic bootloader) and proactively reports a fault code via the vehicle network. This design enables the system to maintain minimal functionality (Limp Home mode) even in the event of a partial memory failure, completely avoiding the system dead loops caused by address configuration errors in traditional solutions.

[0025] Once the boot address switch verification passes, the system first injects an encrypted reset token (dynamically generated from the SHA-256 digest of the new bootloader file and the device serial number) into the reset controller, triggering a key-authenticated hardware reset sequence. If the target storage address is in external serial Flash, the SPI controller's clock domain calibration is synchronously initialized to eliminate the risk of boot failure caused by cross-clock domain phase deviation. After the reset pulse is released, the processor core automatically loads the boot relationship reconstruction engine before executing the first instruction. This engine parses the metadata header of the new bootloader, dynamically reconstructs the jump mapping table with the official application, and performs a triple check:

[0026] 1. Address boundary check: confirm the physical isolation between the official application storage area and the bootloader area; 2. Version compatibility check: Compare the bootloader protocol version number with the version range required by the application; 3. Signature chain verification: Verify the integrity of the digital certificate chain from the bootloader to the application (ECDSA-P384 algorithm).

[0027] After all verifications pass, the system automatically updates the boot topology snapshot in non-volatile memory, recording the current valid boot path. If verification fails (e.g., due to version incompatibility), a safe rollback is triggered: the hardware reset circuit automatically clears the reset token, forcing the controller to return to the transition application address and uploading an error code via the diagnostic interface (UDS 0x31 service). The entire reset process is protected by voltage-adaptive clock gating technology. When power ripple > 200mVpp is detected, a wait cycle is automatically inserted to ensure that the reset signal takes effect within the power supply stability window.

[0028] In summary, the bootloader upgrade method for a thermal management domain controller proposed in the present invention completely abandons the redundant dual bootloader design and only requires a single lightweight transition application (usually less than 15KB) to complete the entire bootloader upgrade process, reducing the Flash space occupied by more than 50%. It can be adapted to resource-constrained embedded scenarios such as thermal management domain controllers.

[0029] At the same time, by forcibly locking the boot address to the transition application, it ensures that even if an abnormal power outage occurs during the upgrade process, it can automatically recover to the safe state before the upgrade after power is restored and continue to execute the unfinished burning task, perfectly avoiding the risk of system bricking caused by damage to the bootloader area in traditional solutions.

[0030] Finally, the transition application directly takes over the bootloader burning operation, breaking the dead loop in the traditional solution where the bootloader cannot repair itself. This allows fatal bootloader errors caused by protocol defects or compatibility issues to be flexibly repaired through the APP layer.

[0031] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0032] In addition, in the present invention, descriptions such as "first," "second," and "one" are for descriptive purposes only and should not be understood to indicate or imply their relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include at least one of such features. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0033] In the present invention, unless otherwise specified or limited, the terms "connection" and "fixation" should be understood in a broad sense. For example, "fixation" can mean fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two elements or interaction between two elements, unless otherwise specified. Those skilled in the art will be able to understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0034] In addition, the technical solutions between the various embodiments of the present invention can be combined with each other, but it must be based on the fact that ordinary technicians in this field can implement it. When the combination of technical solutions is mutually contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

Claims

1. A bootloader upgrade method for a thermal management domain controller, characterized in that: The following steps are involved: S1: After the thermal management domain controller is powered on, it runs the preset transition application; S2: Determine whether the bootloader upgrade command and the bootloader file to be written sent by the host computer are received. If so, enter S3 step. If not, guide the official application to start through the current bootloader file; S3: Modify the boot address of the thermal management domain controller to the storage address of the transition application, and the transition application burns the received bootloader file to the target storage address of the thermal management domain controller; S4: After the programming is completed, the startup address of the thermal management domain controller is modified back to the target storage address; S5: Through a reset operation, the thermal management domain controller runs the new bootloader file based on the modified startup address.

2. A bootloader upgrade method for a thermal management domain controller according to claim 1, characterized in that: In the step S3, if an abnormal power outage occurs during the programming process, the step S3 will be automatically executed after the power is restored to continue programming the unfinished bootloader file.

3. A bootloader upgrade method for a thermal management domain controller according to claim 2, characterized in that: When continuing to burn the unfinished bootloader file, the received bootloader file and upgrade instruction status are used.

4. A bootloader upgrade method for a thermal management domain controller according to claim 1, characterized in that: The transition application executes the file burning operation by calling a preset writing control module in step S3. The writing control module includes: An erase unit, used to clear the original data at the target storage address; Verification unit, used to verify the integrity of the bootloader file after burning.

5. The bootloader upgrade method for a thermal management domain controller according to claim 1, wherein: In the step S3, the startup address is modified to the storage address of the transition application by configuring the startup address register; in the step S4, the startup address is modified back to the target storage address by updating the startup address register.

6. A bootloader upgrade method for a thermal management domain controller according to claim 1, characterized in that: The formal application is a business function execution program of the thermal management domain controller.

7. A bootloader upgrade method for a thermal management domain controller according to claim 1, characterized in that: The S5 step further includes the following steps: S6: Reconstruct the boot relationship between the new bootloader file and the official application, and guide the official application to start through the new bootloader file after reconstruction.

8. The bootloader upgrade method for a thermal management domain controller according to claim 1, wherein: Before the S4 step, the following steps are also included: S40: Calculate the hash value of the new bootloader file after the burning is completed, compare it with the signature issued by the host computer, and clear the burned file and report an error to the host computer if there is any inconsistency.

9. The bootloader upgrade method for a thermal management domain controller according to claim 1, wherein: The target storage address is located in an external serial Flash memory, and the transition application accesses the external serial Flash memory through an SPI interface to perform a programming operation.

Images