http://embeddedgurus.com/stack-overflow/2008/04/iec60730/ Thoughts on embedded systems by Nigel Jones Wed, 28 Jul 2010 00:59:13 +0000 http://wordpress.org/?v=2.9.1 hourly 1 http://embeddedgurus.com/stack-overflow/2008/04/iec60730/comment-page-1/#comment-29 The Walrus Fri, 05 Feb 2010 12:03:01 +0000 http://www.gfcdev.org/test-stack/2008/04/12/iec60730/#comment-29 I once had the misfortune to have to code a sub-system, many years ago, which was supposed to do things like a continuous background RAM test.I designed it, had it all run pre-emptively doing little tiny chunks, and it was all just lovely. Apart from the crash that happened inexplicably about every 3-4 hours of operation.After a vast amount of analysis, I found that there was an obscure and bizarre priority inversion which meant that when the progam was testing its own stack (which it was supposed to detect and skip over), it would in fact leave corrupted dropping on the stack.The nature of the beast was such that a reliable solution was impossible (it took days and days of analysis to figure out what was going on, and to work out that there was no solution).Eventually, I removed the test.LESSON:Product reliability through not being a smart-ass is preferable to trying to prove reliability through adding hugely complex and clever things which may have nasty unforeseen behaviors. I once had the misfortune to have to code a sub-system, many years ago, which was supposed to do things like a continuous background RAM test.I designed it, had it all run pre-emptively doing little tiny chunks, and it was all just lovely. Apart from the crash that happened inexplicably about every 3-4 hours of operation.After a vast amount of analysis, I found that there was an obscure and bizarre priority inversion which meant that when the progam was testing its own stack (which it was supposed to detect and skip over), it would in fact leave corrupted dropping on the stack.The nature of the beast was such that a reliable solution was impossible (it took days and days of analysis to figure out what was going on, and to work out that there was no solution).Eventually, I removed the test.LESSON:Product reliability through not being a smart-ass is preferable to trying to prove reliability through adding hugely complex and clever things which may have nasty unforeseen behaviors.

]]>