Jump to content

[Help] how to get RAM usage from mspdebug?

Recommended Posts



this is probably a dumb question: how can I see the amount of free ram on the chip from within a mspdebug session?


This is my current session:

mspdebug rf2500 
MSPDebug version 0.18 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2011 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO

Trying to open interface 1 on 011
rf2500: warning: can't detach kernel driver: No data available
Initializing FET...
FET protocol version is 30394216
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
fet: FET returned error code 4 (Could not find device (or device not supported))
fet: command C_IDENT1 failed
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 30394216
Configured for Spy-Bi-Wire
Sending reset...
Set Vcc: 3000 mV
Device ID: 0x2553
Device: MSP430G2553
Code memory starts at 0xc000
Number of breakpoints: 2

Available commands:
    =         delbreak  gdb       load      opt       reset     simio     
    alias     dis       help      locka     prog      run       step      
    break     erase     hexout    md        read      set       sym       
    cgraph    exit      isearch   mw        regs      setbreak  

Available options:
    color           gdb_loop        iradix          
    fet_block_size  gdbc_xfer_size  quiet           

Type "help <topic>" for more information.
Press Ctrl+D to quit.

(mspdebug) load ledmatrix.elf
Writing 1518 bytes to c000 [section: .text]...
Writing 1106 bytes to c5ee [section: .rodata]...
Writing   32 bytes to ffe0 [section: .vectors]...

Link to post
Share on other sites

So I guess the problem here is the concept of "free RAM". It's a virtual concept based around the fact that your heap is a certain size, and your stack another. The only thing mspdebug can tell you about is the Stack Pointer, the rest of it would require closer analysis of the ELF output to see how much of the heap got allocated (by the linker) to global & static variables. Mspdebug doesn't help with that to my knowledge.


Sent from my Galaxy Note II with Tapatalk 4



Link to post
Share on other sites

You can mark RAM with a known value say (0xfeee). Then at runtime use mspdebug to examine memory looking for locations that no longer have the value of 0xfeee. Memory in ram that no longer contains the value 0xfeee is an indication that it has been used by a data variable, the heap or as stack memory.


You need to write a function that runs prior to the start of main and "colors" ram. See the code link below for an example of how to create such a function. Link this function with your code and run it with mspdebug. Use CTRL-C to break after you have exercised all your functions. Then use the eXamine gdb cmd:


> x/4xw 0x200


Here we are eXamining ram memory starting at the lowest address (0x200 is the first ram location for most g series chips). Each time you press enter after that command, it will show the value of the next 4 words of ram. Press enter repeatedly and skip over the bss and data addresses and then start looking for '0xfeee', that is where the heap ends. Continue looking for 0xfeee until it changes, that address indicates the lowest stack value. The difference between the end of the heap and the lowest stack address is how much free ram you have. Note: If the value 0xfeee is a common value used in your program then you probably want to use another value to color the stack.


Note: You can't get the amount of free ram just looking at the static numbers provided by the compiler. You must run your code and exercise all code paths to find out the true amount of memory your application uses. See this file for an example of a routine that can "color the stack"




Code starting at line 101



Link to post
Share on other sites

Not many MSP430 projects have dynamic memory allocation.  Unless you are using dynamic memory allocation (i.e. malloc), you can simply look at the bss (sometimes BSS) output from the compiler to see what your static allocation is.


For the stack, unless you are running a threaded RTOS you're going to be running on a single program stack (if you are running a threaded RTOS, you are probably still saving thread-stack-pointers in static memory and you can probe them).  Anyway, the bottom of the stack is generally the upper most RAM address.  So, the uppermost address minus the stack pointer address will give you stack usage at any given time.  mspdebug can give you the value of the stack pointer.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...