If I Only Changed the Software, Why is the
Phone on Fire?
Embedded Debugging Methods Revealed: Technical Mysteries for Engineers
|Your new product crashes and burns...now what do you do?
to Hudson Technologies, the home-away-from-home for four engineers who
tackle real-life software and hardware technical problems while upper
management and customers hover nervously. Chapter after chapter, the
engineers are faced with a series of technical mysteries of products
behaving badly, with the pain of management pressure that "this must be
fixed today.""Phone on Fire" at Amazon.com
|Think for a moment - How many
software or debugging books have you bought and rarely opened? Learning
about debugging can be painful. But what if you could absorb the
lessons during individual "CSI for Embedded Systems"-like mysteries?
Oscar, Josie, Ravi, and Li Mei - technical folks who you've all met and
worked with (or for). They're a typical engineering team with good days
and bad; flashes of inspiration following head-banging frustration
after days of little sleep. They explore traditional and nontraditional
debugging methods and testing, while working with folks from hardware,
system test, and marketing. While they're less dysfunctional than some
teams can get, they feel the same pressure to nail the bugs amid
sometimes frustrating team dynamics, broken or missing tools, some
idiot customers and a stressful trade show demonstration.
mystery begins with a Real-World Bug from Jack Ganssle's collection of
embedded disasters that relate to each mystery. While some Real-World
Bugs are humorous (temperature in a hot Texas town is reported at 505
°F) others result in loss of life - a sobering tribute to the ease with
which we randomly change 1's and 0's in our code.
This book can
be enjoyed in a number of ways - it was written for folks of all
experience levels from students and new engineers to seasoned
technologists. Each mystery is a window into technical team dynamics
and provides a "Day In The Life" for folks curious about the field.
Each mystery stands alone, although the Hudson team is the thread that
weaves the stories together.
While you get caught up in the
mysteries, let the team's tricks get lodged in your brain to come
floating back out when you find a similar bug or symptom in your own
It's all about your approach to problem solving.
Make your next step a logical one instead of a random one.
Chapter 1: The Case of the Irate Customer: Debugging Other People's Code, Fast
Chapter 2: The Newest Employee: Learning the Embedded Ropes through Code Inheritance
Chapter 3: It Compiles with No Errors; It Must Work! Integrating Changes in a Larger System
Chapter 4: The Case of Thermal Runaway: Rare Transient Bugs Are Still Bugs
5: The Case of the Creeping Slider Carriage and the Case of the
Hesitating Clock: Alternate Methods of Understanding System Performance
Chapter 6: If I Only Changed the Software, Why Is the Phone on Fire?
Chapter 7: The Case of the Rapid Heartbeat: Meeting the Spirit of the Requirement
Chapter 8: What Kind of Error Message Is "lume Fault"? When all of the Symptoms Seem Impossible
Chapter 9: When It's Not Hardware, It's Software. And Vice Versa. Blurring the Interface.
Appendix: Li Mei's List of Debugging Secrets