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.

TM4C1294NCPDT: NDK task not pre-empting application task

Part Number: TM4C1294NCPDT

Hello,

I am building an application based on the TI RTOS tcpEcho example where the tcpWorker task, upon being called, posts a semaphore that then enabled another application task to run. For the sake of the exercise I've made the called application task contain an infinite loop (the task never completes.) I want to know how to make it such that the tcpWorker task can preempt the application task while the application task is running. I've made my application task have priority 1 in the config file but the tcpWorker task still never runs while the applicatoin task is running. What do I need to do to make tcpWorker preempt the application task? (see code snippets below.)

Void tcpWorker(UArg arg0, UArg arg1)
{
    int  clientfd = (int)arg0;
    int  bytesRcvd;
    int  bytesSent;
    char buffer[TCPPACKETSIZE];

    System_printf("tcpWorker: start clientfd = 0x%x\n", clientfd);

    Semaphore_post(semaphore0);

    while ((bytesRcvd = recv(clientfd, buffer, TCPPACKETSIZE, 0)) > 0) {
        bytesSent = send(clientfd, buffer, bytesRcvd, 0);
        if (bytesSent < 0 || bytesSent != bytesRcvd) {
            System_printf("Error: send failed.\n");
            break;
        }
    }
    System_printf("tcpWorker stop clientfd = 0x%x\n", clientfd);

    close(clientfd);
}

//......

void Task_0_Fxn(void){
    while(1){
        Semaphore_pend(semaphore0, BIOS_WAIT_FOREVER);
        while(1){
            //...
        }
    }
}

Thank you

  • Hi,

    Can you look in Tools->ROV->Tasks->Detailed to see what the states of the tasks are and to see all the priorities at once also. Also check out the Semaphores in ROV to see if semaphore0 was posted.

    If you are using SysMin in the .cfg file, you can view the output here also in ROV->SysMin->Data Buffer (or something close to that...I'm not on my work PC so I cannot verify the exact name).

    Todd
  • Hi Todd,

    I know that the semaphore0 is posted because the infinite loop in Task_0_Fxn starts executing after the first ethernet transmission to the controller (there's code in the infinite loop that I did not paste here) and the controller echos back what it was given over ethernet (tcpWorker does its thing.) The issue is that subsequent ethernet transmissions (while the Task_0_Fxn infinite loop is running) never get an echo back from the controller which means that the tcpWorker task does not run to completion for subsequent ethernet transmissions. This makes me think that the tcpWorker task is unable to preempt task0 due to priority.

    Using ROV I am able to see all tasks and their priorities. task0 has a lower priority than the "NDK Stack Thread" - this means that it should run? Or are their priority values not comparable?

    The two tasks are also listed "ready."
  • If both threads are "ready" then something with a higher priority is running. What is running? A higher priority task or Swi or Hwi? You can look in ROV->BIOS->Module under the currentThreadType to see which type of thread is currently running and then at thread (e.g. Hwi, Swi or Task) to see which individual one is running.

    Note: priority 1 is the lowest priority (other than idle which is 0).
  • Hi Todd,

    I apologize, I was not using ROV properly. I put a break point in the infinite while loop in Task_0_Fxn and as soon as the controller reaches that break point, the ROV Task window looks like this: 

    Does this seem "correct"? Why are tcpHandler and tcpWorker downgraded to priority 1? Also, why are all the NDK tasks blocked?

    Thank you

    EDIT: properly inserted image

  • How did you create tcpHandler and tcpWorker? The default priority is 1 if you don't explicit set it in the parameters passed into the Task_craete (or Task_construct).

    Since Task_0 is in an infinite loop, there are no context switches to tasks that have the same or lower priority.

    Todd
  • Todd,

    I did not change any of the settings in tcpWorker and handler - they are exactly as they come in the tcpEcho example. How can I raise the priority of these tasks? Also, why is NDK Stack Thread also blocked if it is priority 2 (2>1)? In the TI-RTOS -> Products -> NDK -> Network Scheduling options tab in the config file the Network Task Priority levels are 3,5,7 and 9 (Default.) Shouldn't they thus preempt the lowest priority Task0?

    Thank you
  • tcpHandler creation code

        Task_Params_init(&taskParams);
        taskParams.stackSize = TCPHANDLERSTACK;
        taskParams.priority = 1;
        taskParams.arg0 = TCPPORT;
        taskHandle = Task_create((Task_FuncPtr)tcpHandler, &taskParams, &eb);

    tcpWorker creation code no explicit setting of priority so it gets the default of 1

        Task_Params_init(&taskParams);
        taskParams.arg0 = (UArg)clientfd;
        taskParams.stackSize = 1280;
        taskHandle = Task_create((Task_FuncPtr)tcpWorker, &taskParams, &eb);

    The NDK stack is blocked probably waiting for input from the Ethernet driver. It is not blocked by task_0. When data comes in the Ethernet, it will unblock, process the data and then go back to block waiting for more data to receive (or send). 

    The priorities of the NDK are discussed in the NDK User Guide (section 3.1.2.1). 

    The basic problem is that you added another task that is in an infinite loop so it will starve other tasks at that level and lower. If you move tcpWorker and tcpHandler up a level, the problem should go away.

    Todd

  • Todd, thank you. Changing those priorities to a higher lever than 1 solved this issue.