Topic : Figuring out where the SRAM is going

Forum : ARM

Original Post
Post Information Post
September 22, 2011 - 5:28pm
Guest

I have a program that uses FreeRTOS which worked fine under the STM32F107, but is unhappy on the STM32F205. One thing that I noticed was that my SRAM usage mysteriously shot up between the two versions.

The bss section of my whole project shows about 63k consumed, but the sum of all of the bss sections of the individual components of the project does not even come close at 16k.

I've also noticed some slightly odd behavior that seems indicative of a memory fault of some type, but the debugger doesn't show that I've landed in any of the fault interrupt handlers. Basically the processor will completely crash depending on how much is going on. For what it's worth, I'm using the simple static heap allocator from FreeRTOS (heap_1.c).

Any insight to the source of these incongruous tallies would likely point me in the right direction.

I really appreciate the help!

Thanks,
Sasha
Replies
Post Information Post
+1
0
-1
September 26, 2011 - 8:25am
Raisonance Support Team

Hi Sasha,

Can you share your project or at least your .map file with us, so that we can have an hint about what is going wrong?

Thanks,
+1
0
-1
October 2, 2011 - 7:34am
Guest

Sure thing, I'll send you an email with some of my (admittedly crude) code.

Thanks so much!
+1
0
-1
October 11, 2011 - 7:57pm
Guest

Hi Bruno, I just wanted to check in to make sure that the file I emailed in at my lost post wasn't caught up in some antivirus or spam filters (for being an archive).

Any help is most appreciated!

Thanks,
Sasha
+1
0
-1
October 12, 2011 - 11:00am
Raisonance Support Team

Errr... My SPAM filter, in your case, was only my pile of todoes growing up. Sorry for the delay in answering :/

I properly received your project and built it. I reproduced the behavior you describe, then opened the project map file.
Simply browsing the map file, I found out that your "mppt" variable is eating looots of RAM space.

That may be the issue you are facing. Other variables may hurt as well.
Anyway, the best for you is to perform this map file review by yourself and check all the problems out from there.

Best Regards,
+1
0
-1
October 25, 2011 - 11:52am
Guest

Thanks! I ended up finding that as well. There was a #define that was making it huge and I didn't notice. Is there a good place in Ride to see where the globals are sucking down memory? Or a better way to parse the map file so I don't overlook such things again? I really appreciate your help!

Best,
Sasha
+1
0
-1
October 26, 2011 - 10:11am
Raisonance Support Team

Hi Sasha,

Yes, there is a nice Ride7 feature that can help you find such problems:
In the Project Window, there is a "Show..." button. Click on it, and activate "build information".
Once this is done, rebuidl your project. You will have the RAM/FLASH/EEPROM size eaten by your application, as well as for each individual source file of the application.

This helps a lot finding "overkill objects".

Best Regards,