User`s manual

Dynamic C User’s Manual digi.com 111
6.5.2.1 Reproduce the Problem
Keep an open mind. It might not be a bug in the software: you might have a bad cable connection, or
something along those lines. Check and eliminate the easy things first. If you are reasonably sure that your
hardware is in good working order, then it is time to debug the software.
Some bugs are consistent and are easy to reproduce, which means it will be easier to gather the informa-
tion needed to solve the problem. Other bugs are more elusive. They might seem random, happening only
on Wednesdays, or some other seemingly bizarre behavior. There are a number of reasons why a bug may
be intermittent. Here are some common one:
• Memory corruption
- uninitialized or incorrectly initialized pointers
- buffer overflow
- Stack overflow/underflow
• ISR modifying but not saving infrequently used register
• Interrupt latency
• Other borderline timing issues
• EMI
One of the difficulties of debugging is that the source of a bug and its effect may not appear closely related
in the code. For example, if an array goes out of bounds and corrupts memory, it may not be a problem
until much later when the corrupted memory is accessed.
6.5.2.2 Minimize the Failure Scenario
After you can reproduce the bug, create the shortest program possible that demonstrates the problem.
Whatever the size of the code you are debugging, one way to minimize the failure scenario is a method
called “binary search.” Basically, comment out half the code (more or less) and see which half of the pro-
gram the bug is in. Repeat until the problem is isolated.