Software upgrading method and system for electric power-assisted bicycle

Abstract

The invention discloses a software upgrading method and system for an electric power-assisted bicycle, and belongs to the technical field of vehicle software upgrading, an electronic control unit of the system comprises a micro-control unit and a flash memory chip, the micro-control unit comprises a BOOT area and an operation area, and the flash memory chip comprises a backup area and an upgrading area; the upgrading method comprises the following steps of: copying a software factory version of a running area to a backup area by backing up the software factory version; during version upgrading, copying an upgrading version of the software to the upgrading area and evaluating the upgrading version, if an evaluation requirement is met, determining that upgrading succeeds and copying the upgrading version to the running area for running, otherwise, determining that upgrading fails and continuing to run the current version in the running area; and when the current software version of the running area runs abnormally, copying the factory version from the backup area to the running area to replace the current software version for running. When upgrading is interrupted, normal operation of the original software can be kept, and the factory version can be restored from the backup area even if the software cannot normally operate after upgrading.

Description

Technical Field

[0001] The present invention belongs to the technical field of vehicle software upgrade, and in particular relates to a software upgrade method and system for an electric-assisted bicycle. Background Art

[0002] The control system of an electric-assisted bicycle is generally composed of an electronic control unit ECU (Electronic Control Unit), instruments, controllers and batteries. With the rapid development of electric-assisted bicycles, it is inevitable to upgrade the control system through OTA (Over-The-Air) download.

[0003] During the OTA upgrade, if the user performs operations such as power off or shutdown, the upgrade will be interrupted and the electric bicycle will not be able to be used. For example, when the user upgrades the software version, the BOOT area in the microcontroller unit MCU (Microcontroller Unit) of the electronic control unit ECU will receive the upgrade version data packet sent by the user. In the BOOT area, the boot program will write the data packets one by one to the running area of ​​the MCU. If the upgrade is completed, it will jump from the BOOT area to the running area to run the updated APP software version. However, once the APP software upgrade process is interrupted, the BOOT area can only wait for the user to upgrade again, and at this time the APP software version in the running area has been damaged and cannot be used, which leads to insufficient security of the software version upgrade.

[0004] On the other hand, after the OTA upgrade is successfully downloaded over the air, if the upgraded version has serious defects and cannot run normally, it will also affect the use of the electric assisted bicycle. Therefore, a safer firmware upgrade solution is needed to ensure that the electric assisted bicycle can still run normally after the upgrade fails. Summary of the invention

[0005] In order to solve the shortcomings of the prior art, the present invention adopts the following technical solutions to achieve the purpose of restoring the software to the factory version after a software upgrade fails or restoring the software to the previous version when the software fails to run after the upgrade, thereby ensuring that the electric-assisted bicycle can still operate normally: A method for upgrading software of an electric power-assisted bicycle comprises the following steps: Step 1: Back up the factory version of the software, copy the factory version of the software in the running area to the backup area; Step 2: When the user needs to perform an OTA version upgrade, copy the upgraded version of the APP software to the upgrade area and evaluate the upgraded version. If the evaluation requirements are met, the upgrade is considered successful and the upgraded version is copied to the running area for operation. Otherwise, the upgrade is considered failed and the current version continues to run in the running area. Step 3: When the current software version in the running area runs abnormally, copy the factory version from the backup area to the running area to replace the current software version.

[0006] Furthermore, in step 2, the evaluation of the upgraded version specifically includes the following steps: Step 2.1: Run the boot program in the BOOT area; Step 2.2: The boot program performs a CRC integrity check on the upgrade area. If a complete upgrade version is found in the upgrade area, the upgrade is deemed successful; otherwise, the upgrade is deemed failed.

[0007] Furthermore, in step 3, since the software version of the running area may have defects (bugs), resulting in the firmware not being able to run normally, BOOT will find that the key software information in the running area has been tampered with when it starts. BOOT will re-copy the factory version from the backup area to the running area, so that the software can run normally again. The microcontroller unit MCU generally has some registers, which are usually used to ensure that data is not lost when the system is restarted. Although the software version of the running area can run normally, the stability of the running status of the software version needs to be further confirmed. Here, the stability is judged with the help of registers, which specifically includes the following steps: Step 3.1: read the 32-bit register value through the boot program, and determine whether the upper 16 bits of the register value are the initialized high value 0xA5A5. If not, initialize the register value to 0xA5A50000, and then execute step 3.2; if yes, read the lower 16 bits of the register value, and determine whether the entire register value exceeds the threshold. The threshold is fixed by the boot program in the BOOT area. In the embodiment of the present invention, the threshold is 10. If it does not exceed the threshold, execute step 3.2. If it exceeds the threshold, execute step 3.4; Step 3.2: Count and accumulate the value of the lower 16 bits of the register and write it back to the register. Then, jump to the running area through the boot program to run the current software version. Step 3.3: If the currently running software version can run normally for more than 2 seconds, read the register value and reset it to the initialization register value 0xA5A50000. Otherwise, the crashed electronic control unit ECU software will be reset and restarted by the watchdog, and jump to the boot program in the BOOT area, and execute step 3.1; Step 3.4: Copy the factory version from the backup area to the running area, reset the register value to the initialization register value 0xA5A50000, and then execute step 3.2.

[0008] Furthermore, in step 3, when the current software version in the operation area is running normally, it is actively backed up. When the subsequently upgraded software version runs abnormally, the actively backed-up software version is copied from the backup area to the operation area to replace the current software version. If the actively backed-up software version still runs abnormally, the factory version is copied from the backup area to the operation area to replace the actively backed-up software version. By actively backing up the normally running upgraded version, when the subsequent upgrade is abnormal, it is possible to restore to the previously normally running upgraded version without restoring to the factory version, thereby improving the user experience. At the same time, users can also actively back up the normally running upgraded version according to their own preferences for subsequent abnormal recovery to suit user preferences.

[0009] Furthermore, the active backup backs up multiple upgraded versions in chronological order, and when a subsequently upgraded software version runs abnormally, the most recent version is restored in reverse order according to the chronological order.

[0010] Furthermore, the update package based on the factory version is actively backed up, and only the unit of the software upgrade is updated instead of the entire software version. When the version is restored, only the update package that has been replaced between the currently running software version and the software version to be restored is replaced, thereby reducing the capacity of the backup area and increasing the speed of version recovery.

[0011] Furthermore, when the version is upgraded, the intermediate version between the current upgraded version and the latest software version actively backed up is detected, and the update package of the intermediate version is actively backed up in reverse chronological order. For users who have not upgraded for a long time, there is a problem of cross-version upgrade. Since it spans multiple versions, if the current version runs abnormally, it can only be restored to an earlier version or the factory version. Backing up the update package of the intermediate version in reverse chronological order can restore the version in reverse chronological order when the cross-version upgrade is abnormal, thereby automatically and quickly restoring to a stable running version. Moreover, the update package of the intermediate version is actively backed up, which can save transmission and storage resources. On the other hand, even if the transmission is interrupted, since it is backed up in reverse chronological order and the update package size is relatively small, the previous upgraded version can be backed up in a short time.

[0012] A software upgrade system for an electric-assisted bicycle comprises an electronic control unit ECU. The electronic control unit ECU performs software upgrade according to a software upgrade method for an electric-assisted bicycle. The electronic control unit ECU comprises a microcontroller unit MCU and a flash memory chip Flash. The microcontroller unit MCU comprises a BOOT area and an APP software running area. The flash memory chip Flash comprises a backup area and an upgrade area. The BOOT area is used to store a boot program for software version copying, upgrade version evaluation and program booting.

[0013] Furthermore, the electronic control unit ECU is provided with a register cooperating with the micro control unit MCU; If the currently running software version can run normally for more than 2 seconds, the register value will be read and reset to the initialization register value 0xA5A50000. Otherwise, the crashed electronic control unit ECU software will be reset and restarted by the watchdog and jump to the boot program in the BOOT area. The BOOT area reads the 32-bit register value through the boot program, and determines whether the upper 16 bits of the register value are the initialization high value 0xA5A5. If not, the register value is initialized to 0xA5A50000; if yes, the lower 16 bits of the register value are read, and it is determined whether the entire register value exceeds the threshold. If it exceeds the threshold, the factory version is copied from the backup area to the running area for operation, and the reset register value is the initialization register value 0xA5A50000; After the register value is initialized, or the entire register value does not exceed the threshold, or the register value is reset, the value of the lower 16 bits of the register is counted and accumulated and written back to the register, and then the boot program jumps to the running area to run the current software version.

[0014] Furthermore, the backup area includes a factory version backup area and an upgraded version backup area. The upgraded version backup area is used to actively back up the software version that is running normally. When the subsequently upgraded software version runs abnormally, the actively backed-up software version is copied from the upgraded version backup area to the running area to replace the current software version. If the actively backed-up software version still runs abnormally, the factory version is copied from the factory version backup area to the running area to replace the actively backed-up software version. By actively backing up the normally running upgraded version, when the subsequent upgrade is abnormal, it is possible to restore to the previously normally running upgraded version without restoring to the factory version, thereby improving the user experience. At the same time, the user can also actively back up the normally running upgraded version according to his own preferences for subsequent abnormal recovery to suit the user's preferences.

[0015] The advantages and beneficial effects of the present invention are: The present invention provides a software upgrade method and system for an electric-assisted bicycle. By setting an upgrade area and a backup area on the FLASH of the ECU, even if an interruption occurs during the OTA upgrade, the normal operation of the original APP software can be maintained, thereby avoiding the paralysis of the ECU of the electric-assisted bicycle. Even if the upgraded APP software has serious security defects and cannot run normally, the factory version can be restored from the backup area, thereby greatly enhancing the security and stability of the firmware OTA upgrade, so that users do not need to seek factory return for resolution after program problems occur, and can continue to use the software normally. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a structural schematic diagram of a software upgrade system for an electric-assisted bicycle in an embodiment of the present invention.

[0017] Figure 2 It is a flow chart of a software upgrade method for an electric-assisted bicycle in an embodiment of the present invention.

[0018] Figure 3 It is a flowchart of normal operation of the software version based on the register in an embodiment of the present invention.

[0019] Figure 4 It is a flowchart of version recovery based on registers for abnormal software version operation in an embodiment of the present invention. DETAILED DESCRIPTION

[0020] The specific implementation of the present invention is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described here is only used to illustrate and explain the present invention, and is not used to limit the present invention.

[0021] like Figure 1 As shown, a software upgrade system for an electric assisted bicycle includes an electronic control unit ECU, which includes a microcontroller unit MCU and a flash memory chip Flash. The microcontroller unit MCU is a microcontroller CPU of the electronic control unit ECU. The firmware of the electronic control unit ECU runs on the electronic control unit ECU. The flash memory chip FLASH is a storage chip that is not lost when power is off. In the present invention, it is mainly used to store the firmware of the microcontroller unit MCU. The firmware is the software that performs the most basic and lowest level work of the system.

[0022] In order to avoid the situation where the system cannot run normally due to defects in the upgraded version after the version is upgraded, the present invention adopts a method of restoring to the factory version to automatically restore the upgraded version to the factory version. The microcontroller unit MCU is divided into a BOOT area and an APP software running area. The BOOT area is used to store the boot program of the microcontroller unit MCU. The boot program is mainly used for APP software copying, verifying upgrade packages and booting application programs. The running area is used to store application programs, such as business programs of the electronic control unit ECU; the flash memory chip FLASH is divided into a backup area and an upgrade area. The backup area is generally used to back up the factory program, and the upgrade area is an area for storing OTA upgrade packages. The storage space of the application software of the microcontroller unit MCU is usually around 512K, so the required flash memory chip FLASH size is about 1M. Take the electronic control unit ECU as an example: Required hardware resources: name model resource MCU GD32E503VET6 FLASH 512KRAM 128K External FLASH W25Q32 32M Partition size: name size use BOOT Area 32K Storing boot program APP operation area 480K ECU Application APP upgrade area 512K Store ECU application upgrade package APP backup area 512K Backup ECU factory program like Figure 2 As shown, the specific software upgrade method includes the following steps: Step 1: Back up the factory version of the software and copy the factory version of the software in the running area to the backup area.

[0023] During factory production, a blank microcontroller unit MCU will be programmed with the factory program through a programmer, including programming the bootloader in the BOOT area and programming the factory version of the electronic control unit ECU application in the running area; when the system is run for the first time and the backup area is found to be blank, the factory version of the electronic control unit ECU application (APP software) in the running area will be copied to the backup area; at the same time, the system will jump to the running area and run the factory version of the electronic control unit ECU application, thereby storing the factory program of the electronic control unit ECU in the backup area.

[0024] Step 2: When the user needs to perform an OTA version upgrade, the upgraded version of the APP software needs to be copied to the upgrade area and evaluated. If the evaluation requirements are met, the upgrade is successful and the upgraded version is copied to the running area for operation. Otherwise, the upgrade fails and the current version continues to run in the running area. The evaluation of the upgraded version specifically includes the following steps: Step 2.1: Run the boot program in the BOOT area; Step 2.2: The boot program uses the CRC integrity check method to check the upgrade area. When a legitimate new electronic control unit ECU software upgrade version is found in the upgrade area, it is copied to the running area to replace the currently running software version; when the software upgrade version in the APP software upgrade area is found to be incomplete, it jumps directly to the running area and continues to run the factory version of the electronic control unit ECU.

[0025] Step 3: When the software version in the running area runs abnormally, copy the factory version from the backup area to the running area to replace the currently running software version.

[0026] Sometimes, due to defects (bugs) in the software version of the running area, such as incorrect address use when operating the internal Flash, the running area program has been tampered with, resulting in the firmware being unable to run normally. When BOOT starts, it will find that the key software information in the running area has been tampered with. BOOT will re-copy the factory version from the backup area to the running area, so that the software can run normally again.

[0027] like Figure 3 , Figure 4 As shown, the microcontroller unit MCU generally has some registers, which are usually used to ensure that data is not lost when the system is restarted. Although the software version in the running area can run normally, the stability of the software version running status needs to be further confirmed. Here, the registers are used to judge the stability. The specific steps are as follows: Step 3.1: The boot program reads the 32-bit register value and determines whether the upper 16 bits of the register value are 0xA5A5. If not, the register value is initialized to 0xA5A50000 and step 3.2 is executed; if yes, the lower 16 bits of the register value are read and it is determined whether the entire register value exceeds the threshold. The threshold is fixed by the boot program in the BOOT area. In the embodiment of the present invention, the threshold is 10. If it does not exceed, step 3.2 is executed. If it exceeds, step 3.4 is executed; Step 3.2: Count and accumulate the value of the lower 16 bits of the register and write it back to the register. Then, the boot program jumps to the running area to run the current software version. Step 3.3: If the currently running software version can run normally for more than 2 seconds, reset it to 0xA5A50000 after reading the register value. Otherwise, the crashed electronic control unit ECU software will be reset and restarted by the watchdog, jump to the boot program in the BOOT area, and execute step 3.1; Step 3.4: Copy the factory version from the backup area to the running area, reset the register value to 0xA5A50000, and then execute step 3.2; In another embodiment, if Figure 2 , Figure 4 As shown, a second backup area (i.e., user program backup area) is also provided in the system. When the currently running software version can run normally, the user can perform active backup on the client or mobile communication APP end, and store the current software version as a backup version in the user program backup area. When the subsequent upgraded version runs abnormally, the actively backed-up version is first copied from the user program backup area to the running area to replace the currently running software version. If the actively backed-up backup version still runs abnormally, step 3.4 of the above embodiment is executed to automatically restore to the backup factory version.

[0028] For the version in the second backup area, you can actively or automatically update it, and use the subsequent more stable version to update the previous stable version, but for the factory backup program, users cannot actively or automatically change or overwrite it. For example: the factory version is system OS1.0, which is subsequently updated to 2.0, 3.0, and 4.0. Among them, version 3.0 is more stable or more popular with users than the factory version. In order to improve the user experience, users can actively back up version 3.0 to the user program backup area. When it is subsequently upgraded to 5.0 and a problem is found and it cannot run, the system will be restored to version 3.0.

[0029] In another embodiment, a group of backup areas are provided in the system, which actively back up multiple installed software versions in chronological order. When the currently running version is abnormal, the nearest version is restored in reverse chronological order. Among them, the update package based on the factory version as the baseline is actively backed up, that is, only certain modules of the software upgraded this time are updated, rather than the entire software version. When the version is restored, only the update package that has been replaced between the currently running version and the backup version to be restored needs to be replaced, thereby reducing the capacity of the backup area and increasing the speed of version recovery.

[0030] On the other hand, for users who have not upgraded for a long time, there is the problem of cross-version upgrades. Since multiple versions are crossed, if the current version runs abnormally, it can only be restored to an earlier version or the factory version. After setting up a set of backup areas, multiple versions that have not been upgraded can be obtained at one time during cross-version upgrades, and based on step 3 in the above embodiment combined with the chronological reverse version recovery of this embodiment, it is possible to automatically and quickly restore to a stable running version.

[0031] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some or all of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for upgrading software of an electric power-assisted bicycle, characterized in that The steps include: Step 1: Back up the factory version of the software, copy the factory version of the software in the running area to the backup area; Step 2: When upgrading the version, copy the upgraded version of the software to the upgrade area and evaluate the upgraded version. If the evaluation requirements are met, the upgrade is deemed successful and the upgraded version is copied to the running area for operation. Otherwise, the upgrade is deemed to have failed and the current version continues to run in the running area. Step 3: When the current software version in the running area runs abnormally, copy the factory version from the backup area to the running area to replace the current software version.

2. The method for upgrading software of an electric-assisted bicycle according to claim 1, characterized in that: In step 2, the evaluation of the upgraded version specifically includes the following steps: Step 2.1: Run the boot program in the BOOT area; Step 2.2: The boot program performs integrity check on the upgrade area. If a complete upgrade version exists in the upgrade area, the upgrade is deemed successful. Otherwise, the upgrade is deemed to have failed.

3. The method for upgrading software of an electric-assisted bicycle according to claim 1, characterized in that: The step 3 specifically includes the following steps: Step 3.1: Read the register value through the boot program to determine whether the high bit of the register value is the initialized high bit value. If not, after initializing the register value, execute step 3.2; if yes, read the low bit of the register value and determine whether the entire register value exceeds the threshold. If it does not exceed the threshold, execute step 3.2; if it exceeds the threshold, execute step 3.4; Step 3.2: Count and accumulate the value of the low bit of the register, and jump to the running area through the boot program to run the current software version; Step 3.3: If the currently running software version can run normally, the register value is reset to the initialization register value. Otherwise, the software will be reset and restarted, and jump to the boot program in the BOOT area, and execute step 3.1; Step 3.4: Copy the factory version from the backup area to the running area, reset the register value to the initialization register value, and then execute step 3.

2.

4. The method for upgrading software of an electric-assisted bicycle according to claim 1, characterized in that: In step 3, when the current software version in the running area runs normally, it is actively backed up. When the subsequently upgraded software version runs abnormally, the actively backed-up software version is copied from the backup area to the running area to replace the current software version. If the actively backed-up software version still runs abnormally, the factory version is copied from the backup area to the running area to replace the actively backed-up software version.

5. The method for upgrading software of an electric-assisted bicycle according to claim 4, characterized in that: The active backup backs up multiple upgraded versions in chronological order. When a subsequently upgraded software version runs abnormally, the latest version is restored in reverse order according to the chronological order.

6. The method for upgrading software of an electric-assisted bicycle according to claim 5, characterized in that: The active backup is based on the factory version as the baseline update package, only the units of the software upgraded this time are updated. When the version is restored, only the update packages that have been replaced between the currently running software version and the software version to be restored are replaced.

7. The method for upgrading software of an electric-assisted bicycle according to claim 5, characterized in that: When the version is upgraded, the intermediate version between the current upgraded version and the latest software version that is actively backed up is detected, and the update package of the intermediate version is actively backed up in reverse chronological order.

8. A software upgrade system for an electric-assisted bicycle, comprising an electronic control unit, characterized in that: The electronic control unit performs software upgrade according to the software upgrade method of an electric assisted bicycle according to any one of claims 1 to 7. The electronic control unit includes a micro control unit and a flash memory chip. The micro control unit includes a BOOT area and a running area. The flash memory chip includes a backup area and an upgrade area. The BOOT area is used to store a boot program for software version copying, upgrade version evaluation and program booting.

9. The software upgrade system for an electric-assisted bicycle according to claim 8, characterized in that: The electronic control unit is provided with a register cooperating with the micro control unit; If the currently running software version can run normally, the register value will be reset to the initialization register value. Otherwise, the software will be reset and restarted, and jump to the boot program in the BOOT area. The BOOT area reads the register value through the boot program to determine whether the high bit of the register value is the initialization high bit value. If not, the register value is initialized; if so, the low bit of the register value is read and the entire register value is determined to be greater than the threshold. If it is greater than the threshold, the factory version is copied from the backup area to the running area for operation, and the reset register value is the initialization register value. After the register value is initialized, or the entire register value does not exceed the threshold, or the register value is reset, the low-order value of the register is counted and accumulated, and the boot program jumps to the running area to run the current software version.

10. The software upgrade system for an electric-assisted bicycle according to claim 8, characterized in that: The backup area includes a factory version backup area and an upgraded version backup area. The upgraded version backup area is used to actively back up the software version that runs normally. When the subsequently upgraded software version runs abnormally, the actively backed-up software version is copied from the upgraded version backup area to the running area to replace the current software version. If the actively backed-up software version still runs abnormally, the factory version is copied from the factory version backup area to the running area to replace the actively backed-up software version.

Images