NDK task priorities vs. application task priorities

John Conover

Other Parts Discussed in Thread: SYSBIOS, CCSTUDIO

Hi,

We are running SYS/BIOS with NDK on our production board using the CPSW interface. Our current software versions:

Processor AM3352
Code Composer Version: 6.0.1.00040
Compiler TI v5.1.6
SYS/BIOS 6.40.3.39
XDCTools 3.30.3.47_core
NDK 2.24.0.11

System Analyzer (UIA Target) 1.3.1.08

We currently are running a fixed IP address with four TCP sockets being created and serviced by four different tasks. The tasks are priorities of 7, 6, 6 and 6. The NDK task priorities are:

What we don't understand is the interaction of the NDK against our applications. We have read the other questions about NDK tasks and how it uses the priorities to insure correct operation from it's stand point. From the applications standpoint we have no idea what type of things the NDK will put at medium and low priorities which will be held off by our own higher priority tasks. The NDK documentation does not cover what tasks it creates and what their priorities will be. It seems without this knowledge we can not understand how our system will behave under heavy network load.

Is there better documentation or some other information that could help us?

Thanks,

John C.

over 9 years ago

0 Ashish Kapania over 9 years ago

TI__Mastermind 21645 points

Hi John,

In order to understand how NDK interacts with your application's networking tasks a good understanding of NETCTRL module is important. The NETCTRL module manages event scheduling in NDK (implements the NetScheduler() function). If you've not already done so, I would recommend reading Chapter 4 of the NDK user guide (Section 4.2 in particular). This chapter explains the event scheduler operation and the different modes the NetScheduler() can be run in (at a low/high priority and in interrupt/polling mode). Understanding the different scheduler modes will help choose the right mode for your particular application. It should also help figure out what priority the application network tasks need to run at.

I have listed the different kinds of tasks (along with their description) that NDK creates below:

Main NDK Task: This is the main NDK task. (switches to NetScheduler priority once the event scheduler starts running)
Boot Task: This task is responsible initialization activities and is terminated once it is completed. (Normal Pri task)
DHCP Client Task (if the DHCP Client is used): This task makes the initial DHCP request and subsequent lease renewals. (Normal Pri task)
DaemonNew calls: This task is created as a result of the application calling DaemonNew(). The NDK's HTTP and Telnet servers also call this function. (Priority passed by caller)
dchild Tasks: A daemon creates a dchild task to handle new activity on a socket.
DHCP Server Task (if the DHCP Server is used): This task processes DHCP requests. (Normal Pri task)
DNS Server Task (if the DNS Server is used): This task processes DNS requests. (Normal Pri task)
Tools Services: Example code in the packages\ti\ndk\tools directory creates tasks also.

Based on what features your application uses, you can look at the source code to determine if NDK creates any worker tasks/daemons and what their priorities are. For instance, lets say your app is using the HTTP server module. If you look at the httpOpen() function (in http.c), you will see that a daemon with normal priority is created.

Please note that the NDK tasks/daemons may enter a mode called kernel mode (explained in Chapter 4 of the user guide) to ensure re-entrancy. When running in kernel mode, the task priority is temporarily elevated to kernel priority.

Here's a link to an old FAQ that may also be useful:

http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ#Q:_I_checked_the_troubleshooting_section_in_the_User.27s_Guide_but_NDK_still_cannot_communicate_properly._Is_this_a_priority_issue_between_my_application_and_the_NDK.3F

Hope this helps.

Best,

Ashish

0 Ralf Goebel over 9 years ago

Genius 3715 points

Hi,

please note that the network scheduler will not run with the value entered in the high priority level field. Instead it always uses the default value minus one, which is 3-1=2 for the low priority setting and 9-1=8 for for the high priority setting.

I already pointed this out here, but I didn't get any response.

Ralf

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hi Ashish,

I did carefully read section 4.4.2 before, but to be honest it did not help. In systems we've used in the past the stack code priority was never intermixed with application code priority (it was always higher.) In these systems there was never a question or problem of having communication disrupted by a running task. When the overall system allows such intermixing of priorities it will allow more flexibility, but it also complicates how the system will operate under load and forces you to know far more detailed information about the stack (which is usually a black box) to properly architect your application task priorities. As a system designer you need to be able to track data flow into and out of the system and how it effects your system. Your post is the first time I've seen what NDK schedules and at what priorities (so it is very helpful.)
So for our application only sitting on sockets and possibly running the DHCP client, the only thing on your list seems to be dchild daemons. Would these daemons be running/active while my application code is sitting on a recv() call (would they show up on the task listing under the ROV?) It also seems that we should probably insure that our application code is lower than the NDK's "Normal" priority if we don't want our own tasks to interfere with packet delivery to the socket. Would you agree?
I did also see the FAQ link you mentioned and there were some useful pieces but maybe you guys should just make an official list of possible NDK tasks/daemons and what their priorities would be.

Thanks,
John C.

0 John Conover over 9 years ago in reply to Ralf Goebel

Genius 4350 points

Hi Ralf,

We are basing our code off of the Industrial SDK example in am335x_sysbios_ind_sdk_1.1.0.5/sdk/examples/ethernetip_adapter/eip_ndk.c. They are doing the NC_SystemOpen() call there. The NC_SystemOpen is called with high priority, but it seems you question whether it actually effects the scheduler. Did you check this using ROV in the debugger?

Thanks,
John C.

void NDKACD_stackThread(UArg arg0, UArg arg1)
{
Clock_Params clockParams;
int rc;

/* Create the NDK heart beat */
Clock_Params_init(&clockParams);
clockParams.startFlag = TRUE;
clockParams.period = 200; /*Period set to 200 as we have 500microsec tick period*/

// JC, we are running a 5msec tick period so to match the example code we would want
// a 200/10 = 20 period.
clockParams.period = 200;
Clock_create(&llTimerTick, clockParams.period, &clockParams, NULL);

/* THIS MUST BE THE ABSOLUTE FIRST THING DONE IN AN APPLICATION!! */
rc = NC_SystemOpen(NC_PRIORITY_HIGH, NC_OPMODE_INTERRUPT);
if (rc) {

}

/* Create and build the system configuration from scratch. */
hCfg = CfgNew();
if (!hCfg) {
goto main_exit;
}
..........

0 Ralf Goebel over 9 years ago in reply to John Conover

Genius 3715 points

Hi John,

yes, I checked the priorities on a C6678 device using ROV. But maybe it's different in your application.

The problem is that NC_PRIORITY_HIGH is defined as OS_SCHEDULER_HIGHPRI in netctrl.h, which is then defined as (_oscfg.TaskPriKern-1) in osif.h. When calling NC_SystemOpen(), _oscfg is normally only initialized with default values (see ossys.c), because this function must be called first. NC_SystemOpen() will store the "priority" parameter with the default value in a static variable ("static int SchedulerPriority" in netctrl.c). Changing the priority level after NC_SystemOpen() has no effect on the scheduler priority because NetScheduler() will use the original value as priority.

Additionally, when configuring the NDK using XCONF, the first parameter for NC_SystemOpen() has to be NC_PRIORITY_LOW or NC_PRIORITY_HIGH. It can't be changed to an arbitrary value.

Ralf

0 John Conover over 9 years ago in reply to Ralf Goebel

Genius 4350 points

Ralf,

Thanks for the info. I reviewed your comments and it seems like everything should be ok with the priority. We have seen once or twice a night where there is a sudden delay in our unit responding to a request (like over a second.) I'm modifying the task priorities so that the NDK's NORMAL and HIGH setting are above all our applications as a test run to see if any of our tasks are getting tangled with NDK and causing the occasional burp.

Thanks again,
John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

John Conover said:

So for our application only sitting on sockets and possibly running the DHCP client, the only thing on your list seems to be dchild daemons. Would these daemons be running/active while my application code is sitting on a recv() call (would they show up on the task listing under the ROV?) It also seems that we should probably insure that our application code is lower than the NDK's "Normal" priority if we don't want our own tasks to interfere with packet delivery to the socket. Would you agree?

That is right. If your network tasks have a high CPU utilization and are running at a higher priority than the network scheduler and NDK daemons (dchilds), it is possible that the NDK scheduler (and daemon tasks) are starved of CPU time and are unable to process the network events fast enough. In such a scenario, you would want to either optimize your tasks and lower their CPU util or lower the priority of your tasks below NDK scheduler's priority (and normal NDK priority). I would also suggest raising the NDK scheduler priority to high.

All the dameons/dchilds created by NDK should be visible in ROV's task view. So, if you want to determine what all tasks/daemons are being created by NDK, one way would be to look at ROV once the system is running.

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

I modified the NDK task priorities to 18, 15, 12 and 9 (Kern to Low) and set the number of task priorities to 32. The pings are now erratic ranging from <1msec to 150msec or more. I've completely rebuilt the project but the NDKACD_stackThread is still showing up as a priority of 8. Have I done something illegal or do I need to rebuild the NDK ?

Thanks,

John C.

0 John Conover over 9 years ago in reply to John Conover

Genius 4350 points

Ashish,

It seems the ping being erratic is because one of our main tasks that processes data is set to an 8, which is conflicting with the NDKACD_stackThread. Why is NDKACD_stackThread priority staying at an 8 when I have increased the NDK task priorities?

Thanks,
John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

There is a known bug in NDK due to which the updated configuration values are not visible in NC_SystemOpen() function as it is called very early. Since NC_SystemOpen() is responsible for setting up the scheduler priority, it ends up using the old value. For NC_PRIORITY_HIGH the old value would be (OS_TASKPRIKERN - 1) or (9 -1 = 8).

We already have a bug filed for this issue: SDOCM00086985 NDK configuration values do not apply in NC_SystemOpen

You could work around this issue by updating ti/ndk/netctrl/netctrl.c file as follows and rebuilding NDK library:

int NC_SystemOpen( int Priority, int OpMode )
{
    HANDLE  hSem = 0;

    /* Open the low-level enironment */

    /* Set the network scheduler priority */
    // !!! REMOVE CHECK !!!
    //if( Priority != NC_PRIORITY_LOW &&  Priority != NC_PRIORITY_HIGH )
    //    return(NC_OPEN_ILLEGAL_PRIORITY);

    // !!! REMOVE ASSIGNMENT !!!
    //SchedulerPriority = Priority;

    /* Check the operating mode */
    if( OpMode != NC_OPMODE_POLLING && OpMode != NC_OPMODE_INTERRUPT )
        return(NC_OPEN_ILLEGAL_OPMODE);

    /* Polling at high priority is illegal */
    // !!! REMOVE CHECK !!!
    //if( Priority==NC_PRIORITY_HIGH && OpMode==NC_OPMODE_POLLING )
    //    return(NC_OPEN_ILLEGAL_OPMODE);

    /* Intialize the task environment */
    _TaskInit();

and

/* ARGSUSED */
static void NetScheduler( uint const SerialCnt, uint const EtherCnt )
{
    register int fEvents;

    /* Set the scheduler priority */
    // !!! UPDATE SCHEDULER PRIORITY !!!
    //TaskSetPri( TaskSelf(), SchedulerPriority );
    TaskSetPri( TaskSelf(), 14 ); // Replace SchedulerPriority with desired pri

    /* Enter scheduling loop */
    while( !NetHaltFlag )
    {

I also wanted to check with you that are you using XGCONF or C code to configure NDK ? I have a doubt because I saw an earlier post of yours where you shared C code for a stackThread() that calls NC_SystemOpen() and create a new cfg. If you are using C code then I believe you need to add a CfgEntry to update the different default NDK priorities.

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

The NDKACD_stackThread() function in eip_ndk.c file was copied directly from C:\ti\am335x_sysbios_ind_sdk_1.1.0.5\sdk\examples\ethernetip_adapter example. The only modifications that were made were to eip_main.c and eip_ndk.c for the DHCP/Static IP address setting and the NDK heartbeat timer clock create call (our sys/bios system is running a 5msec heartbeat). We originally had been using methods from the same example but in sdk 1.1.0.4, but were told for link state changes to work correctly we should use the 1.1.0.5. So we still configure NDK settings (task priorities, number of buffers, etc..) via Code Composer but use the files from sdk 1.1.0.5 for setup of IP addresses.
I'll try to rebuild the NDK this morning to see if the task priorities will work correctly.
Thanks,
John C.

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

I copied the ndk_2_24_00_11 directory, renamed it, made your changes and rebuilt it. I'm having issues with Code Composer recognizing the new NDK as being installed. I can add it under the Projects RTSC "other repositories", but it will not show up under RTSC->NDK repositories and the Project configuration does not show an NDK there. Once the NDK is rebuilt, is there a specific way to get Code Composer to recognize it?

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

Have you tried finding the product through product discovery ? Basically you need to click on Windows->Preferences menu item. In the preferences window, go to "Code Composer Studio"->"RTSC"->"Products" tab. Add the path to the newly built ndk directory in the project discovery path section and then click on "search now". A new window with all newly discovered products should open up. Next you need to select the newly built ndk and hit finish. This should install it.

Best,
Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Tried it but it does not find the new 2.24.0.11_copy.

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

I think I figured out why the rebuilt copy is not showing up. You need to uninstall NDK 2.24.0.11 first. In the above window, if you click on NDK 2.24.0.11, you will get an option to uninstall the product. Once the product is uninstalled, click on "search now" again and both the copy and original NDK 2.24.0.11 should show up in the discovered products window.

Best,
Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,
That definitely fixed that problem. I'm currently looking into why I'm getting a:

xdc.PACKAGE_NOT_FOUND: can't locate the package 'ti.ndk.config' along the path: '
C:/ti/uia_1_03_01_08/packages;
C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;
C:/ti/ccsv6/ccsv6/ccs_base;
C:/ti/bios_6_40_03_39/packages;
C:/ti/nsp_1_10_02_09/packages;
C:\ti\ccsv6\xdctools_3_30_03_47_core\packages;
'. Ensure that the package path is set correctly. airtrac.cfg /AIRtrac_sysbios Configuration Validation XDCTools Configuration Marker

Seems like the path C:\ti\ndk_2_24_00_11_rebuild/packages is not there.

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Is the NDK product selected in "project->properties->products and repositories" ? Also, can you share the complete build log ?

Best,
Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

The repository is selected. Which log file are you looking for?

John C.

**** Build of configuration Debug for project AIRtrac_sysbios ****

"C:\\ti\\ccsv6\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../airtrac.cfg'
'Invoking: XDCtools'
"C:/ti/ccsv6/xdctools_3_30_03_47_core/xs" --xdcpath="C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11_copy/packages;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug" "../airtrac.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring airtrac.xea8fnv from package/cfg/airtrac_pea8fnv.cfg ...
js: "C:/Users/..../workspace_v6_1/AIRtrac_sysbios/airtrac.cfg", line 25: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND: can't locate the package 'ti.ndk.config' along the path: 'C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11_copy/packages;C:/ti/ccsv6/xdctools_3_30_03_47_core/packages;..;'. Ensure that the package path is set correctly.
"./package/cfg/airtrac_pea8fnv.cfg", line 195
gmake.exe: *** [package/cfg/airtrac_pea8fnv.xdl] Error 1
Warning: directory "C:/ti/ndk_2_24_00_11_copy/packages" on package path does not exist
js: "C:/ti/ccsv6/xdctools_3_30_03_47_core/packages/xdc/tools/Cmdr.xs", line 51: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.
making ../src/sysbios/sysbios.aea8fnv ...
gmake[1]: Entering directory `C:/Users/jconover/workspace_v6_1/AIRtrac_sysbios/src/sysbios'
clea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/BIOS.c ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/IntrinsicsSupport_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/TaskSupport_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/exc/Exception_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/a8/TimestampProvider_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/a8/Mmu_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/a8/Cache_asm.asm ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/a8/intcps/Hwi_asm.s470 ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/family/arm/a8/intcps/Hwi_asm_switch.s470 ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/timers/gptimer/Timer_asm.s470 ...
asmea8fnv C:/ti/bios_6_40_03_39/packages/ti/sysbios/timers/dmtimer/Timer_asm.s470 ...
area8fnv BIOS.obj arm_IntrinsicsSupport_asm.obj arm_TaskSupport_asm.obj exc_Exception_asm.obj a8_TimestampProvider_asm.obj a8_Mmu_asm.obj a8_Cache_asm.obj intcps_Hwi_asm.obj intcps_Hwi_asm_switch.obj gptimer_Timer_asm.obj dmtimer_Timer_asm.obj ...
gmake[1]: Leaving directory `C:/Users/.../workspace_v6_1/AIRtrac_sysbios/src/sysbios'
gmake: Target `all' not remade because of errors.

**** Build Finished ****

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

It looks like the "package repositories" still has the old product name ndk_2_24_0_11_copy though the product is now called ndk_2_24_0_11_rebuild in your setup.

gmake.exe: *** [package/cfg/airtrac_pea8fnv.xdl] Error 1

Warning: directory "C:/ti/ndk_2_24_00_11_copy/packages" on package path does not exist

Can you look at the "package repositories" in your project and share a screenshot ? Here's an example screenshot showing what I am looking for.

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

Sorry to keep asking but where are NSP_INSTALL_DIR, BIOS_CG_ROOT and COMM_TI_UIA_INSTALL_DIR defined? I've look in every possible project properties configuration and searched every file in the project directory and can't locate these.

Thanks,

John C.

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,
The error is with my modifications to the ndk.mak file. I had the wrong XDC_INSTALL_DIR set. I corrected it, but the build can't find my Java Virtual Machine. I'll let you know when I get it to build.
Thanks,
John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

Variables like NSP_INSTALL_DIR, BIOS_CG_ROOT and COMM_TI_UIA_INSTALL_DIR can be found in "project properties -> Build" window's "variables" tab:

Make sure you select "Show system variables" at the bottom. It is not selected by default and unless it is selected no variables will show up.

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

Finally got the ndk to rebuild (Java VM path would not set correctly until the PC was rebooted.) I still can't get the system to build as the original "ndk_2_24_00_11_copy" directory seems to be stuck in the path. I've checked in the Variables configuration window and everything is good in there. Where is the incorrect path coming from?

Thanks,

John C.

**** Build of configuration Debug for project AIRtrac_sysbios ****

"C:\\ti\\ccsv6\\ccsv6\\utils\\bin\\gmake" -k all

'Building file: ../airtrac.cfg'

'Invoking: XDCtools'

"C:/ti/ccsv6/xdctools_3_30_03_47_core/xs" --xdcpath="C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11_copy/packages;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug" "../airtrac.cfg"

making package.mak (because of package.bld) ...

generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...

configuring airtrac.xea8fnv from package/cfg/airtrac_pea8fnv.cfg ...

js: "C:/Users/jconover/workspace_v6_1/AIRtrac_sysbios/airtrac.cfg", line 25: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND: can't locate the package 'ti.ndk.config' along the path: 'C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11_copy/packages;C:/ti/ccsv6/xdctools_3_30_03_47_core/packages;..;'. Ensure that the package path is set correctly.

"./package/cfg/airtrac_pea8fnv.cfg", line 195

gmake.exe: *** [package/cfg/airtrac_pea8fnv.xdl] Error 1

Warning: directory "C:/ti/ndk_2_24_00_11_copy/packages" on package path does not exist

js: "C:/ti/ccsv6/xdctools_3_30_03_47_core/packages/xdc/tools/Cmdr.xs", line 51: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.

making ../src/sysbios/sysbios.aea8fnv ...

gmake[1]: Entering directory `C:/Users/.../workspace_v6_1/AIRtrac_sysbios/src/sysbios'

.....

area8fnv BIOS.obj arm_IntrinsicsSupport_asm.obj arm_TaskSupport_asm.obj exc_Exception_asm.obj a8_TimestampProvider_asm.obj a8_Mmu_asm.obj a8_Cache_asm.obj intcps_Hwi_asm.obj intcps_Hwi_asm_switch.obj gptimer_Timer_asm.obj dmtimer_Timer_asm.obj ...

gmake[1]: Leaving directory `C:/Users/.../workspace_v6_1/AIRtrac_sysbios/src/sysbios'

gmake: Target `all' not remade because of errors.

**** Build Finished ****

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Ashish,
Because the xdcpath still seems to have "C:/ti/ndk_2_24_00_11_copy/packages" in it, even thought I've gone back to the original NDK, I can no longer build the project. Do you have any idea why "--xdcpath=" is not changing?
Thanks,
John C.

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

When I look in the .cproject file at the top level of the project directory tree I can see the incorrect path being shown under the fileInfo id. When I look under the project properties CCS Build-->XDCTools, the xdcpath looks correct. Should I repost this over in the Code Composer forum?

Thanks,

John C.

.cproject---------------------------------------------------------------------------

</option>

</tool>

</inputType>

</tool>

</fileInfo>

----------------------------------------------------------------------------------------------------

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Ashish,

Finally tried the build that incorporates your suggested changes to fix the priority of the NDK. It does not seem to have work as building with the modified NDK still shows the "User's NDK Stack Thread" priority of an 8. Could there be another reason the priority is not being correctly set?

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

I am assuming you were finally able to use the rebuilt NDK library to build the project ? Just to verify the correct version is being used, can you put a breakpoint in the NetScheduler() function and the single step till TaskSetPri() is called. At this point just check that the scheduler priority is the same as what you set. If the priority is correct, once the app returns from the TaskSetPri() function, the netScheduler task's priority should be the elevated value.

Can you also share the NDKACD_stackThread() function you are using in your app ?

Going back to a question from one of your older posts about modifying "--xdcpath". This can be done through project properties:

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

It looks like the NDK task priorities are still not being used. If I look at the configuration setting I can see that the new number are there:

The Cfg script looks like it is also carrying the correct information:

--------------------------------------------------------------------------------------

Global.IPv6 = false;
Semaphore.supportsEvents = false;
Global.netSchedulerPri = Global.NC_PRIORITY_HIGH;
Global.highTaskPriLevel = 15;
Global.kernTaskPriLevel = 18;
Global.ndkThreadStackSize = 16384;
Global.lowTaskStackSize = 8192;
Global.normTaskStackSize = 8192;
Global.highTaskStackSize = 8192;
Global.ndkThreadPri = 11;

Global.stackThreadUser = "&NDKACD_stackThread";
Ip.autoIp           = false;
Ip.CallByIP           = false;
Ip.ResolveIP       = false;
Ip.dhcpClientMode   = 1;
Ip.address           = "192.168.9.200";
Ip.mask               = "255.255.0.0";
Ip.ifIdx           = 1;
Global.debugPrintLevel = Global.DBG_ERROR;
Exception.excStackSize = 8192;
Task.numPriorities = 32;
Global.normTaskPriLevel = 12;
Global.lowTaskPriLevel = 10;
Clock.swiPriority = 15;
--------------------------------------------------------------------

When we reach the TaskSetPri you can see that the priority of 11 is incorrect (look at the Diassembly side):

After the TaskSetPri() call the priority is an 8:

Not sure why there is still an issue here. I've attached the NDKACD_stackThread() function as you requested. I also had to modify the .cproject file as I've outlined in the Code Composer thread as I never received a response to my question about getting Code Composer to recognize the modified NDK build:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/396293

I beginning to think that Code Composer is not doing what it says. Is there a way to verify the NDK? A version number I could build into it to insure that it is the one being used?

Thanks,

John C.

/**
* \name NDKACD_stackThread
* \brief Main NDK Thread
* \param arg0 Argument if any
* \return none
*
*/
void NDKACD_stackThread(UArg arg0, UArg arg1)
{
    Clock_Params clockParams;
    int rc;

    /* Create the NDK heart beat */
    Clock_Params_init(&clockParams);
    clockParams.startFlag = TRUE;
    //clockParams.period = 200; /*Period set to 200 as we have 500microsec tick period*/

    // JPC, we are running a 5msec tick period so to match the example code we would want
    // a 200/10 = 20 period.
    clockParams.period = 20;
    Clock_create(&llTimerTick, clockParams.period, &clockParams, NULL);

    /* THIS MUST BE THE ABSOLUTE FIRST THING DONE IN AN APPLICATION!! */
    rc = NC_SystemOpen(NC_PRIORITY_HIGH, NC_OPMODE_INTERRUPT);
    if (rc) {

    }

    /* Create and build the system configuration from scratch. */
    hCfg = CfgNew();
    if (!hCfg) {
        goto main_exit;
    }

    /* add the Tcp module configuration settings. */
    ti_ndk_config_tcp_init(hCfg);

    /* Do EIP Application specific Init*/
    EIPACDInit();

    /*
     * Boot the system using this configuration
     *
     * We keep booting until the function returns 0. This allows
     * us to have a "reboot" command.
    */
    do {

       EIPACDStart();
        rc = NC_NetStart(hCfg, ti_ndk_config_Global_NetworkOpen,
                         ti_ndk_config_Global_NetworkClose,
                         ti_ndk_config_Global_NetworkIPAddr);
        EIPACDStop();
    } while (rc > 0 || rc == ACD_LINKDOWN);

    /*EIP Application Exit*/
    EIPACDExit();

    /* Delete Configuration */
    CfgFree(hCfg);
    /* Close the OS */
main_exit:
    NC_SystemClose();
    System_flush();
}

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

I see that you are setting the "Global.stackThreadUser" field. When this is set, NDK will not generate its own stack thread. Therefore, you will need to manually update the cfg with any configuration setting changes you are making in the GUI (XGCONF). Since you want to change the priority values, you will need to add the below code to your stack thread function after CfgNew() call:

/* add the configuration settings for NDK low priority task level. */
    rc = 10;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRILOW,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /* add the configuration settings for NDK normal priority task level. */
    rc = 12;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRINORM,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /* add the configuration settings for NDK high priority task level. */
    rc = 15;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRIHIGH,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /* add the configuration settings for NDK kernel priority task level. */
    rc = 18;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRIKERN,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

In the screenshot you shared, I dont see any change in NetScheduler(). It should be changed as shown below:

/* ARGSUSED */
static void NetScheduler( uint const SerialCnt, uint const EtherCnt )
{
    register int fEvents;

    /* Set the scheduler priority */
    // Change this to below -> TaskSetPri( TaskSelf(), SchedulerPriority );
    TaskSetPri( TaskSelf(), 14 );

Without this change, the scheduler priority will continue to be the old default one.

Best,

Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

I had mentioned before that the code being used is from the Industrial SDK's Ethernet example (C:\ti\am335x_sysbios_ind_sdk_1.1.0.5\sdk\examples\ethernetip_adapter), so the implementation is TI's. When you say that setting the "Global.stackThreadUser" field will not allow the NDK to generate it's own thread I'm not sure exactly what that means as how the NDK operates is not well documented. If setting this field overrides the normal NDK thread process, why didn't the code used in the Ethernet example have the extra configuration entries? I can add it, but I'm concerned that I might be missing something (maybe the reason that they did not originally put this code in?)

I definitely missed the the change you wanted NetScheduler() and I'm building it now.

Thanks,

John C.

0 Prajith Jayarajan over 9 years ago in reply to John Conover

TI__Expert 6335 points

Hi John,

Please refer to the NOTE3 from Ethernet/IP section in AM335x user guide. It mentions that any configuration added through XGCONF tool will be overridden. For isdk 1.1.0.5 ethernetip example you can add the code to change the taks priority inside the function "static void registerIPCfg(HANDLE hCfg)".

Regards,

Prajith

0 John Conover over 9 years ago in reply to Prajith Jayarajan

Genius 4350 points

Hey Prajith,

So your saying that by using the Ethernet/IP example everything that has been configured in Code Composer for the NDK is lost (task priorities, buffer sizes, stack sizes, etc ?) I'm just trying to understand if I should continue to use this example.

Thanks,
John C.

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Ashish,

I've gone back to double check all the changes.

netctrl.c:

---------------------------------------------------------------

int NC_SystemOpen( int Priority, int OpMode )

{

HANDLE hSem = 0;

/* Open the low-level enironment */

/* Set the network scheduler priority */

//if( Priority != NC_PRIORITY_LOW && Priority != NC_PRIORITY_HIGH )

// return(NC_OPEN_ILLEGAL_PRIORITY);

//SchedulerPriority = Priority;

/* Check the operating mode */

if( OpMode != NC_OPMODE_POLLING && OpMode != NC_OPMODE_INTERRUPT )

return(NC_OPEN_ILLEGAL_OPMODE);

/* Polling at high priority is illegal */

//if( Priority==NC_PRIORITY_HIGH && OpMode==NC_OPMODE_POLLING )

// return(NC_OPEN_ILLEGAL_OPMODE);

---------------------------------------------------------------

static void NetScheduler( uint const SerialCnt, uint const EtherCnt )

{

/* Set the scheduler priority */

//TaskSetPri( TaskSelf(), SchedulerPriority );

TaskSetPri( TaskSelf(), 14 );

---------------------------------------------------------------

Rebuilt C:\ti\ndk_2_24_00_11_modified\.

eip_ndk.c:

Added to registerIPCfg()

-------------------------------------------------------------------------------------

/* add the configuration settings for NDK low priority task level. */

tmp = 10;

CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRILOW,

CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&tmp, 0 );

/* add the configuration settings for NDK normal priority task level. */

tmp = 12;

CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRINORM,

CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&tmp, 0 );

/* add the configuration settings for NDK high priority task level. */

tmp = 15;

CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRIHIGH,

CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&tmp, 0 );

/* add the configuration settings for NDK kernel priority task level. */

tmp = 18;

CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRIKERN,

CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&tmp, 0 );

-------------------------------------------------------------------------------------

After checking and rebuilding everything I ran the system, ping'ed it a few times, and then got the following task priorities from ROV:

Somehow it is still set to a priority of 8, which at this point should not happen. Any idea's?

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

Its odd the priority did not change. Can you put a breakpoint in NetScheduler() like before and verify the priority value being passed to TaskSetPri() is 14 and whether the call is changing the priority correctly.

Best,
Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Ashish,

Went back through and found it was still setting the priority incorrectly. I looked at the build output and noticed that the xdcpath is incorrect.

"C:/ti/ccsv6/xdctools_3_30_03_47_core/xs" --xdcpath="C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11/packages;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug" "../airtrac.cfg"

So it is now using the original unmodified NDK even though the RTSC configuration for the project is correct:

I must be missing something about how to set up the modified NDK so the xdcpath points to it.

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

I am not sure why it is not using the modified package. Maybe the ordering is wrong. You can click on the "Order" tab in the above screenshot, and move the modified NDK package to the top of the list.

Can you also hand edit the "XDCtools"->"Package Repositories" list ? Just remove the "${COM_TI_RTSC_TIRTOSTIVAC_INSTALL_DIR}/products/ndk_2_24_01_18/packages" entry and add "<path to custom NDK>/ndk_2_24_01_18_modified/packages". This will force the right package to be used.

Best,
Ashish

0 Prajith Jayarajan over 9 years ago in reply to John Conover

TI__Expert 6335 points

Hi John,

John Conover said:
So your saying that by using the Ethernet/IP example everything that has been configured in Code Composer for the NDK is lost (task priorities, buffer sizes, stack sizes, etc ?) I'm just trying to understand if I should continue to use this example.

The answer is yes. But you can definitely go back to the other approach where you can use app.cfg to configure NDK . Comment out the line Global.stackThreadUser = "&NDKACD_stackThread"; from app.cfg. Please note that the ACD features will not be available (i guess you don't require it) once you do that.

Regards,

Prajith

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hi Ashish,

I reordered the modified NDK and it did not work:

I had tried modifying the "XDCtools"->"Package Repositories" list. I changed "${NDK_INSTALL_DIR}/packages" to "C:\ti\ndk_2_24_00_11_modified\packages" without any luck:

Looking at the Project properties you can see that the xdcpath is set correctly:

Project xdcpath:

xdcpath="C:/ti/ndk_2_24_00_11_modified/packages;C:/ti/uia_1_03_01_08/packages;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug"

----------------------------------------------------------

Build output in console xdcpath:

"C:\\ti\\ccsv6\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../airtrac.cfg'
'Invoking: XDCtools'
"C:/ti/ccsv6/xdctools_3_30_03_47_core/xs" --xdcpath="C:/ti/uia_1_03_01_08/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/ndk_2_24_00_11/packages;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug" "../airtrac.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring airtrac.xea8fnv from package/cfg/airtrac_pea8fnv.cfg ...
generating custom ti.sysbios library makefile ...
Starting build of library sources ...

----------------------------------------------------------

The only thing I can think of that might be an issue is the location of Code Composer v6 and the repositories. The xdctools repository is located in the C:\ti\ccsv6 directory where the NDK and other repositories are under C:\ti. So looking at them:

C:\ti\ccsv6

C:\ti\ccsv6\xdctools_3_30_03_47_core

C:\ti\ndk_2_24_00_11_modified

This was TI's suggested way of installing them on the drive(when I added CCSv6), but the only repository located in this manner is the xdctools_3_30_03_47_core. Any chance this is an issue?

Thanks again for all your help,

John C.

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,

I finally got it to work. Under the project properties, CCS General-->RTSC Tab-->XDCtools version pull-down, I selected a different xdctools (3.25.6.96) and tried to build. The build failed, but I then selected the 3.30.3.47_core version and rebuilt. The correct xdc path finally showed up:

"C:\\ti\\ccsv6\\ccsv6\\utils\\bin\\gmake" -k all

'Building file: ../airtrac.cfg'

'Invoking: XDCtools'

"C:/ti/ccsv6/xdctools_3_30_03_47_core/xs" --xdcpath="C:/ti/ndk_2_24_00_11_modified/packages;C:/ti/uia_1_03_01_08/packages;C:/ti/bios_6_40_03_39/packages;C:/ti/nsp_1_10_02_09/packages;C:/ti/am335x_sysbios_ind_sdk_1.1.0.5/sdk/platform;C:/ti/ccsv6/ccsv6/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.A8Fnv -p AIRtrac_1 -r debug -c "C:/ti/ccsv6/ccsv6/tools/compiler/arm_5.1.6" --compileOptions "-g --optimize_with_debug" "../airtrac.cfg"

making package.mak (because of package.bld) ...

----------------------------------------------------------

Everything looks good so far:

Is it possible to use the system priority defines (OS_SCHEDULER_LOWPRI) instead of the hard-coded numbers (14)?

Thanks,

John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

Good to know the priorities are showing up correctly now.

Yes, I think it should be ok to use OS_SCHEDULER_HIGHPRI instead of hard-coding the priority as NetScheduler() gets called after the cfg is updated.

Best,
Ashish

0 John Conover over 9 years ago in reply to Ashish Kapania

Genius 4350 points

Hey Ashish,
Thanks for all the help. Are the modifications that I made to the NDK going to be released in the next version?
John C.

0 Ashish Kapania over 9 years ago in reply to John Conover

TI__Mastermind 21645 points

Hi John,

This bug has not been committed to a release yet so I will be unable to predict when will the fix be available in a released product. I modified the bug to make it visible externally. You can track it through this link.

(It may take a few hours before the link is active)

Best,
Ashish

Processors

Processors forum

NDK task priorities vs. application task priorities