Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 468

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 483

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 490

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 526

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/theme.php on line 618
Real Life Debugged » Embedded systems

Tag-Archive for ◊ Embedded systems ◊

Jack Ganssle is an embedded guru and also a really neat guy. He collects real life disasters - when products behave Not As Intended. Some are pretty sad when they involve loss of life, but others are funny - like this store sign that reports a temperature of 501 °F. Whew!

When I pitched the concept of individual product disaster mysteries like “Law and Order” or “CSI” for my book, he liked the idea. And I was even more psyched that he would dig through his collection to find Real Life Disasters with similar root causes to the bugs in each of my chapters.

So I thought of Jack when I ran across a post about errors at a site called “The Daily WTF.” (Man I like that name!)

Check out these pics of other interesting Bugs in Public at - There’s Gotta Be A Catch.

And the Walgreens bug? It’s still out there - a student of mine sent me a picture he took of it in mid 2008.

And what caused the bug?  The bias current to an unconnected processor input in the electronic billboard changed; the normal “zero” state drifted to a logic “one.”  Firmware didn’t ignore this unused bit, and accepted the unnecessary and incorrect new data, generating a temperature display that was insane. - From Jack

This is a shout out to Jason Andrews from Cadence who mentioned the value of embedded systems, debugging, visualization and verification as cornerstones in technology going forward. Everything seems to be tied to everything else, and we all need to get our heads out of the cubbyholes (aka cubicles) and take a look at better and more comprehensive ways to solve problems.

Jason also gave a nice plug to If I Only Changed the Software, Why is the Phone on Fire?, and for that I thank him. He mentioned that we share a common publisher, Elsevier/Newnes with his book Co-verification of Hardware and Software for ARM SoC Design. With hardware and software merging closer and closer together as time goes on, we need to be more cognizant of the challenges of verification. We can’t design, develop, debug, or test in a vacuum any longer. Check it out.

For students, Lisa Simone is a dream professor.

She uses the latest technology to teach her classes and her students work in teams on hands-on projects. She arrived for a recent class, for instance, carrying bags of ice, lighters and heat guns, which she used to help her students design devices for temperature detection.

In another of her classes, students use LEGO Mindstorm kits to build robots that perform simulated surgeries. The class meets in a biomedical engineering studio where students work together on interactive projects.

Simone is young, friendly and adventurous. Her idea of fun is to frolic underwater with a school of sharks. She’s an avid scuba diver who has traveled the world photographing marine life. Sneaking up on napping sharks and snapping their photographs gives her great joy. Photographs of marine life adorn her office wall.

She is also a writer. She’s just written a new book — a high-tech thriller in which software engineers act like detectives, forever on the hunt for bugs: software bugs that can cause computer-based products to crash and burn.

The book — If I Only Changed the Software, Why Is the Phone on Fire?– teaches students and readers how to contend with software bugs.

Software engineering is a subject Simone knows well.

Before coming to NJIT in 2006, she worked as an embedded-systems engineer for Lucent Technologies and Motorola. She led teams of engineers who worked on innovative cell-phone technology. Her teaching is informed by real-world experience and she treats her students as if they were actual engineers developing cutting-edge technology.

In the below interview, Simone discusses her teaching, her book, her research projects as well as main passion in life: scuba diving.

Why did you write a mystery novel about problem solving, embedded systems and debugging?

I didn’t want to write a boring textbook about debugging. Instead, I wanted to make the learning fun, so I decided to use mysteries to teach problem-solving skills. Since most people learn debugging through experience and since people like mysteries and stories, I created a fictional engineering company with engineers who have to combat a series of 10 technical mysteries - kind of like CSI or Law and Order for engineers. The company has a cast of new and seasoned engineers, and the book is filled with machines that crash and a phone that catches fire.

My goal is to tease the reader with a series of symptoms, clues, and realistic bugs and provide logical steps to help the reader learn what could be wrong with the software and hardware. The book includes many common types of software bugs, and introduces both traditional and nontraditional debugging methods and testing. Students need to understand that problem solving is a logical process that isn’t that difficult to learn.

I based the mysteries on my actual experiences, and I hope the book will help students and people working in the field gain experience debugging code. I’ve started to use the book in my graduate class, Intro to Embedded Systems, and the students say they like it.

Tell us about the engineers in the book, and why readers might like to read about engineers solving technical mysteries?

I wrote the book to be fun. I’ve tried to make it as realistic as possible, from the way problems are found and reported to the engineers, to the way managers tend to react, which is “this must be fixed today.” The Hudson Technologies engineers — Oscar, Josie, Ravi, and Li Mei — are a fairly typical engineering team: they have flashes of inspiration and at other times bang their sleepless heads on the bench. They feel pressure to nail the bugs amid sometimes frustrating team dynamics, missing tools, some difficult customers and a stressful trade show demonstration. I want readers to identify with the characters so they understand what it’s like to work in industry.

Why is it important for students to know about debugging software and embedded systems?

Most people don’t know what an embedded system is, even though they own dozens of them! An embedded product is anything with smarts - with a computer or microprocessor embedded inside - like a cell phone, a remote control, an iPod, or even in once humble products like toasters. Since more and more of these devices have software in them, they often have bugs which can be challenging to figure out. Software errors are estimated to cost the U.S. economy $60 billion a year. Software bugs in medical devices have killed patients. Student engineers who will design, build, or test smart products will face debugging challenges. Effective problem- solving skills will make a student a valuable asset to any company.

How do you expect readers to use this book?

The 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 provides a “Day in the Life” for folks curious about working in industry. Each mystery stands alone, although the Hudson team is the thread that weaves the stories together. In my preface to the book, I invite readers to write in the margins and work through the examples to solve the mysteries before the team at Hudson Technologies does. Or, just glide along with the team as they tackle one technical mystery after another.

I hope that readers get caught up in the mysteries and that the team’s tricks come floating back out when readers find a similar bug or symptom in their own technical travels. I also included an appendix with a nice summary of bugs and tricks in each mystery.

How long did it take you to write the book?

The book took about 18 months to write part-time, in two chunks. I started the project around 2002 but got busy with research, and a few years later picked it back up again when I joined NJIT. From the beginning, I had created a very detailed outline of each mystery. I am an extremely driven and organized individual, so when it came time to actually write the book I just filled in the blanks.

I loved writing the book! There were some stressful times, such as when I had to produce the three final chapters in about 6 weeks before classes started last fall, but also some wonderful times writing at my kitchen table with a cat on my lap, a few writing marathons in Florida, and a productive stretch at a sidewalk café in Chicago that had free wireless access, a supportive manager, and great beer.

What was your biggest challenge in writing this book?

The biggest challenge was to make the technical mysteries realistic and fun for readers of all experience levels. Real-life engineering problems and believable people. Thanks to my father I am a good technical writer, but this was my first big foray into fiction. I am an avid reader and I found that plot and dialog came pretty easily, but my biggest challenge was perspective or point-of-view. Normally a book is written from one person’s point of view - you’re in their head - you hear what they think and see what they see. But I wanted to get into the heads of all of my fictional engineers so my readers could identify with each. I ended up taking a chance and changing point of view multiple times in each mystery, so each of the team members is a main character at different times. Hopefully now my readers can identify with at least one of the characters to make the mysteries more realistic.

How do you like teaching biomedical engineering at NJIT?

I love it. I run the Capstone Design Program for seniors who are biomedical engineering majors. I’ve been able to redesign that program and make it much more rigorous, project driven and applicable to the real world. I’ve worked in industry for years, and I treat the seniors as if they are engineers in my big engineering design firm. I teach them how to design for the real world, including all the real-life experiences working with difficult customers, writing documentation, submitting invention disclosures and performance reviews. Stuff they don’t expect to learn in college.

You teach several engineering classes and do research at the same time: isn’t this challenging?

Research is challenging but also rewarding, especially in medicine and rehabilitation, so I will always try to balance research and teaching. The people who participate in my studies have suffered brain injuries, but they are excited to help my team develop new methods and therapies, even if those discoveries don’t help them directly. Their enthusiasm is inspirational and one of my subjects emphatically told me he would do anything to help my research efforts: “You can paint me pink and stick me to the ceiling,” he said, “if it helps someone else who has a stroke.”

Tell us about your research projects at NJIT?

I have some neat research projects, and I have five master’s students who are assisting me and I love working with them. In my lab, we design low-cost systems to treat patients with movement disorders that happen after a brain injury, such as a stroke or traumatic brain injury. With funding from the National Institutes of Health, I’m developing a wearable sensor device for the hand called the Shadow Monitor; it helps understand how people use their hands after an injury. Why is this useful? Doctors and researchers know patients with the above injuries often struggle with daily tasks like dressing and eating, but we don’t have good tools to measure and find out which therapies help them the most. With our device, we can observe hand use over 24 hours, and evaluate how well rehabilitation is helping patients regain their hand functions.

We’ve also combined Second Life, the online 3D interactive world, with the Wii Remote game controller, to create a low-cost virtual reality game that patients can use to regain control of their arms.

You are a scuba diving instructor who travels the world photographing underwater shipwrecks and marine life, including some potentially menacing ones, like sharks?

I love scuba diving because when you are underwater there is not enough room in your brain for the stress of daily life. Your senses are overwhelmed with the sea and its bountiful life. We’re the outsiders underwater, but brave sea creatures will check us out if we respect them. Once while diving, I happened upon a baby octopus. I stuck out my finger. He wrapped a tentacle around it and tugged. I suspect he was assessing how big of a threat I presented. After a few tugs, he must have suddenly realized I was larger than he thought and instantly zipped away. I have danced under water with sea lions, twirling around as they tugged on my camera and fins. After nearly 30 exhausting minutes of tumbling play - we humans are much less graceful underwater than they are — I was rewarded with a sea lion kiss. Brave and curious sea turtles have stared me down for a moment, and swam off. Swimming through huge schools of barracuda, salemas and jacks — thousands of fish swimming in a tight ball — makes you feel insignificant.

One of my favorite dive sites is Truk Lagoon near Guam, the site of many WWII shipwrecks. The wrecks are full of supplies, ammo, tanks, torpedoes and small airplanes. (Our dive master told us, “be careful not to bang your dive gear on the torpedoes - they are still live.”) On the Fujikawa Maru, I swam down through the engine room, out of the hull and right through a torpedo hole - the one that had sunk the ship. The shipwrecks are wonderful to explore, but you can’t help feeling sad for the soldiers who died.

And yes, I like sharks. Sharks are pretty cool - I sneak up on white tips and nurse sharks to snap pictures as they sleep - the best shots are right after they wake up! Shark feedings in Fiji and Tahiti can get frenzied, and we’ve collected sharks teeth afterwards. While diving in the Galapagos Islands, I have swum beside massive 40-foot whale sharks and their 15-foot long babies. One of my shark adventures I still can’t tell my mother about. It started with a few silky sharks (they’re like the trouble-making teenagers hanging out on the corner), but evolved into a circle of 35 sharks - with me and another diver in the middle. That’s the only time I’ve ever wondered if they can smell fear through a wetsuit…

(By Robert Flordia, University Web Services)
Read the rest of the interview here.

Several readers commented on the test case article published at here. The reader responses are also presented below.

I really liked the article and the way it was presented. Well done Lisa.

I passed the code through my normal Lint system and it caught the problem and pointed out a couple of others too. This is what it reported:

  1. The Comparison for OvenPW less than 0 at the end is unneccessary, since OvenPW is an unsigned number, it can’t be less than 0. This is a clue to the error.
  2. The loss of precision in the subtraction as the two unsigned numbers (reference_temp_A2D_counts and actual_temp_A2D_counts) are subtracted and the result placed in the signed number, delta_temperature. (another clue)
  3. The loss of precision as the ovenPW is calculated from the Delta Temperature. This is where the problem manifested itself.

An unintended lesson of this, pay attention to what Lint is telling you.

Bob Bailey
Sr. Software Engineer

Thank you Lisa. Your article was a fascinating reading experience. I can only conclude:

“Two sensories are always better than one.”

Art Devine

Dr. Simone’s paper is very thought-provoking, and is refreshingly easy to read. Her approach to solving a problem extends far beyond ovens, of course, and should give us all pause to reflect how we could better do these things. Hats off to her!!!

Thomas Mann

This article is definitely worthwhile to promote as a vivid C programming case or as a trouble-shooting case. It is enlightening for reader to think thing in reverse engineering point of view.

Larry Luo

Out of sheer curiosity, I tried the attached source code with some C compilation tools I haved. Some compilers (e.g. TI Code Composer C/C++ compiler for TMS320C54x) issued a warning like “pointless comparison of unsigned integer with zero” on the instruction “if (ovenPW < 0) …”, giving the programmer a chance to notice the bug described in this article.

Some other ones (e.g. MS Visual C++ 6.0) didn’t report any problems even with the strongest warning level set.

Kazimierz Koziarz