I summarized Parivallal Kannan's presentation at University of Texas and Jack Ganssle's articles on debugging to be used as a "disciplined clear process we should follow for debugging and troubleshooting" as said by Jack Ganssle. Your corrections are most welcomed.

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: ALE would be about 1.7 volts, same true for HC573's clock pin
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)
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
. Stay focused on a single problem at a time.
. Zealot's regard for the scientific method
. Iterative loop of focus, hypothesis, and experiment.
. Never figure anything is working right until proven by repeated experiment
. Problems that mysteriously go away tend to mysteriously come back unless you can prove that the change really fixed the problem
. There is no cosmic conspiracy against you !
. Most problems have simple causes and solutions
. Know the electrical properties of the components in your system: Absolute maximum ratings of currents and voltages; Maximum frequency of operation; ESD
. Analytical thinking: Think about possible “reasons” that can cause the problem seen; Check the input to the system – your design and its schematics (remember GIGO)
. Problem domain identification: Eliminate hardware issues. Then it’s the software’s turn