Three practical tips for debugging automotive embedded software

Since graduating from my master's degree, I have been working in the automotive embedded industry for three years. Compared with school projects, company projects have stricter requirements on code writing standards and test cases. In the automotive industry, most of the code for engineers is generated by EB Tresos, Davinci and Matlab, and only a few complex driver codes need to be designed by engineers themselves. However, this does not mean that engineers only need to follow the design requirements, tick the graphical configuration tool, generate code, and test it a little. If you only have the ability to configure, generate and test, you can only stay at the junior engineer stage, and it is difficult to undertake the development of a module alone, and it is difficult to have a big breakthrough in salary.

I think the first thing an intermediate engineer needs is debugging ability. In the automotive industry, a project has hundreds of thousands or even millions of lines of code. It is impossible for an engineer to fully understand every module, so debugging ability is necessary. When a problem occurs, the debugging tool can be used to locate the module where the problem occurs, and then the corresponding module manager can be found to modify the module configuration to meet the needs of the actual project.

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

In C language, codes are divided into global variables and local variables. Global variables are stored in the RAM of the microcontroller, and local variables are stored in the stack. The debugger can view and modify global variables at any time. We can view the configuration of the module and the assignment of variables through the values ​​of all variables. These contents are known to engineers who are new to microcontrollers. However, in actual projects, this function is the most basic and the most critical.

To give a few examples, when debugging, we need to view the values ​​of some local variables. In some cases, we can view them in the Locals interface, but this interface cannot view the values ​​of all local variables. In order to view the values ​​of local variables, we can create a new value of the same type as the local variable, and continuously assign local variables to all variables in the code. Then we can indirectly view the values ​​of key local variables by viewing global variables.

In actual projects, we may need to adjust some parameters. We can constantly modify the code, compile, and then burn the produced elf file to the microcontroller. If this method is used, it will not only reduce work efficiency, but also may damage the microcontroller by constantly burning the code. The most important thing is trouble, which makes work very unhappy. At this time, you can double-click the variable value to modify the value of the global variable. Take the following figure as an example. We need to constantly modify the output duty cycle of different PWMs at work to find the duty cycle most needed in the project. You can first modify the value of DutyCycle, and then set Test_Flag to 1 or 2 to let the function that sets the duty cycle execute once. Using this method, the execution efficiency of the work can be greatly improved.

In the development of the project, it is often the case that the function enters Det. It may be that our configuration is wrong or the assignment is wrong. Because of various mistakes, the function inevitably enters Det and enters an infinite loop. At this time, the CallStack function is very useful. We can pause the function and then open the CallStack interface to see which function enters Det and causes the function to enter an infinite loop. We can solve the problem step by step. The corresponding window on the right of the double-section function can enter the corresponding function, which is very convenient for debugging.

When viewing variables, we usually use the watch window. However, when viewing large amounts of data, such as SPI cache data, using the watch window will seriously interfere with the operation of the program, which is manifested as slow data refresh. However, using Memory is very good and the refresh is very smooth, so when viewing large data, using the memory window is very advantageous. In the project, due to various reasons, such as the configuration of the debugging tool, the downloaded program is consistent but the function of the microcontroller is inconsistent. At this time, you can copy all the data in the Flash through the memory window, and then use the tool to compare to see whether the code burned into the microcontroller is consistent.

Due to time constraints, I will only share the above three development and debugging techniques. If you encounter new debugging techniques and common errors in your future work, you can summarize them and share them with readers to facilitate your development work.