We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
When in debug mode the compiler probably turns off some of the more advanced optimizations to make the debug view more sensible. If you code is not compliant to the C standard it may work at low optimization levels, but will then break when the optimizer makes assumptions about the code which should be true but are not. Either that or it is a compiler bug =PCan you post information about what actually goes wrong, and what the disassembly looks like for the relevant pieces of code from both version you built?Iso
Presumably changing the "RAM settings" involves writing specific values to specific addresses;compiling with "-O2 -g+" will have the effect of causing accesses to behave as though volatile, whilst this behaviour will be optimised out with "-O2 -Otime"; for example:void foo(void){ unsigned char *f = (unsigned char *)0x100; *f = 2; *f = 4; *f = 6;}Generates three write accesses with debug, but only writes "6" without debug enabled.Declaring f as "volatile unsigned char*", will result in all three writes always being generated.If you are talking to peripherals, are you sure you're using the volatile specifier correctly?hths.
void foo(void){ unsigned char *f = (unsigned char *)0x100; *f = 2; *f = 4; *f = 6;}
yes. all SFR access is protected by volatile.Now I'm thinking of the runtime init problem. the phenomenon is also debug version works but release build fails.