• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 1425 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.

(Multiple) Semaphore_post calls cause stack overflow?

Frank Lewis
Prodigy 195 points
Other Parts Discussed in Thread: TMS320C28346, SYSBIOS

I'm writing a SYS/BIOS application on a TMS320C28346.  CCS version 4.2.4 SYS/BIOS version 6.32.2.39

I have 5 tasks running, each with a different priority.  I'm using binary semaphores, created and configured graphically to control task flow.

My task flow seems to be working fine until I try and block (semaphore_pend) a second task with a semaphore.

One task blocked, no problem.  But when I call the a semaphore_pend with one task already blocked I get a stack overflow error

ti.sysbios.knl.Task: line 330: E_stackOverflow: Task 0x9b00 stack overflow. xdc.runtime.Error.raise: terminating execution

I have switched some of my pends around and the overflow occures in the task that calls the second semaphore_pend.

I have quadrupled the size of my task just to be sure and have also used the ROV to verify that I'm nowhere near the size limit.

Is this some limitation that I'm not aware of?  Configuration issue?  Has anybody else seen this issue before?

  • 0
    TI__Mastermind 20480 points

    Hi Frank,

    have you tried to enable the SYS/BIOS instrumentation? You should be able to see where the semaphores are pending.

    BIOS.libType = BIOS.LibType_Instrumented;
    BIOS.assertsEnabled = true;
    BIOS.logsEnabled = true;

    Do you have any interrupts enabled? You need to have enough stack space for two full Hwi interrupts contexts.

  • 0 in reply to Tom Kopriva
    Prodigy 195 points

    I have determined that this problem wasn't caused by the semaphores, but by me not implementing my HeapMemory for my MessageQ usage correctly.

    I backed my implementation out and did it correctly and the problem has disappeared.  My guess would be that I was stomping over the wrong piece of memory.  I get lucky that way when I write code.