• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 805 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.

An NDK race condition...

Raymond Mack
Expert 1575 points

We are using networking in five different tasks which were getting configured and setup before we call BIOS_start().  Those tasks would run before the main NDK task gets a chance to run.

We call fdOpenSession() at the beginning of each of those tasks and each would get an OOM (out of memory) error.  Putting in a massive amount of time in a task_sleep() call in those tasks solved the issue.

The better solution is to force the NDK to run as the only task in the system. Here is the sequence:

1) Init all hardware in main() while the system is still in "bare metal" mode. Configure all the pins and enable all of the GPIO subsystems you will use

2) Configure the NDK to hook network start.  We use a function called netOpenHook()

3) Call BIOS_start() which will kick off the RTOS with the NDK task as the only useful task running.

4) in netOpenHook() configure all of your real tasks for the system and start them running. That made our tasks work without having any task_sleep() calls before fdOpenSession(). Remember to click the obscure radio button in the BIOS configuration that lets you dynamically create tasks. If you do not turn on dynamic task creation using the XDC system, you will get incomprehensible error messages as your first task dies a horrible death for no apparent reason.

This ensures that the race conditions from the NDK setting up all of its data structures as well as the hardware initialization that happens "under the covers" will happen before any of your tasks start using those resources.

I would appreciate any words of wisdom if this solution has any issues from other hidden sequences.

  • 0
    TI__Mastermind 21645 points

    Hi Raymond,

    The sequence you described looks correct except that you should be creating the app's networking tasks in the networkIPAddrHook function instead of the networkOpenHook function. By the time the IPAddrHook() function is called, it is guaranteed the NDK stack is init'ed and ready.

    If you would like to create the app's networking tasks statically, then another alternative would be to pend on a semaphore at the beginning of each of the task functions and then post the semaphore to unblock these tasks from within the netIPAddrHook function.

    Here's an example showing how to register a netIPAddrHook:

    *.cfg:
var Global = xdc.useModule('ti.ndk.config.Global');
Global.networkIPAddrHook = '&myIPAddrHook';

*.c:
Void myIPAddrHook(IPN IPAddr, uint IfIdx, uint fAdd)
{
    ....
}

    Best,

    Ashish