Black Book on MCU Program Debugging

1. The certainty of the program is greater than that of the hardware. Don't be afraid of program problems.
2. The most important thing for writing a program is not to learn a certain language, but to analyze the problem and propose a solution to the problem.
3. Programs with interrupts are more complicated. The programmer needs to know what I am doing and what others are doing at the same time. Only by thinking about the problem in a "concurrent" way can it be written well.
4. Program modularization is for writing rather than running. Modularization and function are two different concepts. Function is to unify the code that needs to be used multiple times in order to reduce the amount of program code and facilitate maintenance; modularization refers to the functional blocks that break down complex program functions into pieces. A module may consist of multiple functions, or it may be just one function, or it may just be a closely connected block of code.
Module---Open the refrigerator door
1. Raise your right hand and move it to 1cm to the right of the center of the refrigerator door handle
2. Bend your right fingers and build the refrigerator door
3. Pull back with a force of 2kg
4. Complete
5. Good modular design, the interface between modules is simple and clear. In general, a good program is a good program if it looks good and is easy to modify.
6. A good habit of writing programs is to write in modules, test while writing, and write the next module based on the tested module, which can reduce the possibility of program problems, quickly eliminate the modules related to the problem and locate the program statements.
7. Comments are not programs, but they can help the writer improve the possibility of writing while writing, and can also greatly improve the maintainability of the program. It is recommended that C language programs be annotated to functions, and some important operations should be annotated at least; assembly language programs, at least 70% of the statement lines should be annotated, and it is recommended to comment one line.
8. It is normal for a program to have bugs, and you must learn how to find bugs.
9. Faults are divided into soft and hard, and soft faults are the most difficult to find. Soft faults are mostly caused by design criticality and occur under certain starting conditions. When the conditions are destroyed, the fault may disappear without a trace.
The misleading nature of soft faults comes from the experience accumulated with hard faults. Because hard faults do not require starting conditions, people often use
Try---Judge--Try Again
10. Microcontroller software and hardware are inseparable. When finding problems, both types of troops should be used, and one side should not be identified.
11. The difference between debugging experts and novices is that experts know how to find the problem, while novices will be confused.
12. Pay attention to accumulation in daily life. Learning software and hardware is not just about knowing how to use them, but also about being familiar with your actual applications, including application conditions. Otherwise, you will turn a blind eye to the key phenomena that are extremely valuable for reasoning. You can use the "guess" method to find bugs, but after "guessing", you must infer all the phenomena to "verify". So we say "doubt---deny---doubt again---deny again, until you find the truth". The previous "try---judge---try again" is the basic method for finding bugs.
13. In front of bugs, the initialization states of novices and experts are the same, but experts consciously look for phenomena for analysis, while novices just stare at the phenomena in a daze.
14. There are two ways to obtain evidence---search and wait foolishly. Experts mainly search, while novices mainly wait foolishly.
15. The random-to-random method is an extreme confirmation method used when looking for low-probability soft faults. It requires the user to master the basic characteristics of the fault and understand the principle of "low-probability events rarely occur".
16. When a system consists of several parts, the part suspected of causing the fault can be replaced with other systems when looking for faults, and the BUG can be determined by observing whether the fault phenomenon migrates with the part.
17. Focus on the part that needs to be found, exclude the influence of other modules, and use the simplest method to judge. This is the value of the module isolation method.
18. When a time-related BUG occurs, its characteristics of being correct when tested separately and wrong when tested together often drive beginners crazy. When debugging a program with interrupts, you must have multiple ideas and suspect the time correlation of the program.
19. Because it only manifests itself during actual operation, time-related BUGs are more difficult to find. This is one of the reasons why we recommend debugging the program in an actual environment rather than a simulation environment. Complying with basic rules to write programs is the root cause of all BUGs to avoid time-related BUGs. Observing more phenomena and accumulating judgment basis is the magic weapon for finding time-related BUGs.

The above are some experiences summarized by Huqin, the webmaster of the MCU tutorial website http://www.51hei.com, in many years of program development. Although writing programs is tiring, as long as we continue to accumulate experience and keep learning, fun will naturally come with it. When we successfully develop a product, I think we will get more than just a product, but also pride and satisfaction. Being a programmer is a passionate job, and I hope we can all continue to write.