Answers and Solutions

Answer

These six techniques can go a long way in assisting the debugging process: 1. Simplify complex data: Substitute complex analog inputs with digital, synthetic, known, and repeatable data. If a counting pattern does the trick to start, use a counting pattern. For algorithms with coefficients (such as filters), replace the production coefficients with a simpler set of coefficients (such as all zeros except one full-scale coefficient). 2. Divide and conquer: Home in on the location of the problem as much as possible before trying to understand it. This can save significant time both in simulation and in the lab on hardware in the long run. To elaborate, let's say you've got a chained set of processing-intensive signal processing algorithms; let's call them A, B, C, D. When you stimulate A and observe D, you notice a problem. If you can narrow down that the input to C looks fine, but the output of C is bad, you've just homed in on the bug and the problem is likely within C. Now you can strip away dealing with the additional complexities of A, B, and D. This concept also works from a bottom-up perspective. Verify that the lower level functions work first, then work up through the layers of abstraction. For example, perhaps you've got an analog data logger algorithm. Start by verifying the low level A/D interface, physical memory interface, and physical communication bus interface. Then move up a layer to verify functions like data handlers and routers. Finally, verify the top level of the data logger. 3. Slow the process down: Slow down clocks and data rates. Perhaps some timing requirement isn't being met. Maybe one algorithm isn't synchronized with another. Perhaps one of the algorithms that needs to be data-driven was accidentally coded to be clock-driven. Or maybe one device is trying to push data too quickly to another. 4. Only change one variable at a time: When there are multiple inputs, it can be valuable to isolate them and only change one input at a time, observing the system response. The trick here is to identify all the inputs that induce a change in the output of the system. This is related to fault isolation and activation. 5. Create off-line models: These models should match as closely as possible the real-time algorithm, for bit-level comparison. This is most useful for non-intuitive transformations (such as matrix operations) where it's too challenging to understand what the output should look like relative to the input. If the real-time algorithm is fixed-point and the off-line algorithm is floating-point, there may be small discrepancies that accumulate and cause problems. 6. Start from a known-good state: Slowly tune the input until something breaks, and the bug is observable. This can be helpful for scenarios where overflow may be occurring. For example, if bit wrapping is suspected, slowly increase the amplitude at the input until the problem is observed. Similarly, if there are buffers in use, start by feeding a small amount of data into the algorithm and slowly increasing until the suspected condition occurs. Alternatively, maybe a control loop that breaks with large transients may appear fine with smaller deviations around a steady-state condition.

Answer

• Print debugging (or tracing) is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process. This is sometimes called printf debugging, due to the use of the printf function in C. This kind of debugging was turned on by the command TRON in the original versions of the novice-oriented BASIC programming language. TRON stood for, "Trace On." TRON caused the line numbers of each BASIC command line to print as the program ran.

• Remote debugging is the process of debugging a program running on a system different from the debugger. To start remote debugging, a debugger connects to a remote system over a network. The debugger can then control the execution of the program on the remote system and retrieve information about its state.

• Post-mortem debugging is debugging of the program after it has already crashed. Related techniques often include various tracing techniques (for example) and/or analysis of memory dump (or core dump) of the crashed process. The dump of the process could be obtained automatically by the system (for example, when process has terminated due to an unhandled exception), or by a programmer-inserted instruction, or manually by the interactive user.

• "Wolf fence" algorithm: Edward Gauss described this simple but very useful and now famous algorithm in a 1982 article for communications of the ACM as follows: "There's one wolf in Alaska; how do you find it? First build a fence down the middle of the state, wait for the wolf to howl, determine which side of the fence it is on. Repeat process on that side only, until you get to the point where you can see the wolf." This is implemented e.g. in the Git version control system as the command git bisect, which uses the above algorithm to determine which commit introduced a particular bug.

• Delta Debugging – a technique of automating test case simplification.

Saff Squeeze – a technique of isolating failure within the test using progressive inlining of parts of the failing test