A method and system for updating the program of a multi-motor controller based on CAN communication

Abstract

This application belongs to the field of software update control technology and discloses a method and system for updating the program of a multi-motor controller based on CAN communication. Utilizing CAN communication, it achieves parallel updates of multiple motor controllers by sending program update request commands, program update data packets, and device update completion query data packets in stages at different preset time intervals, and receiving corresponding feedback messages. Based on the received messages and the number of devices to be updated, it determines the number of devices not allowed to be updated, the number of devices that have not received data, and the number of devices that have not completed the update, and sends corresponding failure messages, introducing an effective fault judgment and feedback mechanism, thereby enabling timely identification and handling of abnormal situations during the update process. Therefore, it significantly improves the efficiency and reliability of multi-motor controller program updates, overcomes the shortcomings of time-consuming and cumbersome batch updates in existing technologies, and provides an efficient and stable solution for the rapid iteration and batch deployment of motor controller software.

Description

Technical Field

[0001] This application relates to the field of software update control technology, and more specifically, to a method and system for updating the program of a multi-motor controller based on CAN communication. Background Technology

[0002] During the development and mass production phases of motor controller software, as product functional requirements are constantly updated, the motor controller program needs to undergo continuous iteration and often faces the need for batch program updates. When updating the program, a dedicated downloader is typically used, connecting the host computer to the JTAG debugging interface on the motor controller, and then downloading the latest program to each motor controller one by one. To improve operational efficiency and convenience, the industry commonly uses the Bootloader method for program updates.

[0003] When updating the program using the Bootloader method, the host computer sends an online upgrade command and the application to be updated via a specific communication method. Upon receiving the online upgrade command, the motor controller's main control chip switches to Bootloader mode, responds to the program update command, and performs initialization operations. Subsequently, the main control chip receives the updated program data, temporarily stores it in the RAM cache, verifies it, and then writes it to the Flash memory, thus completing the online update of the application.

[0004] However, due to the relatively low development difficulty of program update methods based on traditional serial communication, most existing technologies still use traditional serial communication for bootloader program updates. This traditional serial communication method has significant problems when handling online updates of multiple motor controller programs: First, single-ended communication signals are susceptible to electromagnetic interference, resulting in poor anti-interference capabilities and affecting the stability of program updates; second, the lack of an effective fault diagnosis mechanism during program updates makes it difficult to quickly locate fault information if online updates of multiple motor controllers fail, increasing the difficulty of troubleshooting and resolving problems; most importantly, traditional serial communication cannot achieve simultaneous updates of multiple motor controllers, requiring bootloader program updates for each motor controller individually, which greatly reduces update efficiency, especially when batch updates of a large number of motor controllers are needed, making it time-consuming and cumbersome. Therefore, there is an urgent need for a solution that can improve the efficiency and reliability of program updates for multiple motor controllers.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] The purpose of this application is to provide a method and system for updating the program of a multi-motor controller based on CAN communication, which aims to solve the problems of low update efficiency and poor reliability in the prior art when updating the program of multiple motor controllers online, such as the susceptibility of single-end communication signals to electromagnetic interference, the lack of an effective fault judgment mechanism, and the inability to update multiple motor controllers simultaneously.

[0007] In a first aspect, this application provides a method for updating the program of a multi-motor controller based on CAN communication, which is applied to a host computer for updating the program of multiple motor controllers. The method includes the following steps:

[0008] A1. Set the number of devices to be updated based on the number of motor controllers to be updated;

[0009] A2. Within a first preset time period, send a program update request instruction to all the motor controllers to be updated via CAN communication, and receive an update permission message returned by the motor controllers to be updated;

[0010] A3. Based on the number of devices allowed to update and the number of devices to be updated, determined according to the received allowed update message, determine the number of devices not allowed to update and send the corresponding disallowed update message;

[0011] A4. Within a second preset time period, send a program update data packet to all the motor controllers to be updated via CAN communication, and receive a successful data reception message returned by the motor controllers to be updated;

[0012] A5. Based on the number of devices that have received the update program and the number of devices to be updated, determined according to the received update permission message, determine the number of devices that have not received data and send the corresponding update program failure message;

[0013] A6. Within a third preset time period, send a device update completion query data packet to all the motor controllers to be updated via CAN communication, and receive the update completion message returned by the motor controllers to be updated;

[0014] A7. Based on the number of devices that have completed the update and the number of devices to be updated, determined from the received update completion message, determine the number of devices that have not completed the update, and send a device update program success message and a device update program failure message.

[0015] Secondly, this application provides a multi-motor controller program update system based on CAN communication, including a host computer, a CAN communication module, a CAN bus, and multiple motor controllers. The host computer communicates with the multiple motor controllers through the CAN communication module and the CAN bus.

[0016] The motor controller includes a main control chip, which has RAM memory and Flash memory. The Flash memory includes a Bootloader sector and an application sector. The RAM memory is used to temporarily store programs that need to be updated. The Bootloader sector is used to guide the motor controller to perform program updates. The application sector is used to store programs that the motor controller will execute.

[0017] The host computer is used to execute the steps of the multi-motor controller program update method based on CAN communication described above.

[0018] Beneficial Effects: This application provides a method and system for updating multi-motor controller programs based on CAN communication. By utilizing CAN communication for multi-motor controller program updates, it effectively solves the problems of poor anti-interference, lack of effective fault diagnosis mechanisms, and inability to update multiple motor controllers simultaneously when updating multiple devices using traditional serial communication. Specifically, by sending program update request commands, program update data packets, and device update completion query data packets in stages at different preset time intervals, and receiving corresponding feedback messages, parallel updates of multiple motor controllers are achieved. Simultaneously, by determining the number of devices not allowed to update, the number of devices that have not received data, and the number of devices that have not completed updates based on the received messages and the number of devices to be updated, and sending corresponding failure messages, this application introduces an effective fault diagnosis and feedback mechanism, enabling the host computer to promptly identify and handle abnormal situations during the update process. Therefore, the technical solution of this application significantly improves the efficiency and reliability of multi-motor controller program updates, overcomes the shortcomings of time-consuming and cumbersome batch updates in existing technologies, and provides an efficient and stable solution for the rapid iteration and batch deployment of motor controller software. Attached Figure Description

[0019] Figure 1 A flowchart of a multi-motor controller program update method based on CAN communication provided in this application.

[0020] Figure 2 This application provides a schematic diagram of a multi-motor controller program update system based on CAN communication.

[0021] Labeling Explanation: 1. Host Computer; 2. CAN Communication Module; 3. CAN Bus; 4. Motor Controller; 401. RAM Memory; 402. Flash Memory. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] Please refer to Figure 1 This application discloses a method for updating the program of a multi-motor controller based on CAN communication in some embodiments, which is applied to a host computer to update the program of multiple motor controllers. The method includes the following steps:

[0025] A1. Set the number of devices to be updated based on the number of motor controllers to be updated;

[0026] A2. Within the first preset time, send a program update request command to all motor controllers to be updated via CAN communication, and receive an update permission message returned by the motor controllers to be updated;

[0027] A3. Based on the number of devices allowed to update and the number of devices to be updated determined from the received allow update messages, determine the number of devices not allowed to update and send the corresponding disallow update messages;

[0028] A4. Within the second preset time, send the program update data packet to all motor controllers to be updated via CAN communication, and receive the data reception success message returned by the motor controllers to be updated;

[0029] A5. Based on the number of devices that have received the update program and the number of devices to be updated, determined from the received allow update message, determine the number of devices that have not received data and send the corresponding fail update program message;

[0030] A6. Within the third preset time period, send a device update completion query data packet to all motor controllers to be updated via CAN communication, and receive the update completion message returned by the motor controllers to be updated;

[0031] A7. Based on the number of devices that have completed the update and the number of devices that are yet to be updated, determined from the received update completion message, determine the number of devices that have not completed the update, and send device update program success message and device update program failure message.

[0032] First, step A1 aims to clarify the target scope of this program update. For example, the host computer can pre-configure or determine the total number of motor controllers that need to be updated by scanning the network, and record this number as the number of devices to be updated.

[0033] Secondly, step A2 is the program update initiation phase. The host computer broadcasts a program update request command to all target motor controllers, prompting them to enter update mode. Simultaneously, the host computer listens to the CAN bus, receiving update permission messages from motor controllers that are ready to update. For example, when a motor controller receives the program update request command, it performs a self-test, jumps to the Bootloader program entry point, and then sends an update permission message in response.

[0034] Next, step A3 is used to perform preliminary screening and feedback on the device status before the update begins. The host computer counts the actual number of responding and ready-to-update motor controllers based on the update permission messages received within the first preset time. If this number does not match the preset number of devices to be updated, the number of devices that failed to respond or are not allowed to update is calculated, and a corresponding update disallowed message is sent (this message can be displayed on the local monitor or sent to the monitoring terminal; subsequent update failure messages, device update success messages, and device update failure messages are similar) for subsequent processing or troubleshooting.

[0035] Subsequently, step A4 is the core stage of program data transmission. The host computer sends the program data packet to be updated to all motor controllers via the CAN bus. After successfully receiving and temporarily storing the data packet, each motor controller sends a data reception success message as confirmation. For example, after receiving the program update data packet, the motor controller will temporarily store it in the RAM memory of the main control chip and then send a data reception success message.

[0036] Next, step A5 is used for real-time monitoring and anomaly handling during data transmission. The host computer counts the number of motor controllers that successfully received data packets based on the received data success messages within the second preset time. If any devices fail to receive all data packets, the number of devices that did not receive data is calculated, and a reception update program failure message is sent for subsequent processing or troubleshooting.

[0037] Furthermore, step A6 is the verification and confirmation phase of the program update. After the program update data packet is sent, the host computer sends a device update completion query data packet to inquire whether the motor controller has completed writing the program. After completing the program writing, the motor controller will send an update completion message in response. For example, after the motor controller has written the entire program from the RAM memory of the main control chip to the Flash memory of the main control chip, it will send back an update completion message in response to the device update completion query data packet.

[0038] Finally, step A7 provides the final result feedback for the entire update process. Based on the update completion messages received within the third preset time period, the host computer counts the number of motor controllers that successfully completed the program update. Simultaneously, it calculates the number of devices that failed to complete the update and sends corresponding success or failure messages, thus gaining a comprehensive understanding of the results of this batch update.

[0039] This application effectively solves the problems of low efficiency and poor reliability in the program update of multi-motor controllers in the prior art because it fully utilizes the multi-master, broadcast, and high reliability characteristics of CAN communication and introduces a multi-stage feedback and verification mechanism. It is precisely because clear request, response, data transmission, and completion confirmation processes are set up at each critical stage of the program update, supplemented by real-time statistics and feedback of device status, that the host computer can accurately grasp the update progress and status of each motor controller and promptly detect and handle abnormal situations.

[0040] Compared to traditional serial communication, the CAN communication-based multi-motor controller program update method of this application has significant advantages. Traditional serial communication is usually a point-to-point connection, which cannot achieve parallel updates of multiple devices and requires operation one by one, resulting in low efficiency. This application, however, uses CAN bus for broadcast communication, allowing the host computer to simultaneously send commands and data packets to all motor controllers to be updated, greatly improving the efficiency of batch updates. Furthermore, CAN communication itself has strong anti-electromagnetic interference capabilities and error detection mechanisms, effectively ensuring the stability and reliability of data transmission and avoiding the problem of update failure caused by interference in traditional serial communication. More importantly, this application introduces detailed feedback and verification mechanisms at multiple stages of the program update, including the reception and statistics of update permission messages, data reception success messages, and update completion messages, as well as the determination and feedback of the number of devices not allowed to update, the number of devices that did not receive data, and the number of devices that did not complete the update. This multi-level fault diagnosis mechanism enables the host computer to quickly locate the devices and causes of update failures, significantly improving the efficiency of fault diagnosis and problem solving, thereby comprehensively improving the efficiency and reliability of multi-motor controller program updates.

[0041] Traditional multi-motor controller program update methods simply describe sending a request command and receiving an update permission message when making a program update request, but do not detail how to effectively manage and confirm the response status of each motor controller to be updated in a multi-device environment. For example, when there are multiple motor controllers to be updated, if only a request is sent once or the response is not effectively tracked, some motor controllers may fail to respond in time due to communication delays, busy conditions, or other reasons. This makes it impossible to accurately determine which devices are ready to enter the update state, thus affecting the reliability and efficiency of the subsequent program update process.

[0042] Therefore, in some preferred embodiments, step A2 includes:

[0043] A201. Within the first preset time period, continuously send program update request commands to all motor controllers to be updated via CAN communication;

[0044] A202. Create a device list and receive an update permission message from the motor controller to be updated within a first preset time; the device list contains data bits corresponding to each motor controller to be updated.

[0045] A203. Based on the received allow update message, set the corresponding data bit in the device list until the first preset time ends.

[0046] Specifically, in step A201, program update request commands are continuously sent to all motor controllers to be updated within a first preset time period. The purpose is to ensure that, even in a CAN bus communication environment where data conflicts, message loss, or motor controller processing delays occur, all motor controllers to be updated receive the program update request commands to the greatest extent possible, thereby improving the reliability of the request command delivery. The duration of the first preset time period can be set according to actual needs.

[0047] In step A202, creating the device list can be understood as establishing a data structure in the host computer to record the response status of each motor controller to be updated. This device list can be a bitmap, a Boolean array, or any structure that can represent the status of each motor controller in the form of data bits. Each data bit corresponds one-to-one with a specific motor controller to be updated; for example, the first data bit corresponds to the first motor controller, the second data bit corresponds to the second motor controller, and so on.

[0048] In practical applications, step A203, setting the corresponding data bit in the device list based on the received update permission message, means that when the host computer receives an update permission message from a motor controller to be updated, it finds the corresponding data bit in the device list based on the device identification information (e.g., CAN ID) contained in the message and sets its status from the initial value (e.g., 0) to the responded state (e.g., 1). This process continues until the end of the first preset time, at which point the device list will reflect the status of all motor controllers that have responded within the specified time.

[0049] This application's solution effectively solves the technical problem of ensuring all devices receive the request and accurately identify the responding device in a multi-motor controller environment by continuously sending program update request commands within a first preset time and combining this with a device list to track and record received allowable update messages in real time. The continuous sending mechanism improves the request delivery rate, while the introduction of the device list provides a refined state management method, enabling the host computer to clearly grasp the response status of each motor controller to be updated. Therefore, even if some devices respond slowly or experience communication interruptions at specific times, as long as they successfully respond within the first preset time, their status can be accurately recorded, thus avoiding update omissions or errors caused by a single request or rough judgment.

[0050] The above technical solution significantly improves the reliability and accuracy of the request phase during multi-motor controller program updates. The host computer can monitor the response status of each motor controller to be updated in real time and comprehensively, effectively identifying and recording all devices ready for update. This avoids interruptions in the update process or failures of some devices to successfully enter the update state due to communication uncertainties or differences in device responses. This not only enhances the stability of the overall update process but also lays a solid foundation for subsequent data transmission and update completion confirmation.

[0051] Specifically, in some of the above embodiments, the host computer sends a program update request command to all motor controllers to be updated via CAN communication within a first preset time period, and receives an update permission message returned by the motor controllers to be updated. To ensure the smooth progress and reliability of the program update process, it is necessary to specify the timing of sending the update permission message.

[0052] Therefore, in some implementations, update messages are allowed to be sent back by the motor controller to be updated after responding to the program update request instruction and jumping to the Bootloader program entry point.

[0053] When the host computer sends a program update request command to the motor controller to be updated via CAN communication, the motor controller receives the command. Upon receiving the command, the motor controller performs a series of internal operations, a crucial step of which is jumping to its internal Bootloader program entry point. The Bootloader program is a small program pre-programmed into the motor controller, whose main functions are to boot the device and perform firmware updates. Only after the motor controller successfully enters Bootloader mode is it ready to receive new program data. In this state, the motor controller sends an update permission message back to the host computer, indicating that it is ready to perform a program update.

[0054] The solution in this application limits the sending of update messages to only after the motor controller to be updated has responded to the program update request instruction and successfully jumped to the Bootloader program entry point. This ensures that the host computer, upon receiving the message, can clearly recognize that the motor controller to be updated has entered the correct update mode. This mechanism prevents the host computer from sending program update data packets before the motor controller to be updated is ready, thus effectively preventing update failures due to timing mismatches or incorrect states. Therefore, the host computer can safely perform subsequent program data transmission based on this explicit feedback.

[0055] The above technical solution significantly improves the reliability of program updates. This solution ensures that the host computer only begins data transmission after the motor controller to be updated has fully entered the update state (i.e., Bootloader mode), thus avoiding conflicts or data corruption that may occur when updating while the application is running. This not only increases the success rate of program updates but also simplifies the host computer's logic for judging the motor controller's status, making the entire update process more stable and efficient.

[0056] In some embodiments described above, a scheme is proposed to send a program update request instruction and receive an update permission message within a first preset time. However, during its implementation, some motor controllers to be updated may fail to respond or return an update permission message in a timely manner, causing the host computer to be unable to accurately grasp the actual number of updatable devices, thereby affecting the accuracy and reliability of subsequent program updates. To address this, this application further proposes to refine step A3 to accurately identify and report devices that are not permitted to be updated.

[0057] Specifically, step A3 includes:

[0058] A301. After the first preset time has elapsed, read the number of data bits that have been set in the device list, and use this as the number of devices allowed to update;

[0059] A302. Determine if the number of allowed devices to be updated is equal to the number of devices to be updated;

[0060] A303. If not equal, calculate the difference between the number of devices to be updated and the number of devices allowed to be updated as the number of devices not allowed to be updated, and send a message that does not allow updates containing the number of devices not allowed to be updated.

[0061] Specifically, in step A301, after the first preset time expires, the host computer reads the device list created in step A202. Within the first preset time, based on the received allow update messages, the device list sets the data bits corresponding to each motor controller to be updated. Therefore, the number of set data bits in the device list is actually equal to the number of received allow update messages. Thus, by reading the number of set data bits in the device list, the number of motor controllers that successfully returned allow update messages within the first preset time can be accurately counted, and this number is determined as the number of devices allowed to be updated.

[0062] Further, in step A302, the host computer compares the number of allowed update devices with the number of devices to be updated set in step A1. This determination aims to verify that all expected motor controllers to be updated have successfully responded and are ready for program updates.

[0063] Therefore, in step A303, if the judgment result shows that the number of devices allowed to be updated is not equal to the number of devices to be updated, it indicates that some motor controllers have failed to successfully enter the update preparation state. At this time, the host computer will calculate the difference between the number of devices to be updated and the number of devices allowed to be updated. This difference represents the number of devices that are not allowed to be updated. Subsequently, the host computer will send an update-disallowed message containing the number of devices that are not allowed to be updated. This message can be used to notify the operator or other modules of the system which devices have failed to enter the update mode (since the data bits in the device list correspond one-to-one with each motor controller to be updated, the unset data bits can be used to determine which devices have failed to enter the update mode), so as to carry out subsequent troubleshooting or retry operations.

[0064] The proposed solution accurately counts the number of devices that have responded and are allowed to be updated after the first preset time period ends, and compares this count with the preset number of devices to be updated. This allows for the accurate identification of motor controllers that failed to successfully enter the update preparation state. This mechanism enables the host computer to clearly understand the status of each motor controller to be updated, avoiding blindly performing subsequent update operations when some devices are not ready, thereby improving the reliability and controllability of the entire update process.

[0065] The above technical solution effectively addresses the issue of some devices failing to respond promptly or enter update mode during multi-motor controller program updates. By explicitly identifying and reporting the number of devices not permitted to update, the system provides more accurate update status feedback, facilitating timely detection and handling of anomalies by users or automation systems, thereby improving the success rate of program updates and the overall stability of the system.

[0066] In some embodiments of this application, within a second preset time period, program update data packets are sent to all motor controllers to be updated via CAN communication, and a successful data reception message is received from the motor controllers to be updated. However, in actual implementation, simply sending data packets and waiting for received messages may not effectively cope with complex communication environments, such as data packet loss, delayed response or no response from some motor controllers. This makes it difficult for the host computer to accurately determine whether all motor controllers to be updated have successfully received the program update data packets, thereby affecting the reliability and efficiency of the overall program update.

[0067] Therefore, in some preferred embodiments, step A4 includes:

[0068] A401. Within a second preset time period, continuously send program update data packets to all motor controllers to be updated via CAN communication;

[0069] A402. Initialize the device update program's receive status flag, and within a second preset time, receive the data reception success message returned by the motor controller to be updated; the device update program's receive status flag contains data bits that correspond one-to-one with each motor controller to be updated;

[0070] A403. Based on the received successful data reception message, set the corresponding data bit in the device update program reception status flag until the second preset time ends.

[0071] Specifically, in step A401, the host computer continuously sends program update data packets to all motor controllers to be updated within a second preset time period. This continuous sending mechanism aims to ensure that even in the event of momentary interference in CAN bus communication or temporary busy conditions for some motor controllers, the program update data packets can be reliably sent to all target devices. The program update data packets can be divided into multiple small data blocks for transmission to accommodate the frame length limitations of CAN communication. The duration of the second preset time period can be set according to actual needs.

[0072] Further, in step A402, before sending the program update data packet, the host computer initializes a device update program reception status flag. This flag can be a bitmap or an array, where each data bit or element corresponds one-to-one with a specific motor controller to be updated. Initially, all data bits are set to indicate a non-received state (e.g., set to 0). During a second preset time period, the host computer continuously listens for and receives a successful data reception message returned by the motor controller to be updated. The successful data reception message is an acknowledgment message sent by the motor controller to be updated to the host computer after successfully receiving and processing the program update data packet.

[0073] Therefore, in step A403, once the host computer receives a successful data reception message from a motor controller to be updated, it will identify the corresponding motor controller based on the message and set the corresponding data position in the device update program reception status flag (for example, set it to 1). This process continues until the end of the second preset time. In this way, the device update program reception status flag can reflect the latest status of each motor controller receiving update program data packets in real time.

[0074] This application's solution effectively solves the problems of data packet transmission reliability and difficulty in accurately tracking the reception status during multi-motor controller program updates by continuously sending program update data packets within a second preset time period, combined with a real-time update mechanism for the device update program reception status flag. Continuous sending ensures sufficient data packet transmission and reduces the risk of data loss due to momentary communication problems. Simultaneously, by initializing and dynamically updating the device update program reception status flag, the host computer can accurately record whether each motor controller to be updated has successfully received the program update data packet, thus refining the ambiguous "receiving message" process into traceable and verifiable individual reception statuses. This mechanism allows the host computer to clearly grasp the progress and success rate of the entire data transmission phase, providing a reliable data foundation for subsequent update completion judgment.

[0075] Through the above technical solution, this application significantly improves the reliability and controllability of data transmission during the multi-motor controller program update process. Specifically, the strategy of continuously sending program update data packets effectively reduces the probability of data loss, ensuring that all motor controllers to be updated have the opportunity to receive complete update data. Simultaneously, the introduction of a device update program reception status flag and the real-time setting of corresponding data bits enable the host computer to perform fine-grained management and real-time monitoring of the data reception status of each motor controller to be updated. This allows for accurate identification of which devices have successfully received data and which devices may have reception problems (since the data bits in the device update program reception status flag correspond one-to-one with each motor controller to be updated, the unset data bits can be used to determine which devices have failed to receive data). This precise status tracking capability not only improves the success rate of program updates but also provides a clear basis for subsequent fault diagnosis and anomaly handling, thereby improving the efficiency and stability of the entire program update process.

[0076] Preferably, the successful data reception message is sent back by the motor controller to be updated after receiving the program update data packet and temporarily storing the program update data packet in the RAM memory of the main control chip.

[0077] The "Successful Data Receipt" message is an acknowledgment signal sent by the motor controller to the host computer, indicating that it has successfully received the program update data packet. This message is sent when the motor controller immediately stores the received program update data packet in its main control chip's RAM. The main control chip's RAM, a high-speed volatile memory, is characterized by its fast read / write speed and is suitable for temporary data storage. By first temporarily storing the received program update data packet in RAM, the real-time performance and efficiency of data reception are ensured, avoiding delays or interruptions that might occur if the data is directly written to Flash memory.

[0078] This application's solution links the transmission of a successful data reception message with the temporary storage of program update data packets in the main control chip's RAM, ensuring that the host computer can promptly obtain feedback on the data packet reception status. When the host computer sends a program update data packet, the motor controller to be updated, upon receiving the packet, quickly writes it into the main control chip's RAM. Once the data packet is successfully temporarily stored, the motor controller to be updated immediately sends a successful data reception message. This mechanism allows the host computer to confirm whether each data packet has been received and cached by the target motor controller, thus laying the foundation for subsequent data integrity verification and program writing to Flash memory.

[0079] Through the above technical solution, the host computer can accurately and in real time monitor the reception status of each program update data packet, improving the reliability of the program update process. Temporarily storing the program update data packets in the main control chip's RAM memory utilizes RAM's high-speed read / write capabilities, effectively improving data reception efficiency and providing a buffer for subsequent data writing from RAM to Flash memory, avoiding performance bottlenecks or data loss risks that may arise from direct Flash writing. This helps ensure the stability of data transmission and the smoothness of the update process in scenarios involving parallel updates of multiple motor controllers.

[0080] In some of the above embodiments, although the status flag received by the device update program can record the data received by each motor controller to be updated, there is still room for further optimization in how to accurately and timely determine whether all motor controllers to be updated have successfully received the program update data packet after the second preset time, and how to effectively process devices that have not successfully received the update data packet.

[0081] Therefore, in some preferred embodiments, step A5 includes:

[0082] A501. After the second preset time has elapsed, an update program sending completion command is sent to all motor controllers to be updated via CAN communication, so that the motor controllers to be updated stop writing program update data packets to the RAM memory of the main control chip;

[0083] A502. Read the number of data bits that have been set in the device update program receive status flag, and use that number as the number of devices that have received the update program;

[0084] A503. Determine if the number of devices that have received the update program is equal to the number of devices waiting to be updated;

[0085] A504. If not equal, calculate the difference between the number of devices to be updated and the number of devices that have received the update program as the number of devices that have not received data, and send an update program failure message containing the number of devices that have not received data.

[0086] Specifically, after the second preset time expires, the host computer first sends an update program transmission completion command to all motor controllers to be updated via CAN communication. The purpose of this command is to clearly inform each motor controller that the program update data packet transmission phase has ended, thereby stopping them from writing the program update data packet to the main control chip's RAM. This ensures the integrity and consistency of the data writing process, avoiding potential data truncation or incomplete writing due to the expiration of the time limit.

[0087] Subsequently, the host computer reads the number of data bits that are set in the device update program's receive status flag. This number is actually equal to the number of successfully received data transmission messages, which represents the number of devices that have received the update program. The device update program receive status flag is dynamically updated during the transmission of the program update data packet, and is used to record whether each motor controller to be updated has successfully received the data.

[0088] Furthermore, the host computer compares the number of devices that have received the update program with the number of devices awaiting updates. If they are equal, it indicates that all motor controllers awaiting updates have successfully received the update data packet. If they are not equal, it means that some motor controllers awaiting updates have failed to receive the update data packet. In this case, the host computer calculates the difference between the number of devices awaiting updates and the number of devices that have received the update program; this difference is the number of devices that did not receive data. Subsequently, the host computer sends an update program failure message containing the number of devices that did not receive data, in order to promptly report the update failure.

[0089] The solution in this application explicitly terminates the program update data packet writing process by sending an update program completion command after the second preset time, thus avoiding uncertainty in data writing. Simultaneously, by reading the device update program reception status flag and comparing it with the number of devices to be updated, the number of devices that have received the update program and the number of devices that have not received data can be accurately counted, thereby achieving accurate judgment and feedback on the program update status. This mechanism allows the host computer to clearly understand the reception status of each motor controller to be updated and to perform targeted processing on devices that have not successfully received the update.

[0090] The above technical solution ensures that the reception process of program update data packets is explicitly terminated, avoiding potential data writing problems. Simultaneously, this solution provides the ability to accurately identify and quantify devices that failed to receive program update data packets, enabling the host computer to promptly send a program update failure message. This improves the reliability and controllability of the multi-motor controller program update process, providing accurate data for subsequent troubleshooting and retries.

[0091] In some implementations, step A6 includes:

[0092] A601. Within the third preset time period, continuously send device update completion query data packets to all motor controllers to be updated via CAN communication;

[0093] A602. Initialize the device update completion status flag, and within the third preset time, receive the update completion message returned by the motor controller to be updated; the device update completion status flag contains data bits that correspond one-to-one with each motor controller to be updated;

[0094] A603. Based on the received update completion message, set the corresponding data bit in the device update completion status flag until the third preset time ends.

[0095] The third preset time refers to the time window set by the host computer to wait for all motor controllers to be updated to complete the program update and return an update completion message. Its specific length can be set according to actual needs. Within this time window, the host computer continuously sends device update completion query data packets to all motor controllers to be updated, ensuring that all motor controllers that have entered the update state can receive the query command and have a chance to respond. The device update completion query data packet is a specific CAN message used by the host computer to inquire whether the motor controller has completed the program update and successfully written it to the Flash memory.

[0096] Furthermore, the device update completion status flag is a data structure maintained in the host computer, which can be, for example, a bitmap or a Boolean array, with each data bit corresponding to a different motor controller to be updated. This flag is initialized at the start of the third preset time, with all data bits either cleared to zero or set to an incomplete state. When the host computer receives an update completion message from a motor controller to be updated, it indicates that the motor controller has successfully completed the program update. At this time, the data bit in the device update completion status flag corresponding to that motor controller will be set, indicating a completed state. This process continues until the third preset time ends, at which point the host computer stops receiving update completion messages.

[0097] This application's solution ensures that the host computer can comprehensively and accurately grasp the program update completion status of all motor controllers to be updated by continuously sending device update completion query data packets within a third preset time period, combined with a dynamic update mechanism for the device update completion status flag. The purpose of continuously sending query data packets is to address potential message loss or delays in CAN bus communication, thereby improving query reliability. Simultaneously, by setting independent data bits for each motor controller to be updated and setting these bits in real time based on received update completion messages, the host computer can clearly identify which devices have completed the update and which have not (since the data bits in the device update completion status flag correspond one-to-one with each motor controller to be updated, the setting status of each data bit determines which devices have completed the update and which have not), thus providing an accurate data foundation for subsequent update result statistics and failure handling.

[0098] Through the above technical solution, the host computer can accurately monitor and confirm the update completion status of each motor controller in a scenario where multiple motor controllers are updating their programs simultaneously, in an efficient and reliable manner. This mechanism avoids misjudgments caused by the loss of a single query message, improving the robustness of the update process. Furthermore, by updating the device update completion status flag in real time, the host computer can clearly understand the update progress, providing a clear basis for subsequent update result summarization and anomaly handling, thereby significantly improving the success rate and management efficiency of batch updates for multiple motor controller programs.

[0099] Preferably, the update completion message is sent back by the motor controller to be updated after writing all the programs in the RAM memory of the main control chip into the Flash memory of the main control chip, in response to the device update completion query data packet.

[0100] The main control chip's RAM is typically used for temporary program data storage, while the Flash memory is used for long-term program code storage. Writing the program from RAM to Flash memory is a crucial step in the program update process, ensuring the new program is permanently saved and available for subsequent execution. The response to the device update completion query data packet indicates that the motor controller to be updated will proactively send this message to the host computer after completing its internal program writing operation to confirm the successful completion of the update process.

[0101] The solution in this application ensures that the update completion message received by the host computer is based on the completion of the critical operation of the motor controller to be updated successfully writing the new program from the RAM memory to the Flash memory, by clearly defining the conditions for sending the update completion message. This avoids sending the completion message before the program is fully written to the Flash memory, thereby improving the accuracy and reliability of the update status judgment.

[0102] Through the above technical solution, the host computer can accurately determine whether the motor controller to be updated has truly completed the program update, that is, whether the new program has been stably written to the Flash memory. This helps to avoid update failures or program malfunctions caused by incomplete program writing, thereby improving the stability and success rate of the multi-motor controller program update process.

[0103] In some implementations, step A7 includes:

[0104] A701. After the third preset time has elapsed, read the number of data bits that have been set in the device update completion status flag, and use this number as the number of devices that have completed the update.

[0105] A702. Sends a success message for the device update procedure, containing the number of devices that have completed the update.

[0106] A703. Determine if the number of devices that have completed updates equals the number of devices that need to be updated;

[0107] A704. If not equal, calculate the difference between the number of devices to be updated and the number of devices that have been updated as the number of devices that have not been updated, and send a device update program failure message containing the number of devices that have not been updated.

[0108] Specifically, after the third preset time expires, the host computer will read the device update completion status flag maintained in steps A602 and A603. This device update completion status flag is a set of data bits corresponding one-to-one with each motor controller to be updated. Each set data bit indicates that the corresponding motor controller has successfully returned an update completion message. Therefore, the number of set data bits in this device update completion status flag is actually equal to the number of received update completion messages. By counting the set data bits in this flag, the number of devices that have completed the update can be accurately obtained. Subsequently, the host computer will send a device update program success message, which contains the number of devices that have completed the update, to report the number of devices that have successfully completed the program update to the operator or the upper-level system.

[0109] Furthermore, to comprehensively assess the overall success rate of this batch update, the host computer will determine whether the number of devices that have completed the update is equal to the number of devices to be updated set in step A1. If they are equal, it indicates that all expected motor controllers have successfully completed the program update. If they are not equal, it means that some motor controllers have failed to complete the program update. In this case, the host computer will calculate the difference between the number of devices to be updated and the number of devices that have completed the update, thereby determining the number of devices that have not completed the update. Subsequently, the host computer will send a device update program failure message, which includes the number of devices that have not completed the update, to clearly indicate the number of devices that have failed to complete the update successfully, in order to facilitate subsequent fault diagnosis or targeted handling.

[0110] The solution proposed in this application accurately counts the number of devices that have actually completed the update by immediately reading the device update completion status flag after the third preset time period. Because this flag is continuously set by the update completion message within the third preset time period, the host computer can obtain the final update status of all devices at a specific point in time. By comparing this number of completed update devices with the initially set number of devices to be updated, it is possible to clearly determine whether the batch update was completely successful or partially successful / failed. This clear judgment mechanism, combined with sending separate messages containing the number of successful and failed devices, allows the host computer to obtain refined update result feedback. Therefore, it is possible not only to confirm the overall progress of the update but also to identify the specific number of devices that failed to complete the update, providing crucial information for subsequent system maintenance and troubleshooting.

[0111] Through the above technical solution, this application provides a more accurate and comprehensive feedback mechanism for multi-motor controller program update results. Compared to simply receiving update completion messages in general terms, this solution, by explicitly counting the number of devices that have completed the update and comparing it with the number of devices yet to be updated, can clearly distinguish between update scenarios that are completely successful, partially successful, or completely unsuccessful. As a result, the host computer can obtain detailed information about the update status of each device, significantly improving the transparency and controllability of the update process. This detailed feedback mechanism helps to quickly locate devices that have failed to update, thereby shortening troubleshooting time, improving system maintenance efficiency, and providing users with a more reliable program update experience.

[0112] refer to Figure 2 This application provides a multi-motor controller program update system based on CAN communication, including a host computer 1, a CAN communication module 2, a CAN bus 3, and multiple motor controllers 4. The host computer 1 communicates with the multiple motor controllers 4 through the CAN communication module 2 and the CAN bus 3.

[0113] The motor controller 4 includes a main control chip, which has a RAM memory 401 and a Flash memory 402. The Flash memory 402 includes a Bootloader sector and an application sector. The RAM memory 401 is used to temporarily store programs that need to be updated. The Bootloader sector is used to guide the motor controller 4 to perform program updates. The application sector is used to store programs that the motor controller 4 will execute.

[0114] The host computer 1 is used to execute the steps of the multi-motor controller program update method based on CAN communication described above.

[0115] Specifically, the host computer 1 is the control center of the entire program update system and can be a personal computer, an industrial control computer, or a dedicated programming device. As a preferred implementation, the host computer 1 can be an industrial computer with a high-performance processor and ample storage space to ensure rapid processing of large amounts of program data and complex communication protocols. Alternatively, the host computer can also be a general-purpose personal computer, implementing the required functions by installing appropriate software and hardware adapters.

[0116] CAN communication module 2 serves as the interface between the host computer 1 and the CAN bus 3, responsible for data conversion and transmission between them. This module can be integrated within the host computer 1, for example, as a CAN card with a PCIe or USB interface, or it can be an external, independent CAN adapter. For instance, a USB-based CAN communication module can be used, offering advantages such as convenient connection and compatibility with various host computer platforms. Alternatively, a PCIe-based CAN communication module can be used, providing higher data transmission rates and suitability for scenarios with high real-time requirements.

[0117] The CAN bus is the physical communication medium connecting the host computer (1) and all the motor controllers (4) to be updated. It typically consists of a pair of twisted-pair cables and features high anti-interference capability and multi-master communication. The CAN bus allows multiple devices to connect to the bus simultaneously and communicate, enabling the host computer (1) to interact with multiple motor controllers (4) in a broadcast or point-to-point manner, which is crucial for achieving batch updates.

[0118] Motor controller 4 is the target device for program updates. Each motor controller 4 has a CAN communication interface, which can receive instructions and data sent by the host computer 1. Each motor controller 4 contains a main control chip, which is the core processing unit of the motor controller 4 and is responsible for executing motor control logic and data processing and storage operations during the program update process.

[0119] The RAM memory 401 is a volatile memory used to temporarily store program data packets received from the host computer 1 during program updates. It features fast read / write speeds and is suitable as a temporary buffer. The Flash memory 402 is a non-volatile memory used to permanently store the motor controller program.

[0120] The bootloader sector is a special area in the Flash memory 402 that stores the bootloader program. This bootloader program starts upon power-on of the motor controller 4 or upon receiving a specific instruction. Its main function is to guide the motor controller 4 into program update mode, receiving program data sent by the host computer 1 and writing it to the application sector. The application sector is the area in the Flash memory 402 used to store the applications required for the normal operation of the motor controller 4. After the program update is complete, the new application will be stored in this sector and executed when the motor controller 4 is working normally.

[0121] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for updating a multi-motor controller program based on CAN communication, characterized in that, The method, applied to updating the program of multiple motor controllers on a host computer, includes the following steps: A1. Set the number of devices to be updated based on the number of motor controllers to be updated; A2. Within a first preset time period, send a program update request instruction to all the motor controllers to be updated via CAN communication, and receive an update permission message returned by the motor controllers to be updated; A3. Based on the number of devices allowed to update and the number of devices to be updated, determined according to the received allowed update message, determine the number of devices not allowed to update and send the corresponding disallowed update message; A4. Within a second preset time period, send a program update data packet to all the motor controllers to be updated via CAN communication, and receive a successful data reception message returned by the motor controllers to be updated; A5. Based on the number of devices that have received the update program and the number of devices to be updated, determined according to the received update permission message, determine the number of devices that have not received data and send the corresponding update program failure message; A6. Within a third preset time period, send a device update completion query data packet to all the motor controllers to be updated via CAN communication, and receive the update completion message returned by the motor controllers to be updated; A7. Based on the number of devices that have completed the update and the number of devices to be updated, determined according to the received update completion message, determine the number of devices that have not completed the update, and send device update program success message and device update program failure message; Step A4 includes: A401. During the second preset time period, continuously send program update data packets to all the motor controllers to be updated via CAN communication; A402. Initialize the device update program receiving status flag, and within the second preset time period, receive the data reception success message returned by the motor controller to be updated; the device update program receiving status flag contains data bits that correspond one-to-one with each of the motor controllers to be updated; A403. Based on the received successful data reception message, set the corresponding data bit in the device update program reception status flag until the second preset time ends; Step A5 includes: A501. After the second preset time has ended, an update program sending completion instruction is sent to all the motor controllers to be updated via CAN communication, so that the motor controllers to be updated stop writing program update data packets to the RAM memory of the main control chip; A502. Read the number of data bits that have been set in the device update program reception status flag, and use that number as the number of devices that have received the update program; A503. Determine whether the number of devices that have received the update program is equal to the number of devices to be updated; A504. If not equal, calculate the difference between the number of devices to be updated and the number of devices that have received the update program as the number of devices that have not received data, and send an update program failure message containing the number of devices that have not received data.

2. The method for updating a multi-motor controller program based on CAN communication according to claim 1, characterized in that, Step A2 includes: A201. Within a first preset time period, continuously send program update request commands to all the motor controllers to be updated via CAN communication; A202. Create a device list and, within the first preset time period, receive an update permission message returned by the motor controller to be updated; the device list contains data bits corresponding one-to-one with each of the motor controllers to be updated; A203. Based on the received allow update message, set the corresponding data bit in the device list until the first preset time ends.

3. The method for updating a multi-motor controller program based on CAN communication according to claim 2, characterized in that, The update permission message is sent back by the motor controller to be updated after responding to the program update request instruction and jumping to the Bootloader program entry point.

4. The method for updating a multi-motor controller program based on CAN communication according to claim 2, characterized in that, Step A3 includes: A301. After the first preset time has ended, read the number of data bits that have been set in the device list, and use this number as the number of devices allowed to update; A302. Determine whether the number of allowed update devices is equal to the number of devices to be updated; A303. If they are not equal, calculate the difference between the number of devices to be updated and the number of devices allowed to be updated as the number of devices not allowed to be updated, and send a disallowed update message containing the number of devices not allowed to be updated.

5. The method for updating a multi-motor controller program based on CAN communication according to claim 1, characterized in that, The successful data reception message is sent back by the motor controller to be updated after receiving the program update data packet and temporarily storing the program update data packet in the RAM memory of the main control chip.

6. The method for updating a multi-motor controller program based on CAN communication according to claim 1, characterized in that, Step A6 includes: A601. During the third preset time period, continuously send device update completion query data packets to all the motor controllers to be updated via CAN communication; A602. Initialize the device update completion status flag, and within the third preset time period, receive the update completion message returned by the motor controller to be updated; the device update completion status flag contains data bits that correspond one-to-one with each of the motor controllers to be updated; A603. Based on the received update completion message, set the corresponding data bit in the device update completion status flag until the third preset time ends.

7. The method for updating a multi-motor controller program based on CAN communication according to claim 6, characterized in that, Step A7 includes: A701. After the third preset time has ended, read the number of data bits that have been set in the device update completion status flag, and use that number as the number of devices that have completed the update; A702. Send a device update procedure success message containing the number of devices that have completed the update; A703. Determine whether the number of devices that have completed the update is equal to the number of devices that need to be updated; A704. If they are not equal, calculate the difference between the number of devices to be updated and the number of devices that have been updated as the number of devices that have not been updated, and send a device update program failure message containing the number of devices that have not been updated.

8. A multi-motor controller program update system based on CAN communication, characterized in that, The system includes a host computer, a CAN communication module, a CAN bus, and multiple motor controllers. The host computer communicates with the multiple motor controllers via the CAN communication module and the CAN bus. Each motor controller includes a main control chip with RAM and Flash memory. The Flash memory includes a Bootloader sector and an application sector. The RAM is used to temporarily store programs that need to be updated. The Bootloader sector is used to guide the motor controller to perform program updates. The application sector stores programs that the motor controller will execute. The host computer is used to execute the steps of the multi-motor controller program update method based on CAN communication as described in any one of claims 1-7.

Images