CN110457215B

CN110457215B - Cross-platform MCU debugging method

Info

Publication number: CN110457215B
Application number: CN201910701812.1A
Authority: CN
Inventors: 肖文平; 王子祥; 陈柱; 张航
Original assignee: Shanghai Hinge Electronic Technologies Co Ltd
Current assignee: Shanghai Hinge Electronic Technologies Co Ltd
Priority date: 2019-07-31
Filing date: 2019-07-31
Publication date: 2023-01-10
Anticipated expiration: 2039-07-31
Also published as: CN110457215A

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

Cross-platform MCU debugging method

Technical Field

The invention relates to the field of Micro Controller Units (MCU), in particular to a method for debugging MCU faults in the development process of an automobile MCU or after the development.

Background

Along with the popularization of automobiles, more and more automobiles enter thousands of households, and the rapid development of the existing information technology enables people to put forward higher requirements on automobile intellectualization, so that the intelligent automobiles are expected to bring convenience to the practicality of people. The intelligent vehicle is a comprehensive system integrating functions of environmental perception, planning decision, multi-level auxiliary driving and the like, intensively applies technologies such as computer, modern sensing, information fusion, communication, artificial intelligence, automatic control and the like, and is a typical high and new technology complex. The current research on intelligent vehicles mainly aims to improve the safety and the comfort of automobiles and provide excellent human-vehicle interaction interfaces. In recent years, intelligent vehicles have become hot spots for the research in the field of vehicle engineering in the world and new power for the growth of the automobile industry, and many developed countries incorporate the intelligent vehicles into intelligent transportation systems which are intensively developed. The development of intelligent automobiles puts strict requirements on all aspects of a vehicle body control system, including software and hardware, and the software and the hardware can not be processed by an MCU. The MCU development cycle that the function is powerful is longer, need constantly debug MCU in the development process, traditional debugging method is shown as figure 1, it includes the host computer, the debugging tool, MCU debugging needs special debugging tool, in its debugging process, debug the tool and then debug MCU through host computer control, on the one hand, need special debugging tool, and debugging tool in case accomplish, it is difficult to change, only can be applied to the MCU debugging of specific model, it is not flexible enough, have great limitation. Only the internal information of the MCU, such as registers, variables, and values in the memory area, can be obtained. However, the MCU at the present stage integrates many functions, and it is far from sufficient to know the values of registers, variables, and memory areas, and it is impossible to obtain the operating state of the system from these data, and also impossible to obtain the interdependence between the system operating flow and each module.

In order to facilitate debugging of developers and debug each functional module and the function matched with the MCU in the MCU development process in time, a new MCU debugging device needs to be developed to debug the MCU.

Disclosure of Invention

Based on the defects in the prior art, the technical problem to be solved by the invention is that a cross-platform MCU debugging method is applied to system debugging comprising 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;

and 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 the debugging instruction transmitted by the debugging instruction module.

The invention provides a cross-platform MCU debugging method, further comprising: data generated by MCU debugging are sent to an upper computer for displaying, the data generated by the MCU debugging 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 the 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 a debugging result, the required functional module is directly written into the MCU through the upper computer.

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

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

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

step S701, acquiring a payload (payload) needing to be packaged and acquiring an address, a length and a data packet type of 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.

The invention provides a cross-platform MCU debugging method, further, 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 contains a low byte, if so, executing step S802; if the low byte is not included, returning to step S800, and detecting the 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;

step S804, obtaining the effective load after unpacking;

the invention provides a cross-platform MCU debugging method, further, the debugging instruction module at least comprises one or more of a log printing instruction module, a log grade filtering instruction module, a process interaction instruction module, a firmware obtaining instruction module, a content writing instruction module, a content reading instruction module, an online upgrading instruction module and a tool self-adaptive identification 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 and a tool self-adaptive identification module

Further, the log printing instruction module is configured to start a log printing instruction according to the debugging requirement 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 send the instruction to the firmware acquisition module in the MCU;

the content writing instruction module is configured to issue an instruction for starting content writing according to debugging requirements 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;

and the online upgrading instruction module is configured to start an online upgrading instruction according to the debugging requirement 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;

and 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 function customizing module in the MCU.

The invention provides a cross-platform MCU debugging method, further, 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 and a tool self-adaptive identification module;

further, a log printing module configured to implement log printing by printing out a log (log) message according to an instruction of the log printing instruction module, for informing a developer of an operation state of the program;

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 on-line 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.

The invention provides a cross-platform MCU debugging method, further, a log in the debugging process is printed by a log printing instruction module through issuing an instruction control log printing module, and the log printing comprises the following steps:

step S901, determining whether the log levels 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 needing to be printed;

in step S903, it is determined whether the first character of the address is an "end character", and if the first character of the address is an end character, the process is ended. 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;

in step S912, the process ends.

The invention provides a cross-platform MCU debugging method, further, the printing log grade filtration is completed by a log grade filtration module,

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.

The invention provides a cross-platform MCU debugging method, further, 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 method 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 externally, so that concerned messages can be filtered according to the source process, the target process and the 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 subjected to relevant processing in the program, and the function is possibly 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.

The invention also provides a cross-platform MCU debugging device which is characterized by comprising an MCU, wherein the MCU comprises a CPU, a debugging functional module, a communication module, a storage module and an encapsulation unpacking module;

the CPU is configured to be responsible for calling and operation among all the modules of the system;

the debugging functional module is configured to start a corresponding specific functional module to debug the MCU according to the received debugging instruction, and the debugging functional module can increase or reduce debugging functions according to debugging requirements;

the memory module is configured to store data required in a debugging process, generated data and a debugging functional program or cache data;

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

and the packaging and unpacking module is configured for performing corresponding unpacking or packaging according to the unpacking instruction or the packaging instruction.

The invention also provides a cross-platform MCU debugging device, further comprising an upper computer, wherein the upper computer at least comprises a CPU, a storage module, a debugging instruction module, a communication module and an encapsulation unpacking module, and the CPU is respectively and electrically connected with the storage module, the debugging instruction module, the communication module and the encapsulation unpacking module;

the communication module of the upper computer is electrically connected with the communication module in the MCU, wherein the communication module of the upper computer is in communication connection with the communication module in the MCU through wireless communication or wired communication;

the CPU is configured to be responsible for calling and operation among the modules of the system;

the memory module is configured to be used for storing data required in the debugging process and a debugging instruction program;

the packaging and unpacking module is configured for performing corresponding unpacking or packaging according to the unpacking instruction or the packaging instruction;

and the communication module is configured for the upper computer to communicate with the external equipment.

The invention also provides a cross-platform MCU debugging device, further, the debugging functional module at least comprises one 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 and a tool self-adaptive identification module;

a log printing module configured to implement log printing by which a log (log) message is printed out according to an instruction of the log printing instruction module to inform a developer of an operation state of a program; 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; and the tool self-adaptive identification module is configured to identify whether the upper computer has a matched serial port tool according to the tool self-adaptive identification instruction of the upper computer.

The invention also provides a cross-platform MCU debugging device, further, the debugging instruction module at least comprises one of a log printing instruction module, a log grade filtering instruction module, a process interaction instruction module, a firmware obtaining instruction module, a content writing instruction module, a content reading instruction module, an online upgrading instruction module and a tool self-adaptive identification instruction module:

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 send the instruction to the firmware acquisition module in the MCU; the content writing instruction module is configured to issue an instruction for starting content writing according to debugging requirements 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; and the online upgrading instruction module is configured to start an online upgrading instruction according to the debugging requirement and send the online upgrading instruction to the online upgrading module in the MCU. And 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 instruction to the tool self-adaptive identification module in the MCU.

The invention also provides a cross-platform MCU debugging device, further, the packaging unpacking module is used for carrying out corresponding unpacking or packaging according to the unpacking instruction or the packaging instruction, and the packaging comprises the following steps:

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 packetization process;

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.

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

step S801, detecting whether the frame header contains 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;

step S804, obtain the unpacked payload.

The invention also provides a cross-platform MCU debugging device, further, a log printing module is used for printing logs generated in the debugging process, 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, judging whether the first character of the address is an end character, if the first character of the address is the end character, ending the process; if the first character is not the end character, continuing the next action;

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

step S906, acquiring the next parameter;

step S908, acquiring a next parameter;

step S910, saving the character;

in step S912, the process ends.

Or the log grade filtering module is used for realizing the printing log grade filtering, and the log grade filtering comprises the following steps:

step S601, receiving data of an upper computer end;

step S602, checking the integrity of the data packet, if the data packet is complete, executing step S603, and if the data packet is incomplete, ending the process;

in step S604, the journal that needs to be displayed is selected ON, the journal that does not need to be displayed is selected OFF, and printing is performed.

The invention also provides a cross-platform MCU debugging device, further, the MCU also comprises at least one peripheral interface, the peripheral interface is configured to be used for the communication connection between the MCU and external equipment, and the types of the peripheral interface comprise one or more of an SPI interface, a USB interface, an I2C interface, a CAN interface, a DOIP interface, a UART interface and an R232 interface.

The invention has the beneficial technical effects that:

1. compared with the prior art, the debugging method of the invention directly adopts the MCU and the upper computer to carry out assembly debugging without adopting a special debugging tool as an intermediate medium, thus reducing the debugging cost and having flexible and variable debugging method. The upper computer is enabled to be in direct communication with the MCU to be debugged, so that data transmission is more reliable. And functional modules with special debugging requirements can be added to the MCU at any time according to the debugging requirements, so that the debugging of the MCU of different platforms is realized.

2. The debugging method of the invention puts all the information to be output in the memory (cache) and outputs the information to the outside when waiting for the system to be idle, thus avoiding the competition for time with other tasks with high priority and fully utilizing MCU resources. In the existing debugging tool, data generated when a function or a command is called in the debugging process is not stored, and after the function is called, the data generated by the function can cover the data generated by the previous function when the next function is called. The invention has the effect of saving resources and avoiding the function from being called again by storing the data to be output externally into the cache.

3. And dividing log grades, and setting a log grade filtering module to filter the logs. Therefore, the invention has strong filtering function and supports Log record. When the product is delivered after testing, the emulator needs to be disconnected during testing. That is to say, the conventional debugging method is only suitable for being used during function development. The running condition of the program cannot be known in the test stage. The log tracing and filtering functions added by the tool can solve the problem well. Developers can selectively filter log messages that are not relevant to the bug and quickly track the location of the bug.

4. The program is convenient to transplant, and the debuggers and compilers required by the MCUs of different manufacturers are different from the compilers, so that compatibility cannot be realized. By the debugging device provided by the invention, debugging can be carried out only by writing the debugging functional module into the debugged MCU. Therefore, the debugging tool of the invention relieves the limitation of the platform, the relieved library limitation of the compiler and the limitation of the debugger.

5. The invention can print the debugging 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.

Drawings

The following drawings are merely illustrative and explanatory of the invention and do not limit the scope of the invention.

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

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

Fig. 3 is a schematic structural diagram of a specific instruction function module included in the debug instruction module in the embodiment of the present invention.

Fig. 4 is a schematic structural diagram of a specific functional module included in the debugging functional module in the embodiment of the present invention.

Fig. 5 is a flowchart of the upper computer starting a debugging instruction according to a debugging requirement, issuing the debugging instruction to the MCU, and debugging the MCU in the embodiment of the present invention.

Fig. 6 is a flowchart of sending data generated by MCU debugging to an upper computer for display in the embodiment of the present invention.

Detailed Description

In order to more clearly understand the technical features, objects and effects of the present invention, embodiments of the present invention will now be described with reference to fig. 2 to 6, in which like reference numerals refer to like parts in the various figures. For the sake of simplicity, the drawings are only schematic representations of the relevant parts of the invention, and do not represent the actual structure of the product. In addition, in order to make the drawings concise and understandable, components having the same structure or function in some of the drawings are only schematically illustrated or only labeled.

As for the control system, it is well known to those skilled in the art that it may take any suitable form, either hardware or software, or a plurality of functional modules arranged discretely, or a plurality of functional units integrated into one piece of hardware. In its simplest form, the control system may be a controller, such as a combinational logic controller, a micro-programmed controller, or the like, so long as the operations described herein are enabled. Of course, the control system may also be integrated as a different module into one physical device without departing from the basic principle and scope of the invention.

Example 1:

the embodiment provides a cross-platform MCU debugging device, refer to fig. 2 to 4, including host computer 1, MCU2, host computer 1 includes CPU11, storage module 12, debug instruction module 13, communication module 14, encapsulate unpack module 15, CPU11 respectively with storage module 12, debug module 13, communication module 14, encapsulate unpack module 15 and carry out the electricity and connect, MCU2 includes CPU21, debug functional module 22, communication module 24, storage module 23, encapsulate unpack module 25, at least one peripheral interface 26.

The communication module 14 of the upper computer 1 is connected with the communication module 24 in the MCU, wherein the communication module 14 and the communication module 24 can adopt wireless communication or wired communication mode, if the wireless communication mode is adopted, the wireless communication mode can adopt WIFI, bluetooth, ultra wide band, 4G, 5G communication and other modes, or the wireless communication is T-box. Or a wired communication mode CAN be adopted, for example, the upper computer 1 and the MCU2 have matched interfaces, such as an Ethernet interface, an I2C interface, a USB interface, an RS232 interface, a CAN interface, a DOIP interface, a UART interface and the like. Such as: the communication module 14 of the upper computer 1 is provided with an I2C interface, the communication module 24 of the MCU2 is provided with an I2C interface, and the upper computer 1 and the MCU2 are in wired connection through an I2C data line. When adopting radio communication, communication module 14 of host computer 1 contains the radio communication subassembly, if have Wifi, MCU 2's communication module 24 has and contains the radio communication subassembly, and for Wifi, host computer 1 can be connected with MCU2 through Wifi. Or when the upper computer 1 is a remote computer or a server, the MCU2 can be connected with the upper computer through a T-box.

In the upper computer 1, a CPU11 is mainly used for calling and operating various modules of the system;

the memory module 12 is configured to store data required in a debugging process and a debugging instruction program;

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

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

a communication module 14 configured to communicate with an external device by an upper computer;

in the MCU2, the MCU2 may be an under-development MCU or an already-completed MCU.

The CPU21 is configured to be responsible for calling and operation among the modules of the system;

the storage module 23 is configured to store data used in a debugging process, generated data, a debugging function program or cache data, and the like;

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

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

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

a peripheral interface 26 configured for the MCU to make a communication connection with an external device;

specifically, the peripheral interface includes a plurality of different interfaces, such as SPI interface, USB, I2C interface, CAN interface, RS232 interface, DOIP interface, UART interface, through the interface of different grade type, CAN be connected to MCU with different external device in, debugs external equipment through MCU through the debugging module of host computer.

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 fig. 3, the debug instruction module includes:

the log printing instruction module is configured to start a log printing instruction according to the debugging requirement and issue the log printing instruction to the log printing 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 application layer instruction module is configured to start an application layer instruction according to the requirement and issue the application layer instruction to the application layer function customizing module in the MCU;

referring to fig. 4, the debug function module includes

A log printing module configured to implement log printing, which prints out a log (log) message for informing a developer of an operation state of a program according to an instruction of the log printing instruction module;

and the log grade filtering module is configured to realize log grade filtering, and selectively realizes dynamic filtering of log capacities of different grades according to the instruction of the log grade filtering instruction module. Specifically, the logs are divided into six levels;

Example 2:

the implementation provides a cross-platform MCU debugging method, which comprises two stages, namely, a first stage and a second stage, wherein the first stage comprises the steps that an upper computer starts a debugging instruction to be issued to an MCU according to debugging requirements, and the MCU starts a corresponding debugging functional module to debug the MCU after receiving the debugging instruction;

and the second stage comprises the step of sending data generated by MCU debugging to an upper computer for display, wherein the data generated by MCU debugging at least comprises logs, and the logs are divided into a plurality of log grades according to types. In the process of debugging the MCU, data needing to be output is temporarily stored in a memory and is output to the outside when the 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 a special 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. The concrete steps are as follows: if the MCU needs to be restored, the existing functional module does not have the function, and at the moment, the functional program can be directly written into the MCU through the upper computer.

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

The first stage comprises the steps of:

step S101: starting a debugging instruction module to send an instruction through an upper computer according to debugging requirements;

specifically, the debugging requirement is carried out according to the debugging scheme that the engineer made, and common MCU debugging instruction has been integrated to the debugging instruction module, can also be according to the demand automatic through the host computer through adding or deleting specific debugging instruction. The debugging instruction is defined in advance, and when the MCU end receives the corresponding debugging instruction, the debugging functional module can execute corresponding action according to the debugging instruction.

S102, a packaging and unpacking module of the upper computer packages the received instruction and forms a data packet;

specifically, the data packets to be transmitted need to be encapsulated so that they meet the standard protocol for transmission. Here, the encapsulating and unpacking module encapsulates the instruction to be transmitted according to the predefined protocol requirement.

Step S103, a communication module in the upper computer sends the packaged data packet to the MCU;

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

Step S104, the communication module of the MCU stores the received data packet into a memory;

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

and step S106, the debugging functional module in the MCU calls a corresponding functional program to execute the debugging of the MCU according to the instruction.

Specifically, the debugging functional module is written into the MCU in advance, corresponds to the debugging instruction module in the upper computer, and can perform corresponding debugging actions according to the debugging instruction. If the MCU does not have a corresponding debugging functional module, the debugging functional module can be written into the MCU through the upper computer for debugging.

The debugging functional module comprises a packaged program, and the packaged program can be directly written into the MCU, so that the result is convenient and quick.

The data generated by MCU debugging are sent to the upper computer for display, which at least comprises the following steps:

step S201: transmitting data generated by MCU debugging according to debugging requirements;

specifically, the debugging requirement is that the corresponding debugging function module is started through the debugging function in the MCU according to the instruction issued in the first stage to debug the MCU, the debugging process can generate data such as a system log, a debugging result, the running state of the MCU and the like, and the data needs to be sent to the upper computer to be displayed, so that an engineer can check the data and then analyze the debugging result 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 that the type of the data packet needs to be determined during the data transmission process.

Step S203, a packaging and unpacking module in the MCU packages according to requirements and stores the data packet into a memory;

Step S204, a communication module in the MCU sends the data packet in the memory to an upper computer;

specifically, the data is sent to the upper computer through the communication module in the MCU.

Step S205, an encapsulation unpacking module in the upper computer unpacks the received data packet;

and step S206, the upper computer displays the unpacked data.

Specifically, data generated by MCU debugging are displayed on the upper computer, the project is that the displayed content is used for checking whether the MCU has problems, if yes, the data can display the reasons of the problems, and then the project can modify the data more conveniently.

The debugging functional module comprises a packaged program, the packaged program can be directly written into the MCU, and the result is convenient and quick.

Example 3

The embodiment provides a data packaging and data unpacking method which is completed by a packaging and unpacking module.

The data packaging method comprises the following steps:

specifically, the payload to be transmitted already exists, and the packet is required to be transmitted, and the payload is added with the header according to the type of the data packet to be transmitted;

specifically, since the payload data storage is a segment, whether the address exists is searched in the storage area according to the obtained address, and if the address exists, the address is valid. If the address does not exist, the address is invalid.

specifically, the type of the payload needs to be determined, and the payload in the present invention includes four types, which are respectively defined as follows: the first type: 0x01: 0x02. The third type: 0x03. The fourth type: 0x04. If the payload is of the above four types, it is considered to be valid, and if the payload is not of the above four types, it is considered to be invalid.

step S705, assigning values to the effective loads;

specifically, the assignment includes the packet type and the packet length of the payload according to the judgment, and the verification information, the encryption information and the like are added.

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

in step S707, the packaging process is ended.

The data unpacking method at least comprises the following steps:

specifically, the encapsulated packet includes a frame header (head) and a payload (payload), and the frame header (i.e., header) defines some rules, and if two bytes can be used as the start flag of the packet, one is the header high byte and one is the header low byte. When unpacking, it is first to analyze the frame header, and the data is transmitted in frames, so that the frame header is detected to see whether the high byte is included.

Step S801, detecting that the frame header contains low byte, if the frame header contains low byte, executing step S802; if the low byte is not included, returning to step S800, and detecting the next frame data;

specifically, the encapsulated packet includes a frame header (head) and a payload (payload), where the frame header (i.e., header) defines some rules, and if two bytes can be used as the start flag of the packet, one is the header high byte and the other is the header low byte. When unpacking, it is first of all to analyze the frame header, and the data is transmitted in frames, so that the frame header is detected to see if it contains low bytes.

Step S802, acquiring the length of a data packet;

specifically, when data is transmitted, a frame of data is generally divided into two segments, namely a header (head) and a payload (payload), and the length information of the data packet is placed in the header, so that the length of the data packet can be known by analyzing the subheader of the frame.

Step S803, the packet type is analyzed, and which type the data packet belongs to is determined.

The payload in the present invention includes four types, which are respectively defined as follows: the first type: 0x01: 0x02: 0x03: 0x04. In the data packaging process, the data type is defined, so that the type of the data package can be known by analyzing the frame header.

Step S804, obtaining the effective load after unpacking;

specifically, after the frame header of the data packet is analyzed, the related information is obtained, the frame header is removed, and the payload is left.

Example 4:

during the process of developing the program, a developer can call a Log interface to distribute the Log at any position of the program written by the developer. The system is used for detecting the running state of the system off line. Some variables of programmer interest may also be printed out in various formats during debugging, and Log may be understood as the only window of the detection system after offline. The log in the debugging process is printed by a log printing instruction module through issuing an instruction control log printing module, and the specific log printing process is as follows:

specifically, the journal level is divided into a plurality of levels, if the printed level is the content in the defined level and is opened in the filtering module, the journal level is considered to be matched, and if the printed content is not in the predefined level range or the level range in the filtering module is in a closed state, the journal level is not matched.

in step S903, it is determined whether the first character of the address is an "end character", and if the first character of the address is an end character, the process is ended. If the first character is not an end character, the next action is continued.

In particular, the terminator may be self-defined, typically being "\0".

step S906, acquiring the next parameter;

step S908, acquiring a next parameter;

step S910, saving the character;

in step S912, the process ends.

For example: print a line of debug LOG, logPintf (LOG _ INFO, "this is test% d \0", cnt1, cnt2, cnt 3),

the LOG _ INFO is one of a plurality of levels defined in advance, if in the printing of the LOG _ INFO, the LOG level filtering module, if in the open state, the LOG _ INFO level is matched. If not, the log level filter module is closed.

If the characters are matched, the display character "t" is not "%", the character "t" is saved until the this is test is saved, the program is executed to the percent, the character is percent, the next character is checked, the next character is d, the next parameter cnt1 is obtained, and the cnt1 is converted into a decimal number to be displayed. It should be noted that "\0" is automatically loaded by the system and is not actually displayed. Therefore, the content of the default "%" is not shown, and the character following "%" is considered cnt1.

In the log printing process, the log grade filtering instruction can be issued to the log grade filtering module to perform grade filtering, the log grade filtering module can divide the log into a plurality of grades, in the embodiment, the grades comprise 6, and the capacity of dynamically filtering logs with different grades is realized by matching with an upper computer.

The Log module defines 6 levels, which are debug (debug message), info (information), osMsg (type message), warn (warning), error (Error) and Fatal (Fatal), each level Log is provided with display (on) or closing (off), and by selecting display or closing type selection, required logs can be quickly searched out, and relevant modules are filtered out. For example: if we need to display the debug log, the debug needs to select the On debug message, if the debug log needs to be filtered, the debug needs to select the OFF debug message, and the rest is similar.

The method for realizing the printing log grade filtering is completed through a log grade filtering module, and specifically comprises the following steps:

step S601, receiving data of an upper computer end;

specifically, when the level display of the log module is ON, it means that the log module needs to print the level, and when the level display of the log module is OFF, it means that the log level does not need to be printed;

the Debug log is used for recording the command state in the system debugging process, is mainly used in the single function debugging process, and does not need to consider the whole system. Since the Log at this level is closed by default at the time of software release. When this program is developed, the debug type log is deleted. For example, when the vehicle speed is debugged, the vehicle speed value collected from the CAN network at present CAN be printed in real time. And after the function is completely done, deleting the Log. Since the Log of this level is not of great significance to the system, but is very useful for development and debugging of current functionality.

The Log of the Info Log type is mainly used to record an operation state of the current system. Staged, symbolic actions are used after they have been performed. For example, the peripheral is powered on and initialized successfully. These messages may monitor the operational state of the system and inform the debugger as to which stage the current program is running. If the originally printed info message is not printed, the function of the corresponding area may be failed.

The OsMsg log type message 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, the message queue is output externally. The messages of interest may be filtered out based on the source process, target process, command type. On one hand, the method can detect the process with heavy burden, and can allocate more resources to the process to ensure the normal operation of the process. Some critical commands can be filtered out to get a better understanding of the operation of the system.

The Warn log type is mainly used to Warn developers that an error may occur or an illegal operation is performed.

The ERROR log type message mainly informs a developer that an ERROR is encountered in the program running process, but the ERROR is processed in the program, the function may fail, and the system running is not affected.

The FATA log type message is used to inform the developer that the system has suffered a serious error, resulting in serious consequences such as program crash, software restart, etc.

Example 5:

in the process of debugging the MCU, a developer issues instructions such as log printing, process interaction, content reading and the like to the functional module in the MCU through the debugging instruction module in the upper computer, the data are stored in the memory, preferably stored in the cache, and are not immediately cleared to wait for the outward output of the system when the system is idle, so that the time competition with other high-priority tasks is avoided, and the MCU resource is fully utilized.

Claims

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 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 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 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 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 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 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 online upgrading module is configured to upgrade the MCU and upgrade the MCU according to an upgrading instruction received from 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 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 S906, acquiring the next parameter;

step S908, acquiring a next parameter;

step S910, saving the character;

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;

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;

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;

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;