• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 459 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Stellaris LM4F120H5QR: How to Measure Free Available SRAM?

Rei Vilo
Guru 23935 points
Other Parts Discussed in Thread: ENERGIA

Hi!

I'm using the Stellaris LM4F120H5QR LaunchPad with the Energia framework.

I'm facing an issue with my project: it freezes just when calling a function with parameters. I suspect a memory leak somewhere.

My question is: How to measure the free available SRAM?

As for many other MCUs, I guess it is a difference between the stack and the heap addresses. I've looked around but haven't found anything so far.

Thank you for your help.

  • 0
    Guru 86755 points

    Hi Rei,

        Post your code here, where the freeze or code hang-up occurred, so others can review it. Also, are there any other error messages?

    -kel

  • 0 in reply to Markel Robregado
    Guru 23935 points

    Thank you for your answer.

    I'm afraid extracting the code from the project to circumvent the error would be too difficult and time consuming as I'm adding the FatFs library to my LCD_screen project.

    The FatFs library can be found here and the LCD_screen project there.

    There is no error message and, as I don't use CCS, I have no debugging facilities and I can't have a more detailed picture of what's happening. 

    Hence my call for a function to measure free available SRAM to check my assumption of memory leak.

  • 0 in reply to Rei Vilo
    Guru 117855 points

    While not rising to a "function" - TI's Dave Wilson & others have long suggested, "uniquely seeding the SRAM" - and then checking for encroachment.  (0xFEEDFACE is nicely recognizable {again credit Dave W})

    Don't know that, "having no debug facility" will yield fastest, best, or most efficient code development. 

    CCS, IAR, Keil & others provide "free" versions - all include excellent debug & program capabilities - believe these exist (and grow/prosper) for "good reason."

    Update: Dawns that you may regularly "seed" key points w/in SRAM (rather than entirely filling) - and then simply read these key locations to determine if seed data persists.  (perhaps every 1K, 2K, 4K SRAM byte boundary - this should both speed & ease your memory leak discovery...)  (I'd bet against any such "leak")