A method for locating problems in MCU on-site software debugging

Abstract

The present invention relates to a method for locating problems in MCU on-site software debugging, which specifically includes the following steps: connecting a PC and a vehicle CAN bus with a CAN tool; performing CAN USD security key authentication between the PC and the MCU through built-in security authentication software; setting corresponding debugging instructions on the PC; the MCU receiving the debugging instructions sent from the PC and parsing the debugging instructions; the MCU executing corresponding actions according to the debugging instructions, and printing out the execution results through a serial port; judging whether to locate the cause of the problem according to the execution result in step S5, and ending if the cause of the problem has been located; if the cause of the problem has not been located, returning to step S3, and repeatedly executing S3 to S5 until the cause of the problem is finally located. The present invention helps to analyze and locate the cause of the problem on-site, and even solve the problem. Avoid unnecessary subsequent pressure recurrence and improve the efficiency of problem solving.

Description

Technical Field

[0001] The invention belongs to the technical field of automobile electronic control, and in particular relates to a method for locating problems in MCU on-site software debugging. Background Art

[0002] As cars become smarter, more digital, more connected, and more service-oriented, the requirements for automotive systems are becoming more and more complex, which has led to an increasing demand for MCUs in various electronic controller units in automotive electronic systems. MCUs are crucial in electronic controller units. MCUs manage the power module of the controller, obtain and parse transmission information from the vehicle's CAN and LIN buses, and are the execution units that truly implement system functions. However, because MCUs operate in environments with high heat, dust, severe vibrations, and severe electronic interference, some low-probability problems may occur. The cause of some problems may not be completely located through the log system, and additional auxiliary methods are required to debug the MCU on site and obtain the internal working status of the MCU to further narrow the scope of the problem, determine the direction of the problem, and locate the cause of the problem. Summary of the invention

[0003] In view of the above-mentioned deficiencies in the prior art, the technical problem to be solved by the present invention is to provide a method for locating problems in MCU on-site software debugging, so as to avoid the problem that the cause of the problem cannot be completely located and the MCU working state is abnormal, thereby achieving the effect of helping to analyze and locate the cause of the problem on-site and even solve the problem.

[0004] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0005] A method for locating problems in MCU on-site software debugging, comprising an MCU,

[0006] The specific steps include:

[0007] S1: Use the CAN tool to connect the PC and the vehicle CAN bus, and start the MCU;

[0008] S2: The PC performs CAN USD security key authentication with the MCU through the built-in security authentication software;

[0009] S3: Set the corresponding debugging instructions on the PC;

[0010] S4: The MCU receives the debugging instruction sent from the PC and parses the debugging instruction;

[0011] S5: The MCU executes corresponding actions according to the debugging instruction, and prints out the execution result through the serial port;

[0012] S6: Determine whether the cause of the problem has been located according to the execution result in step S5. If the cause of the problem has been located, end; if the cause of the problem has not been located, return to step S3 and repeat S3 to S5 until the cause of the problem is finally located.

[0013] To further improve the above technical solution, the MCU includes an MCU_DBG_APP inside, and the MCU_DBG_APP is used to assist the MCU in on-site debugging and locating problems;

[0014] The step S2 comprises:

[0015] S2.0: After the MCU is started, the MCU_DBG_APP task begins and S2.1 is executed;

[0016] S2.1: The PC sends a CAN UDS security authentication request to the MCU. After receiving the request, the MCU sends a feedback signal to the PC to request the CAN UDS security key. The PC sends the key to the MCU. After receiving the key, the MCU sends it to MCU_DBG_APP.

[0017] S2.2: Execute the CAN UDS security authentication process in MCU_DBG_APP to determine whether the CAN UDS security authentication is passed. If the authentication is passed, wait for the debugging instruction; if the authentication fails, return to step S2.0 and restart the MCU_DBG_APP task.

[0018] Furthermore, the step S4 comprises:

[0019] After receiving the debugging instruction from the PC, the MCU determines whether the current MCU supports the execution of the debugging instruction. If it does, it executes the corresponding instruction action according to the debugging instruction; if it does not, it sends a signal to the PC to indicate that it does not support the execution of the debugging instruction and waits for the PC to send a new debugging instruction.

[0020] Furthermore, the step S6 comprises:

[0021] Determine whether the cause of the problem has been located according to the execution result in step S5. If the cause of the problem has been located, confirm to exit the security authentication in MCU_DBG_APP and end;

[0022] If the cause of the problem is not located, determine whether to exit security authentication in MCU_DBG_APP. If it is confirmed to exit security authentication, return to step S2.0 and restart the MCU_DBG_APP task; if not, return to step S4 and wait for new debugging instructions.

[0023] Furthermore, the debugging instruction includes:

[0024] Rewrite the output level of the current specified PIN in the MCU;

[0025] Read the input level of the current specified PIN in the MCU;

[0026] Overwrite the current value of the currently specified global variable;

[0027] Read the current value of the currently specified global variable;

[0028] Initiate the power-on / power-off process for the currently specified module;

[0029] Send some protocol messages to the currently specified module;

[0030] Reinitialize the currently specified driver;

[0031] Restart the currently specified module;

[0032] Reset and restart the MCU chip itself;

[0033] And in step S4, the number of debugging instructions sent by the PC to the MCU is one.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] 1. A method for locating problems by debugging software on-site of MCU of the present invention, when the MCU fails, the CAN bus communication and CAN UDS service of the MCU are used to output some debugging instructions on the computer side while retaining the fault site, and these instructions are sent to the MCU through the CAN tool. After receiving these debugging instructions, the MCU executes corresponding actions or outputs some status information to narrow the scope of the problem, clarify the direction of the problem, and even directly find the root cause of the problem; at the same time, in order to avoid other non-developers accidentally triggering this on-site debugging function and causing unnecessary problems, the security key authentication logic is added to the MCU software, and the on-site debugging function can only be used after the authentication is passed; this method helps to analyze and locate the cause of the problem on-site, and even solve the problem. Avoid unnecessary subsequent pressure recurrence and improve the efficiency of problem solving. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is the system architecture diagram of the electronic controller unit.

[0037] Figure 2 A flowchart of a method for locating a problem in MCU on-site software debugging according to an embodiment;

[0038] Figure 3 It is a logic block diagram of the security key authentication logic within the MCU_DBG_APP of the embodiment. DETAILED DESCRIPTION

[0039] The specific implementation modes of the present invention will be further described in detail below in conjunction with the accompanying drawings.

[0040] Before describing the specific implementation of the present invention in detail, the MCU is first introduced. Figure 1 , is the system architecture diagram of the electronic controller unit. There is a driver layer inside the MCU (i.e. Figure 1 driver), UDS protocol stack (i.e. Figure 1 CAN UDS in the Figure 1 The MCU has the following tasks:

[0041] 1. MCU communicates via CAN bus (i.e. Figure 1 CAN network in the ECU) and other ECUs ( Figure 1 ECU1 and ECU2) in the system establish communication and synchronize information;

[0042] 2. MCU needs to manage the power supply of SOC, DSP, SENSOR1 and SENSOR2;

[0043] 3. MCU and SOC establish SPI / UART communication;

[0044] 4. MCU needs to drive / control the DSP chip;

[0045] 5. MCU needs to drive / control SENSOR1 and SENSOR2.

[0046] See also Figure 1-Figure 3 A method for locating a problem in MCU on-site software debugging according to a specific embodiment includes an MCU,

[0047] The specific steps include:

[0048] S1: Use the CAN tool to connect the PC and the vehicle CAN bus, and start the MCU;

[0049] S2: The PC performs CAN USD security key authentication with the MCU through the built-in security authentication software;

[0050] S3: Set the corresponding debugging instructions on the PC;

[0051] S4: The MCU receives the debugging instruction sent from the PC and parses the debugging instruction;

[0052] S5: The MCU executes corresponding actions according to the debugging instruction, and prints out the execution result through the serial port;

[0053] S6: Determine whether the cause of the problem has been located according to the execution result in step S5. If the cause of the problem has been located, end; if the cause of the problem has not been located, return to step S3 and repeat S3 to S5 until the cause of the problem is finally located.

[0054] The embodiment of the invention provides a method for locating problems by debugging software on-site of MCU. When the MCU fails, the CAN bus communication and CAN UDS service of the MCU are used to output some debugging instructions on the computer side while retaining the fault site. These instructions are sent to the MCU through the CAN tool. After receiving these debugging instructions, the MCU executes corresponding actions or outputs some status information to narrow the scope of the problem, clarify the direction of the problem, and even directly find the root cause of the problem. At the same time, in order to avoid other non-developers accidentally triggering this on-site debugging function and causing unnecessary problems, the security key authentication logic is added to the MCU software. Only after the authentication is passed, the on-site debugging function can be used. This method helps to analyze and locate the cause of the problem on-site, and even solve the problem. Avoid unnecessary subsequent pressure recurrence and improve the efficiency of problem solving.

[0055] During implementation, commonly used CAN tools are canoe or kvaser. The PC usually uses BUSMASTER v2.6.0 software through the built-in security authentication software. Other security authentication software can also be used to send security authentication keys to the MCU.

[0056] Please continue to see Figure 2-Figure 3 , wherein the MCU includes MCU_DBG_APP, and the MCU_DBG_APP is used to assist the MCU in on-site debugging and locating problems;

[0057] The step S2 comprises:

[0058] S2.0: After the MCU is started, the MCU_DBG_APP task begins and S2.1 is executed;

[0059] S2.1: The PC sends a CAN UDS security authentication request to the MCU. After receiving the request, the MCU sends a feedback signal to the PC to request the CAN UDS security key. The PC sends the key to the MCU. After receiving the key, the MCU sends it to MCU_DBG_APP.

[0060] S2.2: Execute the CAN UDS security authentication process in MCU_DBG_APP to determine whether the CAN UDS security authentication is passed. If the authentication is passed, wait for the debugging instruction; if the authentication fails, return to step S2.0 and restart the MCU_DBG_APP task.

[0061] In this way, the security key authentication logic is added to the MCU_DBG_APP in the MCU to implement the security authentication function, thereby ensuring that the field debugging function provided by the present invention is not triggered by error.

[0062] Wherein, the step S4 comprises:

[0063] After receiving the debugging instruction from the PC, the MCU determines whether the current MCU supports the execution of the debugging instruction. If it does, it executes the corresponding instruction action according to the debugging instruction; if it does not, it sends a signal to the PC to indicate that it does not support the execution of the debugging instruction and waits for the PC to send a new debugging instruction.

[0064] During implementation, "determining whether the MCU supports the execution of the debug instruction in the current situation" here can be understood as judging whether the debug instruction can be executed based on the actual situation, that is, the current working condition of the MCU. If it can be executed, it means that it supports execution, otherwise it is not supported.

[0065] Wherein, the step S6 comprises:

[0066] Determine whether the cause of the problem has been located according to the execution result in step S5. If the cause of the problem has been located, confirm to exit the security authentication in MCU_DBG_APP and end;

[0067] If the cause of the problem is not located, determine whether to exit security authentication in MCU_DBG_APP. If it is confirmed to exit security authentication, return to step S2.0 and restart the MCU_DBG_APP task; if not, return to step S4 and wait for new debugging instructions.

[0068] The debugging instructions include:

[0069] Rewrite the output level of the current specified PIN in the MCU;

[0070] Read the input level of the current specified PIN in the MCU;

[0071] Overwrite the current value of the currently specified global variable;

[0072] Read the current value of the currently specified global variable;

[0073] Initiate the power-on / power-off process for the currently specified module (for example, power on / off the ai module);

[0074] Send some protocol messages to the currently specified module (for example, send a message to the dsp module to request dsp to mute);

[0075] Reinitialize the current specified driver (such as spi, i2c, uart, adc, pwm, CAN, etc.);

[0076] Restart the current specified module (for example, restart the Android system);

[0077] Reset and restart the MCU chip itself;

[0078] And in step S4, the number of debugging instructions sent by the PC to the MCU is one.

[0079] During implementation, the "currently specified" mentioned here should be based on the judgment of the on-site staff and analyzed according to the specific situation. If the PIN levels need to be checked one by one, then the currently specified debugging instructions should be related to the PIN levels; if the driver needs to be checked, then the currently specified debugging instructions should be to reinitialize the driver in the MCU, and the same applies to other working conditions; where it should be implemented specifically (i.e. which PIN, which global variable, which module, etc.) should be set according to the needs of the on-site staff.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solution of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solution of the present invention, which should be included in the scope of the claims of the present invention.

Claims

1. A method for locating problems in MCU on-site software debugging, characterized in that: Including MCU, The specific steps include: S1: Use the CAN tool to connect the PC and the vehicle CAN bus, and start the MCU; S2: The PC performs CAN UDS security key authentication with the MCU through the built-in security authentication software; S3: Set the corresponding debugging instructions on the PC; S4: The MCU receives the debugging instruction sent from the PC and parses the debugging instruction; S5: The MCU executes corresponding actions according to the debugging instruction, and prints out the execution result through the serial port; S6: judging whether the cause of the problem has been located according to the execution result in step S5, and ending if the cause of the problem has been located; if the cause of the problem has not been located, returning to step S3, and repeatedly executing S3 to S5 until the cause of the problem is finally located; The MCU includes MCU_DBG_APP, which is used to assist the MCU in on-site debugging and locating problems; The step S2 comprises: S2.0: After the MCU is started, the MCU_DBG_APP task begins and S2.1 is executed; S2.1: The PC sends a CAN UDS security authentication request to the MCU. After receiving the request, the MCU sends a feedback signal to the PC to request the CAN UDS security key. The PC sends the key to the MCU. After receiving the key, the MCU sends it to MCU_DBG_APP. S2.2: Execute the CAN UDS security authentication process in MCU_DBG_APP to determine whether the CAN UDS security authentication is passed. If the authentication is passed, wait for the debugging instruction; if the authentication fails, return to step S2.0 and restart the MCU_DBG_APP task.

2. According to claim 1, a method for locating a problem in MCU on-site software debugging is characterized in that: The step S4 comprises: After receiving the debugging instruction from the PC, the MCU determines whether the current MCU supports the execution of the debugging instruction. If it does, it executes the corresponding instruction action according to the debugging instruction; if it does not, it sends a signal to the PC to indicate that it does not support the execution of the debugging instruction and waits for the PC to send a new debugging instruction.

3. According to claim 2, a method for locating problems in MCU on-site software debugging is characterized in that: The step S6 comprises: Determine whether the cause of the problem has been located according to the execution result in step S5. If the cause of the problem has been located, confirm to exit the security authentication in MCU_DBG_APP and end; If the cause of the problem is not located, determine whether to exit security authentication in MCU_DBG_APP. If it is confirmed to exit security authentication, return to step S2.0 and restart the MCU_DBG_APP task; if not, return to step S4 and wait for new debugging instructions.

4. A method for locating a problem in MCU on-site software debugging according to any one of claims 1 to 3, characterized in that: The debugging instructions include: Rewrite the output level of the current specified PIN in the MCU; Read the input level of the current specified PIN in the MCU; Overwrite the current value of the currently specified global variable; Read the current value of the currently specified global variable; Initiate the power-on / power-off process for the currently specified module; Send some protocol messages to the currently specified module; Reinitialize the currently specified driver; Restart the currently specified module; Reset and restart the MCU chip itself; And in step S4, the number of debugging instructions sent by the PC to the MCU is one.

Images