Just to amplify on Janos and Kevin's messages a bit.... when RAM is
corrupted or changing optimization level changes the behavior of a program
the culprit is always one of the following:
- program depends on unspecified behavior e.g.
- order of application of side effects between sequence points
- order of evaluation of function arguments
- program executes an operation with undefined behavior, most often
but not limited to use of uninitialized data or pointer/array
problems
- something platform dependent e.g.
- inline asm error
- stack overflow
- flaky node
- memory mapping problem
- peripheral doing something funny
- compiler bug
In most cases a compiler bug is not the problem, but of course that does
happen too. If you do end up with a demonstrable compiler bug, please
post a concise failure-inducing program to the avr-gcc mailing list, they
take that kind of thing seriously over there.
When writing embedded C it's never a bad idea to have a copy of this
document sitting around:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
More readable documents exist but this one contains the real answers.
John
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
