My debugger use a lot of RAM memory space

[jean_prieur]

Posted on March 18, 2015 at 11:41

Hello everybody,

I have a trouble with the RAM memory space when I'm in debug mode with my STM32F4. I think my debugger take a lot of RAM space resources because I can't watch my variables anymore when my variables take a lot of RAM space.

For your information, I have this problem with the debug mode when my variables occupy more than 130Ko (for a total RAM memory space of 192Ko).

I use Coocox + GNU Tools ARM Embedded (or Yagarto) + ST Link + STM32F427. I think I debug in flash but I'm not sure because I use a ''custom_link.ld''.

Do you ever experienced this kind of trouble?

Thanks a lot, have a good day!

[waclawek.jan]

Posted on March 18, 2015 at 12:16

> For your information, I have this problem with the debug mode when my variables occupy more than 130Ko (for a total RAM memory space of 192Ko).

> I use Coocox + GNU Tools ARM Embedded (or Yagarto) + ST Link + STM32F427. I think I debug in flash but I'm not sure because I use a ''custom_link.ld''.

Can't this be a bug in Coocox's debug module/its configuration, thinking that you are working with a 'F0x/'F1x with less RAM?

I don't use Coocox, maybe try asking the support they provide.

JW

[jean_prieur]

Posted on March 18, 2015 at 18:10

Hello Jan,

I checked, my linker is configured with the correct RAM adresses for STM32F427.

[Tesla DeLorean]

Posted on March 18, 2015 at 18:40

Perhaps it doesn't understand CCMRAM? Perhaps they are using an F405 template with 128KB of RAM at 0x20000000? The linker script drives the LINKER, not the debugger, which may have it's own perspective on the Target device, and it's capabilities/resources.

If you .MAP describes the addresses suitably, use those to view the memory locations. If the data isn't in the .ELF in a usable fashion that could be a problem.

If it's a problem with the CooCox product, then you'll have to get them to address it. Or request the source and remedy it yourself.

[Rhodes.Keith]

Posted on March 18, 2015 at 19:33

I've had problems in the past with gnu-based debuggers having problems if there is not enough stack space available for the main task (assuming you are using multiple tasks or processes).

Check your map file to see how much stack space is available to the main task, which is usually at the top of RAM.

[jean_prieur]

Posted on March 19, 2015 at 18:14

Hello,

I think it can understand CCRAM because I can debug CCM variables. I checked the .map file and the memory adresses are correct, same as the linker:

Memory Configuration
Name Origin Length Attributes
rom 0x08010000 0x001effff xr
ram 0x20000000 0x0002ffff xrw
ram1 0x10000000 0x0000ffff xrw
*
default
* 0x00000000 0xffffffff

What is the debug .ELF file? I find it, but how can I read it? Indeed I use multiple real time tasks. What do you mean about ''the main task''? How can I know how much space is available to the main task? Thanks a lot!

[Tesla DeLorean]

Posted on March 19, 2015 at 19:24

The .ELF is the primary output of the linker, an object file, containing meta-data including variable names and addresses, along with all your code and data. objdump?

If the debugger doesn't understand what Target processor it's using that could be a problem. The linker script is for the linker's benefit, not the debugger's.

[jean_prieur]

Posted on March 20, 2015 at 15:50

Hello,

Thanks, I asked Coocox team to help me about this problem, I will keep you in the loop.