[bearjoe]

My code works on debug build ( -Otime -g+ )
But release build can't work ( -Otime -O2 -zo )
the code is the same. the compiler is ADS1.2

Do you guys have any idea or previous experience on such an issue?

Thanks.

[isogen74]

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 =P

Can 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

[bearjoe]

what I can find is part of the init code deactivated in release build

for example, static init code

0x00003724 EB000464 BL pwrp_gio(0x000048BC)

can't be traced into. while execution, the debugger just skip this line directly to next code and seems got no execution

Yet, for public function call

0x00003744 EBFFF8B7 BL HWM_gio_pwrp(0x00001A28)

is OK for both execution and trace into.


in debug build, both functions can be executed and traced into.


BTW, here is a remap operation in my code before pwrp. I copy the image into RAM and run there. Change all RAM memory settings to fit the image.

isogen74, on Jan 19 2010, 04:47 PM, said:

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 =P

Can 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

[sim]

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?

hth
s.

[bearjoe]

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.

sim, on Jan 19 2010, 10:31 PM, said:

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?

hth
s.

[bearjoe]

This issue got fixed.

the root cause is the MCU pwrp config.
but the odd is
debug can work yet release can't.
Seem that Keil ARM debugger can't emulate the MCU 100% behaviors .

bearjoe, on Jan 19 2010, 10:57 PM, said:

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.