How to check stack and heap usage during run time.

[SIBIN THOMAS]

Posted on February 16, 2018 at 06:03

Hello Everyone,

I am working on SPC560C50L3 MCU with SPC5 Studio. I am trying to add a library file which uses heavy stack and heap using dynamic allocations into my application. My code used to stuck in between due to stack overflow. Now I am able to change the stack size in the user.ld file. But how do I check the stack and heap usage at run time ? Any suggestion would be helpful.

Regards

THOMAS.

#spc560 #stack-overflow

[Tesla DeLorean]

Posted on February 16, 2018 at 07:27

Don't have specific experience with the SPC5 but the typical way to figure stack depth is to fill it with a pattern you can recognize later, and then periodically measure the low-water mark (see how much of the pattern remains walking up from the bottom of the stack's allocation). For heap, wrap the malloc/free to instrument, or write a routine to walk the allocator's structures in the memory arena. ie understand how your allocator manages its space.

If you don't know who's taking the memory, or leaking resources, then you'd want malloc() to tag the allocations so you know. For example use the return address of the malloc caller, and then associate with map or symbol file.

[Erwan YVIN]

Posted on February 16, 2018 at 10:09

Hello Thomas ,

• if you want to update a SPC5Studio demo, you can update this following configuration , save and generate

• If you want to use your own linker file

        in SPC5Studio, rename application.ld by user.ld

and you can customize your stack size by updating this following value

             Best Regards

                            Erwan

[SIBIN THOMAS]

Posted on February 16, 2018 at 16:58

Hello,

Yes, i am able to change my stack size in the user.ld file. But my ultimate aim is to calculate the stack and heap usage during run time and if they exceeds a certain value, i have to do a soft reset to recover leaked memory. So is there any way to keep track of my stack and heap usage while the code is running.

'Filling the stack with a pattern' is this the only way or is there any current stack pointer for checking the stack usage ?

For heap usage, how do I use my malloc/free to keep track of the remaining free space ?

Regards

Thomas.

[Tesla DeLorean]

Posted on February 16, 2018 at 17:51

You could record the deepest stack pointer value seen under a periodic interrupt, 1ms ticker if you have one.

For malloc/free, perhaps understand how the heap actually works on your platform, wrap the routine, allocate slightly more memory so you can place a variable/structure in front, and advance the pointer returned to the user, reverse that on the free, and perhaps count malloc/free calls to see if they balance, or if you free the same memory twice, etc.

Review source or disassembly of allocator currently in use, likely to use a simple linked list, figure how to walk.

[Bogdan Golab]

Posted on February 17, 2018 at 21:23

I was really interested what is the current solution for the stack monitoring. The 0xDEADBEEF pattern approach was taught in 80ties when I was in the electronic-oriented school.

I am happy that the approach is still used.

[Tesla DeLorean]

Posted on February 18, 2018 at 16:05

Well I did travel here from the 80's so not exactly surprising. You tended to be resourceful because an ICE would cost as much as a car, and while trace/profile pods are now much cheaper a lot of people don't have them, or header connections to support them.

Some tools provide for static analysis of call trees and stack depth, but interrupts and nesting there tends to be a bigger unknown factor.

Most things I build have a command line monitor to permit field debug/analysis, these typically include a reporting of stack depth as perceived from the console, and after running test/diagnostic routines. Also try to provide a register dump in case of hard failure, so we have something to work from than trying to determine the flashing pattern of an LED, or silent death. Hot-plugging a system isn't always practical or reliable.

[Bogdan Golab]

Posted on February 18, 2018 at 16:27

I was thinking I am mad starting every project from building serial-based console and simple CLI parser;)

My madness come from my long experience with Cisco routers and their ability to have built-in decent debugging capabilities (including memory and stack traces when a crash occurs). I also add some scripting capabilities to my projects as I like scripting languages.

Another weird thing I like is running code from SRAM (if possible due to SRAM size).  Many people say it's stupid as the flash can survive many cycles of reprogramming. I used to use a TI MCU where the 1000 cycles were killing;) I noticed that you also use this feature.