Topic : Problems debugging STM32 - variable values are shown wrong

Forum : ARM

Original Post
Post Information Post
April 17, 2008 - 9:55pm
Guest

I have a BIG problem! The debugging of an application is almost impossible using the Ride7 IDE.

Here is the code:
long testCall(int a, long b)
{
long c = 0;
c = a + b;
return(c);
}

void testProgram(void)
{
long result = 0;

result = 5;
result = testCall(1000, 100000);
}

int main(void)
{
while(1)
{
testProgram();
}
return(0);
}

The problem is, that if I break the execution at "return(c)", none of the parameters/variables are showing the correct value - when the mouse cursor shows the values.

The "Watch" window also shows wrong values.

What is wrong?
Replies
Post Information Post
+1
0
-1
April 18, 2008 - 9:15am
Guest

You are talking about local variables, or function arguments. These kind of variable are most of the time highly optimized by GCC and are probably stored in the CPU registers instead of memory addresses, and our debugger seems to have difficulties to find out the association between the variable value and the register content.

What you can do is declare (for debugging) the variable c as volatile, or disable all optimisations from GCC (set optimisation level to None).

You should always have a look at the disassembly code to understand what is exactly going on. If you see that the variable c uses a specific register, watch the register content instead of the variable.

Lionel
+1
0
-1
April 18, 2008 - 11:14am
Guest

It sounds like a very big limitation. I have disabled all optimation, and the problem still exists.
It is also not possible to see the 2 parameters (a and b) of the "long testCall(int a, long b)"

I must admit, that I have never used an IDE (with debugger functionallity) that didn't support that.

Right now I am very confused, and think that I might have wasted the money on the Rlink Pro.
If I knew of these limitations I would have chosen IAR...

//Martin
+1
0
-1
April 18, 2008 - 4:19pm
Guest

With or without optimizations, the only way I found to trace your variables is to declare local variables as global instead.
I declared c and result as global variables and everything worked fine. We will try to understand what's happening.

regards,
Lionel
+1
0
-1
April 29, 2008 - 1:23pm
Guest

Hi RB,

For local variable, wait some second and normally, the local variable are good.
For me, when I have the problem, I replace the local variable by a global variable and the tracin of variable is always good.
+1
0
-1
April 29, 2008 - 8:15pm
Guest

Hi Boubou

It is a bug, that the calling parameters of a function is not shown correctly.
I was told in a mail, that they are working on it.

For me it is not a solution to change variables to globals - for debugging purposes. After all the Ride7 is a tool for amateurs only - or?
At least I have paid quite a lot of money for the JLink Pro, and expect a product almost as good and professional as Keil or IAR.

So I sure hope that they solve the bug, and making the tool usable - for debugging too...

//Martin
+1
0
-1
May 7, 2008 - 11:01am
Guest

Hi

I just wanted to let you know that we could fix that issue and the correction will be available up on next release of the Rkit ARM.
We have still some others improvements that we want to include in that release but it should be done in less than one month.

Matloub
+1
0
-1
August 1, 2008 - 6:59pm
Guest

I have installed the latest version of Ride, but this BUG doesn't seem to be solved. Debugging is very hard with this development tool...
+1
0
-1
August 1, 2008 - 7:07pm
Guest

Hi MicroGiga.

I have not upgraded my version yet, but it is very unbelievely to me, if this bug has not been fixed yet.

I have managed to debug my application without being able to see calling parameters. My application is only a merge from the pic platform to cortex platform + a little extra.

Please contact Raisonance about if it is not solved yet, end please post response.

Best regards
Martin
+1
0
-1
August 5, 2008 - 7:03pm
Guest

Hi

The bug described in the first post of this forum was corrected in the previous version of Ride7 and Rkit-ARM.
Now latest version is Ride7 version 7.10.0000 and Rkit-ARM version 1.10.0000.
I will be testing this bug still appear under these versions and let you know.

If you can precise under which version of Ride7 and RKit-ARM you found this bug please let us know.

Best regards,
Matloub
+1
0
-1
August 8, 2008 - 10:02am
Guest

Hi

I have made a trial with Ride7 version 7.10.0000 and Rkit-ARM version 1.10.0000
When the code in "testprogram()" is not optimized so I can put a break point, the value is correctly evaluated.

Best regards,
Matloub