Topic : "Explore Code" for RAM functions

Forum : Ride IDE

Original Post
Post Information Post
April 27, 2010 - 5:41pm

Recently I was developing with RIDE7 + gcc for STM32/ARM and needed to design a function to execute from RAM space. I was able to do this, but I discovered that breakpoints would not work in that RAM function unless I first located it in the "Disassembly View" (where it was shown as just db 'x' and UNDEF lines) and clicked "Explore Code" (often it was necessary to do this several times in nearby areas before debugging with breakpoints or stepping would work as expected).

In Project Properties -> Advanced ARM Options -> Debug environment, I have set "Explore code" = Yes ("Disassembles the whole ROM on Startup or not."), but this function didn't seem to be included in that. Since the linker was aware of its RAM address (it was located in the .RAMtext section and copied into RAM by startup code), isn't there a way that the debugger could be setup to automatically disassemble this code? (or even ALL memory not just ROM -- I know this would generate some meaningless gibberish when attempting to disassemble data, but this would be better than nothing.) Maybe there is already a solution, and I just don't know about it.

Overall, I am very satisfied with RIDE, but occasionally I encounter little things like this that make my life difficult, so then I come nag on the forums :) Thanks again for your support.

Post Information Post
April 28, 2010 - 10:23am
Raisonance Support Team


There are several possible syntaxes to declare RAM functions, and some of them will work but not provide the correct debugging information.
Please give a try at this example from Ride: "\Examples\ARM\Test\testR7.rprj"
It calls a RAM function. I just tried it and I could set a breakpoint in this function from the C code.
Please tell if you observe the same problem with the example.

There is another thing to take care of: the breakpoints in RAM should be set after the code has been copied by the startup. Make sure your reset option is to go to the main at start of debug, not on the reset vector.
The reason for this is that when placing breakpoints in RAM, the debugger does not use the hardware breakpoint address comparators, but prefers to replace the instruction to break by a software break. That allows to have unlimited number of breakpoints in RAM. However, when doing this the code is modified and the debugger saves the original code, to restore it later when removing the break or executing the instruction. So if you place the break before the code is copied in the RAM, the wrong code will be restored.

I hope it helps.

Best Regards,