• Resolved

RE: RTOS/TM4C1292NCPDT: Stack error

Hi,

After timer interrupt is generated, I am creating a task dynamically as below,

Error_Block eb;

Task_Handle ModuleStatusLedHandle;

Task_Params ModuleStatusLedHandleParams;

Error_init(&eb);

Task_Params_init(&ModuleStatusLedHandleParams);

ModuleStatusLedHandleParams.stackSize = 4 * DEFAULT_STACK_SIZE;

ModuleStatusLedHandleParams.priority = TASK_MAX_PRIORITY;

ModuleStatusLedHandleParams.arg0 = IO_MBWDT_MODE;

ModuleStatusLedHandleParams.arg1 = NULL;

ModuleStatusLedHandle =

Task_create((Task_FuncPtr)ModuleStatusLed, &ModuleStatusLedHandleParams, &eb);

When timeout occurs, I am getting as shown below in the console,

What may be the reason for this error ?

Inside timerISRHandler, do I need to clear the timer interrupt? If interrupt clear is required, what API can I use for it?

For resetting timer count register, can I use the code below ?

HWREG(TIMER5_BASE + TIMER_O_TAV)=0;

Regards

Sandra

  • Hi Sandra,

    I split this thread from e2e.ti.com/.../651080 since it is a new question

    The llEnter is an NDK function. It looks like you are trying to call a NDK API from a Hwi or Swi that can only be called from a Task.

    Regarding the timer, you don't need to do any driverlib calls if you use the Timer module in the kernel.

    Todd
  • In reply to ToddMullanix:

    Hi Todd,

    I am part of Sandra's team.

    we have not accessed any NDK API in that task context. we are just trying to delete dynamically created task and re-create dynamic task. if i comment task create its running successful and we are able to get the timer ISR in periodic mode. 

    Is there any timer conflict between NDK and what we used TIMER5? what is default timer used by TI RTOS?

    and also please let me know the API which is used to clear the timer register value to prevent the timeout?

    Regards

    Bala

  • In reply to Balasubramani C:

    Hi Bala,

    Sorry, I read the first post too fast. Can you take a look at this thread to see if it answers your question: e2e.ti.com/.../449914

    Todd
  • In reply to ToddMullanix:

    HI Todd,

    i have gone through the link you provided and i believe the problem is not dynamic task create.

    here i have experimented and recreated the issue with different approach. the sample code is attached here.

    i have used tcpEcho sample project along with trying to user periodic timer module to generate the interrupt in 5 second once. once the timer interrupt occurred, the timer ISR routine post the event to pending task. its working very fine as long as when no Ethernet cable is connected. the execution is breaking the moment Ethernet cable is connected.

    when Ethernet is connected from the beginning of execution, as first timer interrupt itself, execution termination.

    what is the relation between the timer module and NDK?

    here i have attached the code and snapshot.

    tcpEcho.zip

    Regards

    Bala

  • In reply to Balasubramani C:

    Hi Bala,

    The problem is that you are using printf. printf has two issues.

    1. It breaks real-time since when a '\n\' or the printf buffer (CIO) is full, a break-point is hit. CCS reads the contents of the buffer and displays it to the console. Note: this is for TI compiler. The GCC is slightly different but the same real-time issue.

    2. printf uses a lot of stack. It also jumps around and leaves chunks unchanged. So you were getting unlucky. It looks like you have enough stack, but it was really corrupting the things above the stack...the NDK buffers. Note: ROV and the runtime stack check are looking for 0xBEBEBEBE values at the top of the stack. Your call to printf was placing some things on the stack, but then jumping above it (and leaving lots of 0xBEBEBEBE at the top). I bumped the default stack to 1024 and here is your app (minus using DHCP instead of a static IP) task view.

    So, can you try this without printf (or change the printf to System_printf).

    Todd

  • In reply to ToddMullanix:

    Hi Todd,

    Than you for your suggestion. after removing printf, its solved solved the issues in Example tcp_echo project. but if i apply the same thing to my application code, issues remain there.

    in my application code, i dont have any printf or System_printf statement. 

    The timer has created in cfg file and its started in one of the task. here is my timer ISR and followed task code .

    void WatchdogISRHandler()
    {
          Event_post(Event_WDT_Timeout, Event_Id_00);
    }

     

    void WatchdogTaskFxn()
    {
         while(1)

         {
                   /* waiting for event that is posted in timer timeout */
                    Event_pend(Event_WDT_Timeout, Event_Id_00, Event_Id_NONE, BIOS_WAIT_FOREVER);

                    /* Application code */

         }

    }

    here my application code is some mathematical operation and posting an Event or Mailbox to other application task.

    my application code is running perfectly as long as if i comment event post in ISR handler function. if i add event post my application is terminating because of task overflow.

    i have set the task stack size maximum to 10 Kbytes also but still the problem arises.

    find the below debug trace and console error message while system termination.

    find the below detailed task view in ROV. function name and task names are hidden NDA purpose.

    Timer ROV View

    If i add any breakpoints inside WatchdogTaskFxn(), its never reaching. before reaching this function itself Event_pend() itself its termination. 

    can you please help me, what could be the reason of this behavior.

    Regards

    Bala

  • In reply to Balasubramani C:

    You have 4096 for the WatchdogTask, not 10K. Two different things could be happening here.

    1. You are truly blowing the stack. In this case, you need to increase it.

    2. Something is corrupting the top of the stack.

    For either case, can you set a Hardware Watchpoint at the stackbase of the WatchdogTask. Have it break on a read or write. Then run the application. Note, you may hit the breakpoint when the stack is set to 0xBEBEBEBE if you are dynamically creating the stack or running from .cint00 and created the task statically. Simply continue the target. When the top of the stack is changed, you can determine if it is #1 or #2 above. If it is #2, you can see who is corrupting the stack.

    Todd

  • In reply to ToddMullanix:

    Hi Todd,

    I have checked by increasing the stack size. But it didn't help. I am attaching my disassembly view here. I put a break point at the stack base and run. It is not going to that point. The stack base is at 0x20019400.

    I removed the watchdog task and tried to run. Then also stack is getting overflow for the next task having the same stack base. I am attaching the console and the ROV below after removing watchdog task.

    Then I removed the timer module start and stop code from the application. Then it was working fine. The timer module configuration is attached below,

    The code used for starting the timer is given below,

    This condition is not true initially. Then also adding this code leads to stack overflow before doing any operation.. What may be the reason for this problem? Help me to get out of this.

    Thanks & Regards

    Sandra

  • In reply to sandra george78:

    Sandra,

    Do not put a Hardware Breakpoint. Put a Hardware Watchpoint. For example, I have a simple project. Here is the stack for one of the tasks in a memory browser.

    Note the stack (base is 0x200206c0) will grow up (as denoted by the blue arrow) toward the base. I also showed what was before the stack. A common problem it is this block that is over-flowed. So definitely look at what is before your stack.

    To create a Hardware Watchpoint, right-click on the "new breakpoint" arrow in the Breakpoint view and select Hard Watchpoint.

    Then add in the stack base and have it break on a write

    Now run the app. As I noted before, if the stack had not been initialized, the watchpoint will trigger when the 0xbebebebe is written...just continue.

    Once the stack-base is modified (corruption or overflow), the watchpoint will trigger. Simply look to see where you are. For example, I added some code that corrupted the top of the stack. 

    Once the "*ptr = 0x1234" code was executed, the Watchpoint halted the target. It's easy to see where the corruption is occurring now.

    Todd