The 6 Stages of Debugging
Those are common replies to OP's around here...............
JIm
exactly!
In my work I often add
7. How could I have been so stupid?!
In my work I often add
7. How could I have been so stupid?!
+1
Jim
after a few months....
#8 Is that happening AGAIN???
#8 Is that happening AGAIN???

avrcandies wrote:Immediately followed by, "DRAT! What was it I did to fix this the last time?"#8 Is that happening AGAIN???![]()
I was thinking more along the lines of "I fixed this! What the heck did you guys change?!"
In my case that would be: I am sure I fixed it - is my memory really that bad?
Jim trying new iPad Touch
9. "Oh crap, look at all this other questionable code near there..."
10. Why the hell did I use a PIC!?
JIm
Isn't "blaming the innocents" a step too?
You also have to blame the guy who worked on it last and has left the company.
It wasn't me. Before my time...
3.1 - I must have found a compiler bug!
3.2 - Nope, obviously this is a silicon errata!
5.1 - F**K me blind, I should have waited to posted that compiler bug report!
If you are debugging software, the first stage is to blame it on the hardware guys. If that doesn't work call it a compiler bug. If it is hardware you are debugging, the first stage is to blame it on the software guys.
I have given myself several black eyes as I do both.....
Yeah, I do too these days.
Anytime I write a code for a new project (besides designing its board) I prepare myself in advance that I will need to fix many silly bugs (hardware and/or firmware) during the tests. The number of bugs likely varies from 50 (if I am lucky ) up to 500 (if I am not
).
My problem is that I can't sleep well till I finish properly every project I start.
A very good point: it is important to consider, as part of the design, how you will debug your project - something so often missing in problems posted here!
Last step of new board circuit design: Where's the best points to place test point loops (especially on boards that have analog parts).