Controller program upgrading method and system, storage medium, controller and vehicle

Abstract

The invention discloses a controller program upgrading method and system, a storage medium, a controller and a vehicle, and relates to the technical field of equipment upgrading. The controller program upgrading method comprises the following steps: determining that a bootstrap program of a controller is started; and when a flash request is received, upgrading the controller program by utilizing the burn-in file, and when an upgrading error is detected in the upgrading process, storing upgrading error related information corresponding to the upgrading error into a nonvolatile memory of the controller. The nonvolatile memory is arranged in the controller, and the upgrading error related information corresponding to the upgrading error in the upgrading process is stored in the nonvolatile memory, so that the upgrading error of a controller program can be conveniently read and analyzed subsequently, and a specific upgrading error reason is determined.

Description

Technical Field

[0001] This application relates to the field of equipment upgrade technology, and in particular to a controller program upgrade method, system and storage medium, controller, and vehicle. Background Technology

[0002] To address potential errors during controller program upgrades, related technologies propose introducing program backups to prevent controller malfunctions, upgrade verification to prevent the burning of unauthorized programs, and startup verification to prevent the startup of unauthorized programs.

[0003] However, the aforementioned technologies focus primarily on ensuring the controller functions correctly in the event of an upgrade failure. Analyzing the specific reasons for the upgrade failure requires obtaining complete data from the upgrade process, necessitating additional equipment for recording this data and increasing costs. Furthermore, the large amount of information to be analyzed makes the entire analysis process time-consuming and labor-intensive. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art. Therefore, one objective of this application is to provide a controller program upgrade method, system, storage medium, controller, and vehicle, to simply and conveniently analyze the causes of upgrade errors during the controller program upgrade process.

[0005] In a first aspect, embodiments of this application propose a controller program upgrade method, comprising: determining that the controller's bootloader is started; when a flashing request is received, upgrading the controller program using a flashing file, and when an upgrade error is detected during the upgrade process, storing upgrade error-related information corresponding to the upgrade error into the controller's non-volatile memory.

[0006] According to one embodiment of this application, after determining that the controller's bootloader has started, the method further includes: when no flash request is received, starting the controller program, and when a boot error is detected during the boot process, storing the boot error-related information corresponding to the boot error into the non-volatile memory.

[0007] According to one embodiment of this application, before starting the controller program, the method further includes: sending upgrade error-related information stored in the non-volatile memory to an external device, so that the external device can parse the upgrade error-related information.

[0008] According to one embodiment of this application, the method further includes: when a startup error is detected during the startup process, sending the startup error-related information to an external device so that the external device can parse the startup error-related information.

[0009] According to one embodiment of this application, after storing the upgrade error-related information corresponding to the upgrade error in the non-volatile memory of the controller, the method further includes: restarting the bootloader of the controller.

[0010] According to one embodiment of this application, the upgrade error includes at least one of the following errors:

[0011] The controller does not meet the writing conditions, the fingerprint information writing failed, the number of files burned exceeds the expectation, the starting address of the burned file is invalid, the length of the burned file is invalid, the burned file is duplicated, the burned file is invalid, the burned file contains single packet data with invalid length, the burned file contains single packet data that fails integrity verification, no transmission exit request was received, and the integrity verification of the burned file failed.

[0012] According to one embodiment of this application, the startup error includes at least one of the following errors:

[0013] There is no valid controller program, the controller program loading is abnormal, the flash memory self-test in the controller failed, or the integrity verification of the controller program failed.

[0014] Secondly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the controller program upgrade method described in the first aspect embodiment above.

[0015] Thirdly, embodiments of this application propose a controller for executing the controller program upgrade method described in the first aspect embodiments above.

[0016] Fourthly, embodiments of this application provide a vehicle comprising: the controller described in the third aspect of the embodiments above.

[0017] Fifthly, this application provides a controller program upgrade system, comprising: an external device and the controller described in the third aspect embodiment above; wherein the external device is used to send a flashing request to the controller.

[0018] According to one embodiment of this application, the external device is further configured to: parse error-related information stored in the non-volatile memory of the controller and display the parsing results.

[0019] According to one embodiment of this application, the system further includes: a protocol conversion unit having a USB port and a CAN-FD port, wherein the USB port is connected to the external device, the CAN-FD port is connected to the controller, and the protocol conversion unit is used to convert between the USB communication protocol and the CAN-FD communication protocol.

[0020] The controller program upgrade method, system, storage medium, controller, and vehicle of this application embodiment, by setting non-volatile memory in the controller and storing upgrade error-related information corresponding to upgrade errors during the upgrade process in the non-volatile memory, can facilitate subsequent reading and analysis of upgrade errors in the controller program and determine the specific cause of the upgrade error. Attached Figure Description

[0021] Figure 1 This is a flowchart of a controller program upgrade method according to an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of the structure for implementing a controller program upgrade method according to an embodiment of this application;

[0023] Figure 3 This is a flowchart of a controller program upgrade method according to another embodiment of this application;

[0024] Figure 4 This is a flowchart of a controller program upgrade method according to a specific embodiment of this application;

[0025] Figure 5 This is a structural block diagram of the controller according to an embodiment of this application;

[0026] Figure 6 This is a structural block diagram of the vehicle according to an embodiment of this application;

[0027] Figure 7 This is a structural block diagram of a controller program upgrade system according to an embodiment of this application;

[0028] Figure 8 This is a structural block diagram of a controller program upgrade system according to another embodiment of this application.

[0029] Figure label:

[0030] Controller 500, processor 501, memory 503, bus 502, transceiver 504;

[0031] Vehicle 600, controller program upgrade system 700, external equipment 710, protocol conversion unit 720. Detailed Implementation

[0032] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0033] Controllers (such as vehicle controllers) require extensive testing during development, which involves frequent controller program upgrades. The controller program upgrade process includes dividing the controller's internal flash memory into a bootloader area and an application program (APP) area. The bootloader area is responsible for determining whether there is a program upgrade request. If so, it receives the program upgrade request and writes the received file to the APP area, thus completing the controller program upgrade.

[0034] Due to various reasons (such as power outages, incorrect file installation, etc.), upgrade errors may occur during controller upgrades. To address this, related technologies introduce program backups to prevent controller malfunction, upgrade verification to prevent the installation of unauthorized programs, and startup verification to prevent the startup of unauthorized programs. However, these technologies are mostly designed to ensure the controller can function normally when upgrade errors occur; they lack corresponding error diagnosis and logging capabilities. To analyze the specific reasons for upgrade failures, complete data information from the upgrade process needs to be read, which requires an external device with data logging capabilities (i.e., capable of recording this complete data information). However, in actual controller program upgrades, the upgrade device itself may not have data logging capabilities or may be a detachable controller. Obtaining complete data information would increase costs, and the entire operation and analysis process would be time-consuming and labor-intensive.

[0035] Based on this, this application proposes a controller program upgrade method with error cause diagnosis and error information recording. This method can determine the cause of upgrade errors without relying on external devices with storage capabilities or the loss of communication data during the upgrade, reducing the difficulty and cost of troubleshooting program upgrade errors and improving the efficiency of resolving controller program upgrade failures. Furthermore, based on the controller program upgrade method, this application also proposes a computer-readable storage medium, a controller, a vehicle, and a controller program upgrade system.

[0036] The following description, with reference to the accompanying drawings, outlines a controller program upgrade method, system, storage medium, controller, and vehicle according to embodiments of this application.

[0037] Figure 1This is a flowchart of a controller program upgrade method according to an embodiment of this application. The method can be executed by a controller, which can be the ECU (Electronic Controller Unit) of a vehicle to be upgraded. This controller has FLASH, non-volatile memory (such as EEPROM (Electrically Erasable Programmable Read-Only Memory)), and RAM (Random Access Memory), etc. Figure 2 As shown in the diagram. FLASH memory is used for controller upgrade detection and writing the controller's programming file; non-volatile memory is used to store upgrade error information and startup error information related to the controller program; and RAM is used to store some temporary data during the controller program upgrade or startup process.

[0038] like Figure 1 As shown, the controller program upgrade method includes:

[0039] S11, confirm that the controller's bootloader has started.

[0040] S12, when a flashing request is received, the controller program is upgraded using the flashing file, and if an upgrade error is detected during the upgrade process, the upgrade error-related information is stored in the controller's non-volatile memory.

[0041] Upgrade errors can include at least one of the following: controller does not meet the flashing conditions, fingerprint information writing fails, the number of files burned exceeds expectations, the starting address of the burned file is invalid, the length of the burned file is invalid, the burned file contains duplicates, the burned file is invalid, the burned file contains single-packet data of invalid length, the burned file contains single-packet data that fails integrity verification, no transmission exit request is received, and the integrity verification of the burned file fails. The upgrade error-related information can be parameterized data, including: upgrade error encoding information, the write address and write length of the corresponding data (the data where the error occurred), etc. Parameterizing upgrade errors can reduce the amount of data and facilitate subsequent upgrade misalignment analysis. For example, when the controller does not meet the flashing conditions, the NoFlashCond flag is set to 1, and the corresponding upgrade error-related information includes encoding information (such as the NoFlashCond flag encoding and its value), the write address and write length of the corresponding data, etc.

[0042] Specifically, after the controller is powered on, the bootloader program is started first. Once started, if a flash request is received within the target time threshold (which can be preset as needed), the bootloader program will proceed with the controller program upgrade process. This includes upgrading the controller program using a flash file, and if an upgrade error is detected during the upgrade process, storing the relevant upgrade error information in the controller's non-volatile memory (memory whose data is retained even when the power is turned off). The flash request can be initiated via... Figure 2 The PC's FLASH UI interface (also known as the burning interface) is shown for input.

[0043] By setting up non-volatile memory in the controller and storing upgrade error-related information corresponding to upgrade errors during the upgrade process in non-volatile memory, it is convenient to read and analyze upgrade errors in the controller program later and determine the specific cause of the upgrade error.

[0044] In some embodiments of this application, such as Figure 3 As shown, after determining that the controller's bootloader has started, the method further includes:

[0045] S13, when no write request is received, start the controller program, and when a startup error is detected during the startup process, store the startup error-related information to non-volatile memory.

[0046] Startup errors can include at least one of the following: no valid controller program exists, controller program loading error, flash memory self-test failure in the controller, or controller program integrity verification failure. The startup error-related information can be parameterized data, including: startup error encoding information, the read address and read length of the corresponding data, signature verification results, etc. For example, if no valid controller program exists, the NoValidAPP flag is set to 1, and the corresponding startup error-related information includes encoding information (such as the NoValidAPP flag encoding and its value), the read address and read length of the corresponding data (the data where the error occurred), etc.

[0047] Specifically, if the bootloader program area determines that no flashing request has been received within the target time threshold (which can be set in advance as needed), it jumps to the APP program area, where the controller's functions are implemented, i.e., the controller program startup process begins. This includes starting the controller program and, if a startup error is detected during the startup process, storing the startup error-related information to non-volatile memory.

[0048] By storing startup error information corresponding to startup errors during the startup process in non-volatile memory, it is convenient to read and analyze startup errors in the controller program later and determine the specific cause of the startup error.

[0049] In some embodiments of this application, before starting the controller program, upgrade error-related information stored in non-volatile memory is also sent to an external device so that the external device can parse the upgrade error-related information.

[0050] Specifically, once the controller program upgrade is complete, the bootloader's functionality is finished. To run the upgraded controller program at this point, the bootloader needs to be restarted. If the controller is connected to an external device, such as a host PC (e.g., ...), ... Figure 2 As shown in Table 1, after the bootloader is started, the controller can automatically send the upgrade error related information stored in the EEPROM to the external device, so that the external device can parse the upgrade error related information. If no flash request is received within the target time threshold, the controller program will start. When the upgrade error related information is: Byte0 is 0x1, Byte1 is 0x1 (0x11 can be considered upgrade error encoding information), the host computer can parse and display the APP program flash burning error. Of course, if there is no upgrade error related information in the EEPROM, the host computer's parsing result can show no upgrade error or be empty (i.e., no upgrade error result is displayed). The parsing result can be obtained through... Figure 2 The PC's DIAG UI interface (also known as the error message interface) is shown.

[0051] Table 1

[0052]

[0053]

[0054] In some embodiments of this application, after storing upgrade error-related information corresponding to the upgrade error in the controller's non-volatile memory, the controller's bootloader is also restarted.

[0055] By automatically restarting the controller's bootloader after the upgrade is complete, and sending error-related information to external devices for parsing, the cause of upgrade errors can be detected and located in a timely manner when upgrade errors occur.

[0056] It should be noted that after the upgrade is complete, if no upgrade errors occur during the upgrade process, the upgraded controller program will be started after restarting the controller's bootloader and if no flash request is received within the target time threshold. If upgrade errors occur during the upgrade process, the controller program before or after the upgrade can be started after restarting the controller's bootloader and if no flash request is received within the target time threshold.

[0057] In some embodiments of this application, when a startup error is detected during the startup process, startup error-related information is sent to an external device so that the external device can parse the startup error-related information.

[0058] Specifically, when a startup error is detected during the startup process, startup error-related information is sent to an external device, such as a host computer (e.g., a PC). Figure 2 As shown in Table 1 above, when the startup error information is: Byte0 is 0x3, Byte1 is 0x1 (0x31 can be considered as startup error encoding information), the host computer can parse and display the error message indicating an error in reading the APP program from Flash. Of course, if a startup error is detected, the host computer's parsing result can either display "no startup error" or be empty (i.e., no startup error result is displayed). The parsing result can be obtained through... Figure 2 The PC's DIAG UI interface (also known as the error message interface) is shown.

[0059] In the embodiments of this application, such as Figure 2 As shown, communication between the controller (such as an ECU) and external devices (such as a PC) can be achieved through a protocol conversion unit. This protocol conversion unit has a USB (Universal Serial Bus) port and a CAN-FD (Controller Area Network with Flexible Data rate) port. The USB port connects to the external device, and the CAN-FD port connects to the controller. The protocol conversion unit is used to convert between the USB communication protocol and the CAN-FD communication protocol.

[0060] The following is combined Figure 4 The upgrade process of the controller program is described through a specific embodiment.

[0061] like Figure 4 As shown, the upgrade process for the controller program includes:

[0062] S41, Start the bootloader.

[0063] S42, read the write flag.

[0064] S43, determine if there is a flash request.

[0065] Specifically, the presence of a write request can be determined by the write flag. For example, if the write flag is detected as 1 within the target time threshold, it indicates that there is a write request; otherwise, it indicates that there is no write request.

[0066] If there is a write request, proceed to step S441; otherwise, proceed to step S451.

[0067] S441, determine whether the controller meets the flashing conditions.

[0068] The flashing conditions for the controller can be set as needed, such as: 1) the controller is powered on; 2) the controller voltage is greater than the target voltage threshold (which can be set as needed) and lasts for a certain period of time; 3) the vehicle battery power is greater than the target power threshold (such as 50%, 60%, etc.); 4) the vehicle is in the target state, such as the vehicle speed is less than the target vehicle speed threshold and the gear is the preset gear, etc.

[0069] If satisfied, proceed to step S442; otherwise, set the NoFlashCon flag to 1 and proceed to step S47.

[0070] S442, write fingerprint information and determine whether the fingerprint information was successfully written.

[0071] The fingerprint information may include the time when the controller program was written, the supplier information of the writing tool, and the serial number of the writing program.

[0072] If the write is successful, proceed to step S443; otherwise, set the NovalidAPP flag to 1 and proceed to step S47.

[0073] S443, awaiting burn-in request.

[0074] S444, determine whether a reset request has been received.

[0075] If received, proceed to step S47; otherwise, proceed to step S445.

[0076] S445 determines whether the file burning information has been received.

[0077] If received, proceed to step S446 (including S4461-S4465); otherwise, proceed to step S443.

[0078] S4461, increment FlashFileNumber by 1.

[0079] FlashFileNumber refers to the number of files burned.

[0080] S4462 determines whether the number of files burned exceeds expectations.

[0081] If so, set the FlashFileOver flag to 1 and proceed to step S47; otherwise, proceed to step S4463.

[0082] S4463 checks if the starting address of the file to be burned is valid.

[0083] If yes, then execute S4464; otherwise, set the FileAddrError flag to 1 and proceed to step S47.

[0084] S4464 checks if the length of the file to be burned is valid.

[0085] If yes, proceed to step S4465; otherwise, set the FileLenError flag to 1 and proceed to step S47.

[0086] S4465 checks if the burned file is a duplicate.

[0087] If so, set the FileRepetError flag to 1 and proceed to step S47; otherwise, execute step S447 (including S4471-S4473).

[0088] S4471, verify whether the burned file is valid.

[0089] If yes, proceed to step S; otherwise, set the FileNotValid flag to 1 and proceed to step S47.

[0090] S4472, verify whether the length of a single packet of data is valid.

[0091] The file to be burned may include one or more individual data packages.

[0092] If yes, proceed to step S4473; otherwise, set the PacLenError flag to 1 and proceed to step S47.

[0093] S4473, determine whether the single packet data integrity verification passes.

[0094] If yes, proceed to step S448; otherwise, set the PacCheckError flag to 1 and proceed to step S47.

[0095] S448, determine whether a transmission exit request has been received.

[0096] If yes, proceed to step S449; otherwise, set the NoExitReq flag to 1 and proceed to step S47.

[0097] S449, determine whether the data integrity verification passed.

[0098] If yes, proceed to step S443; otherwise, set the FileCheckError flag to 1 and proceed to step S47.

[0099] S451, determine if a valid APP program exists.

[0100] If it exists, proceed to step S452; otherwise, set the NoValidAPP flag to 1 and proceed to step S46.

[0101] S452, Loading the APP program.

[0102] S453, determine if the loading process is normal.

[0103] If yes, proceed to step S456; otherwise, set the LoadAPPFail flag to 1 and proceed to step S454.

[0104] S454, Flash self-test.

[0105] S455 determines whether the Flash self-test was successful.

[0106] If yes, proceed to step S46; otherwise, set the CheckFlashFail flag to 1 and proceed to step S46.

[0107] S456, APP program integrity verification.

[0108] S457, check if the verification passed.

[0109] If yes, proceed to step S458; otherwise, set the CheckAPPFail flag to 1 and proceed to step S46.

[0110] S458, launch the APP program.

[0111] S459, including S4591-S4593 below.

[0112] S4591, run the APP program.

[0113] S4592, determine whether a flash request has been received.

[0114] If yes, proceed to step S4593; otherwise, proceed to step S4591.

[0115] S4593, record write flag.

[0116] After recording the write flag, proceed directly to step S49.

[0117] S46 sends the flag information to the external device.

[0118] Specifically, during the startup process, the detected startup error flag information can be sent to an external device immediately (e.g., via CAN-FD message), and step S47 can be executed simultaneously or after sending it to the external device. The external device can parse the error flag bit (i.e., error code) and the error reason (including error type) and display them in the DIAG UI interface.

[0119] S47, determine the cause of the error and record it in FaultReasonInfo.

[0120] Among them, FaultReasonInfo can represent information that records the reason for the error.

[0121] S48, save error-related information to EEPROM.

[0122] Error-related information may include error codes (such as the flags mentioned above) and FaultReasonInfo.

[0123] S49, restart the bootloader.

[0124] After restarting the bootloader, proceed to step S42, and simultaneously send the error-related information stored in the EEPROM to an external device for parsing, so as to locate the error and find the cause of the error.

[0125] The controller program upgrade method of this application embodiment can store upgrade error-related information in the controller's non-volatile memory when an upgrade error occurs during the controller program upgrade process. This non-volatile memory can be sent to an external device when the bootloader is restarted, allowing the external device to pinpoint the specific cause of the error even in the absence of upgrade process communication data, facilitating troubleshooting or resolving the problem by on-site operators. Simultaneously, in the event of a controller program startup failure, startup error-related information can be automatically sent to an external device, enabling the external device to pinpoint the specific cause of the startup error, facilitating troubleshooting or resolving the problem by on-site operators.

[0126] Based on the controller program upgrade method of the above embodiments, this application proposes a computer-readable storage medium.

[0127] In the embodiments of this application, a computer program is stored thereon, characterized in that, when the computer program is executed by a processor, it implements the controller program upgrade method of the above embodiments.

[0128] Based on the controller program upgrade method of the above embodiments, this application also proposes a controller.

[0129] In this embodiment, the controller is used to execute the controller program upgrade method described in the above embodiment.

[0130] In some embodiments of this application, such as Figure 5 As shown, the controller 500 includes a processor 501 and a memory 503. The processor 501 and the memory 503 are connected, for example, via a bus 502. Optionally, the controller 500 may also include a transceiver 504. It should be noted that in practical applications, the transceiver 504 is not limited to one type, and the structure of the controller 500 does not constitute a limitation on the embodiments of this application.

[0131] Processor 501 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 501 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0132] Bus 502 may include a pathway for transmitting information between the aforementioned components. Bus 502 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 502 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0133] The memory 503 stores a computer program corresponding to the controller program upgrade method of the above embodiments of this application. This computer program is executed under the control of the processor 501. The processor 501 executes the computer program stored in the memory 503 to implement the content shown in the foregoing method embodiments.

[0134] The controller 500 includes, but is not limited to, the vehicle's ECU. Figure 5 The controller 500 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0135] Figure 6 This is a structural block diagram of a vehicle according to an embodiment of this application.

[0136] like Figure 6 As shown, the vehicle 600 includes: the controller 500 of the above embodiment.

[0137] Figure 7 This is a structural block diagram of the controller program upgrade system 700 according to an embodiment of this application.

[0138] like Figure 7 As shown, the controller program upgrade system 700 includes: an external device 710 and a controller 500 as described in the above embodiment.

[0139] Among them, the external device 710 can be a host computer used to send a flash request to the controller 500.

[0140] In some embodiments of this application, the external device 710 is also used to: parse error-related information stored in the non-volatile memory of the controller 500 and display the parsing results.

[0141] In some embodiments of this application, such as Figure 8 As shown, the controller program upgrade system 700 also includes a protocol conversion unit 720.

[0142] In this embodiment, the protocol conversion unit 720 has a USB port 721 and a CAN-FD port 722. The USB port 721 is connected to the external device 710, and the CAN-FD port 722 is connected to the controller 500. The protocol conversion unit 720 is used to convert between the USB communication protocol and the CAN-FD communication protocol.

[0143] It should be noted that for other specific implementations of the controller program upgrade system 700 in this application embodiment, please refer to the specific implementations of the controller program upgrade method in the above embodiments.

[0144] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0145] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0146] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0147] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0148] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0149] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0150] In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0151] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A controller program upgrade method characterized by, The method comprises: determining that a boot program of a controller is started; when a flashing request is received, upgrading a controller program by using a burn-in file, and storing upgrade error related information corresponding to an upgrade error detected during the upgrading to a non-volatile memory of the controller.

2. The controller program upgrade method according to claim 1, wherein After determining that the boot program of the controller is started, the method further comprises: when the flashing request is not received, starting the controller program, and storing start error related information corresponding to a start error detected during the starting to the non-volatile memory.

3. The controller program upgrade method according to claim 2, wherein Before starting the controller program, the method further comprises: sending the upgrade error related information stored in the non-volatile memory to an external device, so that the external device analyzes the upgrade error related information.

4. The controller program upgrade method according to claim 2 or 3, characterized by, The method further comprises: when the start error is detected during the starting, sending the start error related information to the external device, so that the external device analyzes the start error related information.

5. The controller program upgrade method according to any one of claims 1 to 4, characterized by, After storing the upgrade error related information corresponding to the upgrade error to the non-volatile memory of the controller, the method further comprises: restarting the boot program of the controller.

6. The controller program upgrade method according to any one of claims 1 to 5, characterized by, The upgrade error comprises at least one of the following errors: the controller does not meet a flashing condition, fingerprint information writing fails, the number of the burn-in files exceeds an expectation, a start address of the burn-in file is invalid, a length of the burn-in file is invalid, the burn-in file is repeated, the burn-in file is illegal, there is single packet data with invalid length in the burn-in file, there is single packet data with failed integrity check in the burn-in file, a transmission exit request is not received, and the integrity check of the burn-in file fails.

7. The controller program upgrade method according to any one of claims 1 to 6, wherein The start error comprises at least one of the following errors: there is no valid controller program, controller program loading is abnormal, flash self-checking in the controller fails, and the integrity check of the controller program fails.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement the controller program upgrading method according to any one of claims 1-7.

9. A controller characterized by comprising: A computer program product for executing the controller program upgrading method according to any one of claims 1-7.

10. A vehicle characterized by comprising: The method comprises: the controller according to claim 9.

11. A controller program upgrade system, comprising: The system comprises an external device and the controller according to claim 9; The external device is configured to send a flashing request to the controller.

12. The controller program upgrade system of claim 11, wherein, The external device is further configured to: analyze the error related information stored in the non-volatile memory of the controller, and display an analysis result.

13. The controller program upgrade system of claim 11 or 12, wherein, The system further comprises: a protocol conversion unit having a USB port and a CAN-FD port, the USB port being connected with the external device, and the CAN-FD port being connected with the controller, the protocol conversion unit being configured to implement conversion between a USB communication protocol and a CAN-FD communication protocol.

Images