The Nine indispensable Rules for HW/SW debugging hardware and software commissioning 9 rules

I read this book in the weekend, and decided to put the book on my nightstand. It's a short and funny book, the Clear insight and good stories, strongly recommend entry even senior engineers to read it.

Introduction

This book tells your how to find out what's wrong with stuff, quick. It indeed short and fun. I finished reading in the weekend and made some notes. And it convinced me the Nine rules powerful to hardware/software design and design, as some rules I already has, which he lped me find the bugs efficiently. Some Engineer probably say it's an old book, which isn't applicable today, as we have the big progress on HW/SW debug Tools A nd instrument. Although tools can help reduce or find bugs more or less, it'll bring some latent bugs, which is harder to find. Besides, over-dependency on tools blocks a new engineer to become a clear thinker, obviously, this side effect is harmful In one's engineer career life.

How can the work?

A. When it took us a long time to find a bug, it is because we had neglected some essential, fundamental rule; Once we applied the rule, we quickly found the problem.

B. People who excelled at quick debugging inherently understood and applied these rules. Those who struggled to understand or use these struggled to find bugs.

Obvious vs easy

These things is obvious (fundamentals usually is), but what they apply to a particular problem isn ' t always so obvious.

Don ' t confuse obvious with Easy-these rules aren ' t always easy to follow, and thus they ' re often neglected in the heat O F battle.

Debugging vs Troubleshooting

Debugging usually means figuring out what a design doesn ' t work as planned. Troubleshooting usually means figuring out what's broken in a particular copy of a product when the product's design is kn own to be good.

The Nine indispensable Rules

1. Understand the system

No1 rule is the most important, and it deserves much time if you really want to fix bugs ASAP.

1.1. Read the Manual

HW engineer have to read chip datasheet, and SW engineer have to read api/frame document.

1.2. Read everything in depth

Read everything, cover to cover.

1.3. Know The Fundamentals

1.4. Know the road Map

1.5. Understand your Tools

1.6. Look up the details

2. Make it fail recurrence failure

It seems easy and if you don't do it, debugging are hard.

2.1. Do It again

2.2. Start at the beginning

2.3. Stimulate the failure

2.4 But don ' t simulate the failure

2.5. Find the uncontrolled condition that makes it intermittent

2.6. Record everything and find the signature of intermittent bugs

2.7. Don ' t trust statistics too much

2.8. Know that ' that ' can happen

2.9. Never throw away a debugging tool

3. Quit thinking and look! Instead of thinking about it.

3.1. See the failure

3.2. See the details

3.3. Build instrumentation in

Use source code debuggers, debug logs, status messages, flashing lights, and rotten egg odors.

3.4. ADD instrumentation on

Use analyzers, scopes, meters, metal detectors, electrocardinography machines, and soap bubbles ...

3.5. Don ' t be afraid to dive in

3.6. Watch out for Heisenberg

Don ' t let your instruments overwhelm your system.

3.7. Guess only to focus the search

4. Divide and conquer Divide and conquer, conquer

4.1. Narrow the search with successive approximation

4.2. Get the Range

4.3. Determine which side of the bug you is on

4.4. Use Easy-to-spot Test patterns

4.5. Start with the Bad

4.6. Fix The bugs you know about

4.7. Fix the noise first

5. Change one Thing at a time only changes a factor

5.1. Isolate the key factor

5.2. Grab the brass bar with both hands

5.3. Change one Test at a time

5.4. Compare it with a good one

5.5. Determine what do you changed since the last time it worked

6. Keep an Audit Trail debug log

6.1. Write down what do you do, in what Order, and what happened as a result

6.2. Understand that any detail could be the important one

6.3. Correlate Events

6.4. Write it down! No matter how horrible the moment, make a memorandum of it

7. Check the Plug for all set conditions

7.1. Question your assumptions

7.2. Start at the beginning

7.3. Test the tool

8. Get A Fresh view a different point of view

8.1. Ask for Fresh Insight

8.2. TAP Expertise

8.3. Listen to the voice of experience

8.4. Know that's help are all around

8.5. Don ' t be Proud

8.6. Report symptoms, not theories

8.7. Realize that's you don ' t has to be sure

9. If you didn ' t fix it, it ain ' t fixed and you don't fix bug,bug will not solve

9.1. Check that it ' s really fixed

9.2. Check that it's really your fix that fixed it

9.3. Know that it never just goes away by itself

9.4. Fix the cause

9.5. Fix the process

The Link to the book

The Nine indispensable Rules for HW/SW debugging hardware and software commissioning 9 rules