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.

Stack corruption on return from BIOS_start

Other Parts Discussed in Thread: TMS320C6671, SYSBIOS

I have an application with two tasks that I create dynamically. Both were running correctly until I added a new uninstantiated object. Just adding that object declaration cause the stack to get corrupted on return from BIOS_start.

Below is the ROV capture showing the tasks stack location at 0x800017D0.


Here is the correctly initialized stack.

Here I'm at the final stages of BIOS_start in Task_startCore calling Task_SupportProxy_swap which is going to do a task context switch. Notice the task's stack is still good.

Here is the stack after the call. Completely corrupted.


My first calls in this task are

System_printf("enter TaskStatusControl()\n");
Task_sleep(100);

The call to Task_sleep fails which you would expect b/c it checks the stack.

I have tied the following

1. Turned off caching

2. Moved the stack to the internal memory.

3. Moved to static task

4. Moved ALL .text, .const, .stack, .far, .systemHeap to internal memory

What could cause this and how on earth do I go about debugging it?

TMS320C6671 using bios_6_35_04_50, xdctools_3_25_03_72, c6000_7.4.6 (compiler)

  • Hi GaryS,

    Is it possible that what you're doing in your two tasks is taking up a lot of stack space?

    GaryS said:
    Both were running correctly until I added a new uninstantiated object.

    Can you clarify on this?  What is this object, how big is it, is it a local variable (allocated on the Task stack) or is it dynamically allocated?

    GaryS said:
    Here I'm at the final stages of BIOS_start in Task_startCore calling Task_SupportProxy_swap which is going to do a task context switch. Notice the task's stack is still good. ... Just adding that object declaration cause the stack to get corrupted on return from BIOS_start. ... Here is the stack after the call. Completely corrupted.

    BIOS_start doesn't return so at that this point the Task scheduler should be running.  It doesn't look to me like your stack is being corrupted, rather it is being used to store information onto when the task runs.

  • Steven Connell said:
    Is it possible that what you're doing in your two tasks is taking up a lot of stack space?

    At this point the task are doing nothing but calling Task_sleep(100). However the stack is already corrupted on entry to the first task...before any task code is run.

    Steven Connell said:
    Can you clarify on this?  What is this object, how big is it, is it a local variable (allocated on the Task stack) or is it dynamically allocated?

    Below is the exact code, so it will get allocated onto the task's stack. Keep in mind that the task has not gotten to the declaration yet so the object constructor has not been called. I have not tied allocating it from the heap...I'll try that.

    Driver_Dac Dac(Port_1, 0);

    Steven Connell said:
    BIOS_start doesn't return so at that this point the Task scheduler should be running.  It doesn't look to me like your stack is being corrupted, rather it is being used to store information onto when the task runs.

    Correct BIOS_start doesn't return that was a poor choice of words. It does invoke the task scheduler which calls any pending task, however the stack is corrupted. Going through the scheduler you will get to 'Task_checkStacks' which checks for stack overflows. This function checks to see if the stack pointer is pointing to 0xBE which it's not.

    Your thinking that I missed your point about the task pushing to much stuff on it's stack. I'm not. My point is that the stack is corrupted before task entry.

    Here's two new data points. I have two task. Which ever task I declare/create first, either statically or dynamically, is the one that will get hosed.

    While watching the task's stack and stepping through the BIOS code...the first task's stack changes!

    This screams a SYS/BIOS configuration issue. It looks like the BIOS stack and/or heap is too short and running into the first tasks stack. I have moved/allocated/tried everything I can think of...and the first task called dies.

    For what it's worth here's my last map file, but I'm flailing about too much to describe my current configuration. I can tell you that the tasks stacks are in the .far section.

    ENTRY POINT SYMBOL: "_c_int00"  address: 0082cba0

    MEMORY CONFIGURATION

             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      L2SRAM                00800000   00080000  0003e444  00041bbc  RW X
      L1PSRAM               00e00000   00008000  00000000  00008000  RW X
      L1DSRAM               00f00000   00008000  00002000  00006000  RW  
      MSMCSRAM              0c000000   00400000  00000000  00400000  RW X
      DDR3                  80000000   10000000  00106186  0fef9e7a  RW X


    SEGMENT ALLOCATION MAP

    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00800000    00800000    00039120   00039120    r-x
      00800000    00800000    00039120   00039120    r-x .text
    00839120    00839120    000031cc   00000000    rw-
      00839120    00839120    000031cc   00000000    rw- .far
    0083c2f0    0083c2f0    00001a44   00001a44    rw-
      0083c2f0    0083c2f0    00001a44   00001a44    rw- .fardata
    0083dd34    0083dd34    0000035c   0000035c    r--
      0083dd34    0083dd34    0000035c   0000035c    r-- .switch
    0083e090    0083e090    00000120   00000000    rw-
      0083e090    0083e090    00000120   00000000    rw- .cio
    0083e1b0    0083e1b0    00000078   00000078    r--
      0083e1b0    0083e1b0    00000078   00000078    r-- .init_array
    0083e228    0083e228    00000014   00000000    rw-
      0083e228    0083e228    00000014   00000000    rw- .bss
    0083e23c    0083e23c    0000000c   0000000c    rw-
      0083e23c    0083e23c    0000000c   0000000c    rw- .neardata
    0083e400    0083e400    00000200   00000200    r-x
      0083e400    0083e400    00000200   00000200    r-x .vecs
    00f00000    00f00000    00002000   00000000    rw-
      00f00000    00f00000    00002000   00000000    rw- .stack
    80000000    80000000    00100000   00000000    rw-
      80000000    80000000    00100000   00000000    rw- systemHeap
    80100000    80100000    00004d12   00004d12    r--
      80100000    80100000    00004d12   00004d12    r-- .const
    80104d14    80104d14    00001474   00001474    r--
      80104d14    80104d14    00001474   00001474    r-- .cinit

  • Hi GaryS,

    Would you mind taking a couple more screen shots for me?

    I'm interested in seeing screen shots of:

    1. The Task Module ROV Detailed view (it shows a little more info than the Basic view shown in your previous screen, including stack peak)

    2. In the memory window, can you enter the following symbols and take screen shots of the memory contents?
      1. ti_sysbios_knl_Task_Instance_State_0_stack__A
      2. ti_sysbios_knl_Task_Instance_State_1_stack__A
      3. ti_sysbios_knl_Task_Instance_State_2_stack__A

    3. It would also help to see a screen shot of the end of your Task's stack (the end is really the beginning, since Task stacks start at the end and grow upward in the memory view).
      1. For example, you could find the end of "Task 0" stack by entering "ti_sysbios_knl_Task_Instance_State_0_stack__A + 0x2000"
      2. This will actually take you to end of "ti_sysbios_knl_Task_Instance_State_1_stack__A", so you should scroll up in the memory window a little.
      3. (i.e. the first pushes of data onto the "Task 0" stack should happen just above "Task 1's" (ti_sysbios_knl_Task_Instance_State_1_stack__A)stack in the memory window)

    4. The Hwi Module ROV Module view (to see the Hwi stack size and stack peak)

    Steve