A controller software flashing method and related device

Abstract

The application discloses a controller software flashing method and related device, and relates to the field of intelligent networking, the first setting parameter of the factory CAL in the controller and the second setting parameter of the target APP which has been flashed into the controller are acquired, if the compatibility of the two parameters is inconsistent, the programming session is kept from exiting and the flashing operation of the upgraded target CAL is immediately performed, the third setting parameter of the target CAL is acquired after the flashing is completed, and the compatibility is compared with the second setting parameter, if the comparison is consistent, the programming session is exited and the controller controls the target APP and the target CAL as a whole unit to uniformly execute the software restart instruction. The application compares the setting parameters of the factory CAL and the target APP in compatibility, keeps the programming session from exiting and flashes the target CAL immediately when the comparison is inconsistent, and solves the problems of flashing failure, controller lock and production line stop caused by the incompatibility between the target APP and the factory CAL.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicles, and more specifically, to a method and apparatus for flashing controller software. Background Technology

[0002] With the development of the automotive industry, the variety of car models is increasing, and the differences in functional requirements of each model lead to different control software. However, control hardware has tended to be standardized in order to achieve platformization. To improve the hardware commonality rate, the industry generally adopts the production line flashing method, that is, the controller software corresponding to the car model is flashed on the production line equipment of the OEM. The controller is equipped with a unified factory software when it leaves the factory to support production line command interaction and subsequent software support.

[0003] Currently, controller software is typically divided into APP (Application Software) and CAL (Calibration Software), and the two must be used together. During vehicle software iteration upgrades, some new features require simultaneous upgrades to both the APP and CAL, which can easily lead to version incompatibility between the upgraded and unupgraded software. This is because during production line flashing (e.g., flashing the production line of an automotive intelligent torque manager), the APP is usually flashed first, followed by the CAL. During this process, there will be a brief period where the upgraded target APP and the original factory CAL are combined. If the two are incompatible, the upgraded target APP will not function properly, resulting in flashing failure.

[0004] At this point, the controller, having already been flashed with the target app, will not start the bootloader (i.e., the boot software). Furthermore, the target app is incompatible with the factory CAL and cannot be properly woken up and started, ultimately causing the controller to lock up during the flashing process and become unresponsive to subsequent commands. When this problem occurs, the factory has to shut down the production line to replace the controller hardware, which not only severely impacts factory production efficiency but also carries the risk of operational errors during hardware replacement. Summary of the Invention

[0005] In view of this, the present invention discloses a controller software flashing method and related apparatus to solve the problems of flashing failure, controller lock-up and production line shutdown caused by incompatibility between the target APP and the factory CAL.

[0006] A method for flashing controller software, comprising:

[0007] Obtain the first setting parameters of the factory-installed CAL in the controller, and the second setting parameters of the target APP that has been flashed into the controller after the upgrade;

[0008] Compare the first setting parameter with the second setting parameter for compatibility.

[0009] If the first setting parameter and the second setting parameter do not match, keep the programming session running and immediately perform a flashing operation on the upgraded target CAL;

[0010] After the target CAL is written, obtain the third setting parameter of the target CAL;

[0011] The compatibility of the third setting parameter with the second setting parameter is compared.

[0012] If the third setting parameter matches the second setting parameter, exit the programming session and control the controller to treat the target APP and the target CAL as a whole unit, and execute the software restart command uniformly.

[0013] Optionally, it also includes:

[0014] If the third setting parameter does not match the second setting parameter, execute the software re-flash command to re-flash the target APP and the target CAL, and keep the programming session running.

[0015] After the target APP and the target CAL are rewritten, the second setting parameters of the target APP and the third setting parameters of the target CAL are re-acquired and a compatibility comparison is performed.

[0016] If the reacquired second and third setting parameters match, exit the programming session and control the controller to treat the target APP and the target CAL as a whole unit, and uniformly execute the software restart command.

[0017] Optionally, it also includes:

[0018] If the reacquired second and third setting parameters do not match, an extended session command is sent to the controller to detect the startup status of the target APP flashed to the controller.

[0019] If no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to start.

[0020] A forced recovery command is sent to the controller, and the forced recovery command is executed by the bootloader in the controller to restore the target CAL to its factory compatible state so that the target APP can start normally.

[0021] Optionally, if no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to start, including:

[0022] If no successful flashing feedback is received from the controller within a preset time period, the target APP flashed to the controller is determined to have failed to start.

[0023] Or,

[0024] If the number of times the extended session command is repeatedly sent to the controller reaches a preset limit and no successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has failed to start.

[0025] Optionally, it also includes:

[0026] If a successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has started successfully.

[0027] Optionally, the compatibility comparison refers to determining whether the first setting parameter and the second setting parameter, or the third setting parameter and the second setting parameter, have the same first digit code; if the first digit codes are the same, the comparison is considered consistent; if the first digit codes are different, the comparison is considered inconsistent.

[0028] Optionally, different platforms may use different parameter encoding rules;

[0029] Within the same platform, the first setting parameter of the factory-installed CAL, the second setting parameter of the target APP, and the third setting parameter of the target CAL follow the same parameter encoding rules.

[0030] Optionally, obtaining the first setting parameters of the factory-installed CAL in the controller and the second setting parameters of the upgraded target APP that has been flashed into the controller specifically includes:

[0031] Obtain the first setting parameters of the factory CAL in the controller, then write the target APP into the controller, and obtain the second setting parameters of the target APP that has been flashed;

[0032] Or,

[0033] Write the target APP into the controller, and obtain the first setting parameters of the factory CAL in the controller and the second setting parameters of the target APP that has been flashed.

[0034] A computer storage medium storing at least one instruction, which, when executed by a processor, implements the controller software flashing method described above.

[0035] A flashing device, the flashing device comprising: a memory and a processor;

[0036] The memory is used to store at least one instruction;

[0037] The processor is used to execute at least one instruction to implement the controller software flashing method described above.

[0038] As can be seen from the above technical solution, the present invention discloses a controller software flashing method and related apparatus. The method obtains the first setting parameters of the factory-installed CAL in the controller, and the second setting parameters of the upgraded target APP flashed into the controller. The first setting parameters and the second setting parameters are compared for compatibility. If they do not match, the programming session is kept running, and the upgraded target CAL is immediately flashed. After the target CAL flashing is completed, the third setting parameters of the target CAL are obtained and compared for compatibility with the second setting parameters. If they match, the programming session is exited, and the controller is controlled to treat the target APP and the target CAL as a single unit, uniformly executing a software restart command. This invention first obtains the first setting parameters of the factory-installed CAL and the second setting parameters of the target APP and performs a compatibility comparison. If the comparison is inconsistent, the programming session is kept running and the target CAL is immediately flashed, preventing the target APP from starting in an incompatible state with the factory CAL. After the target CAL is flashed, the third setting parameters are obtained and compared with the second setting parameters a second time. If the comparison is consistent, the target APP and the target CAL are treated as a whole and a unified software restart command is executed. This effectively avoids flashing failures caused by incompatibility between the target APP and the factory CAL, prevents the controller from locking up due to software incompatibility, eliminates the need to replace the controller hardware, and effectively solves the production line downtime problem, ensuring continuous and efficient production. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the published drawings without creative effort.

[0040] Figure 1 This is a flowchart of a controller software flashing method disclosed in an embodiment of the present invention;

[0041] Figure 2 This is a schematic diagram of the structure of a controller software flashing device disclosed in an embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of the structure of a writing device disclosed in an embodiment of the present invention. Detailed Implementation

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

[0044] This invention discloses a method and related apparatus for flashing controller software. The method involves first acquiring the first setting parameters of the factory-installed CAL and the second setting parameters of the target application, and then performing a compatibility comparison. If the comparison is inconsistent, the programming session is kept running and the target CAL is flashed immediately, preventing the target application from starting in an incompatible state with the factory CAL. After the target CAL is flashed, a third setting parameter is acquired and compared with the second setting parameter. If the comparison is consistent, the target application and the target CAL are treated as a whole and a unified software restart command is executed. This effectively avoids flashing failures caused by incompatibility between the target application and the factory CAL, prevents the controller from locking up due to software incompatibility, eliminates the need to replace controller hardware, and effectively solves production line downtime problems, ensuring continuous and efficient production.

[0045] The parameter definitions and basic rules in this invention are as follows:

[0046] This invention pre-sets compatibility flag parameters K for both the APP and CAL:

[0047] The compatibility parameters of the factory-set CAL are denoted as the first setting parameter K1;

[0048] The compatibility parameters of the target APP are denoted as the second setting parameter K2;

[0049] The compatibility parameters of the target CAL are denoted as the third setting parameter K3.

[0050] It should be noted that the compatibility flag parameter K is written into the software during the software development process and can be read via CAN (Controller Area Network) communication.

[0051] In practical applications, the compatibility parameter K is divided into encoding ranges according to the platform. If the first digit of the compatibility parameter K of the APP and CAL on the same platform is consistent, they are judged to be compatible.

[0052] The compatibility flag parameter K can be encoded using two bits. Different platforms use different parameter encoding rules (i.e., different platforms correspond to different compatibility parameter K encoding ranges), as illustrated in Table 1:

[0053] Table 1

[0054]

[0055] In Table 1, the APP parameter is also the second setting parameter K2 corresponding to the target APP.

[0056] The CAL parameters include: the first setting parameter K1 corresponding to the factory CAL, and the third setting parameter K3 corresponding to the target CAL.

[0057] The two-digit encoding range for Platform 1 is 10 to 1F; the two-digit encoding range for Platform 2 is 20 to 2F; the two-digit encoding range for Platform 3 is 30 to 3F; and so on.

[0058] The same platform follows the same parameter coding rules. That is, the first setting parameter K1 of the factory CAL of the same platform, the second setting parameter K2 of the target APP, and the third setting parameter K3 of the target CAL follow the same parameter coding rules.

[0059] The parameter encoding rules in this embodiment form the data foundation for the anti-lockdown strategy of this invention. Taking a practical industrial application as an example, multiple sets of non-overlapping numerical ranges can be predefined to distinguish different hardware platforms. For example, the compatibility parameter encoding range for platform 1 can be set to hexadecimal 10 to 1F, the encoding range for platform 2 can be set to 20 to 2F, the encoding range for platform 3 can be set to 30 to 3F, and so on. Under this system, as long as the first digit of the parameter encoding (i.e., the tens digit of the range) is determined, the hardware platform to which it belongs can be uniquely identified. At the same time, special codes are reserved for special states. For example, "FFFF" is defined as the factory compatible state or the universal adaptation state. This state does not belong to any specific platform range, but is recognized as a valid initial value by the APP of all platforms. Within the same platform, whether it is the factory pre-installed CAL, the target APP for upgrade, or the target CAL flashed later, it must strictly comply with the encoding range rules corresponding to that platform. This mandatory encoding specification ensures that a clear mapping relationship is established between the software version and the hardware platform, so that compatibility verification is no longer a vague empirical judgment, but a logical operation based on deterministic mathematical rules. Once the flashing device reads the parameters, it doesn't need to consult a massive version compatibility matrix; it can instantly determine the security of the current software combination simply through size comparisons or bitwise operations. This not only simplifies the firmware logic of the flashing tool but also reserves ample coding space for future vehicle model expansion. When adding a new platform, only a new first-bit coding segment needs to be allocated; there's no need to modify the existing platform's verification algorithm, demonstrating excellent scalability and maintainability.

[0060] In this invention, the factory compatibility status of CAL is set to a custom compatibility encoding, such as FFFF, which can be adapted to apps on all platforms.

[0061] The programming session in this invention can be a 1002 session.

[0062] The software restart command can be command 1101.

[0063] Extended session commands can be 1083 commands.

[0064] The forced recovery command can be command 1092.

[0065] It should be noted that, according to the standard definition of the UDS (Unified Diagnostic Services) protocol in the automotive electronics field, an extended session command is a command sent by a diagnostic tool (such as a lower-level device or flashing device) to an ECU (Electronic Control Unit) to instruct it to switch from the default session mode to the extended diagnostic session mode.

[0066] In the UDS protocol, ECUs have various operating modes or contexts, collectively referred to as diagnostic sessions. Among them, the extended diagnostic session is a diagnostic session mode with a privilege level between the default session and the programming session, and the extended session command is the control command that triggers the ECU to switch from the default session to this mode.

[0067] See Figure 1 The present invention discloses a flowchart of a controller software flashing method, which is applied to a flashing device and includes the following steps:

[0068] Step S101: Obtain the first setting parameters of the factory-installed CAL in the controller, and the second setting parameters of the target APP that has been flashed into the controller after the upgrade.

[0069] In this embodiment, the setting parameters (including the first setting parameter and the second setting parameter) are identification data embedded in the software version header file or a specific storage area, used to characterize the platform type or compatibility family to which the software belongs. The first setting parameter corresponds to the original factory CAL in the controller, and the second setting parameter corresponds to the target APP that has just been written but has not yet been activated.

[0070] This embodiment obtains the first and second setting parameters before the controller restarts, providing a data basis for subsequent compatibility judgment, enabling the system to detect potential version conflict risks before the controller enters the application layer.

[0071] Step S102: Compare the first setting parameter with the second setting parameter for compatibility.

[0072] The compatibility comparison process in this embodiment aims to confirm whether the newly flashed target APP can work collaboratively with the factory CAL temporarily stored in the controller. Since production line flashing typically involves flashing the APP first and then the CAL, in this intermediate state, the controller contains a combination of "new APP + old CAL". If the two belong to different platforms or generations, direct startup will inevitably fail. By comparing the first and second setting parameters, the system can identify this incompatibility in advance, thereby avoiding blindly executing subsequent restart procedures.

[0073] Compatibility comparison refers to determining whether the first set parameter K1 and the second set parameter K2 have the same first digit code. If the first digit codes are the same, it is determined that the comparison is consistent, thus determining that the two belong to the same platform. If the first digit codes are different, it is determined that the comparison is inconsistent, thus determining that the two belong to different platforms.

[0074] For example, if the first setting parameter K1 is 10 and the second setting parameter K2 is 15, and the first digit of both setting parameters is 1, both of which belong to platform 1, then the first setting parameter K1 and the second setting parameter K2 are determined to be compatible.

[0075] For example, if the first setting parameter K1 is 11 and the second setting parameter K2 is 25, and the first digit of the two setting parameters is different, then it is determined that the first setting parameter K1 and the second setting parameter K2 are incompatible and belong to different platforms.

[0076] Step S103: If the first setting parameter and the second setting parameter are inconsistent, keep the programming session running and immediately perform a flashing operation on the upgraded target CAL.

[0077] A programming session is an ECU (Electronic Control Unit) operating mode defined in automotive diagnostic protocols, used for software upgrades, firmware flashing, or modification of critical configuration parameters.

[0078] This step is crucial to preventing controller lockup. "Maintaining the programming session without exiting" means maintaining the current diagnostic communication connection and secure access state between the flashing device and the controller, without sending exit programming mode or reset commands. Maintaining the session is essential because if the programming session exits or a reboot is triggered in an incompatible state, the controller will attempt to load the target app. However, due to the lack of a matching target CAL, the app cannot initialize properly. Simultaneously, because the app image already exists, the bootloader will not automatically take over control, causing the controller to enter a "frozen" state where it cannot run applications or respond to flashing commands. By forcibly maintaining the programming session, the controller is locked in a secure low-level communication mode, creating a protected execution environment for flashing the target CAL. Furthermore, "Immediately perform flashing operation on the upgraded target CAL" is an automatically triggered action in response to inconsistent comparison results, requiring no manual intervention or power-on, thus eliminating the potential for version incompatibility in the shortest possible time.

[0079] In this embodiment, if the first setting parameter K1 and the second setting parameter K2 are inconsistent, that is, the first and second setting parameters K1 are different, it is determined that the first setting parameter K1 and the second setting parameter K2 are incompatible. At this time, the target CAL is immediately flashed and the programming session is kept running to prevent the target APP from starting and running alone. This can prevent the controller from locking due to incompatibility between the target APP and the factory CAL, and ensure that the flashing process can be executed continuously.

[0080] In practical applications, if the first setting parameter K1 and the second setting parameter K2 are inconsistent, the flashing device can generate and record a negative response while maintaining the programming session. This negative response indicates an incompatibility between the target app and the factory-installed CAL. Based on this negative response, the flashing device will then acquire the third setting parameter K3 of the target CAL after the flashing process is complete.

[0081] Step S104: After the target CAL is written, obtain the third setting parameter of the target CAL.

[0082] After the target CAL is written to the controller, the system reads its corresponding setting parameters again as the third setting parameter. This step is to verify whether the actual written CAL version meets expectations and to prevent incorrect CAL files from being written due to transmission errors or file mismatches.

[0083] In practical applications, after the target CAL is flashed, the flashing device obtains the third setting parameter K3 of the target CAL through CAN communication.

[0084] Step S105: Compare the compatibility of the third setting parameter with the second setting parameter.

[0085] The comparison involves the newly written target CAL and the newly flashed target APP. Only when the settings of both indicate that they belong to the same compatibility family can the current software combination be confirmed as safe and usable. This secondary verification constitutes a closed-loop verification of the flashing process, ensuring that the entire process from "discovering incompatibility" to "fixing incompatibility" is controllable.

[0086] The compatibility comparison in this step refers to determining whether the first digit of the third setting parameter K3 is the same as that of the second setting parameter K2. If the first digits are the same, it is determined that the comparison is consistent, thus determining that the two belong to the same platform. If the first digits are different, it is determined that the comparison is inconsistent, thus determining that the two belong to different platforms.

[0087] The "first bit code" does not simply refer to the first character of the string; in the underlying implementation, it usually corresponds to the high-order byte or the high four bits of the parameter value. For example, if the parameter is set to be represented by two hexadecimal digits, then the first bit code is the tenth digit of that hexadecimal number.

[0088] Using the first-order code as a compatibility criterion instead of comparing all data offers significant technical advantages. Firstly, the first-order code typically carries the platform architecture or generational information of the software, representing the most fundamental constraint determining whether the software can run. By capturing this key feature, high-risk scenarios such as cross-platform flashing can be quickly identified with minimal computational overhead. Secondly, compared to complete version hash verification or full-field matching, comparing only the first-order code greatly reduces the computational load on the flashing device's processor and the length of communication messages, making it more adaptable to the high-paced, low-latency production environment requirements of vehicle production lines. It should be understood that although this embodiment uses the first digit of a hexadecimal number as an example, in other embodiments, the first-order code can also be defined as a specific bit field after binary masking operations, as long as this bit field can effectively characterize the software's compatibility family.

[0089] In the actual comparison process, assuming that the third setting parameter K3 is 12 and the second setting parameter K2 is 15, and the first digit of both setting parameters is 1, both belong to platform 1, then the third setting parameter K3 and the second setting parameter K2 are determined to be compatible.

[0090] The third setting parameter K3 is 12, and the second setting parameter K2 is 26. The first digit of the two setting parameters is different. At this time, it is determined that the third setting parameter K3 and the second setting parameter K2 are incompatible and belong to different platforms.

[0091] Step S106: If the third setting parameter matches the second setting parameter, exit the programming session and control the controller to treat the target APP and target CAL as a whole unit and execute the software restart command uniformly.

[0092] In this embodiment, the flashing device is only allowed to exit the programming session and trigger a restart after confirming software compatibility. The term "integrated unit" here does not refer to merging the APP and CAL into a single physical file, but rather to binding them as an inseparable startup object in the control logic. In other words, the execution condition for the restart command is strictly limited to "both the APP and CAL have been verified to be compatible." This logical binding scheme effectively avoids the possibility of independent restarts after a single component update, ensuring that the application software and calibration software within the controller are always compatible each time it switches from programming mode to normal operation mode.

[0093] Specifically, when the third setting parameter K3 matches the second setting parameter K2, confirming their compatibility, the programming session is exited. The target APP and target CAL are treated as a single unit, and a unified software restart command is executed to avoid incompatibility issues caused by their separate startups, ensuring that the controller software starts up stably and runs normally.

[0094] In summary, this invention discloses a controller software flashing method. The method involves obtaining the first setting parameters of the factory-installed CAL within the controller, and the second setting parameters of the upgraded target APP flashed into the controller. A compatibility comparison is performed between the first and second setting parameters. If the comparison is inconsistent, the programming session is maintained, and the flashing operation on the upgraded target CAL is immediately executed. After the target CAL flashing is complete, the third setting parameters of the target CAL are obtained and compared with the second setting parameters. If the comparison is consistent, the programming session is exited, and the controller is controlled to treat the target APP and target CAL as a single unit, uniformly executing a software restart command. This invention first obtains the first setting parameters of the factory-installed CAL and the second setting parameters of the target APP and performs a compatibility comparison. If the comparison is inconsistent, the programming session is kept running and the target CAL is immediately flashed, preventing the target APP from starting in an incompatible state with the factory CAL. After the target CAL is flashed, the third setting parameters are obtained and compared with the second setting parameters a second time. If the comparison is consistent, the target APP and the target CAL are treated as a whole and a unified software restart command is executed. This effectively avoids flashing failures caused by incompatibility between the target APP and the factory CAL, prevents the controller from locking up due to software incompatibility, eliminates the need to replace the controller hardware, and effectively solves the production line downtime problem, ensuring continuous and efficient production.

[0095] In one embodiment, the controller software flashing method may further include:

[0096] (1) If the third setting parameter is inconsistent with the second setting parameter, execute the software re-flashing instruction to re-flash the target APP and the target CAL, and keep the programming session from exiting.

[0097] This step is a defensive action triggered after the initial flashing and verification of the target CAL, when a version mismatch is found between the newly written target CAL and the newly flashed target APP. In a real production environment, although the diagnostic protocol has a low-level verification mechanism, data may still be written but the content may be flipped or mismatched due to bus communication interference, transient errors in memory writes, or abnormal flashing tool cache. In this case, the flashing device will not directly determine that the flashing has failed or exit with an error, but will automatically trigger a software re-flash command to fully overwrite the target APP and target CAL. Throughout the entire re-flashing process, the programming session between the flashing device and the controller must remain in an ongoing state. This constraint is... Figure 1 The core security logic in the illustrated embodiment is continued because, during the intermediate stage of the re-flashing process, the controller is also in an unstable state with a mixture of old and new software or missing software. If the connection is accidentally disconnected or a reset is triggered at this time, the controller lock-up fault can easily be reproduced. Therefore, maintaining the programming session provides a protected flashing environment for automatic re-flashing.

[0098] Therefore, in this embodiment, when the third setting parameter K3 and the second setting parameter K2 are inconsistent, it is determined that the two are incompatible. In order to eliminate parameter incompatibility problems caused by software flashing abnormalities, data writing errors, or version matching deviations, the software re-flashing command is executed at this time, according to... Figure 1 The steps in the illustrated embodiment involve re-flashing the target APP and the target CAL while keeping the programming session running.

[0099] (2) After the target APP and the target CAL are rewritten, the second setting parameters of the target APP and the third setting parameters of the target CAL are obtained again, and a compatibility comparison is performed.

[0100] The re-flashing operation is not simply a matter of blindly executing the steps; it must undergo a secondary verification process identical to steps S104 and S105. The flashing device rereads the setting parameters corresponding to the target APP and target CAL after the re-flashing and re-executes the compatibility comparison algorithm. This closed-loop design of comparison, re-flashing, and re-comparison ensures that the validity of each re-flashing operation can be objectively verified, avoiding the risk of getting stuck in an infinite loop or being falsely judged as successful due to a single re-flashing failing to resolve the issue. Furthermore, this verification logic remains consistent with the initial verification, simplifying the state machine design of the flashing device and eliminating the need to develop a separate verification standard for the re-flashing process.

[0101] (3) If the second and third set parameters are consistent after being re-acquired, exit the programming session and control the controller to treat the target APP and the target CAL as a whole unit and execute the software restart command in a unified manner.

[0102] After the target APP and target CAL are re-flashed, if the second setting parameter K2 of the target APP and the third setting parameter K3 of the target CAL are consistent, it indicates that the re-flashing has eliminated the incompatibility issues caused by software flashing abnormalities, data writing errors, or version matching deviations. At this time, the controller will execute the software restart command on the target APP and target CAL as a whole unit. This method can ensure that the target APP and target CAL start synchronously in a matched state, avoid software lock-up and startup failure caused by restarting the target APP alone, and ensure the stable operation of the controller and the completion of the flashing process.

[0103] Therefore, in this embodiment, the flashing device is only allowed to return to the normal process from the current fault-tolerant branch, i.e., to execute step S106 in embodiment 1, when the verification result after re-flashing confirms that the target APP and the target CAL have restored their compatibility. This indicates that the automatic re-flashing mechanism is not an alternative independent of the basic flashing method, but rather an optional self-healing node embedded in the basic process. Regardless of whether a re-flashing process has been performed, the prerequisite for finally exiting the programming session and triggering a unified restart is always that the software combination compatibility verification is passed. In this way, this embodiment improves the robustness of the flashing method to unexpected transient failures without changing the overall architecture, effectively reducing the probability of production line downtime caused by occasional write errors. It should be understood that although this embodiment describes the situation where a re-flash is triggered immediately after the first inconsistency, in other embodiments, a threshold for the number of re-flashes can also be set, and when multiple consecutive re-flashes still result in inconsistency, the process can then proceed to the subsequent forced recovery process to avoid wasting too much time on unrecoverable failures such as hardware damage.

[0104] In one embodiment, the controller software flashing method may further include:

[0105] (1) If the second setting parameter and the third setting parameter are inconsistent after being re-acquired, an extended session instruction is sent to the controller to detect the startup status of the target APP that has been flashed to the controller.

[0106] If compatibility cannot be confirmed after a re-flash verification, the flashing device will no longer blindly attempt a full flash again, but will instead switch to low-level diagnostic mode. An extended session command is a communication message used to request the controller to enter a specific diagnostic service mode. The purpose of sending an extended session command is to probe whether the target app still possesses the most basic communication response capabilities. If the target app crashes due to severe incompatibility, it will be unable to handle regular application-layer diagnostic requests, but the underlying bootloader is usually still in a standby or active state, able to recognize and respond to these special extended session requests. This step constitutes a crucial detection link in the transition from application-layer fault tolerance to low-level self-rescue.

[0107] Based on this, if the re-acquired second setting parameter K2 and third setting parameter K3 are inconsistent, the flashing device will actively detect the startup status of the target APP flashed to the controller by sending an extended session command to the controller. This will promptly identify whether the controller cannot be woken up or the software is locked due to the continuous incompatibility between the target APP and the target CAL. This will provide an accurate basis for subsequent triggering of the underlying forced recovery command, thus avoiding production line shutdown caused by the controller being flashed to death.

[0108] (2) If no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to start.

[0109] In this embodiment, the successful flashing feedback does not refer to a simple confirmation, but rather a positive response message containing a specific status identifier returned by the controller after successfully loading and running the target APP in response to the extended session command. If the flashing device fails to receive this specific feedback after issuing the command, it indicates that the target APP has failed to take over control normally, i.e., it is in a startup failure state. This negative judgment logic based on no feedback equals failure avoids the uncertainty of relying on complex error code parsing, because in a controller lock-up scenario, any unexpected silence should be regarded as the highest level of fault signal.

[0110] (3) Send a forced recovery command to the controller, and execute the forced recovery command through the bootloader in the controller to restore the target CAL to the factory compatible state so that the target APP can start normally.

[0111] The bootloader (i.e., boot software) is a special piece of code that runs first after the MCU (Microcontroller Unit) is powered on or reset. Its core working principle can be summarized as follows: first, it initializes the hardware operating environment, and then determines whether to perform a software update or directly start the main program based on preset conditions.

[0112] This invention adds a forced recovery instruction to the bootloader program. This instruction can be directly executed by the underlying Boot end of the controller to forcibly restore the target CAL to the factory compatible state (parameter is FFFF). The factory compatible CAL can be adapted to any APP, thereby restoring the APP to normal compatibility and enabling normal startup and operation.

[0113] In this embodiment, once the APP startup failure is determined, the flashing device immediately and automatically issues a forced recovery command. The forced recovery command is designed to bypass the invalid application layer and be directly received and executed by the underlying bootloader. After parsing the forced recovery command, the bootloader will erase or rewrite the area in the memory containing the target CAL to a preset factory compatible state value (e.g., the hexadecimal value FFFF). This embodiment selects FFFF or other specific markers as the factory compatible state because, in the software architecture design, this state value is defined as a "wildcard" or "unbound state," indicating that the current CAL does not contain any platform-specific calibration data, thereby decoupling the strong coupling between the CAL and the specific APP version.

[0114] When the target CAL is in a universally compatible state, even if the currently running target APP does not match its originally expected CAL, the APP can recognize this as a legitimate initial state and will not crash, thus allowing the controller to resume the normal startup process. This mechanism is equivalent to providing the controller with a software-level "safe mode" entry point, ensuring that even in the event of extreme incompatibility causing the application layer to completely paralyze, the controller can still be restored to a state that can be rewritten or diagnosed through low-level intervention, thereby effectively avoiding the serious consequences of being forced to replace hardware due to software lock-up.

[0115] In summary, when the reacquired second and third setting parameters are inconsistent, this invention sends an extended session command to the controller to actively detect the controller's current communication status and the target APP's startup status. It promptly identifies whether the controller's inability to wake up or software lockup is due to persistent incompatibility between the target APP and the target CAL. If no successful flashing feedback is received from the controller, it determines that the target APP flashed to the controller has failed to start. At this point, a forced recovery command is sent to the controller, and the bootloader in the controller executes the forced recovery command to restore the target CAL to its factory compatible state, enabling the APP to restore normal compatibility and achieve normal startup and operation. This achieves low-level self-rescue repair under extreme controller failures without replacing controller hardware, effectively solving the problem of flashing failures and line stoppages.

[0116] In one embodiment, if no successful flashing feedback is received from the controller, the process of determining that the target APP flashed to the controller has failed to start may specifically include:

[0117] If no successful flashing feedback is received from the controller within the preset time period, the target APP flashed to the controller is deemed to have failed to start.

[0118] The preset time period is an empirical threshold derived from the statistics of the normal startup time and communication delay of the controller. The specific value depends on the actual needs. For example, it can be set to 500 milliseconds or 1 second. This invention does not limit it here.

[0119] The purpose of setting a preset time period is to filter out temporary response delays caused by high bus load or processor overload. Only when no feedback is received after the preset time period is the controller confirmed to be in a deadlock state and unable to respond. This timeout-based determination method is simple to implement, has low resource consumption, and is suitable for production line environments with high real-time requirements.

[0120] In another embodiment, if no successful flashing feedback is received from the controller, the process of determining that the target APP flashed to the controller has failed to start may specifically include:

[0121] If the number of times the extended session command is repeatedly sent to the controller reaches a preset limit, and no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to launch. The preset limit is determined based on actual needs, for example, 3 times; this invention does not impose a limitation on this.

[0122] Unlike timeout determination, the retry mechanism used in this embodiment focuses on dealing with occasional communication packet loss or transient interference. In some workshops with complex electromagnetic environments, a single packet loss does not necessarily indicate that the controller is actually damaged. By continuously sending multiple commands and requiring a response each time, the confidence level of the determination can be significantly improved. It should be understood that timeout determination and retry count determination can be used alone or in combination (e.g., setting a short timeout between each retry). Those skilled in the art can flexibly configure them according to the communication quality and cycle time requirements of the actual production line, as long as the purpose of accurately identifying the APP startup failure status can be achieved.

[0123] In one embodiment, the controller software flashing method may further include:

[0124] If a successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has started successfully.

[0125] If a successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has been successfully launched. At this time, the current software flashing process is completed normally, the flashing device exits the programming session, the controller enters normal working state, and the production line can continue to perform subsequent assembly and testing processes.

[0126] In this embodiment, when the flashing device receives a successful flashing feedback message in the expected format, it indicates that the target APP has successfully completed initialization and entered normal operation. At this time, although the previous parameter comparison showed inconsistencies, since the APP can successfully start and respond to diagnostic requests, it means that the current software combination has not caused fatal conflicts at the actual operation level, or the controller has some degree of backward compatibility. In this case, the system should respect the actual operating results rather than relying solely on static parameter comparisons, determine successful startup, and allow the process to continue. This reflects the design principle of "dynamic verification takes precedence over static rules" in this invention, avoiding false interceptions caused by lagging parameter definitions or untimely updates to encoding rules, and further improving the robustness and adaptability of the flashing strategy.

[0127] In one embodiment, step S101 may specifically include:

[0128] Obtain the first setting parameters of the factory CAL in the controller, then write the target APP into the controller, and obtain the second setting parameters of the target APP that has been flashed.

[0129] This embodiment employs a "pre-read baseline value" strategy. Before performing any substantial software write operation, the flashing device first reads the first setting parameters corresponding to the existing factory CAL in the controller memory via a diagnostic protocol and caches them in local memory or registers. Subsequently, the flashing device initiates the transmission and writing process for the target application. After the target application is fully written and verified, a read request is initiated again to obtain the second setting parameters for that target application.

[0130] The advantage of this timing approach is that the flashing device can establish a compatibility comparison benchmark before the flashing task begins, which facilitates real-time status monitoring and log recording during the flashing process. For example, if the pre-read initial settings indicate that the current controller belongs to platform A, while the header information of the target APP to be flashed indicates that it belongs to platform B, the flashing tool can even issue a high-risk warning to the user before writing to the APP, or automatically adjust the subsequent flashing strategy. This approach has a clear logical hierarchy and a well-defined causal relationship in data flow, making it particularly suitable for production line environments with stable communication links and flashing tools with robust session management capabilities.

[0131] In one embodiment, step S101 may further include:

[0132] Write the target app to the controller and obtain the first setting parameters of the factory CAL in the controller and the second setting parameters of the target app that has been flashed.

[0133] This embodiment employs a "post-unified read" or "concurrent read" strategy. In this mode, the flashing device prioritizes the write operation of the target application without pre-reading the parameters of the factory CAL. After the target application is flashed, the flashing device initiates read requests for the first setting parameters of the factory CAL and the second setting parameters of the target application sequentially or simultaneously within the same programming session window. Here, "simultaneously" does not strictly refer to absolute synchronization in physical time, but rather to sending two read commands consecutively or requesting multiple data identifiers in a single compound command without exiting the current programming session or executing a reset command. The technical considerations for adopting this timing are mainly to optimize bus utilization or adapt to specific tool architectures. In some high-cycle production line scenarios, frequent switching between "read mode" and "write mode" may introduce additional handshake overhead. Concentrating read operations after write completion can reduce the number of state machine jumps, thereby shortening the overall flashing cycle. Furthermore, some older or simpler flashing fixtures may not support dynamically inserting read commands during the write process; in this case, post-read becomes the only feasible implementation path.

[0134] It should be noted that although the two timing schemes mentioned above differ in execution order, they achieve the same technical effect: both can provide [something] before the controller executes the unified restart command. Figure 1 The compatibility comparison step provides complete and accurate data input. The core of this invention lies in the "session persistence and overall restart mechanism based on parameter comparison," rather than the absolute order of parameter acquisition. Therefore, in practical applications, those skilled in the art can flexibly select or combine the above timing strategies according to the specific communication protocol characteristics (such as CAN, Ethernet, FlexRay), the firmware capabilities of the flashing tool, and the production line cycle requirements. They can even derive other equivalent timing variations (such as reading factory CAL parameters during APP flashing). As long as these variations can ensure that the acquisition and comparison of dual parameters are completed before triggering a restart, they should all be considered to be covered within the scope of protection of this invention. This inclusive design of timing flexibility effectively avoids the risk of technical solution avoidance caused by the limitation of a single fixed process, and enhances the universality and adaptability of this invention in different vehicle platforms and manufacturing environments.

[0135] Corresponding to the above method embodiments, the present invention also discloses a controller software flashing device.

[0136] See Figure 2 The present invention discloses a schematic diagram of a controller software flashing device, which is applied to a flashing device and includes:

[0137] The first parameter acquisition unit 201 is used to acquire the first setting parameters of the factory calibration software CAL in the controller, and the second setting parameters of the target application software APP that has been flashed into the controller after the upgrade.

[0138] In practical applications, the first parameter acquisition unit 201 can be used to: first acquire the first setting parameter K1 of the factory CAL in the controller through CAN communication; then write the target APP into the controller and acquire the second setting parameter K2 of the target APP that has been flashed.

[0139] Alternatively, the target app can be written into the controller, and then the first setting parameter K1 of the factory-installed CAL in the controller and the second setting parameter K2 of the target app that has been flashed can be obtained through CAN communication.

[0140] The first comparison unit 202 is used to perform a compatibility comparison between the first setting parameter and the second setting parameter.

[0141] Compatibility comparison refers to determining whether the first set parameter K1 and the second set parameter K2 have the same first digit code. If the first digit codes are the same, it is determined that the comparison is consistent, thus determining that the two belong to the same platform. If the first digit codes are different, it is determined that the comparison is inconsistent, thus determining that the two belong to different platforms.

[0142] For example, if the first setting parameter K1 is 10 and the second setting parameter K2 is 15, and the first digit of both setting parameters is 1, both of which belong to platform 1, then the first setting parameter K1 and the second setting parameter K2 are determined to be compatible.

[0143] For example, if the first setting parameter K1 is 11 and the second setting parameter K2 is 25, and the first digit of the two setting parameters is different, then it is determined that the first setting parameter K1 and the second setting parameter K2 are incompatible and belong to different platforms.

[0144] The flashing unit 203 is used to keep the programming session running and immediately perform a flashing operation on the upgraded target CAL if the first setting parameter and the second setting parameter are inconsistent.

[0145] If the first setting parameter K1 and the second setting parameter K2 do not match, that is, their first and second digit codes are different, it is determined that the first setting parameter K1 and the second setting parameter K2 are incompatible. At this time, the target CAL is immediately flashed and the programming session is kept running to prevent the target APP from starting and running alone. This can prevent the controller from locking due to incompatibility between the target APP and the factory CAL, and ensure that the flashing process can be executed continuously.

[0146] In practical applications, if the first setting parameter K1 and the second setting parameter K2 are inconsistent, the flashing device can generate and record a negative response while maintaining the programming session. This negative response indicates an incompatibility between the target app and the factory-installed CAL. Based on this negative response, the flashing device will then acquire the third setting parameter K3 of the target CAL after the flashing process is complete.

[0147] The second parameter acquisition unit 204 is used to acquire the third setting parameter of the target CAL after the target CAL is written.

[0148] After the target CAL is flashed, the flashing device obtains the third setting parameter K3 of the target CAL through CAN communication.

[0149] The second comparison unit 205 is used to perform a compatibility comparison between the third setting parameter and the second setting parameter.

[0150] Compatibility comparison refers to determining whether the first digit of the third setting parameter K3 is the same as that of the second setting parameter K2. If the first digits are the same, the comparison is considered consistent, indicating that the two belong to the same platform. If the first digits are different, the comparison is considered inconsistent, indicating that the two belong to different platforms.

[0151] For example, if the third setting parameter K3 is 12 and the second setting parameter K2 is 15, and the first digit of both setting parameters is 1, both of which belong to platform 1, then the third setting parameter K3 and the second setting parameter K2 are determined to be compatible.

[0152] The third setting parameter K3 is 12, and the second setting parameter K2 is 26. The first digit of the two setting parameters is different. At this time, it is determined that the third setting parameter K3 and the second setting parameter K2 are incompatible and belong to different platforms.

[0153] The first restart unit 206 is used to exit the programming session if the third setting parameter matches the second setting parameter, and to control the controller to treat the target APP and the target CAL as a whole unit and execute the software restart command uniformly.

[0154] When the third setting parameter K3 matches the second setting parameter K2, they are confirmed to be compatible. At this point, the programming session is exited, and the target APP and target CAL are treated as a single unit. The software restart command is executed uniformly to avoid incompatibility issues caused by starting them separately, thus ensuring that the controller software starts up stably and runs normally.

[0155] In summary, this invention discloses a controller software flashing device. It acquires the first setting parameters of the factory-installed CAL within the controller, and the second setting parameters of the upgraded target APP flashed into the controller. The first and second setting parameters are compared for compatibility. If they do not match, the programming session is maintained, and the flashing operation on the upgraded target CAL is immediately performed. After the target CAL flashing is complete, the third setting parameters of the target CAL are acquired and compared for compatibility with the second setting parameters. If they match, the programming session is exited, and the controller is controlled to treat the target APP and target CAL as a single unit, uniformly executing a software restart command. This invention first obtains the first setting parameters of the factory-installed CAL and the second setting parameters of the target APP and performs a compatibility comparison. If the comparison is inconsistent, the programming session is kept running and the target CAL is immediately flashed, preventing the target APP from starting in an incompatible state with the factory CAL. After the target CAL is flashed, the third setting parameters are obtained and compared with the second setting parameters a second time. If the comparison is consistent, the target APP and the target CAL are treated as a whole and a unified software restart command is executed. This effectively avoids flashing failures caused by incompatibility between the target APP and the factory CAL, prevents the controller from locking up due to software incompatibility, eliminates the need to replace the controller hardware, and effectively solves the production line downtime problem, ensuring continuous and efficient production.

[0156] In one embodiment, the controller software flashing device may further include:

[0157] The re-flashing unit is used to execute a software re-flashing instruction if the third setting parameter is inconsistent with the second setting parameter, to re-flash the target APP and the target CAL, and to keep the programming session from exiting.

[0158] The re-comparison unit is used to re-acquire the second setting parameters of the target APP and the third setting parameters of the target CAL after the target APP and the target CAL have been rewritten, and to perform a compatibility comparison.

[0159] The second restart unit is used to exit the programming session if the re-acquired second setting parameters and the third setting parameters match, and to control the controller to treat the target APP and the target CAL as a whole unit and execute the software restart command uniformly.

[0160] In one embodiment, the controller software flashing device may further include:

[0161] The session instruction sending unit is used to send an extended session instruction to the controller if the re-acquired second setting parameter and the third setting parameter are inconsistent, so as to detect the startup status of the target APP flashed to the controller;

[0162] The startup failure determination unit is used to determine that the target APP flashed to the controller has failed to start if no successful flashing feedback is received from the controller.

[0163] The forced recovery unit is used to send a forced recovery command to the controller, and execute the forced recovery command through the bootloader in the controller to restore the target CAL to the factory compatible state so that the target APP can start normally.

[0164] In one embodiment, the startup failure determination unit can be specifically used for:

[0165] If no successful flashing feedback is received from the controller within a preset time period, the target APP flashed to the controller is determined to have failed to start.

[0166] Or,

[0167] If the number of times the extended session command is repeatedly sent to the controller reaches a preset limit and no successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has failed to start.

[0168] In one embodiment, the controller software flashing device may further include:

[0169] The startup success determination unit is used to determine that the target APP flashed to the controller has started successfully if a successful flashing feedback is received from the controller.

[0170] It should be noted that for the specific working principles of each component in the device embodiment, please refer to the corresponding section of the method embodiment, which will not be repeated here.

[0171] Corresponding to the above embodiments, the present invention also discloses a computer storage medium that stores at least one instruction, which, when executed by a processor, implements the steps shown in the embodiments of the controller software flashing method.

[0172] Computer storage media can be tangible media that may contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device. Computer storage media can be machine-readable signal media or machine-readable storage media. Computer storage media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0173] In this embodiment, at least one instruction is not a simple data bitstream, but a set of program code that, after compilation or interpretation, can drive the processor to execute a specific sequence of operations. When these instructions are invoked by the processor, they force the processor to run according to the logical path set by this invention, including but not limited to key actions such as obtaining set parameters, performing compatibility comparisons, maintaining the programming session without exiting when incompatible, triggering immediate flashing of the target CAL, and controlling the unified restart of the entire unit. In other words, this computer storage medium is the solidified carrier of the aforementioned controller software flashing method, transforming the abstract method flow into a reproducible, distributable, and installable product entity.

[0174] Corresponding to the above embodiments, such as Figure 3 As shown, the present invention also provides a schematic diagram of a flashing device, which may include: a processor 1 and a memory 2;

[0175] The processor 1 and memory 2 communicate with each other via communication bus 3.

[0176] Processor 1, for executing at least one instruction;

[0177] Memory 2 is used to store at least one instruction;

[0178] Processor 1 is the core of the operation and control of the flashing device. It may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

[0179] Memory 2 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0180] In this embodiment, the processor executes at least one instruction to implement the steps shown in the controller software flashing method.

[0181] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0182] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0183] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for flashing controller software, characterized in that, include: Obtain the first setting parameters of the factory-installed CAL in the controller, and the second setting parameters of the target APP that has been flashed into the controller after the upgrade; Compare the first setting parameter with the second setting parameter for compatibility. If the first setting parameter and the second setting parameter do not match, keep the programming session running and immediately perform a flashing operation on the upgraded target CAL; After the target CAL is written, obtain the third setting parameter of the target CAL; The compatibility of the third setting parameter with the second setting parameter is compared. If the third setting parameter matches the second setting parameter, exit the programming session and control the controller to treat the target APP and the target CAL as a whole unit, and execute the software restart command uniformly.

2. The controller software flashing method according to claim 1, characterized in that, Also includes: If the third setting parameter does not match the second setting parameter, execute the software re-flash command to re-flash the target APP and the target CAL, and keep the programming session running. After the target APP and the target CAL are rewritten, the second setting parameters of the target APP and the third setting parameters of the target CAL are re-acquired and a compatibility comparison is performed. If the reacquired second and third setting parameters match, exit the programming session and control the controller to treat the target APP and the target CAL as a whole unit, and uniformly execute the software restart command.

3. The controller software flashing method according to claim 2, characterized in that, Also includes: If the reacquired second and third setting parameters do not match, an extended session command is sent to the controller to detect the startup status of the target APP flashed to the controller. If no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to start. A forced recovery command is sent to the controller, and the forced recovery command is executed by the bootloader in the controller to restore the target CAL to its factory compatible state so that the target APP can start normally.

4. The controller software flashing method according to claim 3, characterized in that, If no successful flashing feedback is received from the controller, the target APP flashed to the controller is determined to have failed to start, including: If no successful flashing feedback is received from the controller within a preset time period, the target APP flashed to the controller is determined to have failed to start. Or, If the number of times the extended session command is repeatedly sent to the controller reaches a preset limit and no successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has failed to start.

5. The controller software flashing method according to claim 3 or 4, characterized in that, Also includes: If a successful flashing feedback is received from the controller, it is determined that the target APP flashed to the controller has started successfully.

6. The controller software flashing method according to any one of claims 1 to 4, characterized in that, The compatibility comparison refers to determining whether the first set parameter is the same as the second set parameter, or whether the third set parameter is the same as the second set parameter; if the first set codes are the same, the comparison is considered to be consistent, and if the first set codes are different, the comparison is considered to be inconsistent.

7. The controller software flashing method according to claim 1, characterized in that, Different platforms use different parameter encoding rules; Within the same platform, the first setting parameter of the factory-installed CAL, the second setting parameter of the target APP, and the third setting parameter of the target CAL follow the same parameter encoding rules.

8. The controller software flashing method according to claim 1, characterized in that, The acquisition of the first setting parameters of the factory-installed CAL in the controller, and the second setting parameters of the target APP that has been flashed and upgraded into the controller, specifically includes: Obtain the first setting parameters of the factory CAL in the controller, then write the target APP into the controller, and obtain the second setting parameters of the target APP that has been flashed; Or, Write the target APP into the controller, and obtain the first setting parameters of the factory CAL in the controller and the second setting parameters of the target APP that has been flashed.

9. A computer storage medium, characterized in that, The computer storage medium stores at least one instruction, which, when executed by the processor, implements the controller software flashing method as described in any one of claims 1 to 8.

10. A writing / brushing device, characterized in that, The writing device includes: a memory and a processor; The memory is used to store at least one instruction; The processor is used to execute at least one instruction to implement the controller software flashing method as described in any one of claims 1 to 8.

Images