Proper NDK and Task Priority

npb17

Other Parts Discussed in Thread: TMS320C6472, SYSBIOS

Hi,

I am using CCSv4.2.1 with XDC 3.20.8.88, SYSBIOS 6.30.3.46, NDK 2.20.4.26, and IPC 1.21.2.23 for the TMS320C6472 evaluation board.

I have two cores running on the board. One core (core 0) handles all Ethernet communication and routes data as needed to the other core (core 1) via IPC. I split the data routing on core 0 into two Tasks of equal priority as follows:

eth_msg_parse() : Receiving Ethernet packets and sending data to core 1

messageQ_msg_parse() : Receiving MessageQ messages from core 1 and sending out Ethernet packets

I am trying to determine the best priority for these two tasks in relation to the NDK network function, which I have called runNetwork(). runNetwork() is where NC_SystemOpen() and NC_NetStart() are called. A screenshot of my current Task settings from ROV is shown below:

This setup seems like it works alright, but periodically Ethernet communication doesn't work when I reset the DSP. I am wondering if this has to do with the priority of runNetwork() in relation to eth_msg_parse() and messageQ_msg_parse(). If runNetwork() is lower priority than the normal BIOS Tasks, will Ethernet protocols like responding to ping requests be preempted by the Tasks? The main problem I am seeing is that the DSP will stop responding to Ethernet packets altogether at some point. (My main test of whether Ethernet is working or not is just pinging the board to ensure it's still responding.)

So, is there anything wrong with runNetwork() having a priority of '2' when normal BIOS Tasks have higher priority?

Thanks,

Nick

over 14 years ago

0 Steven Connell over 14 years ago

TI__Mastermind 45025 points

Hi Nick,

Nick Bedbury78040 said:
If runNetwork() is lower priority than the normal BIOS Tasks, will Ethernet protocols like responding to ping requests be preempted by the Tasks?

Yes, if they are of higher priority than the NDK tasks that are responding to pings. The NDK is synchronized via thread priorities. How this works is that all "NDK Tasks" (created via NDK API TaskCreate()) are prioritized relative to the network scheduler thread. This allows all NDK threads and the NDK scheduler thread to work well with each other. Additionally, since thread priority is used for synchronization, It also prevents any NDK thread from starving other non-NDK threads you have running in your system.

What priority did you pass to the NC_SystemOpen() function call?

Nick Bedbury78040 said:
The main problem I am seeing is that the DSP will stop responding to Ethernet packets altogether at some point. (My main test of whether Ethernet is working or not is just pinging the board to ensure it's still responding.)

This could be an issue. Is it true that you can never communicate via Ethernet with the board again? Or is the stack simply unresponsive for a while, and then eventually it starts responding again?

Nick Bedbury78040 said:
So, is there anything wrong with runNetwork() having a priority of '2' when normal BIOS Tasks have higher priority?

You could be running into a starvation issue. Again, I'd be curious to see what priority you passed to the NC_SystemOpen() function.

Steve

0 npb17 over 14 years ago in reply to Steven Connell

Expert 1615 points

This is basically my runNetwork() function, which starts with priority 6, then takes on NC_PRIORITY_LOW = 2.

void runNetwork() {

rc = NC_SystemOpen( NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT );

// Create new configuration for NDK

do{

rc = NC_NetStart( hCfg, NetworkOpen, NetworkClose, NetworkIPAddr );

} while( rc > 0);

// Close NDK

}

Then, NetworkOpen() creates the two tasks described previously with priority OS_TASKPRINORM = 5.

static void NetworkOpen() {

// Create BIOS task to handle receiving Ethernet messages

hEthParse = TaskCreate(eth_msg_parse, "&eth_msg_parse", OS_TASKPRINORM, OS_TASKSTKNORM, 0, 0, 0);

fdOpenSession(hEthParse);

// Create BIOS task to handle creating outgoing Ethernet messages

hMessageQParse = TaskCreate(messageQ_msg_parse, "&messageQ_msg_parse", OS_TASKPRINORM, OS_TASKSTKNORM, 0, 0, 0);

fdOpenSession(hMessageQParse);

}

When the problem occurs, I generally cannot communicate via Ethernet again without powering off the board and reloading the executable files. However, I have never waited more than a few minutes to see if the board responds again after a delay. I should note though that this Ethernet problem may be related to issues on the other core. I am still debugging both projects and I think the core 1 may stall and cause core 0 to stop functioning.

Since both SYSBIOS tasks have blocking function calls in them (eth_msg_parse blocks on a socket and messageQ_msg_parse blocks on MessageQ), I believe the NDK is able to operate correctly during the gaps when both tasks are blocked. I have run the code with NC_PRIORITY_HIGH and there is no difference in the functionality. However, when running with NC_PRIORITY_LOW, if either task ran continously without blocking, the NDK would never execute since the running task would take precedence due to higher priority.

Nick

0 Steven Connell over 14 years ago in reply to npb17

TI__Mastermind 45025 points

Nick,

Are you running a continuous ping command to the board? This is a good way to see when the stack stops responding and if/when it picks back up.

Nick Bedbury78040 said:
However, when running with NC_PRIORITY_LOW, if either task ran continously without blocking, the NDK would never execute since the running task would take precedence due to higher priority.

Here's a little tidbit I just saw in the NDK user's guide that's pertinent to this:

"The scheduler priority (relative to network application thread priority) affects how network applications can
be programmed. For example, when running the scheduler in low priority, a network application cannot
poll for data by continuously calling recv() in a non-blocking fashion. This is because if the application
thread never blocks, the network scheduler thread never runs, and incoming packets are never processed
by the NDK."

But as you said, your tasks are blocking so I think you should be ok, but can you just double check that your app is following the above guideline?

Also:

"Running the scheduler thread at a low priority places certain restrictions on how a task can
operate at the socket layer. For example:
· If a task polls for data using the recv() function in a non-block mode, no data is ever received
because the application never blocks to allow the scheduler to process incoming packets.
· If a task calls send() in a loop using UDP, and the destination IP address is not in the ARP table,
the UDP packets are not sent because the scheduler thread is never allowed to run to process the
ARP reply.
These cases are seen more in UDP operation than in TCP. To make the TCP/IP behave more like
a standard socket environment for UDP, the priority of the scheduler thread can be set to high
priority. See Chapter 4 for more details on network event scheduling."

Nick Bedbury78040 said:
I should note though that this Ethernet problem may be related to issues on the other core. I am still debugging both projects and I think the core 1 may stall and cause core 0 to stop functioning.

Is there a way you could make a test version of your app in which you only run on one core but simulate receiving the data from another core? For example, just have a task that sends the data the the network task? This would help eliminate the multi-core part from the variables list.

Steve

0 npb17 over 14 years ago in reply to Steven Connell

Expert 1615 points

I have Ethernet communication working again. The main solution was to remove RTA, Load, RTDX, and LoggerBuf. I'm not sure if I declared the RTSC modules improperly or if it was an issue of the NDK PRD timing interfering with RTA. I've got another forum post related to that issue.

http://e2e.ti.com/support/embedded/f/355/p/140745/512062.aspx#512062

Thanks for answering my questions about Task priority.

Nick

Processors

Processors forum

Proper NDK and Task Priority