Design method and system for boot startup update based on I2C protocol

Abstract

The application relates to the field of computer system structure, and discloses a design method and system for BOOT starting update based on an I2C protocol, which comprises the following steps: an MCU initializes a watchdog, reads starting configuration BS[1:0], and divides different starting processing branches according to the value of BS[1:0]; if an I2C firmware update branch is entered, the I2C peripheral is initialized, receiving timeout timing is started, and firmware data issued by an upper computer in a three-section frame structure is received; after each section of data is received, independent verification is performed, the MCU switches the I2C transceiving mode to feed back the verification result to the host computer, if the verification fails, the process returns to the stage of waiting for receiving a frame header, and after all the segmented verification passes, the newly received application program is run; if a Flash direct starting branch is entered, internal configuration parameters of the Flash are read and verified; if the verification is qualified, the application program solidified in the Flash is executed, if the verification is unqualified, the I2C firmware update branch is entered, and the host computer is waited for issuing firmware to complete program update. The application improves the reliability of BOOT program upgrading and device starting and running.

Description

Technical Field

[0001] This invention relates to the field of computer system architecture, specifically to a design method and system for BOOT startup and update based on the I2C protocol. Background Technology

[0002] The BOOT program is the core program for embedded SoCs and MCUs to achieve power-on startup and firmware iteration. Current embedded SoC BOOT programs mainly include two operating modes, which represent the mainstream application solutions in the industry.

[0003] One is the power-on firmware startup mode, which automatically runs the BOOT program after the chip is powered on and reset. The pre-programmed application in the non-volatile memory is loaded into the program execution area and runs. It features stable startup and no external intervention required, making it suitable for conventional embedded scenarios.

[0004] The second is the online upgrade mode, which relies on conventional communication interfaces such as UART, CAN, and Ethernet to receive external firmware data, complete the erasure, burning, and restart of the device application, and realize the functional optimization and fault repair of the device after leaving the factory, meeting the firmware iteration requirements.

[0005] However, existing technologies have significant limitations. Some small-package, low-pin-count MCUs and dedicated chips, due to pin resource constraints, cannot connect to external peripherals such as parallel buses, SPI Flash, or support conventional upgrade interfaces such as UART and Ethernet. These chips can only achieve external data interaction using the I2C interface, which occupies very few pins, while existing boot programs generally do not support firmware upgrade functions based on I2C.

[0006] Currently, these low-pin chips can only be programmed once at the factory, making it impossible to upgrade firmware online later. This hinders functional iteration and vulnerability patching, severely limiting the chip's application scenarios and lifespan. Summary of the Invention

[0007] In order to overcome the shortcomings of the existing technology, the purpose of this invention is to provide a design method and system for booting and updating based on the I2C protocol, so as to solve the technical problem that low-pin chips cannot achieve online firmware upgrades through the I2C interface.

[0008] This invention is achieved through the following technical solution: In a first aspect, the present invention provides a design method for BOOT startup and update based on the I2C protocol, comprising: Step 1: The MCU initializes the watchdog timer, reads the boot configuration BS[1:0], and divides different boot processing branches according to the value of BS[1:0]. Step 2: If the I2C firmware update branch is entered, the I2C peripheral is initialized, the receive timeout is enabled, and the firmware data sent by the host computer in a three-segment frame structure is received. After each segment of data is received, the verification is performed independently. The MCU switches the I2C transmit and receive mode to send the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. Step 3: If the Flash direct startup branch is entered, the internal configuration parameters of the Flash are read and verified. If the verification is successful, the program embedded in the Flash is executed. If the verification fails, the program is transferred to the I2C firmware update branch and waits for the host computer to send firmware to complete the program update.

[0009] Preferably, the configuration parameter BS[1:0] in step 1 includes three types of value branches: The first type of value corresponds to I2C upgrade, which involves first reading the Flash configuration and then performing the I2C upgrade. The second type of value corresponds to the Flash direct startup branch; The third type of value corresponds to the MCU first completing the watchdog initialization, and then reading BS [1:0] to complete the startup path splitting.

[0010] Preferably, the three-segment frame structure in step 2 specifically includes three segments of data, as follows: The first segment is the frame header, which includes a three-byte sequence code and a single-byte frame header checksum; The second segment contains the program code length, the starting address of storage, and the single-byte address checksum. The third segment consists of the application's binary code and a single-byte program data checksum. During the data transmission phase, the host computer acts as an I2C master to send data, and the MCU receives data as an I2C slave.

[0011] Furthermore, after each data segment in the three-segment frame is received and stored in the storage space, the MCU calculates the local checksum and compares it with the checksum attached to the host; the MCU configures the I2C slave to transmit mode and feeds back the checksum result to the I2C host; if the check fails, it waits to receive the frame header again, and receives the next data segment after the check passes.

[0012] Furthermore, in step 2, while initializing the I2C peripheral, a receive timer is started, and a receive timeout threshold of 50ms or 100ms is set; if no valid I2C command is received within the timeout period, the configuration information of the corresponding address in the Flash is read to perform verification.

[0013] Furthermore, when the Flash configuration information verification obtains the preset characteristic value 0xAA55AF01, the MCU returns an acknowledgment to the host computer, disables the watchdog timer, and jumps to the preset starting address of the Flash to run the original application program; if the configuration information does not match, it returns the corresponding error code to the host computer and waits for the I2C instruction again.

[0014] Preferably, after the frame header verification passes in step 2, the MCU returns a first type of response signal to the host computer, reinitializes the I2C and watchdog, and waits to receive address and length-related data; after the address verification passes, it returns a response signal to the host computer again and waits to receive program code data.

[0015] Furthermore, after all program code verifications pass, the MCU returns a final response to the host computer, disables the watchdog timer, and jumps to the corresponding starting address in SRAM to execute the application program that has completed receiving.

[0016] Preferably, if the Flash configuration verification fails in step 3, the entire set of logical receiving firmware from step 2, including I2C reception, segmented verification, and verification feedback, is reused. Once the firmware verification is successful, the process jumps to execute the new version of the application.

[0017] Secondly, the present invention also provides a design system for BOOT updates based on the I2C protocol, comprising: The startup branch module is used to initialize the MCU watchdog, read the startup configuration BS[1:0], and divide different startup processing branches according to the value of BS[1:0]. The I2C upgrade module is used to initialize the I2C peripheral, enable the receive timeout, and receive firmware data sent by the host computer in a three-segment frame structure if the I2C firmware update branch is entered. After each segment of data is received, it performs verification independently. The MCU switches the I2C transmit and receive mode and sends the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. The Flash boot module is used to read and verify the internal configuration parameters of the Flash if the Flash direct boot branch is entered. If the verification is successful, the program embedded in the Flash will be executed. If the verification fails, the program will be transferred to the I2C firmware update branch and wait for the host computer to send firmware to complete the program update.

[0018] Compared with the prior art, the present invention has the following beneficial technical effects: This invention provides a design method for booting and updating based on the I2C protocol. It designs a proprietary three-segment data frame format based on the general I2C protocol, allowing flexible configuration of firmware data transmission length and program storage start address. This breaks through the limitations of traditional boot upgrade schemes with fixed parameters and poor adaptability, significantly improving the flexibility and scenario adaptability of firmware upgrades. This method adds a segmented verification and detection mechanism, independently verifying each segment of transmitted data and feeding back the verification results to the host computer in real time by switching the MCU's I2C transmit / receive mode. When data transmission errors occur, the frame header reception process is automatically restarted, effectively avoiding problems such as data transmission distortion and firmware write anomalies, greatly improving the reliability of boot program upgrades and device startup.

[0019] Furthermore, this invention achieves intelligent switching between dual-boot branches through the BS[1:0] configuration parameters, which not only supports the direct startup and operation of normal Flash programs, but also automatically switches to the I2C firmware update process when Flash program configuration is abnormal or the program is damaged, thereby achieving backup repair for device failures and ensuring the stable operation of embedded devices. The overall solution has a simple structure, reliable logic, and strong practicality and applicability. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the design method for BOOT startup and update based on the I2C protocol in this embodiment of the invention. Figure 2 This is a framework diagram of the design method for BOOT startup and update based on the I2C protocol in an embodiment of the present invention; Figure 3 This is a schematic diagram of the design system for BOOT startup and update based on the I2C protocol in an embodiment of the present invention. In the diagram: 1. Startup branch module; 2. I2C upgrade module; 3. Flash boot module. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] The purpose of this invention is to provide a design method and system for BOOT boot update based on the I2C protocol. Addressing the limitations of existing low-pin-package MCUs and dedicated control chips due to pin resource constraints, which prevent them from using conventional upgrade interfaces such as SPI, parallel bus, Ethernet, and CAN, and allow only I2C interface for data interaction, and the lack of a customized frame structure, segmented verification feedback mechanism, and adaptive fault-tolerant logic for boot branches in the traditional standard I2C protocol, resulting in small-package chips being unable to achieve online firmware iteration upgrades, requiring only one-time factory programming, high post-production maintenance costs, and short product lifecycles, this invention proposes a design method and system for BOOT boot update based on the I2C protocol. Through a custom three-segment data frame structure, segmented verification and real-time feedback mechanism, configurable timeout waiting mechanism, and a dual boot branch intelligent switching architecture based on the BS[1:0] configuration bits, this invention achieves flexible, reliable, and low-cost online firmware upgrades and normal Flash boot fault-tolerant repair for MCU devices with extremely low pin resource usage. It possesses strong engineering feasibility and scenario adaptability.

[0023] The present invention will now be described in further detail with reference to the accompanying drawings: Example 1 See Figure 1 and Figure 2 In one embodiment of this invention, a design method and system for BOOT updates based on the I2C protocol are provided. The overall method flow completely covers the entire chain logic, including chip power-on initialization, startup configuration reading, multi-branch startup determination, I2C custom frame firmware reception, segmented data verification, dynamic switching of transmit and receive modes, host feedback of verification results, transmission anomaly retransmission, timeout fault tolerance determination, Flash configuration verification, anomaly fallback upgrade, and program jump execution. This completely solves the industry problem that existing small-pin MCUs cannot achieve reliable BOOT upgrades based on the I2C bus. This method is based on the standard I2C universal protocol extension development, without modifying the underlying bus protocol, and is compatible with most embedded MCU hardware architectures. At the same time, relying on the natural advantages of the I2C bus—few pins, long transmission distance, and strong versatility—no additional external storage chips or communication peripherals are required, significantly reducing hardware design costs and device size, and adapting to various lightweight and miniaturized embedded control scenarios. The specific process is as follows: Step 1: The MCU initializes the watchdog timer, reads the boot configuration BS[1:0], and divides different boot processing branches according to the value of BS[1:0]. Specifically, after the MCU completes the basic system initialization upon power-on reset, it prioritizes the watchdog initialization configuration. The watchdog hardware mechanism monitors the subsequent BOOT program's running status throughout the process, effectively preventing device startup failures caused by program freezes, abnormal crashes, or transmission interruptions during firmware upgrades, thus ensuring the stability and security of the BOOT startup and upgrade process. After completing watchdog initialization and feeding it normally, the MCU accurately reads the startup configuration parameters BS[1:0] embedded within the chip. These parameters are two-bit configuration identifiers that can be flexibly configured via chip fuse bits or configuration registers to accurately distinguish different device startup modes.

[0024] In this embodiment, the BS[1:0] configuration parameter settings have three complete value branches, comprehensively covering various working conditions such as normal device startup, abnormal repair, and active upgrade. The first type of value corresponds to two working logics: a pure I2C active upgrade mode and a fallback mode that reads and verifies the Flash configuration first and then performs I2C upgrade as needed, adapting to scenarios of active firmware iteration and program abnormal repair. The second type of value corresponds to the pure Flash direct startup branch, adapting to normal working scenarios where the device firmware is stable and does not require upgrade, ensuring device startup efficiency. The third type of value corresponds to the hardware initialization priority configuration logic, forcing the MCU to complete the watchdog initialization and basic system configuration first, and then read the BS[1:0] parameters to complete the startup path splitting, effectively avoiding startup failure caused by initialization timing disorder. Through the multi-dimensional and hierarchical BS[1:0] parameter branch design, this method can adaptively switch the startup logic according to user configuration requirements and device operating status, taking into account both the stability of normal startup and the flexibility of firmware upgrade.

[0025] Step 2: If the I2C firmware update branch is entered, the I2C peripheral is initialized, the receive timeout is enabled, and the firmware data sent by the host computer in a three-segment frame structure is received. After each segment of data is received, the verification is performed independently. The MCU switches the I2C transmit and receive mode to send the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. Specifically, the first step is to complete the I2C peripheral initialization configuration, setting the MCU's built-in I2C control module to slave receive mode by default, adapting to the data transmission logic of the host computer's I2C master. Simultaneously, redundant peripherals are disabled and BOOT resources are streamlined to ensure data transmission stability. At the same time, the system synchronously enables a receive timeout timer, with flexibly configurable receive timeout thresholds of 50ms, 100ms, or 500ms depending on the actual application scenario. Shorter timeout thresholds are suitable for typical rapid upgrade scenarios, while a longer timeout threshold of 500ms is suitable for low-speed host computers, long-distance cabling, and industrial control scenarios with strong interference, greatly improving the solution's scenario adaptability.

[0026] The timeout fault tolerance mechanism is a crucial fault-tolerant design feature of this method. Within the timer's countdown period, if the MCU does not receive a valid I2C start command and frame header data from the host computer, the system will not directly determine upgrade failure. Instead, it will actively read the configuration information from the specified Flash memory address for validity verification. The default valid Flash configuration characteristic value is 0xAA55AF01. If the read Flash configuration parameters match this characteristic value perfectly, it indicates that the Flash's internal firmware is complete and the configuration is valid, and the device does not require a firmware upgrade. In this case, the MCU actively returns a normal confirmation signal to the host computer, disables the watchdog timer and I2C upgrade peripherals, and jumps to the default Flash program start address to run the original firmware application, ensuring normal device startup and operation. If the read Flash configuration parameters do not match the default characteristic value, it indicates that the Flash program is corrupted, the configuration is lost, or the firmware is abnormal. The MCU immediately returns the corresponding error code to the host computer, re-enters the I2C instruction waiting state, and continuously listens for upgrade commands from the host computer, waiting for firmware updates and repairs.

[0027] Under normal communication conditions without timeouts, the host computer, acting as the I2C master, continuously sends custom three-segment frame structure firmware data to the MCU, acting as the slave. This invention independently designs a proprietary data frame format based on the standard I2C protocol, overcoming the shortcomings of traditional I2C transmission data being fixed, lacking configurable parameters, and lacking verification feedback. This customized frame structure allows for flexible configuration of the transmission data length and the program's initial storage address for the application to be upgraded, adapting to firmware programs with different capacities and storage address plans, significantly improving upgrade flexibility. The overall data frame is strictly divided into three independent transmission units, each configured with a dedicated check byte, achieving independent segmented verification and error correction.

[0028] The specific frame structure configuration is as follows: The first segment is the frame header unit, consisting of a three-byte fixed sequence code and a one-byte sequence code checksum, used for frame synchronization, data identification, and frame header validity verification, effectively filtering interference noise and invalid data on the bus; the second segment is the parameter configuration unit, containing the transmission data length of the subsequent program binary code, the starting address of the program code in the MCU storage space, and a one-byte checksum for this segment, realizing configurable design of upgrade parameters; the third segment is the firmware data unit, which contains the complete binary code of the application to be upgraded, matched with a one-byte program data checksum, ensuring the integrity of the core firmware data transmission. Throughout the data transmission process, the host computer I2C master always sends data, and the MCU I2C slave passively receives data, conforming to the standard I2C master-slave communication logic and exhibiting extremely strong compatibility.

[0029] After each data segment is received and completely stored in its internal storage, the MCU immediately initiates local verification logic. It reads the currently stored complete segment data, calculates the corresponding checksum in real time, and precisely compares the locally calculated checksum with the checksum byte sent by the host computer along with the data. This achieves independent integrity verification for each data segment. To enable bidirectional interaction and fault feedback, the I2C communication mode is dynamically switched during the verification phase. The MCU switches from I2C slave receive mode to slave transmit mode, and the host computer switches from master transmit mode to master receive mode. The MCU provides accurate verification comparison results to the host computer in real time, allowing the host computer to monitor the transmission status of each firmware data segment.

[0030] If any data segment fails verification, indicating packet loss, data distortion, or bus interference, the MCU immediately terminates the current transmission process, clears the temporary storage data, and automatically reverts to the initial state of waiting to receive the frame header. It then waits for the host computer to resend the frame header data before initiating a new round of data transmission, preventing erroneous data from being written to the storage area and causing program corruption. If the current data segment is completely correct, the MCU returns a valid response signal to the host computer and enters the next data segment reception process, progressively receiving the frame header, parameters, and firmware data. Specifically, after the frame header verification passes, the MCU sends a first-type response signal, reinitializes the I2C peripherals and watchdog timer, and waits to receive address and length parameter data after stabilizing the communication link. After the address and length parameter verifications pass, it returns another response signal, waiting to receive the final program binary code data. This step-by-step verification and confirmation maximizes transmission reliability.

[0031] When all data in the three-segment frame structure has been received and the verification and comparison of each segment are completely correct, it indicates that the firmware upgrade data is complete and the transmission is reliable. At this time, the MCU sends a final upgrade completion response signal to the host computer, disables the watchdog timer and I2C receiving peripheral, terminates the upgrade monitoring process, and actively jumps to the preset program start address in the MCU's internal SRAM to fully execute the newly received application binary code, thus completing the entire process of online firmware upgrade and program startup based on the I2C protocol.

[0032] Step 3: If the Flash direct startup branch is entered, the internal configuration parameters of the Flash are read and verified. If the verification is successful, the program embedded in the Flash is executed. If the verification fails, the program is transferred to the I2C firmware update branch and waits for the host computer to send firmware to complete the program update.

[0033] Specifically, when the MCU reads the BS[1:0] parameters and determines to enter the Flash direct boot branch, the system prioritizes the conventional Flash boot logic, actively reads the preset boot configuration parameters and program verification information inside the Flash, and performs a comprehensive verification of the legality and completeness of the configuration parameters. If the verification result is qualified, it proves that the application program embedded in the Flash is intact and configured normally, and no firmware update is required. The MCU directly disables the watchdog and BOOT upgrade-related peripherals, jumps to the preset running address of the Flash, and executes the embedded application program normally, ensuring that the device powers on and starts up quickly and stably.

[0034] If the Flash configuration parameters fail verification—meaning the internal Flash program is corrupted, configuration parameters are missing, the firmware version is abnormal, or the program has been tampered with—the device cannot boot normally via the conventional Flash method. In this case, the system will not directly report an error and crash; instead, it will automatically trigger a fallback repair mechanism. It will proactively switch to the aforementioned complete I2C firmware update branch, fully reusing the entire set of technical logic for I2C peripheral initialization, timeout monitoring, three-segment frame data reception, segmented verification, result feedback, and abnormal retransmission. It will continuously wait for the host computer to send a new application binary code via the I2C bus. After the new firmware is received and verified to be correct, it will jump to execute the new program, achieving autonomous repair of the device fault and greatly improving the fault tolerance and operational stability of the embedded device.

[0035] In this embodiment, when BS[1:0]=01b or 11b, the system waits for 500ms or 100ms. During this waiting period, if an I2C command is received from the host computer, the system performs BOOT mode I2C communication. If no I2C command is received from the host computer within the waiting time, the system reads the flash configuration parameters and executes the application program in the flash. This structure has been applied to a photoelectric control MCU project, and after verification and testing after tape-out, its functions and performance are normal.

[0036] This method relies on the standard I2C protocol architecture, abandoning the design limitations of traditional BOOT upgrade schemes that depend on multi-pin high-speed buses. Leveraging the advantages of I2C—few pins, long transmission distance, and strong universal compatibility—it perfectly adapts to the hardware conditions of low-pin package MCUs and dedicated chips. Simultaneously, through a customizable configurable frame structure, it achieves flexible adaptation of upgrade addresses and upgrade lengths. Through multiple protection mechanisms including segmented verification, bidirectional feedback, abnormal retransmission, timeout fault tolerance, and fallback repair, it completely solves the technical defects of I2C—such as error-prone low-speed transmission, lack of verification, and uncontrollability. This technical solution has been successfully applied to a photoelectric control MCU project. After tape-out production, complete machine testing, and long-term operational verification, it demonstrates stable BOOT startup, reliable firmware upgrades, excellent fault tolerance, and all functions and performance indicators meet the requirements of actual industrial use, possessing extremely high engineering practicality and economic value.

[0037] Example 2 according to Figure 3 As shown, this embodiment discloses a design system for BOOT boot update based on the I2C protocol, used to implement the design method for BOOT boot update based on the I2C protocol in Embodiment 1. It includes a boot branch module 1, an I2C upgrade module 2, and a Flash boot module 3. Each module operates independently and works collaboratively, completely covering the entire process of chip boot and firmware upgrade. Specifically, it includes: Startup branch module 1 is used to initialize the MCU watchdog, read the startup configuration BS[1:0], and divide different startup processing branches according to the value of BS[1:0]. Specifically, the startup branch module 1 is responsible for initializing the watchdog after the MCU is powered on, reading the startup configuration BS[1:0] parameters, and accurately dividing the startup processing branches into two types: I2C firmware update and Flash direct startup, based on different values ​​of BS[1:0], providing a basis for judgment for the subsequent startup process and ensuring accurate routing of startup modes.

[0038] I2C upgrade module 2 is used to initialize the I2C peripheral, enable the receive timeout, and receive firmware data sent by the host computer in a three-segment frame structure if the I2C firmware update branch is entered. After each segment of data is received, it performs verification independently. The MCU switches the I2C transmit and receive mode to send the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. Specifically, I2C upgrade module 2 is responsible for initializing the I2C peripherals and enabling the receive timeout after entering the I2C firmware update branch. It receives the three-segment frame structure firmware data sent by the host computer. It completes data storage, verification, calculation and comparison segment by segment, switches the I2C transmit and receive modes in real time, and feeds back the verification results to the host computer. In the case of verification failure, it automatically resets to the frame header receiving waiting state. After all data verifications are passed, it controls the MCU to jump to run the newly received application program, realizing online firmware upgrade.

[0039] Flash startup module 3 is used to read and verify the internal configuration parameters of Flash if the Flash direct startup branch is entered; if the verification is successful, it will jump to execute the application program embedded in Flash; if the verification fails, it will switch to the I2C firmware update branch and wait for the host computer to send firmware to complete the program update.

[0040] Specifically, Flash boot module 3 is responsible for reading and verifying the internal configuration parameters of Flash after entering the Flash direct boot branch; if the verification is successful, it jumps to execute the application program embedded in Flash; if the Flash program is abnormal or the parameter verification fails, it automatically switches to the I2C firmware update branch, triggers the system to wait for the host computer to send firmware, and completes the program update and repair.

[0041] Each module of this system precisely corresponds to the core steps of the method implementation. The architecture is simple and the logic is closed-loop. Relying on the advantages of low pin occupancy and stable transmission of I2C, and with the help of a custom frame structure and multiple verification and fault tolerance mechanisms, it is perfectly adapted to the hardware scenarios of low-pin package MCUs and dedicated chips. It effectively solves the technical pain point that traditional small package chips cannot upgrade firmware online. The solution is highly stable and easy to implement, and has good engineering application and promotion value.

[0042] The system architecture provided in this embodiment is simple, logically closed-loop, and highly stable. The three functional modules precisely correspond to each core step of the method embodiment, solidifying the core innovations at the system level: low-pin I2C adaptation, customizable configurable frame structure, segmented verification bidirectional feedback, timeout fault tolerance, and dual-branch adaptive switching. It effectively fills the technological gap of existing small-package MCUs lacking a reliable I2C BOOT upgrade system. Without increasing hardware costs or occupying extra pin resources, it significantly improves the flexibility, reliability, and fault tolerance of embedded device firmware upgrades. It is suitable for various lightweight, miniaturized, and low-pin dedicated control chip engineering application scenarios, possessing broad application prospects and good economic benefits.

[0043] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A design method for BOOT startup and update based on the I2C protocol, characterized in that, include: Step 1: The MCU initializes the watchdog timer, reads the boot configuration BS[1:0], and divides different boot processing branches according to the value of BS[1:0]. Step 2: If the I2C firmware update branch is entered, initialize the I2C peripheral, enable the receive timeout timer, and receive the firmware data sent by the host computer in a three-segment frame structure. After each data segment is received, it performs verification independently. The MCU switches to I2C transceiver mode and sends the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. Step 3: If the Flash branch is directly started, the internal configuration parameters of Flash are read and verified. If the verification is successful, the program will be executed from the Flash memory. If the verification fails, the program will be redirected to the I2C firmware update branch and wait for the host computer to send firmware to complete the program update.

2. The design method for BOOT startup and update based on the I2C protocol according to claim 1, characterized in that, The configuration parameter BS[1:0] mentioned in step 1 includes three types of value branches: The first type of value corresponds to I2C upgrade, which involves first reading the Flash configuration and then performing the I2C upgrade. The second type of value corresponds to the Flash direct startup branch; The third type of value corresponds to the MCU first completing the watchdog initialization, and then reading BS [1:0] to complete the startup path splitting.

3. The design method for BOOT startup and update based on the I2C protocol according to claim 1, characterized in that, The three-segment frame structure described in step 2 specifically includes three segments of data, as follows: The first segment is the frame header, which includes a three-byte sequence code and a single-byte frame header checksum; The second segment contains the program code length, the starting address of storage, and the single-byte address checksum. The third segment consists of the application's binary code and a single-byte program data checksum. During the data transmission phase, the host computer acts as an I2C master to send data, and the MCU receives data as an I2C slave.

4. The design method for BOOT startup update based on the I2C protocol according to claim 3, characterized in that, After each data segment in the three-segment frame is received and stored in the storage space, the MCU calculates the local checksum and compares it with the checksum attached to the host. The MCU configures the I2C slave to transmit mode and feeds back the checksum result to the I2C host. If the checksum fails, it waits to receive the frame header again. After the checksum passes, it receives the next data segment.

5. The design method for BOOT startup and update based on the I2C protocol according to claim 1, characterized in that, In step 2, while initializing the I2C peripheral, start the receive timer and set a receive timeout threshold of 50ms or 100ms. If no valid I2C command is received after the timeout, read the configuration information of the corresponding Flash address to perform verification.

6. The design method for BOOT startup and update based on the I2C protocol according to claim 5, characterized in that, When the Flash configuration information verification obtains the preset characteristic value 0xAA55AF01, the MCU returns an acknowledgment to the host computer, disables the watchdog timer, and jumps to the preset starting address of the Flash to run the original application; if the configuration information does not match, it returns the corresponding error code to the host computer and waits for the I2C instruction again.

7. The design method for BOOT startup and update based on the I2C protocol according to claim 1, characterized in that, After the frame header verification passes in step 2, the MCU returns a first type of response signal to the host computer, reinitializes the I2C and watchdog, and waits to receive address and length-related data. After the address verification passes, it returns another response signal to the host computer and waits to receive program code data.

8. The design method for BOOT startup update based on the I2C protocol according to claim 7, characterized in that, After all program code verifications pass, the MCU returns a final response to the host computer, disables the watchdog timer, and jumps to the corresponding starting address in SRAM to execute the application program that has completed receiving.

9. The design method for BOOT startup and update based on the I2C protocol according to claim 1, characterized in that, If the Flash configuration verification fails in step 3, the entire set of logical receiving firmware from step 2, including I2C reception, segmented verification, and verification feedback, is reused. Once the firmware verification is successful, the process jumps to execute the new version of the application.

10. A design system for BOOT startup and update based on the I2C protocol, characterized in that, include: The startup branch module is used to initialize the MCU watchdog, read the startup configuration BS[1:0], and divide different startup processing branches according to the value of BS[1:0]. The I2C upgrade module is used to initialize the I2C peripheral, enable the receive timeout, and receive firmware data sent by the host computer in a three-segment frame structure if the I2C firmware update branch is entered. After each data segment is received, it performs verification independently. The MCU switches to I2C transceiver mode and sends the verification result back to the host. If the verification fails, it returns to the waiting to receive the frame header stage. After all segments pass the verification, it jumps to run the newly received application. The Flash boot module is used to read and verify the internal configuration parameters of Flash if the Flash boot branch is entered directly. If the verification is successful, the program will be executed from the Flash memory. If the verification fails, the program will be redirected to the I2C firmware update branch and wait for the host computer to send firmware to complete the program update.

Images