Topic : No local variables updated with RLink Pro? + strange breakpoint errors

Forum : ARM

Original Post
Post Information Post
June 5, 2007 - 10:40pm
Guest

Dear Sir,

I cannot have the exact value of local variables in the debugger window. They are always at value -1.
The global variables work, even if the update is very slow.

RLink Pro
Target: custom hardware with STR752FR2
Ride BN746 with patches (06.10.22)
Standard compiler GNUARM V4.0.0, tried also V4.1.1, and V4.2.0, no way
Compiler options: tried everything, -O0, -O1, -Os
All code in ARM mode.
Debug in FLASH: load and run ok, debugger doesn't not show local variables values, even if it list them correctly

Second problem:
erratic problem, even if there just one (1) breakpoint enabled, the following windows comes up when stepping??
-----------------------------------------------------------
OPI Driver
Maximum number of hardware breakpoints reached.
Unable to set more.
-----------------------------------------------------------
the strange thing is that, usually, wiyh only one breakpoint, the debugger works.

Especially the first problem is very serious, please give some indications.

Regards

Romano

Replies
Post Information Post
+1
0
-1
June 6, 2007 - 10:44am
Raisonance Support Team

Hi,

First, we need to know which patche(s) you have installed. Please click "help"->"About" and tell me the "Build Number" of your RIDE.

I did not manage to reproduce your first problem. I see the variables updated correctly. Can you please send me your project, or any example project that shows the problem? (zip the whole project folder, including sources, listings, etc., and send it to "support@raisonance.com")
In the meantime, I suggest you open a data view on your stack. (look at the value of SP and open a data window around it) This might force the debugger to update the values you want to see.

About your second problem: RIDE uses the breakpoints for stepping in C. It usually needs two, but sometimes only one and sometimes more than 2. But when you are in Flash mode, you only have two breakpoints available...
There is not much we can do. I can only suggest you remove your breakpoints before stepping, or you step "by hand" by placing the break after the line you want to execute and then launch the exec. Or you can step in the assembler window, if the C line is simple enough. The simplest solution is to debug in RAM mode until your application is mostly working, and then you just need to validate it in Flash mode. If the application does not fit in the RAM, you can compile in RAM mode but put most code in Flash. (see the comments just before the "main" function in "ride\examples\STRx\test\main.c" to see how to do that) Then, you can validate the code in RAM, then switch and put some other code in RAM for validation. This is not always feasible, but it is most of the time, and when it is, it's quite fine.

Best Regards,

Vincent