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.
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
Why do you think this is related to the optimization level?
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.
It is also possible that your code enabled some low power mode which disabled the debugger; and that code is optimized out at higher settings.
I meant to say that your code might contain manual pragmas to exclude some low power code in case of certain optimization settings.
Hi Tamir
I think that it is related to optimization level because that at lower optimizations levels, it is working properly, at least this is the fact.
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.