Hybrid programming methods, apparatus, equipment, storage media and program products

Abstract

This application discloses a hybrid programming method, apparatus, device, storage medium, and program product, relating to the field of embedded system programming technology. The hybrid programming method includes: acquiring a trigger signal and parsing the trigger signal according to a preset priority rule to obtain an initial startup intent; performing a self-check on the chip's system status using an intelligent diagnostic engine to obtain a system health report; programming the target startup mode of the chip based on the system health report and the initial startup intent; and programming the bootloader corresponding to the target startup mode. By parsing the trigger signal using a preset priority rule, an initial startup intent is determined from multiple possible startup sources. This allows startup to no longer rely on a single hardware pin and can respond to signals from multiple sources such as remote commands and timed events. Simultaneously, the priority rule avoids multi-source conflicts, ensuring that the system executes the most reasonable startup intent according to its importance, thus improving the flexibility and controllability of startup.

Description

Technical Field

[0001] This application relates to the field of embedded system programming technology, and in particular to hybrid programming methods, apparatus, devices, storage media and program products. Background Technology

[0002] In the field of embedded system programming, In-System Programming (ISP) and In-Application Programming (IAP) are two commonly used techniques. ISP technology controls startup through specific physical pins of the chip (such as BOOT0). When the pin is at a specific level, the chip boots from the manufacturer's pre-configured SystemFlash area after power-on and receives external firmware through interfaces such as UART to complete the programming. When the pin is at the opposite level, the chip starts and executes the application program from the user program area. IAP mode allows the application program to receive firmware data and update itself during runtime.

[0003] However, traditional ISP flashing can only be triggered by specific hardware levels, which cannot meet the boot requirements of remote upgrades or complex scenarios. While conventional IAP solutions support on-the-go upgrades, Flash partitions are mostly fixed. Once the size and address of the IAP area and APP area are set, they cannot be adjusted. When firmware version iterations cause changes in program size, problems such as insufficient partition space or wasted resources can easily occur. Summary of the Invention

[0004] The main purpose of this application is to provide a hybrid programming method, apparatus, device, storage medium, and program product, which aims to solve the technical problem that existing programming systems using a single programming technology cannot meet the boot requirements in complex scenarios.

[0005] To achieve the above objectives, this application proposes a hybrid programming method, which includes: The method is applied to chips pre-loaded with a three-stage bootloader consisting of ISP Boot, IAP Boot, and Recovery Boot. The method includes: Collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to start; The system status of the chip is self-checked by the intelligent diagnostic engine to obtain a system health report; The target boot mode of the chip is determined based on the system health report and the initial boot intent. Start the bootloader corresponding to the target boot mode for burning.

[0006] In one embodiment, the step of parsing the trigger signal according to a preset priority rule to obtain the initial intent to be started includes: According to a preset priority rule, the trigger signal with the highest priority is selected as the target trigger signal from the trigger signals. The initial intention to be started is determined based on the trigger source of the target trigger signal.

[0007] In one embodiment, the step of performing a self-check on the system status of the chip using an intelligent diagnostic engine to obtain a system health report includes: The intelligent diagnostic engine performs a self-test on the bootloader area and application area of ​​the chip to obtain the self-test verification value. The self-test result is obtained by comparing the self-test verification value with the preset threshold. A system health report is generated based on the self-test results.

[0008] In one embodiment, the step of determining the target boot mode of the chip based on the system health report and the initial boot intent includes: When the system health report indicates that the system is normal, the target boot mode of the chip is determined to be the boot mode corresponding to the initial boot intent; When the system health report indicates a system abnormality, the target boot mode of the chip is determined to be an abnormal boot mode.

[0009] In one embodiment, the step of starting the bootloader corresponding to the target boot mode for burning includes: When the bootloader corresponding to the target boot mode is ISP Boot, start ISP Boot and receive firmware data sent by the host computer; The firmware data is burned into the application area, and the firmware integrity is verified by the intelligent diagnostic engine when the burning is completed.

[0010] In one embodiment, the step of starting the bootloader corresponding to the target boot mode for burning further includes: When the bootloader corresponding to the target boot mode is IAP Boot, IAP Boot is started and firmware data sent by the host computer is received; Burn the firmware data to the backup area; The firmware data in the backup area is verified, and if the verification is successful, the firmware data in the backup area is overwritten into the application area.

[0011] Furthermore, to achieve the above objectives, this application also proposes a hybrid programming apparatus, the hybrid programming apparatus comprising: The trigger processing module is used to collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to be started; The self-test module is used to perform a self-test on the system status of the chip through an intelligent diagnostic engine and obtain a system health report; A startup determination module is used to determine the target startup mode of the chip based on the system health report and the initial startup intent. The burning module is used to start the bootloader corresponding to the target boot mode for burning.

[0012] In addition, to achieve the above objectives, this application also proposes a hybrid programming device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the hybrid programming method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the hybrid programming method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the hybrid programming method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application utilizes a chip pre-installed with a three-stage bootloader system comprising ISP Boot, IAP Boot, and Recovery Boot. This system acquires trigger signals and performs trigger source parsing based on preset priority rules to obtain the initial boot intent. An intelligent diagnostic engine performs a self-check of the chip's system status to generate a system health report. Based on the system health report and the initial boot intent, the chip targets its boot mode and then programs the corresponding bootloader for that boot mode. Because the chip integrates three independent bootloaders, corresponding to In-System Programming (ISP), In-Application Programming (IAP), and Recovery functions, this three-stage design allows the chip to select the most suitable boot method for different usage scenarios (such as initial programming, in-service upgrades, and firmware corruption recovery), laying the hardware foundation for subsequent multi-mode booting and enhancing the system's adaptability to various scenarios. By parsing the trigger signal through preset priority rules, an initial startup intent is determined from multiple possible startup sources. This makes startup no longer dependent on a single hardware pin and can respond to signals from multiple sources such as remote commands and timed events. At the same time, the priority rules avoid conflicts between multiple sources and ensure that the system executes the most reasonable startup intent according to its importance, significantly improving the flexibility and controllability of startup. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the hybrid programming method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the hybrid programming method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the hybrid programming method of this application; Figure 4 This is a schematic diagram of the module structure of the hybrid programming device according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the hybrid programming method in this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: to collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to start; to perform self-check on the system status of the chip through an intelligent diagnostic engine to obtain a system health report; to start the target startup mode of the chip according to the system health report and the initial startup intention; and to start the bootloader corresponding to the target startup mode for burning.

[0023] This application provides a solution that, through a three-stage bootloader design rather than the traditional single-stage design, can simultaneously meet the needs of ISP remote upgrades, IAP in-process upgrades, and abnormal recovery. The three independent bootloaders in this application can achieve functional isolation, preventing the entire system from being paralyzed due to the failure of a single module. The independent existence of Recovery Boot is the key to ensuring that the system does not become "bricked" when firmware malfunctions.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, a microchip, or an electronic device or virtual device capable of performing the above functions. The following description uses a hybrid programming device (hereinafter referred to as a programming device) as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, this application provides a hybrid programming method. This hybrid programming method is applied to chips pre-loaded with a three-stage bootloader consisting of ISP Boot, IAP Boot, and Recovery Boot. (Refer to...) Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the hybrid programming method of this application.

[0026] In this embodiment, the hybrid programming method includes steps S10 to S40: Step S10: Collect the trigger signal and perform trigger source parsing on the trigger signal according to the preset priority rules to obtain the initial intention to start.

[0027] It should be noted that the burning device in this application embodiment may be equipped with a three-stage bootloader (three-stage bootloader module). Specifically, the three-stage bootloader may include an ISP Boot module, an IAP Boot module, and a Recovery Boot module.

[0028] It should be explained that the aforementioned ISP Boot module relies on the original manufacturer's BootLoader and can perform firmware upgrades via the USART1 interface. After the ISP Boot module is triggered, it can boot from the chip's System Flash. The aforementioned IAP Boot module can receive data from the host computer via the USART2 interface and supports application (APP) updates during the chip's system operation. The Recovery Boot module is dedicated to abnormal recovery; it can automatically start when the intelligent diagnostic engine detects corrupted APP firmware and reads normal firmware from the backup area to restore the system. The three-stage bootloader achieves flexible switching through internal jump instructions; before jumping, the integrity of the target module is verified by the diagnostic engine.

[0029] It should be noted that the aforementioned trigger signal is a signal composed of input events or states that can cause a change in the system startup mode. In this embodiment, a multi-startup-source triggering module may be provided, and trigger source parsing of the trigger signal may be implemented based on the multi-startup-source triggering mechanism. Specifically, after the system is powered on, the multi-startup-source triggering module may prioritize the acquisition of trigger signals and perform trigger source parsing on the trigger signals according to a preset priority to determine the initial startup intent corresponding to the trigger signal.

[0030] It is understood that the above-mentioned preset priorities can be set according to the needs of actual applications. In some embodiments of this application, the preset priorities from largest to smallest can be: abnormal recovery signal > remote command > local button > pin level > timer event > EEPROM configuration. For example, when a network remote programming command is detected, ISP Boot is directly triggered; when an RTC alarm event is triggered, IAP Boot is started to perform timed upgrades; when the BOOT0 pin (PF4-BOOT0) is connected to a high level, ISP Boot is triggered to upgrade via USART1; when a GPIO combination button (such as GPIO1+GPIO2 pressed simultaneously) is triggered, Recovery Boot is started. Among them, the external EEPROM configuration word can be preset with a default boot mode, which is suitable for unified configuration in mass production scenarios.

[0031] It should be understood that the aforementioned intent to be started can be used to characterize the bootloader to be started corresponding to the trigger signal. For example, a network remote burning command corresponds to ISP Boot, and an RTC alarm event corresponds to IAP Boot. The specific correspondence between the bootloader and the trigger signal can be set according to the actual application, and the embodiments of this application do not limit this.

[0032] For example, the trigger source type corresponding to the BOOT0 pin level signal is a hardware pin, which usually originates from PF4-BOOT0; the trigger source type corresponding to the GPIO combination button state is a hardware pin, which usually originates from general-purpose input / output pins such as GPIO1 and GPIO2; the trigger source type corresponding to the external EEPROM configuration word is external storage, which is usually obtained through an external EEPROM memory connected via an interface such as I2C; the trigger source type corresponding to the RTC alarm clock event flag is an internal peripheral, which is usually obtained through the chip's internal real-time clock module; the trigger source type corresponding to the network remote command is the communication interface, which is usually determined by the data packets received through the Ethernet interface; and the trigger source type corresponding to the USART command is the communication interface, which is usually determined by the data received through the USART1 and USART2 interfaces.

[0033] It is understood that the embodiments of this application break through the limitation of single pin control through the multi-start source triggering mechanism, and support multi-source triggering such as BOOT0 pin, GPIO combination button, external EEPROM configuration word, RTC alarm clock event, network remote command, etc., and can flexibly switch the start path according to the actual scenario.

[0034] In its specific implementation, the programming device of this application embodiment can collect trigger signals, filter the trigger signals according to preset priority rules, and then parse them to obtain the corresponding initial intention to be started. Because it uses a multi-startup-source triggering mechanism, it supports multi-source triggering, improving the flexibility of startup path switching.

[0035] Step S20: The system status of the chip is self-checked by the intelligent diagnostic engine to obtain a system health report; Step S30: Determine the target boot mode of the chip based on the system health report and the initial boot intent; Step S40: Start the bootloader corresponding to the target boot mode for burning.

[0036] It should be noted that the intelligent diagnostic engine in this embodiment can be an engine for automatically detecting the system status of the chip itself. Through the intelligent diagnostic engine, self-testing during the chip startup phase can be achieved, enabling a comprehensive detection of the system status upon power-up, automatically matching the optimal startup and programming mode, and providing a basis for subsequent startup decisions. By performing a self-test on the chip's system status, a system health report can be obtained to determine the health of the system.

[0037] It is understood that different boot modes may be provided in this application embodiment corresponding to different bootloaders. Specifically, the ISP mode corresponds to the bootloader ISP Boot, the IAP mode corresponds to the bootloader IAP Boot, and the Recovery mode corresponds to the bootloader Recovery Boot. In embedded systems, the selection of the boot mode directly determines whether the device can normally enter the working state or complete the upgrade task. This application determines the final boot mode based on the health report and the initial boot intent, avoiding the forced execution of erroneous intents when the system is abnormal; at the same time, it achieves limited fault protection and avoids conflicts that may occur when multiple trigger sources exist simultaneously.

[0038] It should be understood that once the target boot mode is determined, the corresponding bootloader can be started to acquire firmware data and complete the burning process.

[0039] This application utilizes a chip pre-installed with a three-stage bootloader system comprising ISP Boot, IAP Boot, and Recovery Boot. This system acquires trigger signals and performs trigger source parsing based on preset priority rules to obtain the initial boot intent. An intelligent diagnostic engine performs a self-check of the chip's system status to generate a system health report. Based on the system health report and the initial boot intent, the chip targets its boot mode and then programs the corresponding bootloader for that boot mode. Because the chip integrates three independent bootloaders, corresponding to In-System Programming (ISP), In-Application Programming (IAP), and Recovery functions, this three-stage design allows the chip to select the most suitable boot method for different usage scenarios (such as initial programming, in-service upgrades, and firmware corruption recovery), laying the hardware foundation for subsequent multi-mode booting and enhancing the system's adaptability to various scenarios. By parsing the trigger signal through preset priority rules, an initial startup intent is determined from multiple possible startup sources. This makes startup no longer dependent on a single hardware pin and can respond to signals from multiple sources such as remote commands and timed events. At the same time, the priority rules avoid conflicts between multiple sources and ensure that the system executes the most reasonable startup intent according to its importance, significantly improving the flexibility and controllability of startup.

[0040] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating Embodiment 2 of the hybrid programming method of this application.

[0041] like Figure 2 As shown in this embodiment, the step of parsing the trigger signal according to a preset priority rule to obtain the initial intent to be started includes: Step S11: Select the trigger signal with the highest priority from the trigger signals as the target trigger signal according to the preset priority rules; Step S12: Determine the initial intention to be started based on the trigger source of the target trigger signal.

[0042] It should be noted that, in this embodiment of the application, a priority mapping table with preset priorities may be provided. The trigger source corresponding to the trigger signal and the priority corresponding to the trigger source can be determined through the priority mapping table.

[0043] It is understandable that when multiple trigger signals are detected at the same time, the trigger signal with the highest priority can be used as the target trigger signal, and the start mode to be selected can be determined according to the trigger source of the target trigger signal, that is, the initial start intention can be determined.

[0044] For example, consider the following scenario: The device is scheduled to perform a firmware update at 3 AM daily (intended IAP Boot); at 2:55 AM, maintenance personnel send an emergency upgrade command via the cloud, but due to network latency, the command data packet is received by the device at 3:00:01 AM (intended ISP Boot); a field engineer happens to be debugging at 3 AM and presses the GPIO1+GPIO2 combination button (intended Recovery Boot). At this time, the flashing device can receive three valid trigger signals due to the above three events. According to the priority mapping table, the abnormal recovery signal corresponding to the GPIO1+GPIO2 combination button has the highest priority. Therefore, the abnormal recovery signal can be used as the target trigger signal, and the initial boot intent is determined to be to initiate Recovery Boot.

[0045] In some embodiments of this application, the intelligent diagnostic engine can generate a system health report containing the status of each module in the system after diagnosis. If there are abnormal items, the system health report can be identified as a system abnormality; if there are no abnormal items, the system health report can be identified as a normal system. That is, the step of determining the target startup mode of the chip based on the system health report and the initial startup intention includes: when the system health report indicates a normal system, determining the target startup mode of the chip as the startup mode corresponding to the initial startup intention; when the system health report indicates a system abnormality, determining the target startup mode of the chip as an abnormal startup mode.

[0046] It should be noted that the solution proposed in this application allows for direct entry into abnormal boot mode upon detection of an anomaly. At this point, Recovery Boot can be initiated directly, enabling recovery from backup or other methods to repair the system, ensuring system availability and reducing on-site maintenance costs.

[0047] For example, electromagnetic interference or voltage fluctuations during device operation can cause partial data in the APP area stored in Flash to be overwritten; or malicious programs may modify the firmware content. After power-on, the CRC self-test module verifies the APP area. If the calculated result is inconsistent with the preset CRC value burned at the factory, an anomaly is detected. At this time, an abnormal boot mode can be entered and Recovery Boot can be automatically started to restore normal firmware from the backup area.

[0048] For example, an unexpected power outage during an upgrade process might corrupt the Bootloader area. Upon power-up, a CRC check of the Bootloader area will fail, indicating an anomaly. In this case, an abnormal boot mode can be entered, and Recovery Boot will automatically start. Since the system may not be able to recover automatically in this situation, recovery can be achieved through external intervention (such as ISP flashing).

[0049] This application embodiment selects the highest priority trigger signal from among the trigger signals as the target trigger signal according to a preset priority rule; the initial startup intent is determined based on the trigger source of the target trigger signal. Because priority management is used, decision-making confusion caused by multi-source signal conflicts is avoided, ensuring that the system always executes the most critical startup requirements according to the preset importance (such as abnormal recovery taking precedence over remote upgrades, and remote upgrades taking precedence over local timed upgrades), thereby improving the orderliness and determinism of the startup process.

[0050] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and / or second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3, Figure 3 This is a flowchart illustrating Embodiment 3 of the hybrid programming method of this application.

[0051] like Figure 3 As shown in this embodiment, the step of performing a self-check on the system status of the chip using an intelligent diagnostic engine to obtain a system health report includes: Step S21: Perform a self-test on the bootloader area and application area of ​​the chip using the intelligent diagnostic engine to obtain the self-test verification value; Step S22: Compare the self-test verification value with the preset threshold to obtain the self-test result; Step S23: Generate a system health report based on the self-test results.

[0052] It should be noted that the aforementioned bootloader area is a storage area used to store bootloader programs. In this embodiment, a three-stage bootloader (i.e., ISP Boot, IAPBoot, and Recovery Boot) is pre-installed in the bootloader area. The aforementioned application area is a storage area used to store user applications, which may include firmware data used to enable application execution.

[0053] For example, the storage area described above in this application embodiment is Flash storage. The internal Flash storage of the chip in this application embodiment can be divided into a bootloader area, a dynamically configurable IAP area, an APP area, a backup area (for firmware backup and abnormal recovery), and a log area (for storing diagnostic reports and burning records).

[0054] In some embodiments of this application, external communication with a host computer and multiple devices can be achieved through interfaces such as USART1, USART2, USB, and Ethernet. The hardware includes triggering components such as BOOT0 pin, GPIO combination buttons, and RTC clock.

[0055] In some embodiments of this application, the self-test method may include integrity self-testing. The intelligent diagnostic engine may include a Cyclic Redundancy Check (CRC) module. This CRC self-testing module can perform integrity checks on the three-segment bootloader stored in the bootloader area and the firmware data in the application area. Specifically, the CRC self-testing module of this application embodiment can run a CRC check algorithm on the data stored in a specified area, calculate a self-test check value, and compare this self-test check value with a preset threshold to obtain the integrity self-test result.

[0056] For example, the CRC self-test module can run a CRC check algorithm on the three-segment bootloader stored in the bootloader area to obtain a first check value; compare the first check value with a first preset threshold used to determine whether the three-segment bootloader is complete; if they are inconsistent, the three-segment bootloader is determined to be incomplete and the self-test result is determined to be failed; if they are consistent, the three-segment bootloader is determined to be complete and the self-test result is determined to be passed.

[0057] For example, the CRC self-test module can run a CRC check algorithm on the firmware data stored in the application area to obtain a second check value; compare the second check value with a second preset threshold used to determine whether the firmware data is normal; if they are inconsistent, the firmware data is determined to be incomplete; if they are consistent, the firmware data is determined to be complete.

[0058] In some embodiments of this application, the self-test may also include a stack overflow self-test. The intelligent diagnostic engine may also include a stack overflow detection module, which calculates the remaining space and compares it with a threshold by reading the stack pointer and the stack bottom address, thereby determining the stack overflow self-test result and avoiding stack overflow risks.

[0059] In some embodiments of this application, the self-test may also include a memory mapping self-test. The intelligent diagnostic engine may also include a memory mapping verification module, which can check whether the memory address mapping table is consistent with a preset value, thereby determining the memory mapping self-test result and preventing memory corruption.

[0060] In some embodiments of this application, the self-test method may further include peripheral communication self-test. The intelligent diagnostic engine may also include a peripheral communication test module, which can sequentially detect the communication status of interfaces such as USART1, USART2, USB, and Ethernet, send test frames and verify responses, thereby determining the peripheral communication self-test result.

[0061] It should be noted that, based on the self-test results of each test item in the embodiments of this application, a system health report can be generated. If any item fails the self-test, the system health report can be considered as a system abnormality.

[0062] In some embodiments of this application, the step of starting the bootloader corresponding to the target boot mode for flashing includes: when the bootloader corresponding to the target boot mode is ISP Boot, starting the ISP Boot and receiving firmware data sent by the host computer; flashing the firmware data to the application area, and verifying firmware integrity through the intelligent diagnostic engine when flashing is complete.

[0063] For example, the ISP mode in this embodiment can be triggered by a high level on the BOOT0 pin, a network remote command, etc. After the ISP mode is triggered, the corresponding bootloader ISP Boot can be started. In this case, the chip can load the bootloader from the System Flash and establish communication with the host computer through the USART1 interface to receive firmware data sent by the host computer. The bootloader ISP Boot can write the firmware data into the application area and perform firmware integrity verification through the intelligent diagnostic engine when the writing is complete. When the firmware integrity verification passes, it can jump to the hardware program area to run. In ISP mode, the UART / USB / Ethernet remote command line interface can be opened to support firmware upload, log download, register read and write, and real-time debugging.

[0064] In some embodiments of this application, the step of starting the bootloader corresponding to the target boot mode for burning further includes: when the bootloader corresponding to the target boot mode is IAP Boot, starting IAP Boot and receiving firmware data sent by the host computer; burning the firmware data to the backup area; verifying the firmware data in the backup area, and overwriting the firmware data in the backup area to the application area when the verification is successful.

[0065] For example, in this embodiment, the IAP mode can receive commands from the host computer or be triggered by an RTC alarm event via the USART2 interface. After the IAP mode is triggered, the corresponding bootloader IAP Boot can be started. In this case, the system still maintains some functional operation. The Flash memory is divided into an IAP area (0x08000000-0x08000FFF) and an APP area (0x08001000-0x0800FFFF) by default. After receiving the firmware data sent by the host computer, IAP Boot first writes it to the backup area, and after verifying that it is correct, it overwrites the APP area to avoid firmware corruption caused by upgrade interruption. After the upgrade is completed, it can jump to the new APP program to run without restarting, realizing "upgrade during operation".

[0066] In some embodiments of this application, dynamic management of Flash partitions can also be performed. Specifically, during system initialization, external EEPROM configuration words or host computer instructions can be read to determine the parameters of each partition. When the firmware size increases, the address range of the APP area can be adjusted to 0x08001000-0x0801FFFF by sending instructions from the host computer, while the size of the log area is reduced; when it is necessary to add a backup area to store multiple firmware versions, the backup area can be expanded to 0x08020000-0x0803FFFF. During partition adjustment, the system will first migrate the original data to a temporary storage area to avoid data loss, and after the adjustment is completed, the validity of the partition is verified by the memory mapping verification module. That is, the method further includes: reading external EEPROM configuration words or host computer instructions, and determining partition parameters for each partition based on the external EEPROM configuration words or host computer instructions; when the firmware size increases, adjusting the address range of the application area from a first range (e.g., 0x08001000-0x0800FFFF) to a second range (e.g., 0x08020000-0x0803FFFF), and reducing the log area size. When a backup area increase request is received, expanding the address range of the backup area.

[0067] In some embodiments of this application, multi-device collaborative flashing is also supported. Specifically, the host can establish communication with multiple slave devices through a HUB (for UART / USB interface devices) or a switch (for Ethernet interface devices). The host sends broadcast commands to complete device networking and address allocation. During flashing, the host can first send pre-diagnostic commands to all slave devices, allowing only devices that pass the diagnosis to enter flashing mode. Subsequently, firmware data is sent in batches, and flashing progress feedback from each device is received in real time. When a slave device encounters a verification error, the device is automatically paused and a repair command is sent, while other devices continue flashing. After the repair is completed, the progress is synchronized to ensure overall flashing efficiency.

[0068] This embodiment of the application uses an intelligent diagnostic engine to perform self-tests on the chip's bootloader area and application area, obtaining self-test verification values. These values ​​are then compared with preset thresholds to obtain self-test results. A system health report is generated based on these results. Because the self-test is performed on the chip's bootloader area and application area, it provides an objective basis for subsequent assessments of its integrity and stability, avoiding the risks associated with blindly trusting firmware. Generating a system health report not only provides direct evidence for current boot decisions (such as whether to enter recovery mode), but also allows the report to be stored in the log area for later development debugging, fault analysis, or remote maintenance, helping to quickly locate the root cause of problems and improve maintenance efficiency. It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the hybrid programming method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0069] This application also provides a hybrid programming apparatus; please refer to [reference needed]. Figure 4 , Figure 4 This is a schematic diagram of the module structure of the hybrid programming device according to an embodiment of this application. The hybrid programming device includes: The trigger processing module 10 is used to collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to be started; The self-test module 20 is used to perform a self-test on the system status of the chip through the intelligent diagnostic engine and obtain a system health report; The startup determination module 30 is used to determine the target startup mode of the chip based on the system health report and the initial startup intent. The burning module 40 is used to start the bootloader corresponding to the target boot mode for burning.

[0070] The hybrid programming device provided in this application, employing the hybrid programming method described in the above embodiments, can solve the technical problem that existing programming systems, using a single programming technology, cannot meet the startup requirements in complex scenarios. Compared with the prior art, the beneficial effects of the hybrid programming device provided in this application are the same as those of the hybrid programming method provided in the above embodiments, and other technical features in the hybrid programming device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0071] This application provides a hybrid programming device, 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 hybrid programming method in the above embodiment 1.

[0072] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a hybrid programming device suitable for implementing embodiments of this application. The hybrid programming device in these embodiments 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 hybrid programming 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.

[0073] like Figure 5 As shown, the hybrid programming device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the hybrid programming device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the hybrid programming device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows hybrid programming devices 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.

[0074] 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 ROM 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.

[0075] The hybrid programming device provided in this application, employing the hybrid programming method described in the above embodiments, can solve the technical problem that existing programming systems using a single programming technology cannot meet the startup requirements in complex scenarios. Compared with the prior art, the beneficial effects of the hybrid programming device provided in this application are the same as those of the hybrid programming method provided in the above embodiments, and other technical features of this hybrid programming device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0076] 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.

[0077] 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.

[0078] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the hybrid burning method in the above embodiments.

[0079] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0080] The aforementioned computer-readable storage medium may be included in the hybrid programming device; or it may exist independently and not assembled into the hybrid programming device.

[0081] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the hybrid programming device, cause the hybrid programming device to: Collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to start; The system status of the chip is self-checked by the intelligent diagnostic engine to obtain a system health report; The target boot mode of the chip is determined based on the system health report and the initial boot intent. Start the bootloader corresponding to the target boot mode for burning.

[0082] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0083] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0084] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0085] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described hybrid programming method. This solves the technical problem that existing programming systems, employing a single programming technology, cannot meet the startup requirements in complex scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the hybrid programming method provided in the above embodiments, and will not be elaborated upon here.

[0086] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the hybrid programming method described above.

[0087] The computer program product provided in this application can solve the technical problem that existing burning systems, which use a single burning technology, cannot meet the boot requirements in complex scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the hybrid burning method provided in the above embodiments, and will not be repeated here.

[0088] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A hybrid programming method, characterized in that, The method is applied to chips pre-loaded with a three-stage bootloader consisting of ISP Boot, IAP Boot, and Recovery Boot. The method includes: Collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to start; The system status of the chip is self-checked by the intelligent diagnostic engine to obtain a system health report; The target boot mode of the chip is determined based on the system health report and the initial boot intent. Start the bootloader corresponding to the target boot mode for burning.

2. The hybrid programming method as described in claim 1, characterized in that, The step of parsing the trigger signal according to a preset priority rule to obtain the initial intent to be started includes: According to a preset priority rule, the trigger signal with the highest priority is selected as the target trigger signal from the trigger signals. The initial intention to be started is determined based on the trigger source of the target trigger signal.

3. The hybrid programming method as described in claim 1, characterized in that, The step of performing a self-check on the system status of the chip using an intelligent diagnostic engine to obtain a system health report includes: The intelligent diagnostic engine performs a self-test on the bootloader area and application area of ​​the chip to obtain the self-test verification value. The self-test result is obtained by comparing the self-test verification value with the preset threshold. A system health report is generated based on the self-test results.

4. The hybrid programming method as described in claim 1, characterized in that, The step of determining the target boot mode of the chip based on the system health report and the initial boot intent includes: When the system health report indicates that the system is normal, the target boot mode of the chip is determined to be the boot mode corresponding to the initial boot intent; When the system health report indicates a system abnormality, the target boot mode of the chip is determined to be an abnormal boot mode.

5. The hybrid programming method as described in claim 3, characterized in that, The step of starting the bootloader corresponding to the target boot mode for burning includes: When the bootloader corresponding to the target boot mode is ISP Boot, start ISP Boot and receive firmware data sent by the host computer; The firmware data is burned into the application area, and the firmware integrity is verified by the intelligent diagnostic engine when the burning is completed.

6. The hybrid programming method as described in claim 3, characterized in that, The step of starting the bootloader corresponding to the target boot mode for burning also includes: When the bootloader corresponding to the target boot mode is IAP Boot, IAP Boot is started and firmware data sent by the host computer is received; Burn the firmware data to the backup area; The firmware data in the backup area is verified, and if the verification is successful, the firmware data in the backup area is overwritten into the application area.

7. A hybrid programming apparatus, characterized in that, The apparatus is used to implement the hybrid programming method as described in any one of claims 1-6, and the hybrid programming apparatus includes: The trigger processing module is used to collect trigger signals and perform trigger source parsing on the trigger signals according to preset priority rules to obtain the initial intention to be started; The self-test module is used to perform a self-test on the system status of the chip through an intelligent diagnostic engine and obtain a system health report; A startup determination module is used to determine the target startup mode of the chip based on the system health report and the initial startup intent. The burning module is used to start the bootloader corresponding to the target boot mode for burning.

8. A hybrid programming device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the hybrid programming method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the hybrid programming method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the hybrid programming method as described in any one of claims 1 to 6.

Images