Since graduating with a master’s degree, I have been working in the automotive embedded industry for three years. Compared to school projects, company projects have stricter requirements for code writing standards and test cases. In the automotive industry, most of the engineers’ code is generated by EB Tresos, Davinci, and Matlab, with only a few complex driver codes designed by engineers themselves. However, this does not mean that engineers only need to follow design requirements, click around in graphical configuration tools, generate code, and do a little testing. If an engineer only has the ability to configure and generate tests, they can only remain at the junior engineer level and find it difficult to independently undertake the development of a module, making it hard to achieve significant salary breakthroughs.

I believe that the first ability to possess as a mid-level engineer is debugging capability. In the automotive industry, a project’s code can have hundreds of thousands, or even millions, of lines. Engineers cannot possibly know every module in detail, so they must have debugging skills. When issues arise, they can use debugging tools to locate which module the problem occurred in and then find the corresponding module owner to modify the module’s configuration to meet the actual project needs.

Next, we will take the debugging tool winIDEA as an example to introduce some common debugging techniques to help engineers better solve practical project problems.

In C language, code is divided into global variables and local variables. Global variables are stored in the microcontroller’s RAM, while local variables are stored in the stack. The debugger can view and modify global variables at any time. We can check the configuration of the module and the variable assignment situation through the values of all variables. This knowledge is something that entry-level embedded engineers learn. However, in actual projects, this function is the most fundamental and critical.

To give a few examples, during debugging, we may need to check the values of some local variables. Some values can be viewed in the Locals window, but this window cannot show all local variable values. To view local variable values, we can create a new value of the same type as the local variable, and continuously assign the local variable to the global variable in the code. We can then check the global variable to indirectly view the values of critical local variables.

In actual projects, we may need to tune some parameters. We can keep modifying the code, compiling, and then burning the produced ELF file to the microcontroller. If we use this method, it not only reduces work efficiency but also risks damaging the microcontroller repeatedly due to constant burning of code, which is particularly troublesome and makes work extremely frustrating. At this time, we can double-click the position of the variable value to modify the value of the global variable. For example, we need to continuously modify the output duty cycle of different PWMs to find the most needed duty cycle in the project. We can first modify the value of DutyCycle and then set Test_Flag to 1 or 2 to execute the function that sets the duty cycle once. Using this method can greatly improve work execution efficiency.

During project development, situations often arise where we enter Det, which may be due to incorrect configurations or assignments. Due to various mistakes, it is inevitable that functions enter Det, causing them to enter an infinite loop. At this point, the CallStack function is very useful. We can pause the function and then open the CallStack window to check which function entered Det, leading to the infinite loop. We can solve problems step by step. The corresponding window on the right can enter the corresponding function, making debugging very convenient.

When viewing variables, we usually use the watch window, but when checking large amounts of data, such as SPI buffer data, using the watch window can cause serious interference with program operation, manifested as slow data refresh. However, using Memory is excellent, as it refreshes very smoothly. Therefore, when checking large data, using the memory window is advantageous. In projects, due to various reasons, such as configuration issues with debugging tools, the downloaded program may be consistent, but the functions of the microcontroller are inconsistent. At this point, we can use the memory window to copy all Flash data and then use tools to compare to see if the code burned into the microcontroller is consistent.

Due to time constraints, I can only share these three development debugging tips for now. In the future, when I encounter new debugging techniques and common errors in my work, I will compile them and share them with readers to facilitate everyone’s development work.