• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 2509 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Good way to check stack size

Max Maung
Prodigy 30 points
Other Parts Discussed in Thread: HALCOGEN

Hi.  I'm using TI Hercules RM48 processor with ccs v5 and Halcogen to control some hardware.  I understand that I could change the length of STACKS in sys_link.cmd file to control the size of the stack.  I'm looking for a good and relatively pain free way to determine the size of the stack my program needs.  So far, it's not that difficult because I know where the worst case scenario occurs and I could put a break point in the debugger to see addresses of local variables to get an idea of how big my stack size should be.  But I'm afraid as my program grows, it may become hard for me to figure out where I should put my break point to estimate how big of the stack my program uses.

Besides initializing stack memory initially with known values and checking for the break in pattern, are there any good ways that the compiler or debugger provides that would assist programmer in determining a good stack size?  For example, I heard a particular processor could automatically go to a break point in emulator if a stack pointer goes beyond user specified number.  A mechanism like that would allow me to keep decreasing the size of stack until break point is hit.

Thank you all in advance.

  • 0
    TI__Genius 11645 points

    Hello,

    There is no inbuilt hardware mechanism in ARM core to do this, I can suggest a few ways to do this.

    1)

    a. If you are interested in abort, then you can configure the memory which you think should not be used by CPU due to over growing stack as separate MPU region.

    b. Assign the AP property of that region to No Access, so whenever stack overgrows in to this region you will get an abort.

    2)

    a. The more simpler way should be to assign the stack size lot more than what you will need and fill them using a known pattern prior to the run.

    b. Run your test and make sure the max stack usage scenarios like nested routines, interrupts etc are occurring.

    c. At the end you can check the memory to see whats the last entry which contains something not matching the known pattern should be the max stack utilization number.

    Hope this helps.

    Best Regards,

    karthik.

  • 0
    TI__Mastermind 49120 points

    Hi,

    You can use the "stack depth profiler" tool that is included along with the other codegen tools. The executable is named armsdp.exe and you can find it in the same folder as the other codegen tools such as the compiler or linker.

    The {CCS install directory}/tools/compiler/{ARM compiler version}/docs folder also includes separate user guides for the compiler and the linker. The compiler user guide SPNU151x also includes a chapter that describes the stack depth profiler functionality.

    Regards, Sunil

  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    Prodigy 30 points

    Thank you, Karthik.  While 2nd suggestion works as expected, as for the first suggestion how would I make it work?

    Here is what I did for the 1st suggestion:

    1. reduced user stack length to 0x100, so with the supervisor stack length of 0x100, the program has the total stack size of 0x200.  This took place in Halcogen.

    2. In sys_link.cmd, I added a new memory region called BADST.  Here is how it appeared:

    MEMORY
    {
        VECTORS (X)  : origin=0x00000000 length=0x00000020
        FLASH0  (RX) : origin=0x00000020 length=0x0017FFE0
        FLASH1  (RX) : origin=0x00180000 length=0x00180000
        STACKS  (RW) : origin=0x08000000 length=0x00000600
        RAM     (RW) : origin=0x08000600 length=0x0003fa00

    /* USER CODE BEGIN (2) */
        BADST   (X)  : origin=0x07FFF000 length=0x00001000
    /* USER CODE END */
    }

    3. called the following function in the main.

    void TestStackInit(void)
    {
        int i[300];
        int j;
        for(j = 0; j < 300; j++)
        {
            i[j] = 0x5a5a5a5a;
        }
        return;
    }

    When I ran it with the debugger, I noticed the array i location was allocated to 0x07FFFD44.  This is clearly inside the bad memory region (in fact, the address isn't even in the RAM).  I stepped through the code, and everything proceeded normally.  No abort was observed.

  • 0 in reply to Sunil Oak
    Prodigy 30 points

    Thanks, Sunil.  I ran into a lot of problems trying to use sdp470.exe.  The stack depth profiler isn't compatible with ELF output format.  I tried using coeff format, but ccs complains about some progma's being undefined in files that are generated by Halcogen.  So I take it to mean that Halcogen isn't meant for coeff output format.