• Locked Locked
  • Replies 5 replies
  • Subscribers 119 subscribers
  • Views 20213 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M3 - How detect stack overflow?

Andre Pereira
Note: This was originally posted on 12th January 2011 at http://forums.arm.com

Hi everybody,

I've started developing whit ARM few weeks a go and I have this doubt:
The Cortex-M3 have some hardware detection of stack overflow?

Let me explain:
I've used PIC24 for my last projects, and using as example, the PIC24 have the register "SPLIM" (Stack Pointer Limit) where you write the address of the last byte of your software stack and if your software try to write in more than the address wrote in the SPLIM register, the processor causes a "trap" (a kind of interruption with an dedicated vector).
Using this "trap" you can know if you have any stack overflow.

The ARM Cortex-M3 have something like that?

I've searched in the ARM v7 and the Cortex-M documentation and I just found something about BusFault in stacking but I don't understand very well.

Sorry for my poor english (I'm from Brazil) and thanks in advance.
André Rairan.
Parents
  • Arm Employee Badge
    Note: This was originally posted on 14th January 2011 at http://forums.arm.com

    First of all, in case you don't know, many compiler suites generate information about how much stack your program required.
    For example, in Keil MDK, after you compile a project, you will find a html file in the project directory. Inside you can find something like this
    main (Thumb, 36 bytes, Stack size 8  bytes, hello.o(.text))

    [Stack]

    • Max Depth = 128
    • Call Chain = main ⇒ __2printf ⇒ _printf_char_common ⇒ __printf
    (it is a long file, but  you should be able to locate this information easily).

    From the same file, you should be able to locate the stack size required for your interrupt handlers.
    For each level of interrupt, you need to reserved 9 words. (Depending on the stack pointer value when interrupt happen, a word of padding might be need so that the stack frame is double word aligned).

    Now you can work out the maximum stack size you need by consider
       the stack size required from main( )
    + the stack size required for interrupt handlers when nested
    + 9 words x number of interrupt level.

    However, this will not check the situations when the stack pointer is modified manually inside the code.

    If using MPU, you can define two regions (the MPU support 8 regions):
    Region 0 cover the whole 4GB address space to allow the program to access program, data and I/O as usual.
    Region 1 define a small memory block (minimum MPU region is 32 bytes) to be blocked from any accesses.
    The rest of the regions (region 2 to region 7) remain disabled.
    Then enable the MPU (MPU_CTRL set to 1).
    When the block memory is accessed, a hardfault (or memoery management fault if you enable this exception) would take place.

    By setting the blocked memory region to the limited of the stack memory, the hardfault will be triggered when your program use more stack then you expected.

    Note:
    1. A MPU region starting address must be aligned to the size of the MPU region.
    2. By using this method, the values of registers pushed to the stack before hardfault is entered could be lost.

    If you want to allow the program to be resumed, it is easier to use data watchpoint comparator in DWT to trigger debug monitor exception.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 14th January 2011 at http://forums.arm.com

    First of all, in case you don't know, many compiler suites generate information about how much stack your program required.
    For example, in Keil MDK, after you compile a project, you will find a html file in the project directory. Inside you can find something like this
    main (Thumb, 36 bytes, Stack size 8  bytes, hello.o(.text))

    [Stack]

    • Max Depth = 128
    • Call Chain = main ⇒ __2printf ⇒ _printf_char_common ⇒ __printf
    (it is a long file, but  you should be able to locate this information easily).

    From the same file, you should be able to locate the stack size required for your interrupt handlers.
    For each level of interrupt, you need to reserved 9 words. (Depending on the stack pointer value when interrupt happen, a word of padding might be need so that the stack frame is double word aligned).

    Now you can work out the maximum stack size you need by consider
       the stack size required from main( )
    + the stack size required for interrupt handlers when nested
    + 9 words x number of interrupt level.

    However, this will not check the situations when the stack pointer is modified manually inside the code.

    If using MPU, you can define two regions (the MPU support 8 regions):
    Region 0 cover the whole 4GB address space to allow the program to access program, data and I/O as usual.
    Region 1 define a small memory block (minimum MPU region is 32 bytes) to be blocked from any accesses.
    The rest of the regions (region 2 to region 7) remain disabled.
    Then enable the MPU (MPU_CTRL set to 1).
    When the block memory is accessed, a hardfault (or memoery management fault if you enable this exception) would take place.

    By setting the blocked memory region to the limited of the stack memory, the hardfault will be triggered when your program use more stack then you expected.

    Note:
    1. A MPU region starting address must be aligned to the size of the MPU region.
    2. By using this method, the values of registers pushed to the stack before hardfault is entered could be lost.

    If you want to allow the program to be resumed, it is easier to use data watchpoint comparator in DWT to trigger debug monitor exception.
Children
No data