Design Con 2015
Breaking News
Comments
Newest First | Oldest First | Threaded View
HenryC
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
HenryC   4/11/2011 5:44:13 AM
NO RATINGS
It always have been a nightmare for me whenever "intermittent failure" happens. The worse one which takes me almost 48 hours to debug is the component being used was a counterfeit part! Now that is a very good challenge. Luckily we are able to identify most of them prior to use nowadays.

WKetel
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
WKetel   8/11/2010 4:54:56 PM
NO RATINGS
The best choice for finding and curing intermittant problems is to have a very good understanding of the system, and then to understand what part of the failure is a result, as opposed to being the driver. So unless one has a history of fixing a certain system, whith a good knowledge of what the problem usually is, it is good to work toward an understanding first.

t.alex
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
t.alex   8/1/2010 7:01:06 AM
NO RATINGS
Intermittent errors are sometimes nightmare! We always tried to have some methods to run the test hundreds of times just to catch the bug.

WKetel
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
WKetel   7/28/2010 2:45:35 PM
NO RATINGS
It is certainly true that intermittent failures are a large challeng. In this case, if they had been able to detect that the failure did in fact have a specific driving event, it would have saved a lot of investigation time. Of course, if the very first step had been a check to see what had changed recently, then the time to find the problem would also have been reduced a lot. I also have had experiences where purchasing, or some other cost reducing person, has made a change "that should not have any effect" on the function of a design. A capacitor that is completely adequate for power-rail bypassing is seldom acceptable as a timing circuit element.

lrrp
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
lrrp   7/16/2010 9:07:44 PM
NO RATINGS
Corollary #1 to Lesson #10. The person that introduced the cost reduction will receive a bonus & accolades. The engineer that originally designed the circuit & will have to "fix" it again will receive a low performance rating for letting a bad design be released. Corollary #2: Look for any changes that occurred prior to the failures starting. H/W, S/W or mechanical. e.g. I've seen a change in box layout move a noise source near a sensitive circuit which caused problems.

peteryoung
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
peteryoung   7/12/2010 7:57:53 PM
NO RATINGS
Lesson 1 is the red flag that gets me going. It is important to look and listen to those that are [possibly] operators for a particular system. This is the area that will yield the most satisfying amount of real engineering follow-up data. One of the things that I have discovered is that many lower level workers that are present to assist in the design,production, and/or implementation of a system are not as fully trained as you would like them. So the idea that "Lesson #1" is even on this list tells me that staff training must be intensified.

ChrisGammell
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
ChrisGammell   7/12/2010 7:32:04 PM
NO RATINGS
I agree, "intermittent failure" makes bad times for everyone...unless they have a helpful engineer on call of course!

old account Frank Eory
User Rank
Rookie
re: Why Debugging Projects Take Way Longer Than Planned
old account Frank Eory   7/12/2010 4:25:36 PM
NO RATINGS
I would like to add Lesson 10, which couldn've eliminated the need for several of the earlier Lessons. Lesson 10: When a product that was previously reliable starts failing after a cost reduction, look first at the components that were modified to reduce cost. Inevitably, when a product is re-engineered to reduce cost, the level of verification and analysis is less than what was done during the initial development. This often comes back to bite you and your customers.

Sanjib.A
User Rank
CEO
re: Why Debugging Projects Take Way Longer Than Planned
Sanjib.A   7/11/2010 7:10:41 AM
NO RATINGS
Thanks to Jit for sharing his nice experience. Sorry for the trouble he had gone through with the hotel room booking. I believe, most of the time, debugging is much harder than designing from the scratch, especially when the problem doesn't get reproduced easily and the design was done by somebody else. I too have faced situations similar where a memory chip was replaced with a cheaper part during cost-out activity, which was less immune to noise. The problem did not used to show-up consistently unless the temperature was brought to a couple of degrees Celsius. But I was luckier to have an oven and much more time than Jit.



Top Comments of the Week
Flash Poll
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
<b><a href=Betajet">

The Circle – The Future's Imperfect in the Present Tense
Betajet
5 comments
The Circle, a satirical, dystopian novel published in 2013 by San Francisco-based writer Dave Eggers, is about a large, very powerful technology company that combines aspects of Google, ...

Max Maxfield

Recommended Reads From the Engineer's Bookshelf
Max Maxfield
27 comments
I'm not sure if I read more than most folks or not, but I do I know that I spend quite a lot of time reading. I hate to be idle, so I always have a book or two somewhere about my person -- ...

Martin Rowe

Make This Engineering Museum a Reality
Martin Rowe
Post a comment
Vincent Valentine is a man on a mission. He wants to make the first house to ever have a telephone into a telephone museum. Without help, it may not happen.

Rich Quinnell

Making the Grade in Industrial Design
Rich Quinnell
16 comments
As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

Special Video Section
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
10:29
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...
TE Connectivity's clear-plastic, full-size model car shows ...
Why culture makes Linear Tech a winner.
Recently formed Architects of Modern Power consortium ...
Specially modified Corvette C7 Stingray responds to ex Indy ...
Avago’s ACPL-K30T is the first solid-state driver qualified ...
NXP launches its line of multi-gate, multifunction, ...
Doug Bailey, VP of marketing at Power Integrations, gives a ...
See how to ease software bring-up with DesignWare IP ...
DesignWare IP Prototyping Kits enable fast software ...
This video explores the LT3086, a new member of our LDO+ ...
In today’s modern electronic systems, the need for power ...