Well before anyone could sensibly answer those questions, you'd need to define exactly what is different about your debugging version and your production version.
well, your post was kind of "debug w/o optimization. test optimized"

This is the basis for the following replies.
Also, 'static' bugs can be debugged by almost any means, the problem is the 'dynamic' bugs.

Erik Malund said:
What if some of your testing is inserting 'wild' values using the ICE?
I don't know, what if? Configure and use the ICE properly and it won't happen. Perhaps an example so I can understand what you're talking about?
If you have a very complicated calculation, it is a good test to test it with various inputs. If that is difficult/impossible by external means, you can patch them in in the ICE and see the result. This, particularily is my way of testing if the value from e.g. a sensor is "impossible" which should give an error code, not lock the system.

Erik Malund said:
What if you get a report of this pesky "about once a day ..." and your debuggin version run flawlessly.
Then clearly, you need to perform some detailed tests with your production version and consider ways of getting useful information out of the tests without using an ICE.
Tell me ANY way to "getting useful information" other than an ICE that will in no way change the timing/location in memory of routines/variable use, of the system.


Erik Malund said:
What does it help that "There is a difference between debugging and testing" if you can not debug an error found in testing?
Well it wouldn't help at all which is why your code and procedures should be structured so you CAN debug an error found in testing.
they are "structured so you CAN debug", the so called 'optimizer' is turned OFF.

I'm not really sure what your argument is Erik. If you can't fit unoptimized code into the available space or if it is not fast enough, then you have to optimize it.
True, but NOT BY USING A STUPID "OPTIMIZER" just code it better i.e. write optimized, do not rely on a 'mechanical' thingy..

You have no choice other than going for a bigger/faster chip, which is a nice defeatist way of increasing unit cost.
sure you do, see above.

If you do optimze, then an ICE isn't likely to work well, so you have to look to other methods for debugging and testing. That's just a given.
give me JUST ONE that in no way whatsoever use any extra resources and do noy affect timing or anything else.

If the kind of problems you're talking about cause so much hassle, then I'm sorry to say it sounds like you're not approaching testing properly.
They do not (see above) and I do not, in any way, "approach testing" I know that the only person you can not test is yourself. The issue is NOT "hassele with testing" the issue is "fixing what the testers report to you"

Out of curiosity Erik, what language do you develop most your firmware in?
round numbers 85% C 15% assembler

Erik