Since most of my designs fall into the one-off category, I am sincerely interested in knowing more on proving the design in such cases.
One off really does not have much to do with it. I would state that "mission critical" or not is the determining factor for the time you can afford to spend on design thouroughfullness.

You can not really "prove" a design, I have seen design errors that showed up less then once a year. (coincidence errors)

An example of a thing that can be done:
set a breakpoint in your ICE at the deepest subroutine you have (some deciphering of the M51 file can tell you where) and read the SP. Then check the assembly for all your interrupts and add the max at every priority level to the SP - are you over?.

Another very important issue thet I often find missing is that all functions incapable of handling the min or max value (0-255 for a char NOT "what the program can generate") of a parameter MUST be able to survive (and mark) if an invalid value is presented - or, at least, gracefully error out.

Oh, and DO use a lint program, it is amzing what it will catch.

Anyhow re "design" vs "test".
You can state "I ran a 5V 12 MHz uC at 3.3 volts and 16MHz and it worked" is that a valid design?

The main types of errors that I can think of just now are
1) Ignoring the datasheet e.g. a memory chosen on the "typ" speed
2) Clerical programming errors e.g. '=' instead of '==' in an if
3) Functional programming errors e.g. stack overflow when subroutine max depth coincided with interrupts at all priorities.

Since we all (I assume) are human, not much can be done about 2), but that will be found in the first test and be a solid bug so no "proof" will be involved.

re 1) that is a matter of actually checking all timings.
re 3) here we get into a mix of carefulness, forethought and experience and - rellly - I have no other idea than Nikes "just do it"


Erik