CN110457215B - Cross-platform MCU debugging method - Google Patents

Abstract

The invention provides a cross-platform MCU debugging method, which comprises an upper computer and an MCU and is characterized by at least comprising the following steps: the upper computer starts a debugging instruction module according to debugging requirements to send a debugging instruction to the MCU, and the MCU starts a corresponding debugging functional module to debug the MCU after receiving the debugging instruction; the debugging instruction module is configured to call a corresponding debugging instruction according to debugging requirements to debug the MCU; and the debugging functional module is configured to correspond to the debugging instruction module and start the corresponding debugging functional module to debug the MCU according to the debugging instruction transmitted by the debugging instruction module. Compared with the existing MCU debugging method, the method has the advantages that the MCU and the upper computer are directly adopted for assembling and debugging, a special debugging tool is not adopted as an intermediate medium, the debugging cost is reduced, and the debugging method is flexible and variable.

Description

A Cross-platform MCU Debugging Method

technical field

The invention relates to the field of microprocessor controllers (Microcontroller Unit, MCU), in particular to a method for debugging the faults of the MCU in the development process of the automobile MCU or which has been developed.

Background technique

With the popularization of automobiles, more and more automobiles have entered thousands of households. Now the rapid development of information technology has made people put forward higher requirements for intelligent automobiles. It is hoped that intelligent automobiles can bring convenience to people's practicality. An intelligent vehicle is a comprehensive system that integrates functions such as environmental perception, planning and decision-making, and multi-level assisted driving. It uses technologies such as computers, modern sensing, information fusion, communication, artificial intelligence, and automatic control. technology complex. At present, the research on intelligent vehicles is mainly devoted to improving the safety and comfort of automobiles, and providing an excellent human-vehicle interaction interface. In recent years, intelligent vehicles have become a research hotspot in the field of vehicle engineering in the world and a new driving force for the growth of the automobile industry. Many developed countries have incorporated them into their respective intelligent transportation systems. The development of smart cars puts forward strict requirements on all aspects of the body control system, including software and hardware, and the processing of software and hardware cannot be separated from the MCU. However, the powerful MCU has a long development cycle, and the MCU needs to be continuously debugged during the development process. The traditional debugging method is shown in Figure 1, which includes the host computer, debugging tools, and MCU. MCU debugging requires special debugging tools. In the debugging process, the host computer controls the debugging tool to debug the MCU. On the one hand, a special debugging tool is required. Once the debugging tool is completed, it is difficult to change it. It can only be used for debugging of a specific type of MCU, which is not flexible enough. , has great limitations. Only the internal information of the MCU can be obtained, such as the values of registers, variables, and memory areas. However, the current MCU integrates many functions. It is far from enough to only know the values of registers, variables, and memory areas. From these data, it is impossible to obtain the operating status of the system, and it is also impossible to obtain the operating process of the system and the relationship between each module. of interdependence.

In order to facilitate the debugging of developers and timely debug each functional module in the MCU development process and the matching functions related to the MCU, it is necessary to develop a new MCU debugging device to debug the MCU.

Contents of the invention

Based on the defects in the prior art, the technical problem to be solved in the present invention is a cross-platform MCU debugging method, which is applied to system debugging including a host computer and an MCU, and is characterized in that it at least includes the following steps:

The upper computer starts the debugging command module according to the debugging requirements and sends the debugging command to the MCU, and the MCU starts the corresponding debugging function module to debug the MCU after receiving the debugging command;

The debugging instruction module is configured to call the corresponding debugging instruction program to debug the MCU according to the debugging requirements;

The debugging function module is configured to correspond to the debugging instruction module and start a corresponding specific function module to debug the MCU according to the debugging instruction issued by the debugging instruction module.

The present invention provides a cross-platform MCU debugging method, further comprising: the data generated by MCU debugging is sent to the host computer for display, the data generated by the MCU debugging includes logs, and the logs are divided into multiple log levels according to types; In the process of debugging the MCU, temporarily store the data that needs to be output in the memory, and wait for the external output when the system is idle; or include when it is found that the debugging function module in the MCU does not have a built-in preset function module or according to the debugging results, it is necessary to add additional Functional modules, at this time, directly write the required functional modules into the MCU through the host computer.

The present invention provides a cross-platform MCU debugging method. Further, the debugging instruction needs to be encapsulated before being sent to the MCU, and the MCU needs to unpack the received packaged data packet to obtain the debugging instruction;

The data generated by the MCU debugging needs to be encapsulated before being sent to the upper computer, and the upper computer needs to unpack the received encapsulated data packets to obtain the data packets generated by debugging.

The present invention provides a cross-platform MCU debugging method, further, said data encapsulation at least includes the following steps:

Step S701, obtaining the payload (payload) that needs to be packaged and obtaining the address, length, and data packet type of the payload therefrom;

Step S702, judging whether the address is valid, if the address is invalid, execute step S707, and end the packaging process; if the address is valid, execute step S703;

Step S703, judging the command type of the payload, if the command type of the payload is valid, then perform step S704, if the command type of the payload is invalid, then perform step S707, and end the packaging process;

Step S704, judging whether the data length of the payload is valid, if the data length is invalid, then execute step S707, end the packaging process, if the data length is valid, then execute step S705;

Step S705, assigning a value to the payload;

Step S706, storing the packaged data into the data area to be sent;

Step S707, end the packaging process.

The present invention provides a cross-platform MCU debugging method, further, said unpacking the received encapsulated data packet includes the following steps:

Step S800, detecting whether the frame header contains a high byte, if it contains a high byte, then execute step S801, if there is no high byte, return to step S800, and detect the next frame;

Step S801, detecting whether the frame header contains a low byte, if it contains a low byte, then execute step S802; if it does not contain a low byte, then return to step S800, and detect the next frame data;

Step S802, obtaining the length of the data packet;

Step S803, analyzing the packet type to determine which category the data packet belongs to;

Step S804, obtaining the unpacked payload;

The present invention provides a cross-platform MCU debugging method, further, the debugging instruction module at least includes a log printing instruction module, a log level filtering instruction module, a process interaction instruction module, a firmware acquisition instruction module, a content writing instruction module, a content One or more of the reading instruction module, the online upgrade instruction module, and the tool adaptive identification instruction module;

The debugging function module includes at least one or more of the log printing module, log level filtering module, process interaction module, firmware acquisition module, content writing module, content reading module, online upgrade module, and tool adaptive identification module

Further, the log printing instruction module is configured to start the log printing instruction according to the debugging requirement and send it to the log printing module in the MCU;

The log level filtering command module is configured to start the log level filtering command according to the debugging requirements and send it to the log level filtering module in the MCU;

The process interaction instruction module is configured to start the process interaction instructions between various processes according to the debugging requirements and send them to the process interaction module of the MCU;

The firmware acquisition instruction module is configured to start and issue the instruction to acquire firmware to the firmware acquisition module in the MCU according to the debugging requirements;

The content writing command module is configured to send the content writing command to the content writing module in the MCU according to the debugging requirements to start the content writing;

The content reading instruction module is configured to issue an instruction to start content reading according to the debugging requirements to the content reading module in the MCU;

The online upgrade instruction module is configured to issue an instruction to start the online upgrade to the online upgrade module in the MCU according to the debugging requirement.

A tool adaptive recognition command module configured to start a tool adaptive command according to requirements and send it to the tool adaptive recognition module in the MCU;

The application layer instruction module is configured to start the application layer instruction and send it to the application layer function customization module in the MCU according to requirements.

The present invention provides a cross-platform MCU debugging method. Further, the debugging function module at least includes a log printing module, a log level filtering module, a process interaction module, a firmware acquisition module, a content writing module, a content reading module, an online One or more of upgrade modules and tool adaptive identification modules;

Further, the log printing module is configured to realize log printing, which prints out the log (log) message according to the instruction of the log printing instruction module, and is used to inform the developer of the running status of the program;

The log level filtering module is configured to implement log level filtering, and selectively implements the ability to dynamically filter logs of different levels according to the instructions of the log level filtering instruction module;

The process interaction module is configured to record the information transmission between multiple tasks in real time, and it starts the information transmission recording between multiple tasks according to the process interaction instruction;

A firmware acquisition module configured to acquire firmware information, which acquires firmware information according to a firmware acquisition instruction;

The content writing module is configured to write the received information that needs to be written into the memory, and writes the corresponding data into the memory of the MCU according to the content writing instruction;

The content reading module is configured to read the information to be read, and reads the corresponding content according to the content reading instruction;

The online upgrade module is configured to upgrade the MCU, which upgrades the MCU according to the upgrade instruction received from the host computer;

The tool adaptive identification module is configured to identify whether the upper computer has a supporting serial port tool according to the tool adaptive identification instruction of the upper computer;

The application layer function customization module is configured to customize the functions of the application program according to the application layer instructions of the upper computer.

The present invention provides a cross-platform MCU debugging method. Further, the log in the debugging process is printed by the log printing instruction module and the log printing module is controlled by issuing instructions. The log printing includes the following steps:

Step S901, judging whether the log level matches, if it matches, execute step S902, if not, execute step S912;

Step S902, read the characters that need to print the first address of the character string in the debugging data packet;

Step S903, judging whether the first character of the address is a "terminator", if the first character of the address is a terminator, then end the process. If the first character is not an end character, continue to the next step;

Step S904, judge whether the character is '%', if the character is not '%', then execute step S910, save the character; if the character is '%', then obtain the next character;

Step S905, judge whether the next character is x or d, if it is d, then execute step S906, if it is x, then execute step S908;

Step S906, obtaining the next parameter;

Step S907, convert the obtained parameters into decimal characters and execute step S910;

Step S908, obtaining the next parameter;

Step S909, converting the obtained parameters into hexadecimal characters and performing step S910;

Step S910, saving the character;

Step S911, point to the next byte, jump to repeat step S903, until all characters are printed;

Step S912, end the process.

The present invention provides a cross-platform MCU debugging method, and further, the printing log level filtering is completed through the log level filtering module,

Step S601, receiving data from the host computer;

Step S602, check the integrity of the data packet, if the data packet is complete, then perform step S603, if the data packet is incomplete, then end the process;

Step S603, analyzing the type of the data packet and putting the data packet into the corresponding level according to the type;

Step S604, select ON for the log that needs to be displayed, select OFF for the log that does not need to be displayed, and then print;

When the level of the log module shows ON, it means that the level needs to be printed out; if the level of the log module shows OFF, it means that the level of the log does not need to be printed out.

The present invention provides a cross-platform MCU debugging method, further, the log levels include at least any two of Debug logs, Info logs, OsMsg logs, Warn logs, ERROR logs, and FATAL logs;

Debug log: used to record the command status during system debugging;

Info log: used to record a running state of the current system;

OsMsg log: It is used to record an interaction process between processes. As long as the message queue sent by the process is marked with the OsMsg label and output externally, it can filter out the concerned messages according to the source process, target process, and command type;

Warn log: used to warn developers that errors may have occurred or illegal operations have been performed;

ERROR log: Inform the developer that an error has been encountered during the running of the program, but this type of error has been dealt with in the program, and the function may be invalid, but the system operation will not be affected;

FATAL log: It is used to inform developers that the system has encountered serious errors, resulting in program crashes and software restarts.

The present invention also provides a cross-platform MCU debugging device, which is characterized in that it includes an MCU, and the MCU includes a CPU, a debugging function module, a communication module, a storage module, an encapsulation and unpacking module, and the CPU is respectively connected with the debugging function module, the communication module, Storage module, packaging and unpacking module connection;

CPU, which is configured to be responsible for calls and calculations between modules of the system;

The debugging function module is configured to start the corresponding specific function module to debug the MCU according to the received debugging instruction, and the debugging function module can increase or decrease the debugging function according to the debugging requirements;

The storage module is configured to store data needed in the debugging process, generated data, and debugging function programs or cache data;

A communication module configured to communicate between the MCU and the host computer;

The encapsulation and unpacking module is configured to perform corresponding unpacking or encapsulation according to the unpacking instruction or the encapsulation instruction.

The present invention also provides a cross-platform MCU debugging device, further comprising a host computer, the host computer at least includes a CPU, a storage module, a debugging instruction module, a communication module, a packaging and unpacking module, and the CPU communicates with the storage module and the debugging module respectively. The instruction module, the communication module, and the packaging and unpacking module are electrically connected;

The communication module of the upper computer is electrically connected to the communication module in the MCU, wherein the communication module of the upper computer and the communication module in the MCU are connected by wireless communication or wired communication;

CPU, which is configured to be responsible for calls and calculations between modules of the system;

The storage module is configured to store the data needed in the debugging process and the debugging instruction program;

The debugging instruction module is configured to call the corresponding debugging instruction program to debug the MCU according to the debugging requirements;

An encapsulation and unpacking module configured to perform corresponding unpacking or encapsulation according to an unpacking instruction or an encapsulation instruction;

The communication module is configured for the host computer to communicate with external devices.

The present invention also provides a cross-platform MCU debugging device, further, the debugging function module at least includes a log printing module, a log level filtering module, a process interaction module, a firmware acquisition module, a content writing module, and a content reading module , online upgrade module, tool self-adaptive identification module;

The log printing module is configured to implement log printing, and it prints out log (log) messages according to the instructions of the log printing instruction module to inform developers of the running status of the program; the log level filtering module is configured to implement log printing. Level filtering, which selectively implements the ability to dynamically filter logs of different levels according to the instructions of the log level filtering command module; the process interaction module is configured to record the information transfer between multiple tasks in real time, and it starts multiple tasks according to the process interaction command. Information transfer records between tasks; the firmware acquisition module is configured to acquire firmware information, and it acquires firmware information according to the firmware acquisition instruction; the content writing module is configured to write the received information that needs to be written into the memory , which writes corresponding data into the memory of the MCU according to the content writing instruction; the content reading module is configured to read the information to be read, and reads the corresponding content according to the content reading instruction; The online upgrade module is configured to upgrade the MCU, which upgrades the MCU according to the upgrade instruction received from the upper computer; the tool adaptive identification module is configured to determine whether the upper computer has Supporting serial tool for identification.

The present invention also provides a cross-platform MCU debugging device, further, the debugging instruction module at least includes a log printing instruction module, a log level filtering instruction module, a process interaction instruction module, a firmware acquisition instruction module, and a content writing instruction module , content reading command module, online upgrade command module, and tool adaptive recognition command module:

The log printing instruction module is configured to start the log printing instruction according to the debugging requirements and send it to the log printing module in the MCU; the log level filtering instruction module is configured to start the log level filtering instruction according to the debugging requirements and send it to the MCU The log level filtering module; the process interaction instruction module is configured to start the process interaction instructions between each process according to the debugging requirements and sends them to the process interaction module of the MCU; the firmware acquisition instruction module is configured to start the acquisition of the firmware according to the debugging requirements The command is issued to the firmware acquisition module in the MCU; the content writing command module is configured to start content writing according to the debugging requirements and is sent to the content writing module in the MCU; the content reading command module is configured to The instruction for starting content reading according to the debugging requirement is sent to the content reading module in the MCU; the online upgrade instruction module is configured to send the instruction for starting online upgrading according to the debugging requirement to the online upgrading module in the MCU. The tool adaptive recognition instruction module is configured to start the tool adaptive instruction according to requirements and issue it to the tool adaptive recognition module in the MCU.

The present invention also provides a cross-platform MCU debugging device. Further, the packaging and unpacking module is used to perform corresponding unpacking or packaging according to the unpacking instruction or packaging instruction, and the packaging includes the following steps:

Step S701, obtaining the payload (payload) that needs to be packaged and obtaining the address, length, and data packet type of the payload therefrom;

Step S702, judging whether the address is valid, if the address is invalid, execute step S707, and end the packaging process; if the address is valid, execute step S703;

Step S703, judging the command type of the payload, if the command type of the payload is valid, then perform step S704, if the command type of the payload is invalid, then perform step S707, and end the packaging process;

Step S704, judging whether the data length of the payload is valid, if the data length is invalid, then execute step S707, end the packaging process, if the data length is valid, then execute step S705;

Step S705, assigning a value to the payload;

Step S706, storing the packaged data into the data area to be sent;

Step S707, end the packaging process.

The present invention also provides a cross-platform MCU debugging device, further, the unpacking includes the following steps:

Step S800, detecting whether the frame header contains a high byte, if it contains a high byte, then execute step S801, if there is no high byte, return to step S800, and detect the next frame;

Step S801, detecting whether the frame header contains a low byte, if it contains a low byte, then execute step S802; if it does not contain a low byte, then return to step S800, and detect the next frame data;

Step S802, obtaining the length of the data packet;

Step S803, analyzing the packet type to determine which category the data packet belongs to;

Step S804, obtaining the unpacked payload.

The present invention also provides a cross-platform MCU debugging device, further, the log printing module is used to print the log generated during the debugging process, and the log printing includes the following steps:

Step S901, judging whether the log level matches, if it matches, execute step S902, if not, execute step S912;

Step S902, read the characters that need to print the first address of the character string in the debugging data packet;

Step S903, judging whether the first character of the address is a "terminator", if the first character of the address is a terminator, then end the process; if the first character is not a terminator, continue to the next step;

Step S904, judge whether the character is '%', if the character is not '%', then execute step S910, save the character; if the character is '%', then obtain the next character;

Step S905, judge whether the next character is x or d, if it is d, then execute step S906, if it is x, then execute step S908;

Step S906, obtaining the next parameter;

Step S907, convert the obtained parameters into decimal characters and execute step S910;

Step S908, obtaining the next parameter;

Step S909, converting the obtained parameters into hexadecimal characters and performing step S910;

Step S910, saving the character;

Step S911, point to the next byte, jump to repeat step S903, until all characters are printed;

Step S912, end the process.

Or the log level filtering module is used to realize printing log level filtering, and the log level filtering includes the following steps:

Step S601, receiving data from the host computer;

Step S602, check the integrity of the data packet, if the data packet is complete, then perform step S603, if the data packet is incomplete, then end the process;

Step S603, analyzing the type of the data packet and putting the data packet into the corresponding level according to the type;

Step S604, select ON for the logs that need to be displayed, select OFF for the logs that do not need to be displayed, and then print.

The present invention also provides a cross-platform MCU debugging device, further, the MCU also includes at least one peripheral interface, the peripheral interface is configured to communicate with the external testing equipment for the MCU, the peripheral interface The types include one or more of SPI interface, USB interface, I2C interface, CAN interface, DOIP interface, UART interface, and R232 interface.

Beneficial technical effect of the present invention:

1. Compared with the prior art, the debugging method of the present invention directly adopts the MCU and the upper computer to assemble and debug without using a special debugging tool as an intermediate medium, so that the debugging cost is reduced and the debugging method is flexible and variable. Make the host computer communicate directly with the MCU to be debugged, making data transmission more reliable. Moreover, functional modules with special debugging requirements can be added to the MCU at any time according to the debugging requirements, so as to realize the MCU debugging of different platforms.

2. The debugging method of the present invention puts all the information that needs to be output in the memory (cache), and waits for the external output when the system is idle, which avoids competing for time with other high-priority tasks and makes full use of MCU resources. Existing debugging tools do not save the data generated when a function or command is called during the debugging process. After the function call is completed, the data generated by it will overwrite the data generated by the previous function when the next function call is made . The present invention has the effect of saving resources by storing the data to be outputted in the cache, and avoiding the function from being called again.

3. The log level is divided, and the log level filter module is set to filter the log. Therefore, the present invention has a powerful filtering function and supports Log records. After the product is delivered for testing, it is necessary to disconnect the emulator during testing. That is to say, the traditional debugging method is only suitable for function development. It is impossible to know how the program works during the testing phase. The log tracking and filtering functions added by this tool can solve this problem very well. Developers can selectively filter out log messages that are irrelevant to bugs, and quickly track and locate bugs.

4. The program is easy to transplant. The debuggers and compilers required by MCUs of different manufacturers are different and cannot be compatible. With the debugging device provided by the present invention, it is only necessary to write the debugging function module into the debugging MCU to carry out debugging. Therefore, the debugging tool of the present invention removes the restriction of the platform, removes the restriction of the library of the compiler, and removes the restriction of the debugger.

5. The present invention can print the debug log in real time, and when the MCU is debugged, the log generated after the MCU is debugged can be printed through the log printing module.

Description of drawings

The following drawings only illustrate and explain the present invention schematically, and do not limit the scope of the present invention.

FIG. 1 is a schematic diagram of a debugging process for an MCU in the prior art.

FIG. 2 is a schematic structural diagram of an MCU debugging system in an embodiment of the present invention.

FIG. 3 is a schematic structural diagram of a debugging instruction module including specific instruction function modules in an embodiment of the present invention.

FIG. 4 is a schematic structural diagram of debugging function modules including specific function modules in an embodiment of the present invention.

FIG. 5 is a flow chart of the host computer in the embodiment of the present invention starting a debugging command to issue a debugging command to the MCU and debugging the MCU according to the debugging requirements.

FIG. 6 is a flow chart of sending data generated by MCU debugging to a host computer for display in an embodiment of the present invention.

detailed description

In order to have a clearer understanding of the technical features, purposes and effects of the present invention, the specific implementation of the present invention will now be described with reference to accompanying drawings 2-6, and the same symbols in each figure represent the same parts. In order to make the drawings concise, the figures in each figure only schematically show the relevant parts of the present invention, and do not represent the actual structure of the product. In addition, to make the drawings concise and easy to understand, in some drawings, only one of the components having the same structure or function is schematically shown, or only one of them is marked.

Regarding the control system, as is well known to those skilled in the art, it can take any appropriate form, either hardware or software, multiple functional modules discretely set, or multiple functional modules integrated into one piece of hardware. a functional unit. In the simplest form, the control system can be a controller, such as a combination logic controller, a microprogram controller, etc., as long as it can realize the operations described in this application. Of course, the control system can also be integrated into one physical device as different modules, all of which do not deviate from the basic principle and protection scope of the present invention.

Example 1:

This embodiment provides a cross-platform MCU debugging device, referring to Fig. 2 to Fig. 4, including a host computer 1, an MCU 2, and the host computer 1 includes a CPU 11, a storage module 12, a debugging command module 13, a communication module 14, packaging and unpacking Module 15, CPU11 are respectively electrically connected with storage module 12, debugging module 13, communication module 14, packaging and unpacking module 15, MCU2 includes CPU21, debugging function module 22, communication module 24, storage module 23, packaging and unpacking module 25, At least one peripheral interface 26 .

The communication module 14 of host computer 1 is connected with the communication module 24 in the MCU, and wherein communication module 14 and communication module 24 all can adopt wireless communication or wired communication mode, if adopt wireless communication mode, wireless communication mode can WIFI, bluetooth, ultra-wide band , 4G, 5G communication, etc., or wireless communication as T-box. Wired communication methods can also be used. For example, the host computer 1 and MCU2 have matching interfaces, which can be Ethernet interfaces, I2C interfaces, USB interfaces, RS232 interfaces, CAN interfaces, DOIP interfaces, UART interfaces, etc. For example, the communication module 14 of the upper computer 1 has an I2C interface, and the communication module 24 of the MCU2 has an I2C interface, then the upper computer 1 and the MCU2 are connected by wire through an I2C data line. When adopting wireless communication, the communication module 14 of host computer 1 contains wireless communication assembly, as has Wifi, and the communication module 24 of MCU2 has and contains wireless communication assembly, is WIFI, and upper computer 1 can be connected with MCU2 by WIFI. Or when the host computer 1 is a remote computer or server, it can be connected to the MCU2 through the T-box.

In the upper computer 1, the CPU 11 is mainly used for invoking and computing among the various modules of the system;

The storage module 12 is configured to store the data needed in the debugging process and the debugging instruction program;

The debugging instruction module 13 is configured to call the corresponding debugging instruction program to debug the MCU according to the debugging requirements;

Encapsulation and unpacking module 15, configured to perform corresponding unpacking or encapsulation according to the unpacking instruction or encapsulation instruction;

The communication module 14 is configured for the host computer to communicate with external devices;

In MCU2, MCU2 can be an MCU under development, or a completed MCU.

CPU21, which is configured to be responsible for calls and calculations among various modules of the system;

The storage module 23 is configured to store data needed in the debugging process, generated data, debugging function programs or cache data, etc.;

The debugging function module 22 is configured to start a corresponding specific function module to debug the MCU according to the debugging instruction issued by the debugging instruction module, and the debugging function module 22 can increase or decrease the debugging function according to the debugging requirements;

The communication module 24 is configured to communicate with the upper computer for the MCU;

The packaging and unpacking module 25 is configured to perform corresponding unpacking or packaging according to the unpacking instruction or the packaging instruction;

The peripheral interface 26 is configured to communicate with the MCU and external testing equipment;

Specifically, the peripheral interface includes multiple different interfaces, such as SPI interface, USB, I2C interface, CAN interface, RS232 interface, DOIP interface, and UART interface. Through different types of interfaces, different external devices can be connected to the MCU. , through the debugging module of the upper computer to debug the external equipment through the MCU.

Specifically, it should be noted that the electrical connection in the present invention may be a direct electrical connection or an indirect electrical connection.

Referring to Figure 3, the debug command module includes:

The log printing command module is configured to start the log printing command according to the debugging requirements and send it to the log printing module in the MCU;

The log level filtering command module is configured to start the log level filtering command according to the debugging requirements and send it to the log level filtering module in the MCU;

The process interaction instruction module is configured to start the process interaction instructions between various processes according to the debugging requirements and send them to the process interaction module of the MCU;

The firmware acquisition instruction module is configured to start and issue the instruction to acquire firmware to the firmware acquisition module in the MCU according to the debugging requirements;

The content writing command module is configured to send the content writing command to the content writing module in the MCU according to the debugging requirements to start the content writing;

The content reading instruction module is configured to issue an instruction to start content reading according to the debugging requirements to the content reading module in the MCU;

The online upgrade instruction module is configured to issue an instruction to start the online upgrade to the online upgrade module in the MCU according to the debugging requirement.

A tool adaptive recognition command module configured to start a tool adaptive command according to requirements and send it to the tool adaptive recognition module in the MCU;

The application layer instruction module is configured to start the application layer instruction and send it to the application layer function customization module in the MCU according to the requirements;

See Figure 4, the debugging function modules include

The log printing module is configured to realize log printing, which prints out the log (log) message according to the instruction of the log printing instruction module, and is used to inform the developer of the running status of the program;

The log level filtering module is configured to implement log level filtering, and selectively implements the ability to dynamically filter logs of different levels according to the instructions of the log level filtering instruction module. Specifically, the log is divided into six levels;

The process interaction module is configured to record the information transmission between multiple tasks in real time, and it starts the information transmission recording between multiple tasks according to the process interaction instruction;

A firmware acquisition module configured to acquire firmware information, which acquires firmware information according to a firmware acquisition instruction;

The content writing module is configured to write the received information that needs to be written into the memory, and writes the corresponding data into the memory of the MCU according to the content writing instruction;

The content reading module is configured to read the information to be read, and reads the corresponding content according to the content reading instruction;

The online upgrade module is configured to upgrade the MCU, which upgrades the MCU according to the upgrade instruction received from the host computer;

The tool adaptive identification module is configured to identify whether the upper computer has a supporting serial port tool according to the tool adaptive identification instruction of the upper computer;

The application layer function customization module is configured to customize the functions of the application program according to the application layer instructions of the upper computer.

Example 2:

This implementation provides a cross-platform MCU debugging method, see Figure 5 and Figure 6, which includes two stages, the first stage includes the host computer according to the debugging requirements to start the debugging command and send it to the MCU, after the MCU receives the debugging command Start the corresponding debugging function module to debug the MCU;

The second stage includes sending the data generated by MCU debugging to the host computer for display. The data generated by MCU debugging includes at least logs, which are divided into multiple log levels according to the type. In the process of debugging the MCU, temporarily store the data that needs to be output in the memory, and wait for the external output when the system is idle. Or when it is found that the debugging function module in the MCU does not have a built-in preset function module or according to the debugging requirements, it is necessary to add a special function module, and directly write the required function module into the MCU through the host computer. Specifically, if the MCU needs to be restored, the existing functional modules do not have this function. At this time, the functional program can be directly written into the MCU through the host computer.

The debugging instruction module is configured to call the corresponding debugging instruction program to debug the MCU according to the debugging requirements;

The debugging function module is configured to correspond to the debugging instruction module and start the corresponding function module to debug the MCU according to the debugging instruction issued by the debugging instruction module.

The first phase consists of the following steps:

Step S101: According to the debugging requirements, start the debugging instruction module to send instructions through the host computer;

Specifically, the debugging requirements are carried out according to the debugging plan formulated by the engineer. The debugging instruction module integrates common MCU debugging instructions, and can also automatically add or delete specific debugging instructions through the host computer according to requirements. The debugging instructions are defined in advance, and when the MCU receives the corresponding debugging instructions, its debugging function module will execute corresponding actions according to the debugging instructions.

Step S102, the encapsulation and unpacking module of the host computer encapsulates the received instruction and forms a data packet;

Specifically, all data packets that need to be transmitted need to be packaged so that they can be transmitted only if they meet the standard transmission protocol. Here, the encapsulation and depacketization module encapsulates the instructions to be transmitted according to the predefined protocol requirements.

Step S103, the communication module in the host computer sends the encapsulated data packet to the MCU;

Specifically, the process of the communication module in the host computer sending the data packet to the MCU is that the communication module of the MCU receives the data packet sent by the host computer.

Step S104, the communication module of the MCU stores the received data packets in the memory;

Step S105, the encapsulation and unpacking module in the MCU unpacks the received data packet and obtains an instruction;

Step S106, the debugging function module in the MCU invokes the corresponding function program according to the instruction to execute the debugging of the MCU.

Specifically, the debugging function module is pre-written into the MCU, and the debugging function module corresponds to the debugging instruction module in the host computer, and it can perform corresponding debugging actions according to the debugging instruction. If there is no corresponding debugging function module in the MCU, it can be debugged by writing the debugging function module into the MCU through the host computer.

The debugging function module includes a packaged program, which can directly write the packaged program to the MCU, and the result is convenient and quick.

Sending the data generated by MCU debugging to the host computer for display includes at least the following steps:

Step S201: Send the data generated by the MCU debugging according to the debugging requirements;

Specifically, the debugging requirement is to start the corresponding debugging function module through the debugging function in the MCU to debug the MCU according to the instructions issued in the first stage. The debugging process will generate a system of logs, debugging results, MCU running status and other data , These data need to be sent to the host computer for display, so that engineers can view these data and analyze the debugging results of the MCU.

Step S202, judging the data type;

Specifically, a data packet may be generated during the debugging process, and a command packet may also be generated, so the type of the data packet needs to be determined during the data transmission process.

Step S203, the encapsulation and unpacking module in the MCU performs encapsulation according to requirements and stores the data packets in the memory;

Specifically, all data packets that need to be transmitted need to be packaged so that they can be transmitted only if they meet the standard transmission protocol. Here, the encapsulation and depacketization module encapsulates the instructions to be transmitted according to the predefined protocol requirements.

Step S204, the communication module in the MCU sends the data packet in the memory to the host computer;

Specifically, sending data from the MCU to the host computer is carried out through the communication module.

Step S205, the encapsulation and unpacking module in the host computer unpacks the received data packet;

Step S206, the host computer displays the unpacked data.

Specifically, the data generated by MCU debugging is displayed on the host computer. The project can display the content to check whether there is a problem with the MCU. If there is a problem, the data will show the cause of the problem, and then the project can modify the data more conveniently. .

The debugging function module includes a packaged program, which can directly write the packaged program to the MCU, and the result is convenient and fast.

Example 3

This embodiment provides a data encapsulation and data unpacking method, which is completed by an encapsulation and unpacking module.

The data encapsulation method includes the following steps:

Step S701, obtaining the payload (payload) that needs to be packaged and obtaining the address, length, and data packet type of the payload therefrom;

Specifically, the payload that needs to be transmitted already exists, and it needs to be packaged when transmitting, and the payload can be transmitted according to the type of the data packet by adding a header;

Step S702, judging whether the address is valid, if the address is invalid, execute step S707, and end the packaging process; if the address is valid, execute step S703;

Specifically, since the load data is stored in segments, it is searched in the storage area according to the obtained address whether the address exists, and if the address exists, it means that the address is valid. If the address does not exist, the address is invalid.

Step S703, judging the command type of the payload, if the command type of the payload is valid, then perform step S704, if the command type of the payload is invalid, then perform step S707, and end the packaging process;

Specifically, the type of the payload needs to be judged. The payload in the present invention includes four types, which are respectively defined as follows: the first type: 0x01: Log message packet. The second type: 0x02: CMD message packet. The third type: 0x03: Firmware packet. The fourth category: 0x04: OS Msg packet. If the payload is of the above four types, it is considered valid, and if the payload is not of the above four types, it is considered invalid.

Step S704, judging whether the data length of the payload is valid, if the data length is invalid, then execute step S707, end the packaging process, if the data length is valid, then execute step S705;

Step S705, assigning a value to the payload;

Specifically, the assignment includes the type of the data packet judged based on the payload, the length of the data packet, plus verification information, encryption information, and the like.

Step S706, storing the packaged data into the data area to be sent;

Step S707, end the packaging process.

The data unpacking method at least includes the following steps:

Step S800, detecting whether the frame header contains a high byte, if it contains a high byte, then execute step S801, if there is no high byte, return to step S800, and detect the next frame;

Specifically, the encapsulated data packet includes a frame header (head) and a payload (payload), and the frame header (ie header) defines some rules. If two bytes can be used as the start flag of this data packet, One is the high byte of the frame header, and the other is the low byte of the frame header. When unpacking, the first thing is to analyze the header of the frame. The data is transmitted in frames, so the header of the frame is checked to see if it contains high bytes.

Step S801, when the frame header is detected, the low byte is included, if the low byte is included, then step S802 is performed; if the low byte is not included, then return to step S800, and the next frame data is detected;

Specifically, the encapsulated data packet includes a frame header (head) and a payload (payload), and the frame header (ie header) defines some rules. If two bytes can be used as the start flag of this data packet, One is the high byte of the frame header, and the other is the low byte of the frame header. When unpacking, the first thing is to analyze the frame header. The data is transmitted in frames, so the frame header is checked to see if it contains low bytes.

Step S802, obtaining the length of the data packet;

Specifically, when the data is transmitted, a frame of data is generally divided into two sections, namely the frame header (head) and payload (payload), and the data packet length information is placed in the frame header, so by analyzing the frame subheader, you can Know the length of the packet.

Step S803, analyzing the packet type to determine which type the data packet belongs to.

The payload in the present invention includes four types, respectively defined as follows: the first type: 0x01: Log messagepacket. The second type: 0x02: CMD message packet. The third type: 0x03: Firmware packet. The fourth type: 0x04: OS Msg packet. In the data packet process, the data type has been defined, so the type of the data packet can be known by analyzing the frame header.

Step S804, obtaining the unpacked payload;

Specifically, after analyzing the frame header of the data packet, relevant information is obtained, the frame header is removed, and the payload remains.

Example 4:

During the process of developing the program, the developer can call the Log interface to distribute the Log anywhere in the program he writes. It is used to detect the running status of the system offline. During the debugging process, some variables that programmers care about can also be printed out in various formats. Log can be understood as the only window of the detection system after offline. The logs in the debugging process are printed through the log printing command module to control the log printing module by issuing commands. The specific log printing process is as follows:

Step S901, judging whether the log level matches, if it matches, execute step S902, if not, execute step S912;

Specifically, the present invention divides the log level into multiple levels, if the printed level is the content in the defined level and opened in the filter module, it is considered to be a match, if the printed content is not in the predefined level If it is within the range or the grade range in the filter module is off, then it is a mismatch.

Step S902, read the characters that need to print the first address of the character string in the debugging data packet;

Step S903, judging whether the first character of the address is a "terminator", if the first character of the address is a terminator, then end the process. If the first character is not an end character, continue to the next step.

Specifically, the terminator can be defined by itself, usually "\0".

Step S904, judge whether the character is '%', if the character is not '%', then execute step S910, save the character; if the character is '%', then obtain the next character;

Step S905, judge whether the next character is x or d, if it is d, then execute step S906, if it is x, then execute step S908;

Step S906, obtaining the next parameter;

Step S907, convert the obtained parameters into decimal characters and execute step S910;

Step S908, obtaining the next parameter;

Step S909, converting the obtained parameters into hexadecimal characters and performing step S910;

Step S910, saving the character;

Step S911, point to the next byte, jump to repeat step S903, until all characters are printed;

Step S912, end the process.

For example: print a line of debug log, logPintf(LOG_INFO,"this is test%d\0", cnt1, cnt2, cnt3),

LOG_INFO is one of multiple predefined levels. If LOG_INFO is printing, the log level filter module, if it is turned on, the LOG_INFO level is matched. Does not match if it is not a defined level type or when the log level filter module is turned off.

If it matches, the displayed character "t" is not "%", then save "t" until this is test is saved, at this time, the program executes to %, the character is %, check the next character, it is d, and get the next parameter cnt1, convert cnt1 to decimal number display. It should be noted that "\0" is automatically loaded by the system and is not actually displayed. Therefore, the content of "%" is not displayed by default, and the character after "%" is considered to be cnt1.

During the log printing process, the log level filtering module can be sent to the log level filtering module to perform level filtering through the log level filtering command. The log level filtering module will divide the log into multiple levels. Realize the ability to dynamically filter logs of different levels.

The Log module defines 6 levels, namely debug (debugging message), info (information), OsMsg (type message), Warn (warning), Error (error), Fatal (fatal), each level of log is set to display (on) or off (off), by choosing to display or close the selection, you can quickly find the required logs and filter out the relevant modules. For example: if we need to display the debug log, then debug needs to select On debug message, if we want to filter out debug log, then debug needs to select OFF debug message, and so on.

The realization of printing log level filtering is accomplished through the log level filtering module, which specifically includes the following steps:

Step S601, receiving data from the host computer;

Step S602, check the integrity of the data packet, if the data packet is complete, then perform step S603, if the data packet is incomplete, then end the process;

Step S603, analyzing the type of the data packet and putting the data packet into the corresponding level according to the type;

Step S604 selects ON for the log that needs to be displayed, selects OFF for the log that does not need to be displayed, and then prints;

Specifically, when the level of the log module shows ON, it means that the level needs to be printed out; if the level of the log module shows OFF, it means that the level of the log does not need to be printed out;

The Debug log is used to record the command status during system debugging. It is mainly used when debugging a single function without considering the entire system. Because when the software is released, the Log of this level is turned off by default. When the program is developed, the debug type log will be deleted. For example, when we debug the vehicle speed, we can print out the current vehicle speed value collected from the CAN network in real time. Wait for this function to be fully completed, and then delete this Log. Because this level of Log is not very meaningful to the system, but it is very useful for the development and debugging of the current function.

The Info log type Log is mainly used to record a running status of the current system. This type of message is used after a phased, iconic action has been performed. For example, the peripheral device is powered on and the peripheral device initialization is successful. These messages can monitor the running status of the system and inform the debugger what stage the current program is running at. If it is found that the info message that should be printed is not printed, it means that the function of the corresponding area may be faulty.

OsMsg log type messages are used to record an interaction process between processes. As long as the message queue sent by the process is marked with the OsMsg label, it will be output to the outside world. Messages of interest can be filtered out based on the source process, target process, and command type. On the one hand, it can detect heavy-duty processes, and allocate more resources to such processes to ensure their normal operation. You can also filter out some key commands to gain a deeper understanding of the system's running process.

The Warn log type is mainly used to warn developers that errors may have occurred or illegal operations have been performed.

The ERROR log type message mainly informs the developer that an error has been encountered during the running of the program, but this type of error has been dealt with in the program, and the function may be invalid, but the system operation will not be affected.

FATA log type messages are used to inform developers that the system has encountered a serious error, resulting in program crashes, software restarts and other serious consequences.

Example 5:

In the process of debugging the MCU, developers send these instructions to the MCU to debug the functional modules through the debugging instruction modules in the host computer, such as log printing, process interaction, and content reading, and start the corresponding functional modules. The generated debugging data is stored in the memory, preferably in the cache, instead of being cleared immediately and waiting for the external output when the system is idle, so as to avoid competing for time with other high-priority tasks and make full use of the MCU resource.

Claims (9)

1. A cross-platform MCU debugging method is applied to debugging of an upper computer and an MCU, and is characterized by at least comprising the following steps:

the upper computer starts a debugging instruction module according to debugging requirements to send a debugging instruction to the MCU, and the MCU starts a corresponding debugging functional module to debug the MCU after receiving the debugging instruction;

the debugging instruction module is configured to call a corresponding debugging instruction program according to debugging requirements to debug the MCU;

the debugging functional module is configured to correspond to the debugging instruction module and start a corresponding specific functional module to debug the MCU according to a debugging instruction issued by the debugging instruction module;

the debugging instruction needs to be packaged before being sent to the MCU, and the packaging of the debugging instruction at least comprises the following steps:

step S701, acquiring a payload to be packaged and acquiring an address, a length and a data packet type of the payload from the payload;

step S702, judging whether the address is valid, if the address is invalid, executing step S707 to end the packaging process; if the address is valid, go to step S703;

step S703 of determining the command type of the payload, if the command type of the payload is valid, executing step S704, and if the command type of the payload is invalid, executing step S707, and ending the packetizing process;

step S704, determining whether the data length of the payload is valid, if the data length is invalid, executing step S707, ending the encapsulation process, if the data length is valid, executing step S705;

step S705, assigning values to the effective loads;

step S706, storing the packaged data into a data area to be sent;

in step S707, the packaging process is ended.

2. The cross-platform MCU debugging method of claim 1, further comprising: data generated by MCU debugging are sent to an upper computer for displaying, the data generated by MCU debugging at least comprise logs, and the logs are divided into a plurality of log grades according to types;

in the process of debugging the MCU, temporarily storing data to be output in a memory, and outputting the data to the outside when a system is idle;

or when the debugging functional module in the MCU is found not to be internally provided with a preset functional module or an additional functional module is required to be added according to the debugging requirement, the required functional module is directly written into the MCU through the upper computer.

3. The cross-platform MCU debugging method of claim 2,

the MCU needs to unpack the received encapsulated data packet to obtain a modulation instruction;

the data generated by MCU debugging need to be packaged before being sent to the upper computer, and the upper computer needs to unpack the received packaged data packet to obtain the data packet generated by debugging.

4. The cross-platform MCU debugging method according to claim 3,

the unpacking of the received encapsulated data packet comprises the following steps:

step S800, detecting whether the frame header contains high byte, if so, executing step S801, if not, returning to step S800 to detect the next frame;

step S801, detecting whether the frame header includes a low byte, if so, executing step S802; if the low byte is not included, returning to step S800, and detecting next frame data;

step S802, acquiring the length of a data packet;

step S803, analyze the packet type, judge which kind of packet belongs to;

and step S804, acquiring the unpacked effective load.

5. The cross-platform MCU debugging method according to claim 1, wherein the debugging instruction module at least comprises one or more of a log printing instruction module, a log level filtering instruction module, a process interaction instruction module, a firmware acquisition instruction module, a content writing instruction module, a content reading instruction module, an online upgrading instruction module, a tool adaptive identification instruction module, and an application layer instruction module;

the debugging functional module at least comprises one or more of a log printing module, a log grade filtering module, a process interaction module, a firmware acquisition module, a content writing module, a content reading module, an online upgrading module, a tool self-adaptive identification module and an application layer function formulation module.

6. The cross-platform MCU debugging method according to claim 5,

the log printing instruction module is configured to start a log printing instruction according to debugging requirements and issue the log printing instruction to the log printing module in the MCU;

the log grade filtering instruction module is configured to start a log grade filtering instruction according to debugging requirements and issue the log grade filtering instruction to the log grade filtering module in the MCU;

the process interaction instruction module is configured to start process interaction instructions among the processes according to debugging requirements and issue the process interaction instructions to the MCU;

the firmware acquisition instruction module is configured to start an instruction for acquiring firmware according to debugging requirements and issue the instruction to the firmware acquisition module in the MCU;

the content writing instruction module is configured to start a content writing instruction according to the debugging requirement and issue the content writing instruction to the content writing module in the MCU;

the content reading instruction module is configured to start a content reading instruction according to the debugging requirement and send the content reading instruction to the content reading module in the MCU;

the online upgrading instruction module is configured to start an online upgrading instruction according to debugging requirements and send the online upgrading instruction to the online upgrading module in the MCU;

the tool self-adaptive identification instruction module is configured to start a tool self-adaptive instruction according to the requirement and issue the tool self-adaptive identification instruction to the tool self-adaptive identification module in the MCU;

the application layer instruction module is configured to start an application layer instruction according to the requirement and send the application layer instruction to the application layer customizing function module in the MCU;

the log printing module is configured to realize log printing, and is used for printing and outputting log messages according to the instructions of the log printing instruction module so as to inform the operating state of the program to developers;

the log grade filtering module is configured to realize log grade filtering and selectively realize dynamic filtering of log capacities of different grades according to the instruction of the log grade filtering instruction module;

the process interaction module is configured to record information transmission among the tasks in real time and start the information transmission record among the tasks according to the process interaction instruction;

a firmware acquisition module configured to acquire information of firmware, which acquires firmware information according to a firmware acquisition instruction;

the content writing module is configured to write the received information needing to be written into the memory, and write corresponding data into the memory of the MCU according to the content writing instruction;

the content reading module is configured to read information to be read, and reads corresponding content according to a content reading instruction;

the online upgrading module is configured to upgrade the MCU and upgrade the MCU according to an upgrading instruction received from the upper computer;

the tool self-adaptive identification module is configured to identify whether the upper computer has a matched serial port tool or not according to a tool self-adaptive identification instruction of the upper computer;

and the application layer function customizing module is configured to customize the functions of the application program according to the application layer instruction of the upper computer.

7. The cross-platform MCU debugging method of claim 6, wherein the log in the debugging process is printed by a log printing instruction module issuing an instruction to control a log printing module, and the log printing comprises the following steps:

step S901, determining whether the log grades are matched, if so, executing step S902, and if not, executing step S912;

step S902, reading the character of the character string head address in the debugging data packet to be printed;

step S903, determining whether the first character of the address is an "end character", and if the first character of the address is an end character, ending the process; if the first character is not the end character, continuing the next action;

step S904, determining whether the character is '%', if the character is not '%', executing step S910 to save the character; if the character is '%', acquiring the next character;

step S905, determining whether the next character is x or d, if so, performing step S906, and if so, performing step S908;

step S906, acquiring the next parameter;

step S907, converting the acquired parameters into decimal characters and executing step S910;

step S908, acquiring a next parameter;

step S909, converting the acquired parameters into hexadecimal characters and executing step S910;

step S910, saving the character;

step S911, pointing to the next byte, skipping and repeating step S903 until all characters are printed;

step S912, the process ends.

8. The cross-platform MCU debugging method of claim 6, wherein implementing print log level filtering is accomplished by a log level filtering module, comprising the steps of:

step S601, receiving data of an upper computer end;

step S602, the integrity of the data packet is checked, if the data packet is complete, the step S603 is executed, and if the data packet is incomplete, the process is ended;

step S603, analyzing the type of the data packet and putting the data packet into a corresponding grade according to the type;

step S604, selecting ON the log needing to be displayed and selecting OFF the log not needing to be displayed, and then printing;

when the level display of the log module is ON, the log module indicates that the level needs to be printed, and when the level display of the log module is OFF, the log module indicates that the log level does not need to be printed.

9. The cross-platform MCU debugging method of claim 2,

the log grade at least comprises any two of a Debug log, an Info log, an OsMsg log, a Warn log, an ERROR log and an FATAL log;

a Debug log: the system is used for recording the command state in the system debugging process;

the Info log: used for recording an operation state of the current system;

OsMsg log: the system is used for recording an interactive process among processes, and the OsMsg label is marked on a message queue sent by the processes for outputting, so that concerned messages can be filtered out according to a source process, a target process and a command type;

the Warn log: used for warning developers that errors may occur or illegal operations are performed;

ERROR log: informing developers that errors are encountered in the program running process, but the errors are processed in the program, and the functions may be invalid, but the system running is not influenced;

FATAL Log: the system is used for informing a developer that the system encounters serious errors, and the result is program crash and software restart.

Images