Hardware and Software debugging nine method: The third rule don't want to see

Imagination, the cause of a lot of problems, the actual reason only to see to find! If guessing how a failure occurs, it often fixes problems that are not bugs, wasting time and destroying other places, so don't do that. In the medical field, there are stethoscope, blood test, X-ray, B-Super method. Also in software, the method of observation is to set breakpoints, add debug statements, monitor program values, and check memory and so on. Hardware methods such as oscilloscope, Logic Analyzer, oscilloscope and other tools to test the signal, timing and line impedance and other ways. When the wrong assumptions do not negate, the workload of finding bugs is as much as before, but it gives you less time, so you have to rely on the following principles.

1. Observation failure

When you find a bug, you see that it is actually a failure, and you have to look closely and find enough details to debug it. If you do not pay attention to the whole process, it may cause you to misinterpret a lot of problems, fix the wrong place, and worse, may be due to the timing changes, the real problem is hidden, resulting in the mistaken bug has been fixed.

2. View Details

Typically, every time you look at a system in order to discover a failure, you'll learn more about the failure, which will help you determine where to look next to get more detail, so you can see the design and find the cause of the problem based on the details. The observation of the details should persist until the cause of the problem can be locked out within several possibilities. In this process, experience will help, and experience will tell you when the cause of the problem has been locked down and make a good debugging staff. For example, occasional bugs, if you see the underlying failure details, when you think the bug has been repaired, it is easy to confirm the fix, without relying on statistics, you can see that the problem is not happening.

3. Inserting Piles tool

During the development process, the software can be used for single-step tracking and inserting breakpoints to debug; After release, it is only possible to enter meaningful variables in the monitor so that runtime observation, in any state, should open a debug window, and let the code output state information, in the PC, the server, often use the running log. In the embedded system, the serial and PC communication is usually used to monitor the operation status by the host computer. The best way to do this is to consider debugging from the beginning of the design, and insert the piles as part of the product requirements. This helps in later commissioning, when thinking about where to insert piles, but also helps to better design the system and avoid bugs. No matter how thoughtful the design is, there are always unforeseen circumstances when you start debugging. So, don't worry, just plug the system in when necessary, and be aware that after inserting the pile tool, to make the failure happen again, and to ensure that there is no impact on the problem, after finding the problem and resolving it, remove the piles so that the end product is not affected.

4. Add external tool for inserting piles

When debugging hardware, you can use Multimeter, oscilloscope, logic Analyzer, Spectrum meter and other instruments to observe the hardware. Note that all instruments must have sufficient speed and accuracy to be able to measure errors, such as the problem of 230M signal saturation distortion cannot be observed if the oscilloscope with a bandwidth of 200M is used.

5. Don't be afraid to study deeply

If the code has a bug, in order to fix it, you need to rebuild the software, first build a debug version, add debug statements to see the parameters that need to be viewed, fix it, mark all the debug statements with #ifdef, and re-deliver the product code.

6. Note the Heisenberg effect

Heisenberg effect, in the quantum field is the uncertainty principle, so any pile can affect the original system, such as the scope of the probe to increase the capacitance of the circuit, different software versions, the software may run time and scale will be different, open the chassis lid, will change the internal components of the temperature and so on. Therefore, the system must fail again after the pile is inserted to ensure that it is not trapped by the Heisenberg effect.

7, guess just to determine the focus of the search

On the basis of understanding the system, your guess may be close to the truth, which is good, so you can determine the focus of the search, but before attempting to repair, you still need to see the failure again, in order to confirm that the guess is correct. But don't overdo it by guessing that it tends to lead you astray. The exception is if some issues are more prone to problems than others, or if they are easy to fix, check these issues first. For example, the bulb is not bright, should first replace the light bulb, if good, explain the problem solved, otherwise check the switch, and then check whether the line is aging.

Hardware and Software debugging nine method: The third rule don't want to see