Hi,

francesc.pau, which version of the RIDE7 and ARM kits are you using?
Can you send us your project? (there are so many ways to 'use the lib'...)

Henrik, we know there are still problems with watches in the new version, especially when optimizing. But all the projects I have tested were handled better by the new version than the previous. Can you please send us your project?

Best Regards,

Vincent

I am sorry but I can not disclose my projects. Nor spend more time hunting the many bugs in the IDE. I have learned to workaround most, so for now i just revert to the old one.
I have not setup specific watches. But are merely using the local watches window
Optimization is set to NO_OPTIMIZATION for the file in question and as i mention it works with the older version.

I have installed the version 7.18.0903 of RIDE7 and I can see the local variables. IT WORKS.

What may be the reason that makes that the emulation direct keys (F7 for step into, F8 for step over, ..) doesn't work?

Hi,

I answered in the other thread:
http://raisonance-forum.xsalto.com/viewtopic.php?id=2770

Best Regards,

Vincent

Just reinstalled version 7.18.0903 and local variables do not work - Atleast not aswell as when using the other version.. Adding variables to Watch window seems to work, better than the earlier versions ..

Hi,

Thanks for the feedback.

Unfortunately, there is nothing we can do to improve things if we don't have example projects that allow us to reproduce the problem. Hopefully someone else will have the same problem and less sensible data...

Best Regards,

Vincent

Sorry I can't share my source code... But I work in a very competitive field and we have very strict policies.. But I find it a funny way look at software testing. If I told my customers from scratch that I needed their code to test my own software, I would be out of business in a heartbeat.
Currently I am using freeRTOS/OpenRTOS I can tell you that much ;-) and I am defining local variables using notation like this: u8 temp = 10; .. Maybe the debugger messes up because it expect char, int kind of notation when defining - Wild guessing here from my part? If I get a moment tomorrow I might try to fiddle around a bit with the problem, see if I can narrow it down to specific projects or functions...

Furthermore the debugger seems to be getting worse and worse, by each release at locating where the program counter are in the C-source code when you try to step through optimized code - Maybe it's because the compiler gets better at optimization, but that part really need some work, if you intend to keep it usable..

Just disabling optimization seems like a cheap workaround. I realise that these things are not easy to implement, but hey youre the IDE developers. The compiler you get for free! So get at it :P

BR
Henrik

Hi,

Of course we do testour software, (and use it internally) and we don't rely on customers for testing. However, you can never test every possible situation, especially when you are developing user interfaces. So when a customer finds a problem that has passed through our tests, we need his help for reproducing it before we can solve it. But my feeling is that we do that much less than many other companies, even some very successful ones... ;)

About debugging optimized code, please note that it is often not possible at all to watch some variables, because they don't exist at all after the optimization phase. They might be completely optimized out, or only receive some intermediate values that never correspond to what you would expect by reading the C code. The same is true for the C statements that can be split in several parts, factorized or merged with other statements, or even purely removed.
What I mean is, it's not just a problem of "getting at it". I admit that we could probably make things better with more work, and we intend to do it in the future. But there are some things that are just not possible.

Best Regards,

Vincent

Sorry if I came across a bit harsh - Was meant as a bit of phun - I have spent years developing API's for other programmers to use. So I know how hard it can be to reproduce bugs that customers see.. I also know from experience how hard it can be to convince an company like keil that there is a bug in their compiler, hehe..
As I mentioned I realise that stepping through optimized C-code with a debugger is not an easy feat - And I realise that optimized variables are notably hard to get right - volatile can be a help when debugging those ;).. Most debuggers I know have trouble with optimized variables, but none the less - I know several C-debuggers which are more precise in their stepping.. RIDE stops at the right spot when setting a break point, but when stepping the currently highlighted C-Line is often very out of touch with the executed code.. Sometimes jumping back and going over the same code again..
Code that is removed is already handled in the way that you can't put a break by them.. So I would say that is not an issue..

Hi,

There is no problem; That was an interesting clarification to make for other customers anyways.
Just please be careful with 'phun', as many readers of this forum don't have such a good command of the English language as you do, and they might not be able to realize that there is a joke if you don't add smileys :) or state explicitly that it's humour. And that includes us; we hire English or American people for correcting our docs, but we cannot afford that for the forum... ;)

You will find more info on the way GCC optimizes, and why you see the PC going back when stepping, in this FAQ:
http://raisonance-forum.xsalto.com/viewtopic.php?id=2694

I'm afraid there is not much we can do on our side concerning this particular point.

Best Regards,

Vincent

@VincentC
1. With regards to the phun.. I did add a smiley (:P) in the end, but I will restrain myself from phun (normally do)..

2. I have a question regarding the statement that you can't do much about the debugger stepping all over the place.. Other debuggers seem to be able to handle that, to varius degrees of success. When I look at the main.lst file for the example listed i your link - I think the debugger COULD handle stepping over init code, better than it currently does.

The list file contains this information - (removed) related code:

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:64

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:67

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:70

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:76

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:82

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:64 <---Without analyzing code I would say that Execution starts here

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:67

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:70

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:73

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:76

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:79 <--- Ready to execute this part

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:82

D:\RIDE7\Ride\Examples\ARM\REva\STM32F103_Toggle/main.c:85

If not stepping through the assembler code I would let the debugger execute the initialization block (which can be detected by the fact that the c- lines appear several times in the list files) and then always choose to break just before the latest mention of a line.. I.e. If I select break at line 79 I would expect the break to be ready to execute the last mention of that line. Not the init part, as this would be before I actually completed line 76...

Hi,

Yes, I had something like this in mind when I said that "we could probably make things better". However, it might be much more complex than this and we cannot deduce general rules from the observation of this single (and simple) example. For instance, nothing guarantees that the initialization will be placed at lower addresses than the execution part of the C statement. Also, the execution itself could be split and/or factorized with other statements, possibly from other functions. (the C standard allows that, even if very few compilers do it, and I don't know if GCC does, or if it doesn't now but will in a future release) And analyzing the assembler or bytecode to detect the init from the exec is quite easy for a human being, but very complex to automatize.

Are the other debuggers you are referring to working better than Ride on applications compiled with GCC? Or are they using their own compilers? As far as I can tell, the problem is really related to the way GCC generates code and (mostly) debug information. If it was our compiler, we would simply have it not generate a C line flag on the initialization part of the statement. That's what we do for STM8, for example, and debugging works quite nicely even after optimization. (of course watches and very complex functions can still be affected, but it's much better)

I have searched for a option in GCC that would improve things but found none. (except reducing opti level ;) )
I have looked at the temp assembler file generated by the compiler for an indication saying which code was init and which was exec but found nothing like that. (which means there is probably none in the object file either)
Do you have other suggestions to make?

Best Regards,

Vincent

Here is a quote on this topic from the official GCC website:

Complete doc here:
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Vincent

...
And other related information here:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Debugging-Optimized-Code.html

Vincent

The debuggers I refer to have been using proprietary compilers - But often generating more compact code than GCC (nearly all my projects are code/memory-size critical) on same target - So I figured that they would face the same issues as you guys.. Have not used other GCC debuggers, like gdb to the same degree as RIDE I must admit.

Read your links and a couple of discussions regarding debugging optimized code with GCC and they do support your oppinion, when you dig into it - Optimized GCC do help the debugger much in terms of creating reliable debugging once optimization is enabled :-(

It seems that people are debating if and how to improve GCC debugging... But that will take ages before it turns into something usable I think. There seems to be a strong sense that it

Another option that could help during debugging is to make it possible to create bookmarks for easier navigation between source and make it easy to navigate to set breakpoints (Maybe call up a list of set breakpoints).. Navigating larger projects can be a pain during debugging, when the PC makes a sudden jump to another part of code.

/Henrik

Hi,

Bookmarks should be feasible, I will try to push that here.
Thanks for this interesting suggestion.

There is already a list of breakpoints that allows to "Go To Source":
Start a debug session, set a few breakpoints, then click "View"->"Debug Windows"->"View Flags"
Then you will see the list of breakpoints currently set. You can right-click on a break and select "View Source" and it will display the location of the breakpoint in the source.
(Bookmarks would just be another type of flag that has no impact on debug or execution...)

I hope it helps.

Best Regards,

Vincent

Ahh I see - Ill start using that - Never thought that flags = breakpoints...

/Henrik