• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 2116 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.

Adding Task_stat() call to running task causes crash after 10-15 seconds.

John Conover
Genius 4350 points

Other Parts Discussed in Thread: AM3359, SYSBIOS

Hi,

          We are porting over a AM3359 StarterWare project to SYS/BIOS and had it running well over the weekend with a single task. There are currently 5 hardware interrupts firing, two tasks (but only one is running.) We then added a Task_stat() call to the running task and after 10-15 seconds we get this SYS/BIOS error:

[CortxA8] Starting main loop1
Exception occurred in ThreadType_Task.
Task handle: 0x80e3eda0.
Task stack base: 0xb4e81b40.
Task stack size: 0x3fab4e81.
R0 = 0xb4e81b40  R8  = 0xffffffff
R1 = 0x3fab4e81  R9  = 0xffffffff
R2 = 0xb4e81b40  R10 = 0xffffffff
R3 = 0xb4e81b80  R11 = 0xffffffff
R4 = 0x80e42db0  R12 = 0xb4e81b40
R5 = 0xffffffff  SP(R13) = 0x80e42d88
R6 = 0xffffffff  LR(R14) = 0x80070a7c
R7 = 0xffffffff  PC(R15) = 0x80070578
PSR = 0x8000019f
ti.sysbios.family.arm.exc.Exception: line 176: E_dataAbort: pc = 0x80070578, lr = 0x80070a7c.
xdc.runtime.Error.raise: terminating execution

The two Tasks are created like this:

    /* Create two tasks that share a resource*/
    Task_Params_init(&taskParams);
    taskParams.priority        = 4;
    taskParams.stackSize    = 16384;
    tsk1 = Task_create (MainLoop_task, &taskParams, NULL);

    Task_Params_init(&taskParams);
    taskParams.priority        = 4;
    taskParams.stackSize    = 16384;
    tsk2 = Task_create (task2, &taskParams, NULL);

    BIOS_start();

    The current stacks are:

     Heap: 131072

     By looking at the PC in the error of 0x80070578, it appears to be in the Task_stat() call:

     So what could the problem be?

     Is it a hardware interrupt firing off causing problems or possibly some internal stack size the is to small? Our ISR routines have no special code for register saving or restores, but this was not an issue with StarterWare.

Any help is appreciated.

John C.

  • 0
    TI__Mastermind 45025 points

    Hi John C.

    Can you look at the ROV tool when this happens?  Do you see stack overflows happening in the Task module view?

    Also, you may want to see this FAQ about how to back trace when you get an exception + register dump like you are seeing:

    http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#4_Exception_Dump_Decoding_Using_the_CCS_Register_View

    Steve

  • 0 in reply to Steven Connell
    Genius 4350 points

    Hey Steve,

              When I look at the ROV tool after the error, the Task Basic tab says "Target memory read fail", so I don't think I can get any stack info from that. Let me look into your link to see if I can trace the stack back.

    Thanks,

         John C.

  • 0 in reply to John Conover
    Genius 4350 points

    Hey Steve,

                       I looked into the link and tried the first thing they mention on there and copied the PC, SP and LR into the register view from the dump. What I get in Code Composer is that is looks like it was in the middle of the TaskSupport_stackUsed() function when it imploded. Any suggestions?

    Thanks,

         John C.

  • 0 in reply to John Conover
    Genius 4350 points

    Steve,

                I tried removing the Task_stat() call and replaced it with a Task_yield() to allow my second task to run. Well both tasks now run but I get a crash within the Task_yield() call. So in either case something bad is happening while calling a SYS/BIOS task function.

    John C.

  • 0 in reply to John Conover
    Genius 4350 points

    Steve,

                 I've tried running this over and over, and whether I use the Task_stat or Task_yield, when the problem occurs it appears to be in the exact same spot. I would think if this was and interrupt causing the issue that I would see some variance in the timing. So is there a document that describes the how SYS/BIOS uses the "heap" vs. "stack" and the proper way of adjusting their size.

    Thanks,

         John C.

  • 0 in reply to John Conover
    Genius 4350 points

    Steve,

                  If I take a look at this error strictly from ROV, I see a Data Modules->Exception->data abort error at address 0x80db40cc (see first picture.) When I look at the MMU settings under ROV I don't see anything unusual about that address range(see second picture.) The memory map shows:

    80db0000    00080000     airtrac_pea8fnv.oea8fnv (.bss:ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A)

    80cf0000   raw_buffer
    80db0000   ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A
    80e30000   memp_memory_PBUF_POOL_base
    80e7ec00   dataXcorrAvg

           So I don't see any obvious issues with this address. Does SYS/BIOS have any special protections for that range?

    Thanks,

         John C.

    Image 1

    Image 2

  • 0 in reply to John Conover
    TI__Mastermind 45025 points

    John C.

    This sounds like a stack overflow problem.  Can you try increasing your Task's stack size? For the Task function that's calling Task_stat or Task_yield?

    If you have a lot of memory available, try doubling your Task stack size (you can reduce it later, if this is indeed the culprit).

    After you increase the stack size, try single stepping over those calls to Task_stat/_yield and then use ROV to check the stack peak.

    Steve

  • 0 in reply to John Conover
    TI__Mastermind 45025 points

    John Conover said:
    So is there a document that describes the how SYS/BIOS uses the "heap" vs. "stack" and the proper way of adjusting their size.

    Yes, you should check out the SYS/BIOS User's Guide.  It comes with your BIOS installation.  For example, it's here on my machine:

    C:\ti\CCS5.4.0.00091\bios_6_35_01_29\docs\Bios_User_Guide.pdf

    In particular, the following sections are related to your question:

    • 6.5 Stacks
    • 6.7 Dynamic Memory Allocation

    Steve

  • 0 in reply to Steven Connell
    Genius 4350 points

    Hey Steve,

                      Yes it definitely is a stack corruption problem. There are a couple of function calls that can use a lot of stack and on one of the calls it blows out the main_task stack which corrupts the tasks stack base among other things. I've increased the stack size of the task when I dynamically create it using the taskParams.stackSize    = 32768 variable. The issue I see is that when I go to increase this further I get an out of memory error on the task create call. I can't find anything in the Users Guide that shows how to increase the memory allowed for tasks stack use. I have increased the task defaultStackSize very high, but this does not seem to have any effect. Can you tell me where I can increase the memory allowed for task stacks?

    Thanks,

         John C.

  • 0 in reply to John Conover
    Guru 19890 points

    John C.,

    Task module will allocate stack memory for its instance from the heap specified in Task.defaultStackHeap property.
    If this is null, then I think the stack memory will be allocated from system heap.
    In this case, you will be able to increase the size of system heap by the following script in .cfg file :

    Program.heap = 0x2000; // Example to set system heap with 0x2000

    Also, you can specify statically allocated global memory as a stack heap in runtime instance creation.
    Pseudo code would looks like below:

    #pragma DATA_ALIGN(g_stackBuffer, 8);
    #pragma DATA_SECTION(g_stackBuffer, ".stack_buffer");
    Int g_stackBuffer[0x1000]; // 4*0x1000 stack size

    Task_Params tskParams;
    Task_Params_init (&tskParams);
    tskParams.stack = (Ptr) g_stackBuffer;
    tskParams.size = sizeof(g_stackBuffer);
    tskParams. ... = ...;

    Task_create (...);

    Lastly, you are now focusing on Task's stack but you should care about system stack also because
    you see the problem with Task_yield().
    You can change the size of system stack by the following script in .cfg file:

    Program.stack = 0x2000; // Example to set system stack with 0x2000

    Best Regards,
    Kawada 

     

  • 0 in reply to Naoki Kawada
    Genius 4350 points

    Kawada,

                    Thank you much. I had been trying to increase the system stack but the Users Guide is not very clear and needs more examples. Because we had been using StarterWare before, the depth of the stack needed by the code had no boundary except for the size of the DDR memory(and how much you used in your executable image.) So when we shifted the code into a bounded stack I should have expected this issue, but I had allocated 16K thinking it should be more than enough. Since the system has been running I found that the code that was causing the issue used 22K of stack. Thanks again for the help.

    John C.