Hardware and Software debugging nine method: Fourth rule divide and conquer

1. Narrow the search by successive approximation
By using dichotomy to narrow down the problem, this method is the only rule that needs to be applied when looking for a problem, and all other rules help you follow this rule. First search in front 1/2, if wrong, then search the top 1/4, if correct, then the search scope is set between 1/4-1/2, and then subdivided again, several times will find the problem.
Actual case: There are times the program is slow to run, especially after the buzzer rang once, a few seconds to the corresponding key. Therefore, using this method, it is soon determined that slow is caused by waiting for the buzzer time is too long, from the program logic, waiting for the buzzer End Function and no error, but where the loop is waiting for the buzzer end flag variable, is processed in the interrupt, the flag is not defined as volatile type, Therefore, after being optimized by the compiler, only one time is obtained when the loop is judged, so only the loop delay time-out is terminated. The problem is resolved after the volatile type is changed.
2. Use easy-to-view test mode
When memory read-write test, communication data occasional failure test, sending the AA FF or 1 to 100 continuous data is more likely to find errors than using random data. When testing the color of color display screen distortion, the use of red, green, blue and yellow color bar than pictures to easily find problems.

Actual case: There is a time to use the TFT display picture, black and white display normal, color color distortion, and burr serious, thinking that the display has a quality problem, the use of color bar, found that the display and color and set inconsistencies, carefully contrast to find the driver issued 16-bit data, according to bytes sent, the data is reversed, So the adjustment shows normal.

3. Start searching from one end of the problem
Do not start at the right end of the confirmation, the correct is too many, so you need to start from the wrong side, and then upstream to find.
4. Fix known bugs
Sometimes it's hard to believe that a system has a lot of bugs, which makes the separation principle of divide and conquer difficult, so if you do identify one of them, you should fix it immediately and then look for other problems. Only fixed a known error to focus on finding other problems, sometimes fixing one problem, and the other disappearing, which is a bug in two questions.
5, first eliminate noise interference
In hardware, noise may also be difficult to find a variety of intermittent problems, so before looking for problems, you should first pay attention to the short-term pulse interference, clock echo, analog signal noise, timing fluctuations and other unstable factors;
In software, unreasonable multithreading, accidental punch-in routines, uninitialized local variables can cause a lot of random behavior in the system, causing a lot of trouble for the job.
In addition, technical staff can easily become a perfectionist, in order to achieve high quality, all the bad design is repaired again, may be because the previous program written by the bad looking program code to delete the rewrite, but if it does not cause real problems, it is best to keep them, not too extreme, Your focus is on finding bugs and eliminating them, a fix that delays real research time.

Hardware and Software debugging nine method: Fourth rule divide and conquer