Making Embedded Systems, 2nd Edition

Chapter 9. Getting into Trouble

I’ve already talked about the importance of testing as you go and unit tests. However, sometimes there are bugs. And if you knew what was wrong, you’d have fixed it by now. Unless you are reading this book while sitting on a beach (as is recommended), you are probably looking for concrete advice about your current issue. If I were sitting next to you, my mental checklist would look like this:

• Is it powered? Are you sure?

• Are you sure that the device is running the code you think it is?

• Can you test only that part of the system?

• Did you check the errata for the chip? Did you check the part number for the chip?

• If it’s intermittent, is it a timing error? Stack overflow?

• Is it related to uninitialized variables? Does making variables global make it better or worse?

• Can you turn optimizations off and see if it still happens?

• Have you looked at the map file? (More about that in Chapter 11.)

• In case of emergency (and random nonsensical error): could it be a ground loop problem?

You’d be surprised how often a problem is found in the first few steps. These questions come from the experience of being wrong, of failing and trying again, of finding the problem only to wish I’d looked there first.

Make your own checklist. Learn your own common issues. While I’ll go through many items on my list in more detail, let your list grow with your experience.

For the most part, I don’t want to talk about the errors that can be found through compiler ...