Firmware upgrading method and device, equipment and storage medium

Abstract

The invention relates to the technical field of firmware upgrading, and discloses a firmware upgrading method, device and equipment and a storage medium, which are applied to a core in a multi-core controller, take the core as a control core, and comprise the following steps: acquiring respective firmware upgrading packages of a plurality of cores, and storing the firmware upgrading packages in a shared cache region; sending a switching preparation signal to other cores, wherein the switching preparation signal is used for indicating the other cores to enter a switching preparation state; receiving a switching ready signal fed back by each other core, wherein the switching ready signal is used for indicating that each other core stores the current operation information; according to the switching ready signal, a firmware upgrading signal is synchronously sent to the other cores, and the firmware upgrading signal is used for indicating the other cores to load and run new firmware according to the corresponding firmware upgrading package in the shared cache region. The problem that in the prior art, core firmware upgrading synchronism in a multi-core controller is poor is solved.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology, and in particular to a firmware upgrade method, apparatus, device, and storage medium. Background Technology

[0002] Current electric vertical takeoff and landing (eVTOL) aircraft flight control systems widely employ multi-core controllers. The reliability and consistency of their firmware upgrades directly impact flight safety. Existing technologies primarily rely on three solutions: Option 1 is an independent core upgrade scheme, where each core independently receives and verifies its own firmware image and independently performs firmware switching operations, with simple state synchronization only through software message passing or shared memory. Option 2 is a sequential upgrade scheme, upgrading the firmware of each core one by one in sequence. During the upgrade process, some cores run the old firmware while others run the new firmware, and version compatibility checks ensure normal system function during the transition. Option 3 is a reset-based upgrade scheme, where after a system reset, each core loads the new firmware from Flash, and the boot order of each core is controlled by a bootloader. All three schemes aim to complete the firmware update of each core and are suitable for ordinary multi-core devices, but they are difficult to match the high safety requirements of the eVTOL flight control system.

[0003] In eVTOL application scenarios, the limitations of existing technologies are particularly prominent: In Scheme 1, each core is upgraded independently, and simple state synchronization cannot achieve precise coordination of firmware switching, easily leading to inconsistent upgrade rhythms for core modules such as flight control, attitude adjustment, and power distribution, causing command execution delays or conflicts; Scheme 2 upgrades sequentially, but the mixed operation of old and new firmware disrupts the real-time performance and consistency of multi-core collaboration, while eVTOL's flight attitude control and fault redundancy handling functions have extremely high requirements for multi-core synchronous response; Scheme 3 relies on system reset to trigger upgrades, but the reset operation directly interrupts the normal operation of the flight control system, and the bootloader can only control the startup sequence, unable to achieve synchronous switching of each core during the upgrade process, seriously affecting the flight continuity and safety of eVTOL. All three schemes lack a unified leading control mechanism, globally synchronized switching trigger logic, and standardized coordination processes, resulting in the inability for each core firmware upgrade to complete the switching at the same time.

[0004] Therefore, existing technologies suffer from poor synchronization of firmware upgrades among core components in multi-core controllers. In the high-safety-requirement scenario of eVTOL flight control systems, this can easily lead to data interaction errors between multiple cores, failure of functional collaboration, and even serious risks such as loss of flight attitude control. It cannot meet the stringent requirements of eVTOL for firmware upgrade reliability and collaborative consistency. Summary of the Invention

[0005] This invention provides a firmware upgrade method, apparatus, computer device, and storage medium to solve the problem of poor synchronization of firmware upgrades among cores in multi-core controllers in the prior art.

[0006] Firstly, a firmware upgrade method is provided, applied to one core in a multi-core controller, using this core as the control core. The method includes: Obtain the firmware upgrade packages for each of the multiple cores and store them in a shared cache. Send a handover readiness signal to each of the other cores. The handover readiness signal is used to indicate that the other cores are entering the handover readiness state. Receive switching ready signals from other cores. The switching ready signals are used to indicate that other cores have saved their current running information. Based on the switch-ready signal, a firmware upgrade signal is synchronously sent to each of the other cores. The firmware upgrade signal is used to instruct the other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

[0007] Optionally, firmware upgrade signals are sent synchronously to other cores, including: A trigger instruction is written to the synchronization register of the system control unit. The trigger instruction is used to instruct the system control unit to generate a firmware upgrade signal. The firmware upgrade signal is simultaneously transmitted to other cores through the hardware bus of the multi-core controller.

[0008] Optionally, send a switchover readiness signal to each of the other cores, including: A switch preparation signal is written to shared memory, which is used by other cores to obtain the switch preparation signal from shared memory through a preset status query method.

[0009] Optional firmware upgrade methods also include: After each other core receives the switchover preparation signal and enters the switchover preparation state, it controls each other core to save its current operating information; After all cores have completed the firmware upgrade synchronously, they are instructed to read the current running information and restore the running state before the upgrade.

[0010] Optionally, after synchronously sending firmware upgrade signals to other cores based on the switch-ready signal, the system may also include: After each of the other cores loads and runs the new firmware, it receives the switch completion flag written by each of the other cores to the shared memory of the multi-core controller; The system detects the switch completion flags of other cores in the shared memory. Once it is confirmed that the switch completion flags have been written to all other cores, the firmware upgrade switch is deemed successful. If the switch completion flags of all other cores are not detected within the preset timeout period, the rollback mechanism is triggered, and each other core is controlled to revert to the firmware version and running state before the upgrade based on the saved current running information.

[0011] Optionally, after obtaining the firmware upgrade packages for each of the multiple cores, the following may also be included: Multiple core firmware upgrade packages are merged into a multi-core firmware bundle. The multi-core firmware bundle carries an overall digital signature, an overall integrity check value, and an independent check value corresponding to each core firmware upgrade package. The overall digital signature of the firmware bundle is verified based on the pre-set public key, and the overall digital signature verification result is obtained. If the overall digital signature verification passes, the overall integrity verification value of the multi-core firmware bundle is verified based on the preset verification algorithm to obtain the overall integrity verification result. If the overall integrity verification passes, extract the firmware upgrade package corresponding to each core in the multi-core firmware bundle, and verify the independent check value of each firmware upgrade package to obtain the independent check result of each core. If all core firmware upgrade packages pass independent verification, each core firmware upgrade package is stored in the shared cache. If the overall integrity verification fails or any core firmware upgrade package fails independent verification, the firmware upgrade process is terminated.

[0012] Optionally, after obtaining the firmware upgrade packages for each of the multiple cores, the following may also be included: Perform version consistency checks on multiple core firmware upgrade packages and the currently running firmware. The version consistency check includes at least version compatibility checks, dependency checks, and version number consistency checks. If all version consistency checks pass, the firmware upgrade process continues; if any check fails, the upgrade is terminated and detailed information of the failed check is recorded.

[0013] Optional version consistency checks, specifically including: Version compatibility check: Calls a preset compatibility matrix to check the compatibility between each core firmware upgrade package, as well as the compatibility between the current firmware version of each core and the corresponding firmware upgrade package version. Dependency check: Invoke the preset dependency matrix to check whether the functional dependencies and data dependencies between each core firmware upgrade package are correct; Version number consistency check: Check whether the overall version number of each core firmware bundle meets the system's preset requirements, and check whether the version number of each core firmware upgrade package follows the unified version naming convention.

[0014] Secondly, a firmware upgrade device is provided, applied to one core of a multi-core controller, using this core as the control core, comprising: The acquisition module is used to acquire the firmware upgrade packages of each of the multiple cores and store the firmware upgrade packages in the shared cache area; The sending module is used to send a handover preparation signal to each other core. The handover preparation signal is used to indicate that other cores enter the handover preparation state. The receiving module is used to receive the switching ready signals fed back by other cores. The switching ready signals are used to indicate that other cores have saved their current running information. The upgrade module is used to synchronously send firmware upgrade signals to other cores based on the switch ready signal. The firmware upgrade signal is used to instruct other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

[0015] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the firmware upgrade method described above.

[0016] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the firmware upgrade method described above.

[0017] In the aforementioned firmware upgrade method, apparatus, device, and storage medium, a single core uniformly acquires the firmware upgrade packages for all cores and stores them in a shared cache, replacing the existing technology's model where each core independently acquires firmware packages without centralized management. This avoids asynchronous upgrade startup caused by differences in the timing of firmware upgrade package acquisition among cores. It sends a switching preparation signal to other cores and receives a switching ready signal, forcing all other cores to save their current operating information and report their ready status before upgrading, preventing some cores from starting the upgrade before they are ready and ensuring that the upgrade progress of all cores remains consistent. Based on the switching ready signal, it synchronously sends firmware upgrade signals to other cores, ensuring that all other cores receive the upgrade command and load the new firmware at the same time, while the core itself synchronously executes the upgrade, completely avoiding the mixing of old and new firmware. The entire process is led and controlled by a single core, ensuring efficient collaboration among all stages of the upgrade process and further guaranteeing synchronization. Therefore, this invention solves the problem of poor synchronization of firmware upgrades among cores in existing multi-core controllers. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a firmware upgrade method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a firmware upgrade device according to an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0022] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," or "in response to determination." Similarly, the phrase "if determined" or "if matched to [described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once matched to [described condition or event]," or "in response to matched to [described condition or event]."

[0024] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0027] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0028] Please see Figure 1 As shown, Figure 1 A flowchart illustrating the firmware upgrade method provided in this embodiment of the invention includes the following steps: S11: Obtain firmware upgrade packages for each of the multiple cores and store the firmware upgrade packages in the shared cache.

[0029] A multi-core controller contains multiple cores, and any one of these cores can be selected as the control core to manage the entire firmware upgrade process. In a multi-core controller, all cores may need to undergo firmware upgrades simultaneously, or only some cores (more than one) may need to undergo firmware upgrades simultaneously.

[0030] Each core's firmware upgrade package contains firmware code specific to that core, as well as firmware header information (such as version number, build time, etc.).

[0031] The shared buffer is a "public data storage and interaction carrier" designed within a multi-core controller (such as the Infineon TC397) to support the firmware upgrade process. Essentially, it's a dedicated storage area accessible to multiple cores. Its core value lies in: data isolation and protection, preventing direct writing to the firmware runtime area (such as the Flash firmware storage partition), preventing contamination of the currently running old firmware when firmware upgrade package verification fails, and ensuring the basic functional security of the eVTOL flight control system; unified data source support, providing a "complete and consistent data source" for subsequent centralized verification (digital signature, integrity check) by the main core and synchronous loading of new firmware by each core, avoiding verification omissions or loading errors due to data dispersion; and efficiency adaptation, adapting to the high-speed read / write requirements of firmware data, ensuring rapid data reception, verification, and loading under eVTOL real-time requirements (such as the DO-178C standard requiring a response time of <1 millisecond). The shared buffer's storage medium is preferably RAM or Flash temporary area, with a capacity covering the maximum size of all firmware upgrade packages and reserving redundant space.

[0032] In one example, for a multi-core controller (such as the 6 TriCore cores TC0-TC5 of the TC397), it is necessary to obtain the firmware upgrade package for each core. TC1-TC5 are slave cores, and TC0 is the master core. Generally, the master core is used as the control core to control the entire firmware upgrade process. It receives the firmware upgrade packages of all cores through CAN or Ethernet (DoIP protocol) and stores them in a shared buffer.

[0033] S12: Send a handover preparation signal to each other core. The handover preparation signal is used to instruct other cores to enter the handover preparation state.

[0034] It should be noted that the switch preparation signal is not a traditional "software message", but a "hardware-level status notification" implemented through flags in the shared memory status area.

[0035] In one embodiment, sending a switchover preparation signal to other cores includes: writing the switchover preparation signal into shared memory, so that each other core can obtain the switchover preparation signal from the shared memory through a preset status query method. Specifically, the core logic of the control core sending the switchover preparation signal is "flag bit writing + status synchronization". After storing the firmware upgrade package of each core in the shared cache, it changes the "switchover preparation flag bit" in the shared memory from "not ready" to "ready" through a direct memory write instruction. Other cores obtain the signal by "polling the shared memory flag bit". Once they detect that the "switchover preparation flag bit" in the shared memory is in the "ready" state, they determine that they have received the switchover preparation signal and enter the switchover preparation state. It should be noted that if the control core also needs to upgrade the firmware, it also needs to obtain the signal by "polling the shared memory flag bit". Once it detects that the "switchover preparation flag bit" in the shared memory is in the "ready" state, it determines that it has received the switchover preparation signal and the control core enters the switchover preparation state.

[0036] In one example, in a real-world application scenario of the Infineon TC397 multi-core controller (6 cores, TC0 as the master core, TC1-TC5 as slave cores, and TC0 as the control core), TC0 has received firmware upgrade packages from all 6 cores via Ethernet and stored them in the shared cache (addresses 0x70001000-0x70080000). TC0 executes an instruction to rewrite the value of the shared memory address 0x000 (switch ready flag) from 0x00000000 to 0x00000001. This write operation is performed via the TC397's SCU (System Control Unit) bus with a transmission delay of 0.5 microseconds, ensuring that the signal takes effect quickly. Cores TC1-TC5 read the value of shared memory address 0x000 at a frequency of 10 microseconds per time. During the third poll, TC1 detects that the value of shared memory address 0x000 is 0x00000001 and confirms that it has received the switchover preparation signal. Other cores (TC2-TC5) detect the signal in sequence and confirm that they have received the switchover preparation signal, and begin to enter the switchover preparation state.

[0037] S13: Receive the switching ready signal from other cores. The switching ready signal is used to indicate that other cores have saved the current running information.

[0038] This step is a crucial verification link connecting "sending the switchover preparation signal" and "synchronously triggering the firmware upgrade," directly determining the feasibility of subsequent multi-core synchronous switching. Only after confirming that all other cores have returned a switchover ready signal will the control core synchronously send a firmware upgrade signal to all other cores, avoiding switchover failure or system anomalies caused by insufficient preparation of some cores.

[0039] The switching readiness signal is a "status confirmation flag" fed back from other cores to the control core. It is typically a dedicated value bit within the "ready flag array" in the shared memory status area, using a uint32 binary flag as its core form. Status feedback is achieved through changes in the value at a fixed address, requiring no additional software messages or bus transmissions, perfectly adapting to the microsecond-level synchronization requirements of multi-core controllers. It should be noted that if the control core also needs to upgrade its firmware, it must also change the dedicated value bit in the "ready flag array" in the shared memory status area to feed back the switching readiness signal.

[0040] In one example, a "ready flag array" is reserved in the shared memory (such as the 0x70000000-0x70001000 region of TC397), with an address range of 0x004-0x01B, and is of type uint32[6] (each of the 6 cores occupies 1 element). Each core corresponds to an independent position in the array, for example, TC1 corresponds to address 0x008 and TC2 corresponds to address 0x00C. The value at this position is the switching ready signal of the core. The default state (not ready) of the array element corresponding to each core is 0x00000000. After saving the current running information, the array element corresponding to itself is rewritten to 0x00000001 by the instruction. This value is the "switching ready signal". The control core can directly determine whether the corresponding core is ready by reading the value at this address.

[0041] S14: Based on the switch ready signal, synchronously send firmware upgrade signals to other cores. The firmware upgrade signal is used to instruct other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

[0042] The core function of this step is that, after confirming that all other cores are ready, the control core synchronously sends firmware upgrade signals to all other cores, triggering all other cores to simultaneously load the new firmware from the shared cache. This achieves synchronous switching and avoids the mixing of old and new firmware across different cores. It should be noted that if the control core also needs to upgrade its firmware, it must also participate in the synchronous switching process to ensure that the control core and other cores complete the loading of the new firmware simultaneously.

[0043] In one example, taking the TC397 multi-core controller as an example, the control core TC0 polls the ready flag array (addresses 0x004-0x01B) in shared memory to confirm that the flag bits corresponding to other cores TC1-TC5 are all 0x00000001, and all other cores have completed the saving of running information; the control core TC0 updates the "synchronization status" at shared memory address 0x034 from 0x02 (synchronization waiting to complete) to 0x03 (synchronization triggering), completing the pre-trigger state preparation; the control core TC0 executes the instruction to write the trigger value 0x00000001 to the SCU synchronization register (address 0xF0036100); the SCU module immediately generates a hardware synchronization signal, which is simultaneously transmitted to all other cores TC1-TC5 through the CoreLink hardware bus with a transmission delay of 0.3 microseconds, and the time difference of all cores receiving the signal is <0.1 microseconds, meeting the "microsecond-level synchronization" requirement.

[0044] The aforementioned firmware upgrade method uses a single core to uniformly acquire the firmware upgrade packages for all cores and store them in a shared cache, replacing the existing technology where each core independently acquires firmware packages without centralized management. This avoids asynchronous upgrade startup caused by differences in the timing of firmware upgrade package acquisition among cores. It sends a switchover preparation signal to other cores and receives a switchover ready signal, forcing all other cores to save their current operating information and report their ready status before upgrading. This prevents some cores from starting the upgrade before they are ready, ensuring that the upgrade progress of all cores remains consistent. Based on the switchover ready signal, it synchronously sends firmware upgrade signals to other cores, ensuring that all other cores receive the upgrade command and load the new firmware at the same time. Simultaneously, each core executes the upgrade synchronously, completely avoiding the mixing of old and new firmware. The entire process is controlled and managed by a single core, ensuring efficient collaboration among all stages of the upgrade process and further guaranteeing synchronization. Therefore, this invention solves the problem of poor synchronization of firmware upgrades among cores in existing multi-core controllers.

[0045] In one embodiment, synchronously sending firmware upgrade signals to other cores includes: writing a trigger instruction to the synchronization register of the system control unit, the trigger instruction being used to instruct the system control unit to generate a firmware upgrade signal, and the firmware upgrade signal being simultaneously transmitted to other cores through the hardware bus of the multi-core controller.

[0046] The core of this embodiment is to ensure that the firmware upgrade signal is transmitted to all other cores simultaneously via the hardware bus through the hardware-level operation of "writing trigger instructions to the system control unit (SCU) synchronization register", thereby achieving microsecond-level synchronous triggering and solving the core pain point of "insufficient time accuracy" when switching to new firmware in multiple cores from the underlying technology.

[0047] The System Control Unit (SCU) is the core hardware module of a multi-core controller (such as the TC397), responsible for critical functions such as system-level synchronization and interrupt management. The TC397's SCU module has a built-in synchronization register with a fixed physical address of 0xF0036100. Its core function is to "receive trigger instructions → generate hardware synchronization signals." This register is designed at the hardware level, with a response latency of less than 1 microsecond after an instruction is written, far superior to the response speed of a software state machine.

[0048] It should be noted that, in addition to the SCU synchronization register, other hardware synchronization mechanisms can be used to achieve "synchronous transmission of firmware upgrade signals" in order to adapt to the hardware modules of different multi-core controllers. Specific solutions include: 1) Hardware timer synchronous interrupt mechanism Implementation logic: The control core configures the global hardware timer of the multi-core controller, sets a unified trigger time, and enables timer interrupts for all cores. After confirming that all other cores are ready, the control core starts the timer. When the timer reaches the preset time, it generates a synchronous interrupt signal (i.e., a firmware upgrade signal), which is simultaneously distributed to all other cores through the interrupt controller's hardware bus.

[0049] Applicable scenarios: Suitable for multi-core platforms without SCU synchronization registers but with global hardware timers, especially suitable for firmware upgrade scenarios where the trigger time can be preset.

[0050] 2) Hardware event synchronization unit mechanism Implementation logic: Utilizing the event synchronization unit built into the multi-core controller, the control core configures "firmware upgrade trigger" as a global synchronization event. After confirming that all other cores are ready, the control core sends a synchronization event by writing to the event trigger register. The event synchronization unit converts this event into a hardware signal, which is simultaneously transmitted to the event receiving interface of all other cores via a dedicated event bus.

[0051] Applicable scenarios: Suitable for mid-to-high-end multi-core controllers that support hardware event synchronization mechanisms, and adapted to scenarios with high requirements for anti-interference of synchronization signals (such as the strong electromagnetic interference environment of eVTOL).

[0052] 3) Global reset signal mechanism Implementation logic: The control core preloads the firmware upgrade package into a designated partition (non-running area) of the shared cache. After confirming that all other cores are ready, it triggers the generation of a global reset signal (i.e., the firmware upgrade signal) by writing to the reset control register. The global reset signal simultaneously resets all other cores via the hardware bus. After the cores are reset, the bootloader directly loads the new firmware from the shared cache, achieving synchronous switching.

[0053] Applicable scenarios: Suitable for entry-level multi-core controllers without dedicated synchronization registers / event synchronization units, or scenarios with high requirements for simplified upgrade processes (such as low-cost eVTOL auxiliary control systems).

[0054] In one embodiment, the firmware upgrade method further includes: after each other core receives a switching preparation signal and enters a switching preparation state, it controls each other core to save its current operating information; after all cores have completed the firmware upgrade synchronously, it instructs each other core to read the current operating information and restore the operating state before the upgrade.

[0055] The core of this embodiment is to ensure that firmware upgrades do not interrupt core functions through a closed-loop operation of "saving running information before switching and restoring running status after upgrade", while providing a basis for rapid rollback in case of upgrade failure, thus solving the key issues of "functional continuity" and "fault tolerance" in the process of upgrading multi-core controllers.

[0056] After other cores obtain the switching preparation signal through a preset method (such as shared memory polling), they immediately enter the switching preparation state and save the current running information to non-volatile memory (such as Flash or EEPROM).

[0057] After all cores have synchronously completed the loading and initialization of the new firmware, the control core confirms the completion of the core switchover via shared memory. The control core sends a recovery command via shared memory. Upon receiving the recovery command, other cores read the previously saved current operating information from the storage medium to ensure restoration to the state before the upgrade.

[0058] In one embodiment, after synchronously sending firmware upgrade signals to each other core according to the switch-ready signal, the method further includes: after each other core loads and runs the new firmware, receiving the switch-complete flag written by each other core in the shared memory of the multi-core controller; detecting the switch-complete flags of each other core in the shared memory, and determining that the firmware upgrade switch is successful after confirming that all other cores have written the switch-complete flag; if the switch-complete flags written by all other cores are not detected within a preset timeout period, triggering a rollback mechanism and controlling each other core to revert to the firmware version and running state before the upgrade based on the saved current running information.

[0059] The core of this embodiment is to confirm the loading and running results of the new firmware for all other cores through a closed-loop logic of "shared memory flag detection + timeout rollback", while providing a fast recovery plan for upgrade failures, thus solving the key problem of no fallback plan when multi-core firmware upgrades fail.

[0060] The handover completion flag is stored in a "handover completion flag array" in shared memory. After other cores load and run the new firmware, they modify their own corresponding handover completion flag array, i.e., write the handover completion flag. The control core receives the handover completion flags written by other cores through polling, without requiring other cores to actively send notifications. The polling interval can be set by the user (e.g., 5 microseconds / time).

[0061] If the control core does not detect the switchover completion flags of all other cores within the preset timeout period, it immediately determines "switchover failure" and triggers the rollback mechanism. The control core sends a rollback command through shared memory, controlling all other cores to read the previously saved running information and revert to the old firmware version and running state before the upgrade. After the rollback is completed, the control core records an error log for easy fault diagnosis.

[0062] In one example, taking the TC397 multi-core controller as an example, after the control core TC0 sends a firmware upgrade signal, the other cores TC1-TC5 synchronously load the new firmware and complete initialization: After loading the new firmware, TC1 (Flight Attitude Control Core) executes the attitude calculation task, confirms that the function is normal, and sets the shared memory address 0x020 (its corresponding switch completion flag array) to 0x00000001. TC2-TC5 complete the new firmware operation within 80-90 microseconds after receiving the firmware upgrade signal, and set the corresponding switch completion flag arrays 0x024, 0x028, 0x02C, and 0x030 in the shared memory to 0x00000001 respectively.

[0063] The control core TC0 polls the switch completion flag array for addresses 0x01C-0x033 at a frequency of 5 microseconds per poll. On the 18th poll (90 microseconds after signal triggering), it detects that the flag bits for TC1-TC5 are all 0x00000001; the control core TC0 immediately determines that the firmware upgrade switch was successful. If, after 10 milliseconds (the preset timeout), the control core TC0 detects that address 0x028 (the flag array corresponding to TC3) is still 0x00000000, while the flag arrays for other cores are all 0x00000001, it immediately determines that the upgrade failed and triggers the rollback mechanism.

[0064] In one embodiment, after obtaining the firmware upgrade packages for each of the multiple cores, the process further includes: merging the firmware upgrade packages of the multiple cores into a multi-core firmware bundle, wherein the multi-core firmware bundle carries an overall digital signature, an overall integrity check value, and an independent check value corresponding to each core firmware upgrade package; verifying the overall digital signature of the firmware bundle based on a preset public key to obtain an overall digital signature verification result; if the overall digital signature verification passes, verifying the overall integrity check value of the multi-core firmware bundle based on a preset verification algorithm to obtain an overall integrity verification result; if the overall integrity verification passes, extracting the firmware upgrade packages corresponding to each core in the multi-core firmware bundle, and verifying the independent check value of each firmware upgrade package to obtain an independent check result for each core; if the independent checks of all core firmware upgrade packages pass, storing each core firmware upgrade package in a shared cache area; if the overall integrity verification fails or the independent check of any core firmware upgrade package fails, terminating the firmware upgrade process.

[0065] The core of this embodiment is to prioritize "overall digital signature verification" as the primary security verification step, ensuring security and uniqueness through "pre-set public key", and then sequentially performing overall integrity verification and independent verification, forming a three-layer progressive security verification scheme.

[0066] The public key of the firmware publisher (such as an RSA-2048 public key or an ECC-256 public key) is pre-embedded in the secure storage area (such as the HSM hardware security module or the protected Flash area) of the control core (e.g., TC0 of TC397). Once pre-embedded, the public key cannot be modified or read; it can only be accessed through the hardware encryption module of the control core, preventing tampering or leakage. The control core extracts the "overall digital signature" and "signature algorithm identifier" from the multi-core firmware bundle, calls the hardware encryption module to load the pre-embedded public key, performs signature verification according to the specified algorithm, and obtains the overall digital signature verification result.

[0067] After the overall digital signature verification is passed, the control core performs an integrity check on all data in the multi-core firmware bundle to ensure that there is no missing data, tampering, or transmission error in the bundle.

[0068] After the overall integrity verification is passed, the control core parses the main body of the multi-core firmware bundle, extracts the firmware upgrade package corresponding to each core, calculates the data of the extracted single firmware upgrade package and compares it with the attached independent check value to obtain the independent check result of the firmware upgrade package corresponding to each core.

[0069] In one embodiment, after obtaining the firmware upgrade packages for each of the multiple cores, the process further includes: performing a version consistency check on the firmware upgrade packages for the multiple cores and the currently running firmware, wherein the version consistency check includes at least a version compatibility check, a dependency check, and a version number consistency check; if all version consistency checks pass, the firmware upgrade process continues; if any check item in the version consistency check fails, the upgrade is terminated and detailed information of the failed check item is recorded.

[0070] This embodiment further ensures "internal co-compatibility of the new firmware" and "transitional adaptation of the new firmware to the currently running firmware", avoiding multi-core controller malfunctions due to version incompatibility.

[0071] Specifically, the version consistency check includes: version compatibility check, which calls a preset compatibility matrix to check the compatibility between each core firmware upgrade package, as well as the compatibility between the current running firmware version of each core and the corresponding firmware upgrade package version; dependency check, which calls a preset dependency matrix to check whether the functional dependencies and data dependencies between each core firmware upgrade package are correct; and version number consistency check, which checks whether the overall version number of each core firmware bundle meets the system's preset requirements, and also checks whether the version number of each core firmware upgrade package follows a unified version naming convention.

[0072] The compatibility matrix is ​​a two-dimensional table embedded in the control core security storage area (such as OTP). It defines compatibility relationships according to the dimension of "core ID × version number," solving the problem of adaptability judgment between "new firmware" and "old firmware." The dependency matrix is ​​a structured table defining "functional calls and data interactions between cores." It clarifies functional dependencies and data format requirements according to the dimension of "dependent party × dependent party," solving the problem of accurately determining "who depends on whom and what they depend on." The version number consistency check must simultaneously meet "overall version compliance" and "individual version specification," solving the problem of "global version uniformity and standardized naming format."

[0073] In a specific embodiment, taking the multi-core controller TC397 (main core TC0, slave cores TC1-TC5, where TC0 is the control core) as an example, its entire firmware upgrade process is as follows: The first step is to collect and process the firmware image files of all cores (TC0-TC5).

[0074] Specifically, each core firmware image contains: firmware code and firmware header information (version number, build time, checksum, etc.). Then, all firmware images are merged into a multi-core firmware bundle, generating metadata containing the following information: each core firmware version number, a core dependency matrix, a version compatibility matrix, the firmware bundle version number, a build timestamp, and the hash value of each core firmware image. An overall digital signature is generated for this firmware bundle using an asymmetric encryption algorithm (such as RSA-2048 or ECDSA).

[0075] The second step is to verify the firmware bundle.

[0076] Specifically, the control core receives firmware bundles via CAN or Ethernet (DoIP) and stores them in a shared buffer (RAM or Flash temporary area). Then, the control core uses a pre-configured public key to verify the overall digital signature of the firmware bundle. After successful verification of the overall digital signature, the control core calculates the hash value of the firmware bundle and compares it with the hash value stored in the metadata. Based on the comparison result, the overall integrity verification result is determined. After successful overall integrity verification, the integrity of each core firmware image is then verified (using CRC32 or hash values), i.e., independent verification.

[0077] The third step is a version consistency check.

[0078] After the second step of verification is passed, the control core checks whether the firmware versions of each core are compatible with each other according to the compatibility matrix, and checks the compatibility between the current firmware version of each core and the new firmware version; it checks whether the dependencies between the firmware of each core are correct according to the dependency matrix, ensuring that all dependencies meet the requirements; and then checks whether the firmware bundle version number is consistent with the system requirements.

[0079] The fourth step is to switch between multiple cores simultaneously.

[0080] After the above version consistency check passes, the control core switches the readiness flag via shared memory settings. Each core polls shared memory. Upon detecting a switch preparation flag, it enters a switch preparation state and saves its current runtime information to non-volatile memory (such as Flash or EEPROM). Then, each core sets a "ready" flag in shared memory. Once the control core detects all "ready" flags, it sets a hardware synchronization trigger flag. Each core enters a hardware synchronization wait state, awaiting a hardware synchronization signal. The master core triggers the hardware synchronization signal by writing to the SCU (System Control Unit) synchronization register. The hardware synchronization signal reaches all cores simultaneously via the hardware bus, ensuring microsecond-level synchronization accuracy. On the rising edge of the hardware synchronization signal, all cores simultaneously perform the following operations: stop the current task execution, refresh the instruction and data caches, update the program counter (PC) to point to the new firmware entry address, update the interrupt vector table to point to the new firmware interrupt handler, and restore the new firmware's runtime state (from non-volatile memory). After each core completes the switch to the new firmware, it sets a "switch complete" flag in shared memory. Once the control core detects all "switch complete" flags, it confirms a successful switch. If a core fails to set the "switch complete" flag within the timeout period, the master core triggers a rollback mechanism.

[0081] In some embodiments, only the differences between the firmware upgrade package and the current firmware can be transmitted and verified, reducing upgrade time and storage space.

[0082] In some embodiments, this solution is also applicable to drones, aerospace multi-core controllers, and industrial control systems with high security requirements. For larger-scale multi-core systems (such as dozens of cores), in scenarios with a large number of cores, distributed firmware verification can be adopted: the cores are grouped, with each group having a control core; each group's control core verifies the firmware of its own group; the top-level control core verifies the overall signature and inter-group consistency.

[0083] In some embodiments, for a multi-device eVTOL system, blockchain technology can be used to manage firmware versions: the overall digital signature and version information of the firmware bundle are stored on the blockchain; each device obtains firmware version information and verification public key from the blockchain to ensure that all devices use the same version of firmware.

[0084] In one embodiment, a firmware upgrade device is provided, applied to one core of a multi-core controller. For example... Figure 2 As shown, it includes an acquisition module 21, a sending module 22, a receiving module 23, and an upgrade module 24. Detailed descriptions of each functional module are as follows: Module 21 is used to obtain the firmware upgrade packages of each of the multiple cores and store the firmware upgrade packages in a shared cache area; The sending module 22 is used to send a handover preparation signal to each other core. The handover preparation signal is used to indicate that other cores enter the handover preparation state. The receiving module 23 is used to receive the switching ready signal fed back by each other core. The switching ready signal is used to indicate that each other core has saved the current running information. The upgrade module 24 is used to synchronously send firmware upgrade signals to other cores according to the switch ready signal. The firmware upgrade signal is used to instruct other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

[0085] This invention also provides an electronic device, including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the aforementioned firmware upgrade method; to avoid repetition, this will not be described again here. Alternatively, the electronic device can implement the functions of each module in this embodiment of the firmware upgrade device; this will also not be described again here.

[0086] This invention also provides a readable storage medium storing a program that, when executed by a processor, implements the aforementioned firmware upgrade method. To avoid repetition, this will not be described further here. Alternatively, when the program is executed by a processor, it implements the functions of each module in this embodiment of the firmware upgrade device, which will also not be described further here.

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0088] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

Claims

1. A firmware upgrade method, characterized in that, The method, which applies to one core in a multi-core controller and uses that core as the control core, includes: Obtain the firmware upgrade packages for each of the multiple cores and store the firmware upgrade packages in a shared cache area; Send a handover preparation signal to each of the other cores, the handover preparation signal being used to instruct the other cores to enter the handover preparation state; Receive switching ready signals from other cores, the switching ready signals being used to indicate that each other core has saved its current running information; Based on the switch ready signal, a firmware upgrade signal is synchronously sent to each of the other cores. The firmware upgrade signal is used to instruct the other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

2. The firmware upgrade method according to claim 1, characterized in that, The synchronous sending of firmware upgrade signals to the other cores includes: A trigger instruction is written to the synchronization register of the system control unit. The trigger instruction is used to instruct the system control unit to generate the firmware upgrade signal. The firmware upgrade signal is simultaneously transmitted to the other cores through the hardware bus of the multi-core controller.

3. The firmware upgrade method according to claim 1, characterized in that, Sending a handover preparation signal to each of the other cores includes: The switching preparation signal is written to shared memory, so that each other core can obtain the switching preparation signal from the shared memory through a preset status query method.

4. The firmware upgrade method according to claim 1, characterized in that, The method further includes: After receiving the switching preparation signal and entering the switching preparation state, each of the other cores controls the other cores to save the current running information; After all cores have completed the firmware upgrade synchronously, they are instructed to read the current running information and restore the running state before the upgrade.

5. The firmware upgrade method according to claim 1, characterized in that, After synchronously sending firmware upgrade signals to each of the other cores according to the switch-ready signal, the process further includes: After each of the other cores loads and runs the new firmware, it receives the switching completion flag written by each of the other cores in the shared memory of the multi-core controller; The switch completion flags of each of the other cores in the shared memory are detected. After confirming that the switch completion flags have been written to each of the other cores, the firmware upgrade switch is determined to be successful. If the switch completion flags of all other cores are not detected within the preset timeout period, a rollback mechanism is triggered, and each other core is controlled to revert to the firmware version and running state before the upgrade based on the saved current running information.

6. The firmware upgrade method according to claim 1, characterized in that, After obtaining the firmware upgrade packages for each of the multiple cores, the process also includes: The multiple core firmware upgrade packages are merged into a multi-core firmware bundle, which carries an overall digital signature, an overall integrity check value, and an independent check value corresponding to each core firmware upgrade package. The overall digital signature of the firmware bundle is verified based on the preset public key to obtain the overall digital signature verification result; If the overall digital signature verification passes, the overall integrity verification value of the multi-core firmware bundle is verified based on the preset verification algorithm to obtain the overall integrity verification result. If the overall integrity verification passes, extract the firmware upgrade package corresponding to each core in the multi-core firmware bundle, and verify the independent verification value of each firmware upgrade package to obtain the independent verification result of each core. If all core firmware upgrade packages pass independent verification, each core firmware upgrade package is stored in the shared cache. If the overall integrity verification fails or any core firmware upgrade package fails independent verification, the firmware upgrade process is terminated.

7. The firmware upgrade method according to claim 1, characterized in that, After obtaining the firmware upgrade packages for each of the multiple cores, the process also includes: A version consistency check is performed on the firmware upgrade packages of the multiple cores and the currently running firmware. The version consistency check includes at least version compatibility check, dependency check and version number consistency check. If all version consistency checks pass, the firmware upgrade process continues; if any check fails, the upgrade is terminated and detailed information of the failed check is recorded.

8. The firmware upgrade method according to claim 7, characterized in that, The version consistency check specifically includes: Version compatibility check: Calls a preset compatibility matrix to check the compatibility between each core firmware upgrade package, as well as the compatibility between the current firmware version of each core and the corresponding firmware upgrade package version. Dependency check: Invoke the preset dependency matrix to check whether the functional dependencies and data dependencies between each core firmware upgrade package are correct; Version number consistency check: Check whether the overall version number of each core firmware bundle meets the system's preset requirements, and check whether the version number of each core firmware upgrade package follows the unified version naming convention.

9. A firmware upgrade device, characterized in that, A core used in a multi-core controller, serving as the control core, includes: The acquisition module is used to acquire the firmware upgrade packages of each of the multiple cores and store the firmware upgrade packages in a shared cache area; The sending module is used to send a handover preparation signal to each other core, the handover preparation signal being used to instruct the other cores to enter the handover preparation state; The receiving module is used to receive the switching ready signal fed back by each other core, the switching ready signal being used to indicate that each other core has saved its current running information; The upgrade module is used to synchronously send firmware upgrade signals to each of the other cores according to the switch ready signal. The firmware upgrade signal is used to instruct the other cores to load and run the new firmware according to the corresponding firmware upgrade package in the shared cache.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the firmware upgrade method as described in any one of claims 1 to 8.

11. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the firmware upgrade method as described in any one of claims 1 to 8.

Images