Hi When I use optimization level 2 or 3, the debbuger crash and the Uvision halt. I'm using uVision 4.21 and ULINK Pro with STM32F103ZC (the same problem also with the ST-LINK V2). Thanks
Are you sure the debugger crashes?
Might it not be that you put a breakpoint and then press Run. And don't get the program to stop at the breakpoint because higher optimization levels have rearranged the actual code generation so you no longer have any good matching between source lines and blocks of one or more assembler instructions?
If you do press run and have the breakpoint at the wrong place, then the debugger will run and run and run, without "returning" to the editor.
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
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.
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.