Topic : Can not watch any local variables in newest Ride7 debugger

Forum : Ride IDE

Original Post
Post Information Post
October 19, 2009 - 2:26pm
Guest

I've just installed the newest version of Ride7 (7.24.09.0251) and RKit (1.22.09.0254).
The firmware is compiled correctly and downloaded using RLink. The problem occurs when I want to watch local variables. All of them are displayed as: "Error (3): undefined symbol". It happens also when i select "No optimization" in the compiler options. It didn't happen in previous Ride7 and RKit version and i could watch some of local variables (however, most of them were displayed with wrong values). Why is that ??? When i install newer versions of Ride7 i experience new problems with the debugger...

Replies
Post Information Post
+1
0
-1
October 22, 2009 - 10:52am
Guest

Hi

From the version you refer you must be working with ARM targets.
May be the projects I tried were not complex enough or I have missed something.
Can you tell this issue would happen with every project, every target, with the simulator or only with RLink?
What else would I need to reproduce the issue?

Regards,
Matloub

+1
0
-1
October 23, 2009 - 1:51pm
Guest

I have only one project debugged in this version of Ride7 and RKit. The project uses STM32F103VBT6 device.
With previous version of Ride the problem was not big because I could watch some of the variables; in the newest verision I can't watch any of them.

+1
0
-1
October 23, 2009 - 2:37pm
Raisonance Support Team

Hi,

I can see at least 4 explanations to what you describe:

1. Better optimization from the compiler, which can result in the variables (or accesses to variables) being optimized out or similar things. Keep in mind that we cannot guarantee that optimized code is debuggable at all. As a workaround, you can disable optimization, or declare the variables that you want to watch as global and volatile, just for the time of debugging the functions that access them.

2. Regression in the debugger.

3. Combination of better optimization from the compiler and old bug, so far unseen, in the debugger.

4. Bug in the compiler. That's very unlikely but still possible.

You must first rule out explanation #1 by disabling optimization and declaring these variables as global and volatile. Or you can look at the disassembly code to see if the variable still really exists and is handled as you expect.

If the problem persists, to solve the problem we must understand precisely what happens, and for that we will need to have a project that shows the problem, and also to know the versions of the kits that you had before. (when you managed to watch these variables)

Best Regards,

Vincent