• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 196 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.

TMS320F28P650DH: ERAD problem/error

HS FAE Germany
Mastermind 33090 points

Part Number: TMS320F28P650DH

Tool/software:

Hi,

customer trying to use the ERAD module to implement stack overflow detection and has been studied the example erad_ex3_stack_overflow_detect provided with CCS. It seems that RTOSISR() will cause some kind of system reset/error if the program is made to continue after the ESTOP0 within RTOSISR() and it is not clear what causes this behavior.

 Customer tried following:

  • Changed the RTOSINT trigger address to a value before __TI_STACK_END

  • Tried to terminate the recursion in recursiveFunction() from RTOSISR()

What could cause this behavior? 

Regards, Holger

  • 0
    TI__Mastermind 32695 points

    Hi,

    The example is meant to showcase how to detect stack overflow. The ISR is triggered when the stack pointer is closer to the end of stack memory.  In the example, we just have an ESTOP so the CPU halts to demonstrate the ERAD's capability. If you continue executing it will corrupt the adjacent memory location and can cause unexpected behavior. For example, if you are running from RAM, the example could go ahead and overwrite the application code and cause fault.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    TI__Mastermind 33090 points

    Hi Veena,
    what is your suggestion when ISR triggered close to end of stack? What should be done?
    What would be your suggestion if ISR triggered when stack is overflowed? For example, would it be possible to recover the program from a known prior good state?

    Regards, Holger

  • +1 in reply to HS FAE Germany
    TI__Mastermind 32695 points

    Hi Holger,

    This is mostly used during development/debug. Ideally, usage of recurring functions are discouraged. We use it in the example to simulate a stack overflow scenario. If the application is using more stack memory than what is allocated, recommendation is to increase the stack size (with sufficient buffer). If this happens at runtime, we should prevent the application to continue execution to avoid corrupting the other memory region. That is the reason we configure the ISR to be triggered not when the stack has overflowed, but at a certain threshold level (Because ISR itself will consume few bytes of stack)

    Regards,

    Veena