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.

CgfNew() is creating issues when ndktest project is integrated to my application

Other Parts Discussed in Thread: TMS320C6657

In my application I am using a 20ms timer ISR and 2 application tasks which pend and post a semaphore. I tested the ndktest sample project independantly for UDP connection and I am able to echo the packets that I send via hercules.exe windows based application0181.app_1Nov_NotWorking.cfg

When I integrated the ndktest sample project to my application, my application just seems to be blank. In the

MainNetworkTask() function of ndktest.c, I commented all the code just after the following system printfs:

    System_printf (VerStr);

    System_flush ();

In the above case, i am able to see the version banner "TCP/IP Stack 'Hello World!' Application" getting printed on my screen. But if i just enable the next line of the code i.e., the following piece of code related to CfgNew() the version banner no more gets displayed. I had tried many options like increasing the BIOS heapsize in app.cfg etc but of no use. Can someone help please?

   

/***************************************************************************

     Create a new configuration

    ***************************************************************************/

    hCfg =

CfgNew ();

   

if ( !hCfg )

    {

        System_printf (

"Unable to create configuration\r\n");

        System_flush ();

       

return (0);

    }

 Attached is my app.cfg file that I am using. Please let me know in case you see any issues in any of the configurations?

  • Some questions: is your processor C6657? What is the MCSDK and PDK version? NDK version? what is your ndktest sample project, is it based on the hello world example? When you added cfgNew(), did the program run into cfgNew, where did it stuck?

    Regards, Eric 

  • I could surpass this problem, but now i am facing another problem related to NC_NetStart() function. I am using a customized TMS320C6657 based board which supports 2 UART ports and 1 PHY port. In my iniitialization function, I do the initialization of UART0 and PHY ports. If I do not connect the physical LAN cable to my board, I could see that the code just waits in NC_NetStart() and does not exit it (till i reconnect the ethernet cable again).

    1) Is NetStart() call a blocking call and will exit only if the physical LAN cable is connected

    2) In my application, I hav e to dynamically start or stop the ethernet functionality based on the type of communication port selected by the user on a GUI. Is there any means in which I can achieve this functionality.

    I use the following version

    MCSDK   mcsdk_2_01_02_06

    PDK         pdk_c6657_1_1_2_6

    NDK         ndk_2_22_03_20

    SYS/BIOS   bios_6_37_00_20

  • Hello All,

    I used the fix mentioned by  on Dec 12 2012 21:14 PM

     in the post "NC_NetStop(1) -> NC_NetStart() doesn't work.(Link LEDs balck out)". The issue is related to a fix that needs to be implemented in MDIO_close() function in [mdio.c] in pdk. And NC_NetStop() works well.
    After pull ether cable , and reconnection, NC_NetStop() can re-establish emac connection.
    (ofcause , All IP Connections are shutdown ;-) 

    ------- changed source --------

    void MDIO_close( Handle hMDIO ) {     Uint32         ltmp1;     Uint32           i;

        MDIO_Device *pd = (MDIO_Device *)hMDIO;

        /*      * We really don't care what state anything is in at this point,      * but to be safe, we'll isolate all the PHY devices.      */ #if defined(C6474) | defined(C6457) | defined(C6472) /*| defined(C6657)*/

        ltmp1 = MDIO_REGS->ALIVE;     for( i=0; ltmp1; i++,ltmp1>>=1 )     {         if( ltmp1 & 1 )         {             PHYREG_write( pd->regId, PHYREG_CONTROL, i, PHYREG_CONTROL_ISOLATE |                                              PHYREG_CONTROL_POWERDOWN );             PHYREG_wait( pd->regId );         }     } #endif

    }

    Hope TI will take a note of this and implement this fix in the next release of PDK of C6657. The PDK version of C6657 in which I implemented the fix is PDK_C6657_1_1_2_6 which is the latest version as on 30th December 2013.

     

    Thanks,

    Abiramy.R