An electric two-wheeler controller OTA upgrade and rollback method and electric two-wheeler

Abstract

This invention discloses an OTA upgrade and rollback method for an electric two-wheeled vehicle controller and an electric two-wheeled vehicle. The controller includes an MCU and a Bluetooth chip. The MCU's flash memory is divided into a bootloader guidance area and an APP running area, while the Bluetooth chip's flash memory is divided into a Bluetooth APP area and an MCU program backup area. The method includes: after the controller is powered on, the MCU chip enters the guidance area, detects a valid upgrade flag, backs up the current firmware in the APP running area, and encrypts and transmits it to the backup area. After the backup is completed, an OTA upgrade is performed. After the upgrade is completed, the guidance area verifies the upgraded firmware in the APP running area. If the verification passes, it jumps to the running area and sets the upgrade flag to invalid; if the verification fails, a rollback process is triggered. The guidance area decrypts the firmware stored in the backup area and rolls it back to the APP running area. By utilizing the remaining space resources of the Bluetooth chip, the overall resource utilization efficiency of the controller is improved.

Description

Technical Field

[0001] This invention relates to the field of electric two-wheeler upgrade technology, and in particular to an OTA upgrade and rollback method for an electric two-wheeler controller and an electric two-wheeler. Background Technology

[0002] As the electric two-wheeler industry rapidly develops towards intelligence and the Internet of Things (IoT), over-the-air (OTA) updates have become a core standard feature of electric two-wheeler controllers. This technology enables remote iterative updates to vehicle firmware, which not only flexibly expands the functional boundaries of the vehicle and enriches the riding experience, but also promptly fixes software security vulnerabilities discovered during vehicle operation, effectively ensuring vehicle operational stability and significantly enhancing the overall lifecycle value of the equipment.

[0003] However, current mainstream OTA upgrade and rollback solutions for electric two-wheelers generally rely on a dual-partition storage architecture in the flash memory of the microcontroller unit (MCU) in the controller to achieve firmware rollback functionality. To meet the storage requirements of dual partitions, the MCU needs to be equipped with large-capacity flash memory, directly increasing the hardware production cost of the controller. At the same time, electric two-wheeler controllers are equipped with Bluetooth chips to achieve wireless communication functions. The flash resources of this Bluetooth chip are only used to run the Bluetooth application itself, leaving a large amount of flash space idle for a long time, resulting in a serious waste of hardware resources, which contradicts the industry's development needs for cost reduction, efficiency improvement, and efficient resource utilization. Summary of the Invention

[0004] To address the aforementioned problems and technical requirements, the inventors have proposed an OTA upgrade and rollback method for an electric two-wheeled vehicle controller, along with the electric two-wheeled vehicle itself. This method solves the problems of traditional solutions requiring a large-capacity flash memory in the controller MCU and the waste of flash resources in existing Bluetooth chips. The technical solution of this invention is as follows:

[0005] In a first aspect, this application provides an OTA upgrade and rollback method for an electric two-wheeled vehicle controller. The electric two-wheeled vehicle controller includes an MCU chip and a Bluetooth chip. The flash memory of the MCU chip is divided into a bootloader area and an APP running area, and the flash memory of the Bluetooth chip is divided into a Bluetooth APP area and an MCU program backup area. The method includes the following steps: After the controller is powered on, the MCU chip enters the bootloader area to check the upgrade flag bit; If the upgrade flag is valid, the bootloader area of ​​the MCU chip backs up the current firmware of the APP running area and transmits it in encryption to the MCU program backup area of ​​the Bluetooth chip. After the backup is completed, the host computer communicates with the bootloader area of ​​the MCU chip to execute the OTA upgrade process; After the OTA upgrade is completed, the bootloader area of ​​the MCU chip verifies the upgraded firmware in the APP running area. If the verification is successful, it jumps to the APP running area to execute vehicle functions and sets the upgrade flag to invalid. If the verification fails, it triggers the rollback process. The bootloader area of ​​the MCU chip decrypts the firmware stored in the MCU program backup area of ​​the Bluetooth chip and rolls it back to the APP running area of ​​the MCU chip.

[0006] A further technical solution is that the method also includes: If the upgrade flag is invalid, the bootloader area of ​​the MCU chip verifies the current firmware in the APP runtime area. If the verification passes, it jumps to the APP runtime area to execute vehicle functions; if the verification fails, it triggers the rollback process.

[0007] A further technical solution involves the MCU chip's bootloader area backing up the current firmware of the APP runtime area and encrypting and transmitting it to the Bluetooth chip's MCU program backup area, including: The bootloader area of ​​the MCU chip erases the original firmware of the MCU program backup area of ​​the Bluetooth chip according to the instructions of the host computer; The bootloader area of ​​the MCU chip encrypts the current firmware of the MCU chip's APP runtime area in fixed-byte packets; Insert the checksum of each encrypted data packet at the end of the packet, concatenate them into a complete data packet, and send it to the MCU program backup area of ​​the Bluetooth chip in a specified format. The Bluetooth chip recalculates the checksum of the encrypted data segment in the received whole data packet and compares it with the checksum in the received whole data packet. If the comparison matches, the MCU program backup area continues to receive the next whole data packet; otherwise, it sends an ERR to the MCU chip, which responds to the ERR and retransmits the data packet.

[0008] A further technical solution involves the MCU chip's bootloader area backing up the current firmware of the APP runtime area and encrypting and transmitting it to the Bluetooth chip's MCU program backup area, and also includes: During the current firmware encrypted transmission process, the MCU chip and Bluetooth chip also perform CRC32 cumulative verification on the multiple packets of data transmitted in the APP running area and the multiple packets of data received in the MCU program backup area respectively; After the current firmware encryption transmission is completed, the MCU chip will send the CRC32 check value of the encrypted firmware to the Bluetooth chip. If the two chips match, the firmware backup is considered successful. The Bluetooth chip and the MCU chip will store the CRC32 check value in their own flash memory. If the two chips do not match, the firmware backup is considered to have failed.

[0009] A further technical solution is that the method also includes: If the firmware backup fails, the MCU chip records the invalid code flag in its own flash memory for the MCU program backup area of ​​the Bluetooth chip. When the rollback process is triggered later, the MCU chip detects the invalid code flag and directly stays in the bootloader area to wait for the upgrade response without performing the rollback operation.

[0010] The further technical solution is that the rollback process includes: The MCU chip detects the code flags in the MCU program backup area of ​​the Bluetooth chip; If the code flag is valid, compare the CRC32 checksum values ​​stored in the flash memory of the MCU chip and the Bluetooth chip respectively. If the comparison is inconsistent, stay in the bootloader area and wait for the upgrade response. If the comparison matches, the bootloader area of ​​the MCU chip will decrypt the encrypted firmware of the MCU program backup area of ​​the Bluetooth chip and write it into the APP running area of ​​the MCU chip. After the rollback is complete, a second verification is performed on the current firmware in the APP running area. If the verification passes, the system jumps to the APP running area to execute vehicle functions. If the verification fails, the system stays in the bootloader area to wait for the upgrade response.

[0011] The further technical solution is that the OTA upgrade process includes: The bootloader area of ​​the MCU chip erases the original firmware of the APP running area of ​​the MCU chip according to the instructions of the host computer; The bootloader area of ​​the MCU chip receives the upgrade firmware transmitted from the host computer and writes the upgrade firmware into the APP runtime area of ​​the MCU chip.

[0012] A further technical solution is that the method also includes: If the upgrade flag is invalid and the program jumps to the APP runtime area of ​​the MCU chip, when the APP runtime area receives the OTA command sent by the host computer and meets the upgrade conditions, it will set the upgrade flag to valid and jump to the bootloader area of ​​the MCU chip.

[0013] A further technical solution is that the firmware verification of the APP running area and the secondary verification after rollback in the bootloader area of ​​the MCU chip are both implemented using the CRC check algorithm.

[0014] Secondly, this application also provides an electric two-wheeled vehicle, including a controller installed on the vehicle. The controller includes an MCU chip and a Bluetooth chip, and the MCU chip communicates with a host computer through the Bluetooth chip. The flash memory of the MCU chip is divided into a bootloader area and an APP running area. The flash memory of the Bluetooth chip is divided into a Bluetooth APP area and an MCU program backup area. The MCU program backup area is used to store the current firmware of the APP running area for backup. The controller is used to implement the steps of the OTA upgrade and rollback method for electric two-wheeled vehicle controllers as described in the first aspect.

[0015] The beneficial technical effects of this invention are: 1) Utilize the remaining flash resources of the Bluetooth chip and allocate a dedicated MCU program backup area to replace the original dual-partition storage on the MCU chip. This not only saves MCU hardware costs but also avoids the waste of idle Bluetooth flash resources and improves the overall resource utilization efficiency of the controller.

[0016] 2) A dual verification mechanism of single packet checksum and overall CRC32 cumulative check is adopted to ensure the security and accuracy of firmware backup transmission and reduce data transmission errors. At the same time, the automatic power-on verification and automatic rollback process for upgrade failure are designed. Combined with the dual judgment of backup area code flag bit and CRC32 check value, the system fault tolerance is greatly improved and invalid rollback is avoided.

[0017] 3) The firmware is encrypted in packets during backup and decrypted before being written to the MCU during rollback. This effectively prevents the firmware from being tampered with or leaked during transmission and storage, and improves data security throughout the OTA upgrade process. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the space allocation between the MCU chip and the Bluetooth chip within the controller provided in this application; Figure 2 This is a flowchart of the OTA upgrade and rollback method for electric two-wheeled vehicle controllers provided in this application, with the bootloader area as the main body; Figure 3 This is a flowchart of the OTA upgrade and rollback method for electric two-wheeled vehicle controllers provided in this application, with the APP running area as the main body. Detailed Implementation

[0019] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0020] One embodiment of this application provides an electric two-wheeled vehicle, including a controller capable of Bluetooth OTA (Over-The-Air) updates. This type of controller typically has two chips: an MCU (Microcontroller Unit) chip that controls motor operation and vehicle functions, and a Bluetooth chip that enables wireless communication with a host computer. The Bluetooth chip and the MCU chip communicate via a serial port for data transmission (e.g., transmitting instructions from the host computer to the MCU) and firmware backup code transfer, or via SPI communication. Optionally, the host computer is typically a user's mobile app, a manufacturer's cloud server, etc.

[0021] Space allocation between Bluetooth chip and MCU chip, as follows Figure 1 As shown, by dividing the MCU chip's flash memory into a bootloader area and an APP runtime area, the dual-partition storage structure is eliminated. The bootloader, the first program to run after power-on, is located before the operating system kernel starts and is responsible for the critical tasks of initializing the hardware, loading the system kernel, and guiding its execution. The Bluetooth chip's flash memory is divided into a Bluetooth APP area and an MCU program backup area. The MCU program backup area stores the current firmware of the APP runtime area for backup. Using the Bluetooth chip's surplus flash space to replace the MCU chip's local dual partitions for OTA upgrades and rollbacks solves the problems of high hardware costs and wasted flash resources in the Bluetooth chip caused by the MCU chip's large-capacity dual flash partitions.

[0022] Based on the above controller, an OTA upgrade and rollback method for electric two-wheeled vehicle controllers can be implemented, combined with... Figure 2 , Figure 3 As shown, the method includes the following steps: S1. After the controller is powered on, the MCU chip enters the bootloader area to check the upgrade flag. If the upgrade flag is valid, it enters S2.

[0023] S2. The bootloader area of ​​the MCU chip backs up the current firmware of the APP running area and transmits it in encryption to the MCU program backup area of ​​the Bluetooth chip.

[0024] S3. After the backup is completed, the host computer communicates with the bootloader area of ​​the MCU chip to execute the OTA upgrade process.

[0025] S4. After the OTA upgrade is completed, the bootloader area of ​​the MCU chip verifies the upgraded firmware in the APP running area. If the verification is successful, it jumps to the APP running area to execute vehicle functions and sets the upgrade flag to invalid. If the verification fails, it triggers the rollback process. The bootloader area of ​​the MCU chip decrypts the firmware stored in the MCU program backup area of ​​the Bluetooth chip and rolls it back to the APP running area of ​​the MCU chip.

[0026] In the above embodiments, the MCU program backup area of ​​the Bluetooth chip is the remaining flash area of ​​the Bluetooth chip, providing dedicated backup storage space for the original firmware of the APP running area of ​​the MCU chip. This fully utilizes the flash resources of the Bluetooth chip, saving MCU hardware costs, avoiding idle and wasted Bluetooth flash resources, and improving the overall resource utilization efficiency of the controller. Furthermore, firmware backup is encrypted, and decryption is required before writing to the MCU during rollback. This effectively prevents the firmware from being tampered with or leaked during transmission and storage, enhancing data security throughout the OTA upgrade process.

[0027] In one possible implementation, S1 above further includes: proceeding to S5 if the upgrade flag is invalid.

[0028] The bootloader area of ​​the S5 MCU chip verifies the current firmware in the APP runtime area. If the verification passes, it jumps to the APP runtime area to execute vehicle functions; if the verification fails, it triggers the rollback process.

[0029] In one possible implementation, S2 specifically includes: S2.1 The bootloader area of ​​the MCU chip erases the original firmware of the MCU program backup area of ​​the Bluetooth chip according to the host computer's instructions. Specifically, after detecting a valid upgrade flag, the bootloader area replies to the host computer to complete the handshake with the bootloader. Then, the host computer sends an erase command to the Bluetooth chip to erase the MCU program backup area of ​​the Bluetooth chip. After the erasure is completed, it sends a status to the MCU's bootloader area.

[0030] S2.2 The bootloader area of ​​the MCU chip encrypts the current firmware of the MCU chip's APP runtime area in fixed-byte packets. A checksum of the encrypted data is inserted at the end of each packet, and the packets are then concatenated into a single data packet and sent to the MCU program backup area of ​​the Bluetooth chip in a specified format. In this embodiment, the data is first encrypted in packets of 256 bytes each, with the last packet padded with 0xFF if it is less than 256 bytes. Then, a checksum of the encrypted data is inserted at the end of each packet, and the resulting data packet is sent to the Bluetooth chip in AT command format.

[0031] S2.3 The Bluetooth chip recalculates the checksum of the encrypted data segment in the received whole data packet and compares it with the checksum in the received whole data packet. If the comparison matches, it replies OK to the MCU chip, and the MCU program backup area continues to receive the next whole data packet. Otherwise, it replies ERR to the MCU chip, and the MCU chip responds to ERR and retransmits the data packet.

[0032] Optionally, the MCU and Bluetooth chip can use the same checksum calculation method, such as an 8-bit cumulative sum algorithm: the 256 bytes of encrypted data are added byte by byte, and the final result is modulo 256 (only the lower 8 bits are kept) to obtain a 1-byte checksum.

[0033] In this embodiment, S2 further includes: S2.4 During the current firmware encryption transmission process, in addition to calculating the checksum of a single data packet, the MCU chip and Bluetooth chip also perform CRC32 cumulative verification on the multiple data packets transmitted in the APP running area and the multiple data packets received in the MCU program backup area. After the current firmware encryption transmission is completed, the MCU chip sends the CRC32 checksum of the entire encrypted firmware (the final cumulative result) to the Bluetooth chip. If the two chips match, the firmware backup is determined to be successful, and the Bluetooth chip and MCU chip respectively store the CRC32 checksum in their own flash memory; if the two chips do not match, the firmware backup is determined to be unsuccessful, and proceed to S2.5.

[0034] S2.5 If firmware backup fails, the MCU chip records the code flag of the MCU program backup area of ​​the Bluetooth chip in its own flash as invalid. When the rollback process is triggered later, the MCU chip detects the invalid code flag and directly stays in the bootloader area to wait for the upgrade response without performing the rollback operation.

[0035] In one possible implementation, the OTA upgrade process in S3 above specifically includes: S3.1 The bootloader area of ​​the MCU chip erases the original firmware of the APP running area of ​​the MCU chip according to the instructions of the host computer.

[0036] S3.2 The bootloader area of ​​the MCU chip receives the upgrade firmware transmitted from the host computer and writes the upgrade firmware into the APP running area of ​​the MCU chip.

[0037] In one possible implementation, the rollback process in S4 above includes: S4.1 The MCU chip detects the code flag bit in the MCU program backup area of ​​the Bluetooth chip. If the code flag bit is valid, proceed to S4.2; otherwise, proceed to S4.5.

[0038] S4.2. Compare the CRC32 checksum values ​​stored in the flash memory of the MCU chip and the Bluetooth chip respectively. If they do not match, proceed to S4.5; if they match, proceed to S4.3.

[0039] S4.3 The bootloader area of ​​the MCU chip decrypts the encrypted firmware of the MCU program backup area of ​​the Bluetooth chip and writes it into the APP running area of ​​the MCU chip.

[0040] S4.4 After the rollback is completed, a second verification is performed on the current firmware in the APP running area. If the verification passes, the system will jump to the APP running area to execute vehicle functions and reset the upgrade flag. If the verification fails, the system will proceed to S4.5.

[0041] S4.5, Remains in the bootloader area waiting for an upgrade response, and then replies to the host computer that the rollback failed.

[0042] In S5 above, if the verification fails, the rollback process is triggered in a manner similar to that in S4 above, including: if the code flag in the MCU program backup area of ​​the Bluetooth chip is valid, the CRC32 checksums stored in the MCU chip and the Bluetooth chip flash are compared. If they are inconsistent or the code flag is invalid, the process remains in the bootloader area waiting for the upgrade response and replies to the host computer that the rollback failed. If they are consistent, the encrypted firmware in the MCU program backup area of ​​the Bluetooth chip is decrypted and written to the APP running area of ​​the MCU chip. After the rollback is completed, the current firmware in the APP running area is verified again. If the verification passes, the process jumps to the APP running area to execute vehicle functions. If the verification fails again, the process remains in the bootloader area waiting for the upgrade response and replies to the host computer that the rollback failed.

[0043] In one possible implementation, in S5 above, if the upgrade flag is invalid and the user jumps to the APP runtime area of ​​the MCU chip, then... Figure 3 As shown, when the APP runtime receives an OTA command from the host computer, it first determines whether the OTA upgrade conditions are met. If the conditions are not met, it sends a negative response to the host computer and continues to execute vehicle functions in the APP runtime. If the conditions are met, it sends a "waiting for response" response to the host computer, sets the upgrade flag to valid, and jumps to the bootloader area of ​​the MCU chip to execute S1~S4. In this embodiment, the OTA upgrade conditions need to meet the comprehensive coordination of hardware, software, network, user operation, and security mechanisms. The most core basic condition is that the vehicle has intelligent control and networking capabilities, while the key to upgrade execution lies in three elements: sufficient battery power, vehicle stationary, and stable network.

[0044] Optionally, the firmware verification of the APP running area and the secondary verification after rollback in the bootloader area of ​​the MCU chip proposed in S4 and S5 are both implemented using the conventional CRC verification algorithm, and the algorithm implementation process will not be described in detail here.

[0045] It should be noted that if there are other chips or storage areas in the controller, the same function of the MCU program backup area of ​​the Bluetooth chip can be achieved. For example, the EEPROM in the controller can be used as the backup medium for the firmware of the MCU chip's APP running area, so as to realize firmware backup and OTA upgrade rollback.

[0046] The above descriptions are merely preferred embodiments of this application, and the present invention is not limited to the above embodiments. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the spirit and concept of the present invention should be considered to be included within the protection scope of the present invention.

Claims

1. A method for OTA upgrade and rollback of an electric two-wheeled vehicle controller, characterized in that, The electric two-wheeler controller includes an MCU chip and a Bluetooth chip. The flash memory of the MCU chip is divided into a bootloader area and an APP running area, and the flash memory of the Bluetooth chip is divided into a Bluetooth APP area and an MCU program backup area. The method includes the following steps: After the controller is powered on, the MCU chip enters the bootloader area to check the upgrade flag bit; If the upgrade flag is valid, the bootloader area of ​​the MCU chip backs up the current firmware of the APP running area and transmits it in encrypted form to the MCU program backup area of ​​the Bluetooth chip. After the backup is completed, the host computer communicates with the bootloader area of ​​the MCU chip to execute the OTA upgrade process; After the OTA upgrade is completed, the bootloader area of ​​the MCU chip verifies the upgraded firmware in the APP running area. If the verification is successful, it jumps to the APP running area to execute vehicle functions and sets the upgrade flag to invalid. If the verification fails, it triggers the rollback process. The bootloader area of ​​the MCU chip decrypts the firmware stored in the MCU program backup area of ​​the Bluetooth chip and rolls it back to the APP running area of ​​the MCU chip.

2. The OTA upgrade and rollback method for electric two-wheeled vehicle controller according to claim 1, characterized in that, The method further includes: If the upgrade flag is invalid, the bootloader area of ​​the MCU chip verifies the current firmware of the APP running area. If the verification passes, it jumps to the APP running area to execute vehicle functions; if the verification fails, it triggers the rollback process.

3. The OTA upgrade and rollback method for electric two-wheeled vehicle controller according to claim 1, characterized in that, The bootloader area of ​​the MCU chip backs up the current firmware of the APP runtime area and encrypts and transmits it to the MCU program backup area of ​​the Bluetooth chip, including: The bootloader area of ​​the MCU chip erases the original firmware of the MCU program backup area of ​​the Bluetooth chip according to the instructions of the host computer. The bootloader area of ​​the MCU chip encrypts the current firmware of the APP running area of ​​the MCU chip in fixed-byte packets; Insert a checksum of the encrypted data packet at the end of each packet, concatenate them into a complete data packet, and send it to the MCU program backup area of ​​the Bluetooth chip in a specified format; The Bluetooth chip recalculates the checksum of the encrypted data segment in the received whole data packet and compares it with the checksum in the received whole data packet. If the comparison matches, the MCU program backup area continues to receive the next whole data packet; otherwise, an ERR is sent to the MCU chip, and the MCU chip responds to the ERR and retransmits the data packet.

4. The OTA upgrade and rollback method for electric two-wheeled vehicle controller according to claim 3, characterized in that, The bootloader area of ​​the MCU chip backs up the current firmware of the APP runtime area and encrypts and transmits it to the MCU program backup area of ​​the Bluetooth chip, and also includes: During the current firmware encryption transmission process, the MCU chip and the Bluetooth chip also perform CRC32 cumulative verification on the multi-packet data transmitted in the APP running area and the multi-packet data received in the MCU program backup area respectively; After the current firmware encryption transmission is completed, the MCU chip will send the CRC32 check value of the overall encrypted firmware to the Bluetooth chip. If the two chips match, the firmware backup is determined to be successful. The Bluetooth chip and the MCU chip will store the CRC32 check value in their own flash memory. If the two chips do not match, the firmware backup is determined to be unsuccessful.

5. The OTA upgrade and rollback method for electric two-wheeled vehicle controller according to claim 4, characterized in that, The method further includes: If the firmware backup fails, the MCU chip records the invalid code flag in its own flash for the MCU program backup area of ​​the Bluetooth chip. When the rollback process is triggered subsequently, the MCU chip detects the invalid code flag and directly stays in the bootloader area to wait for the upgrade response without performing the rollback operation.

6. The OTA upgrade and rollback method for an electric two-wheeled vehicle controller according to claim 1 or 2, characterized in that, The rollback process includes: The MCU chip detects the code flag bit in the MCU program backup area of ​​the Bluetooth chip; If the code flag is valid, compare the CRC32 checksum values ​​stored in the flash memory of the MCU chip and the Bluetooth chip respectively. If the comparison is inconsistent, stay in the bootloader area and wait for the upgrade response. If the comparison matches, the bootloader area of ​​the MCU chip will decrypt the encrypted firmware of the MCU program backup area of ​​the Bluetooth chip and write it into the APP running area of ​​the MCU chip. After the rollback is completed, the current firmware in the APP running area is verified a second time. If the verification passes, the system jumps to the APP running area to execute vehicle functions. If the verification fails, the system stays in the bootloader area to wait for the upgrade response.

7. The OTA upgrade and rollback method for an electric two-wheeled vehicle controller according to claim 1, characterized in that, The OTA upgrade process includes: The bootloader area of ​​the MCU chip erases the original firmware of the APP running area of ​​the MCU chip according to the instructions of the host computer; The bootloader area of ​​the MCU chip receives the upgrade firmware transmitted from the host computer and writes the upgrade firmware into the APP running area of ​​the MCU chip.

8. The OTA upgrade and rollback method for an electric two-wheeled vehicle controller according to claim 2, characterized in that, The method further includes: If the upgrade flag is invalid and the process jumps to the APP running area of ​​the MCU chip, when the APP running area receives the OTA command sent by the host computer and meets the upgrade conditions, the upgrade flag is set to valid and the process jumps to the bootloader area of ​​the MCU chip.

9. The OTA upgrade and rollback method for an electric two-wheeled vehicle controller according to claim 6, characterized in that, The bootloader area of ​​the MCU chip uses the CRC check algorithm to perform firmware verification and secondary verification after rollback of the APP running area.

10. An electric two-wheeled vehicle, characterized in that, The system includes a controller installed on the vehicle, the controller comprising an MCU chip and a Bluetooth chip, the MCU chip communicating with a host computer via the Bluetooth chip; The flash memory of the MCU chip is divided into a bootloader area and an APP running area, and the flash memory of the Bluetooth chip is divided into a Bluetooth APP area and an MCU program backup area. The MCU program backup area is used to store the current firmware of the APP running area for backup. The controller is used to implement the steps of the OTA upgrade and rollback method for electric two-wheeled vehicle controllers as described in any one of claims 1 to 9.

Images