What to check

  1. Power
    • Check power and gnd connectivity on all Ics and discretes
    • Check Vcc with a scope, not a meter
  2. Clock
    • Check clock connectivity
    • Is the oscillator running: X2 pin should be toggling
  3. Processor
    • Is the processor is out of RESET: Reset pin should be low
    • Activity on continuously active signals:
      • ALE
      • AD[] (LSBs are best)
      • A[] (LSBs are best)
      • RD
      • WR
  4. Memory
    • Address and data lines: Are bus lines shorted together? Probe all address and data lines
    • Chip-selects
  5. Peripherals
    • All ICs – Chip selects, WR and RD
  6. Transceivers' voltage levels OK?
    • MAX232s, transducers etc
  7. HOST settings
    • Port settings (COM, LPT), etc
  8. Chips in their sockets
    • It's common for a pin to bend under the chip and appear to go into the socket
  9. Not done yet ?
    • Timing analysis (data sheets, LA etc)
    • Analyze data transfers (LA)
  10. Control registers
    • Should be correctly initialized/programmed
  11. ISRs
    • Make sure you are protecting all your registers.
    • Make sure you restore protected values: The same number of values in the reverse orer.
    • Use RETI not RET: Otherwise your interrupt will only be executed once and mysteriously stops executing
    • Enable only one interrupt at a time, and even if it seems to work spend a few minutes checking its operation. This is a lot faster than searching for the cause of some weird problem later when a dozen interrupts are flying around.
    • Does the stack balance: the stack just after the ISR return must be identical to the stack just before it

Debugging algorithm

  1. Observe the behavior to find the bug (Determine the bug's symptoms) Often, one needs to reproduce it at all (if reported by a client from field) and make it "happen" often enough (e.g. more often than once a day) - often helps if the application is "overloaded" - as many inputs (including communication channels) is activated at a time and as quickly as possible.
  2. Gain as much information as possible about it
  3. Think about possible “reasons” that can cause the problem seen (Round up the usual suspects)
  4. Generate a hypothesis based on cause and effect
  5. Generate an experiment to test the hypothesis (what’s wrong and why)
  6. Fix the bug (Not a quick and dirty fix)
  7. Provide proof that the change really fixed the problem (Not merely because the symptom has disappeared)
  8. Look for way to find any similar problems.

Misc. Notes

Always design your system with debug in mind!

Keep the tracking of the changes you make in the program. First try to find the bug in these parts.

Further reading

debugging at wikipedia