RL debbuger crash when using optimization Level 2 & 3

Hi Per
the debugger crash befor i can put any breakpoint or prees run. It seems that even the
programm did not loaded to the flash as usual (as if i work with lower optimization levels)
befor it stopped on the main.
When i say "Crash" i mean that the debbuger stops to responde during flash loading.

Yehuda

Hi Per
the debugger crash befor i can put any breakpoint or prees run. It seems that even the
programm did not loaded to the flash as usual (as if i work with lower optimization levels)
befor it stopped on the main.
When i say "Crash" i mean that the debbuger stops to responde during flash loading.

Yehuda

the debugger crash befor i can put any breakpoint or prees run.

So if it hasn't actually executed the code in question how do you think it could be the optimisation carried out when producing the code which is causing you the problem?

Maybe the download fails because the optimized version is larger, and is trying to download into nonexistant memory in the target.

There are often many different things that can go wrong. The best way to fail big time is to "know" what the error is directly, instead of trying to narrow down the error source.

Steve

While trying to load the code to the flash, the debugger crash, not during program execution. This happen olny if i use optimization level 2 or 3.
When I use optimization level 0 or 1 then every thing is work properly.

Thanks

Yehuda

Per

In general, if the code size is large to fit the device, i expect the compiler to notice it, but in this case the optimized version code size is much lower the device flash size.

Yehuda

The compiler have no reason to notice if code is too large. The compiler do not care.

The linker would care, except that the linker doesn't know how much memory the device has. The linker just link based on the information entered in the project settings. Tellit a 8kB chip has 16kB flash, and it will link happily twice as much code as the device can handle.

I'm not so fond of your "I expect". It is a wording that is very closely associated with "I assume". It tends to lead to problems, when the assumptions/expectations failed to match the reality. The majority of all bugs that hurt us everyday are caused by "I assume" or "I expect".

So, have you verified that the code gets downloaded 100% correct?

Have you verified that you can start the debugger from the start of the code? Don't do the run to "main" while trying to track down your problem.

this problem can be rectified with latest version of KEIL(4.22a and above)

Hello

I had the same problem with STM32 project.
Today I tested that newest version with uVison 4.23 in now debugging okay for optimization Level 2.
I am pretty sure it was because of Windows 7.