Migration from standalone app to DSP/BIOS with the NDK-Socket-API support

 Alan, thank You very much for advice.

I still trying to combine these two projects... All HWIs are managed by DSP/BIOS dispatcher and posts SWI or tasks with appropriate processing. But after calling NDK socket API function connect() program hangs. ...

Please see the solution to this post.  It sounds like it could be the same problem.

Dear Steven!

Thank You for reply!

But, unfortunately, it isn't my case.... . I don't use interrupts which are necessary for NDK (it uses INT6 and 7 for EMAC ... ).

Now i created two DSP/BIOS-based simple audio-loopback projects. Audio-loopback is performed directly in HWI (count from RBUF register is copied to XBUF register). Both use SAME initialization for McASP and codec and SAME HWI routine.

First project is based on NDK example "helloWorld" (UDP-echo-server); Second project has only one process - HWI for audio-loopback (without NDK...).

Loopback in the first one DON'T work. In the second - all right. In both projects CPU periodically enters HWI from McASP. I can even store received counts of input signal and plot them. But I can't reproduce them in the project with NDK ...

So the problem isn't solved yet... I will be very appreciative for any help and ideas...

Vitalii

Vitalii Kukush said:

But after calling NDK socket API function connect() program hangs. ...

Does the app ever return from the connect() call?  If so, what is the return value and error code?

If you halt the program when it's hanging, what's it doing?  Is it idling?

Can you open the ROV tool and check the TSK module?  Doe it show anything useful?

Steve

Thanky You, Steve, for advice!

No, app doesn't return from the connect()...

Today I have tried to import NDK to the DSP/BIOS project with simple audio-loopback (as it is described in SPRU523G). NDK is imported succesfully, but the problem remains.

Without declaration of necessary for NDK objects in tcf-file (PRD, HOOK and TSK  object) loopback works perfectly. CPU load 22.88%. When I declare them - loopback doesn't work, but NDK is initialised succesfully (obtains IP). CPU load 23.3% I have checked. CPU enters HWI from McASP periodically. In HWI I can store received count to array and plot them. But I can't send them back ....

I have tried to use different interrupts for serving audio-loopback (from 4 to 15). It doesn't help. (Yes, I have seen, that interrupts 5-8 and 11, 12, 15 are used by NDK or BIOS. With these interrupts my app doesn't even enter HWI from McASP ) I have tried to re-configure Codec, McASP after obtaining IP (in  NetworkIPAddr - callback function ). Doesn't help.

Kernel/objects viewer shows four TSK objects (after obtaining IP):

- DHCPclient (state: blocked);

- ConfigBoot (state: terminated);

- tskStartNDK (state: blocked);

- TSK_idle (state: running). DHCPclient and ConfigBoot are created by NDK. I create only tskStartNDK in the tcf-file.

Interesting ... May be this attempt could identify my problem:

- I enable also Tx complete interrupt in McASP

- in HWI put next waiting cycle before copying Rx count to TX: while( ! ( mcasp->regs->SRCTL5 & 0x10 ) );  // Check for Tx ready

After this, application makes only audio loopback. NDK isn't initialised...

It seems like TX and RX processes become asynchronous when NDK is added to the DSP/BIOS configuration....

Thank you in advance!

Vitalii

PINMUXes are identical for both cases (with and without declaration of necessary for NDK objects in tcf-file ).

Vitalii Kukush said:

I planed to perform data processing in a SWI called from HWIs of corresponding modules (EDMA, McASP)

Are you using the SWI to do the data processing?  Or is this being done in the HWI?  It seemed like it may be happening in the HWI, base on your last post.

Is "tskStartNDK" your main NDK thread?  (e.g. it calls NC_SystemOpen, NC_NetStart, etc.)?

What happens if you put a delay of 30 seconds into the beginning of that task (tskStartNDK)?

Do you hear audio playing (from the audio loopback) and then it will stop playing after 30 seconds? (i.e. when the NDK starts?)

It may also be helpful to attach the code of your tskStartNDK function (and *.tcf file).  If you don't want to share those publicly, just send me a friend request on the forum and then we can email files to one another.

Steve

Steve, thank you for reply!

1. I use only HWI for "processing". For experiments I have created a simple DSP/BIOS-based project. Purpose of project: perform audio-loopback in background of TCP/IP stack functions (now only NDK initialisation ). So under "processing" I mean simple copying Rx to Tx;

2.  Yes, "tskStartNDK" is my main NDK thread.  (e.g. it calls NC_SystemOpen, NC_NetStart, etc.);

3.  In the beginning of tskStartNDK routine I have made 10 second delay with  TSK_sleep(10000). Yes, you're right! I hear audio playing (from the audio loopback) and then it stops playing after 30 seconds (i.e. when the NDK starts?). Then I begin to move place, where TSK_sleep delays the process of NDK initialization.... And... sound reproduction is stopped after printf(VerStr) !!!! During initialization NDK widely uses printf for displaying of process stages. It seems that due to calls of printf() stops sound loopbacking... Why??? I have tried to replace this first call of printf by LOG_printf() - don't help. This call also stops loopbacking.... WHY and HOW fix this problem? ;

I have tried (TSK_sleep(10000) is called at the beginning of the tskStartNDK routine ):

1. All L2 memory set as "Cache" (in the properties of the "Global Settings" in the tconf tool). All program and data was moved to the SDRAM. Nothing changes ... 10 second of sound, then silence  with NDK succesfull initialization.

2. The changes in p.1 and all SDRAM is marked as cacheable (all bits in MAR registers are set to 1 (it was done also in the properties of the "Global Settings" in the tconf tool. All MAR bitmasks are set to 0xffffffff ) ). The CPU load is decreased significantly (from 22.8...23.4% to 3.3...3.4%). But the problem isn't solved.... 10 second of sound, then silence with NDK succesfull initialization;

3. Same as p.1 and p.2, but only part of L2 memory (128k of 256k) is used by cache. ... part of DSP/BIOS program/data is allocated in th L2 memory. ... Nothing changes ... 10 second of sound, then silence with NDK succesfull initialization.

I attach to this post my tskStartNDK function,  *.tcf file, and HWI function. (I hope, some members of e2e communiti have similar problem. Sharing a problem with community means help another to solve it in future).

Thank You in advance! Vitalii

// ====================================

//   --------    tskStartNDK routine ----------------------

// ====================================

int StackTest() 

{             extern HANDLE            hCfg;  

 extern char *VerStr;  

//extern void evalCallBack();  

extern char *DomainName;  

extern char *HostName;

 extern char *LocalIPAddr;  

extern char *LocalIPMask;  

extern char *GatewayIP;

 extern char *DNSServer;

 // -------------

 int               rc;

/TSK_sleep(10000);      

rc = NC_SystemOpen( NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT );    

if( rc )     {         printf("NC_SystemOpen Failed (%d)\n",rc);         for(;;);     }

 TSK_sleep(10000);

    // Print out our banner     printf(VerStr);     //LOG_printf(&trace, VerStr);

    TSK_sleep(10000);

    //     // Create and build the system configuration from scratch.     //

    // Create a new configuration  hCfg = CfgNew();  

   if( !hCfg )     {         printf("Unable to create configuration\n");         goto main_exit;     }

    //TSK_sleep(10000);

    // The evaluation version of TCP/IP Stack restricts usage of stack     // to maximum of 24 Hours. If application wants to be notified 5 min     // before the timeout, it can register a callback function by using     // the following configuration code section.  

   {         void (*pFxn)() = &evalCallBack;         CfgAddEntry( hCfg, CFGTAG_SYSINFO, CFGITEM_SYSINFO_EVALCALLBACK, 0,                     sizeof(void(*)()), (UINT8*) &pFxn, 0 );     }

    // We better validate the length of the supplied names   

  if( strlen( DomainName ) >= CFG_DOMAIN_MAX ||         strlen( HostName ) >= CFG_HOSTNAME_MAX )     {         printf("Names too long\n");         goto main_exit;     }

    // Add our global hostname to hCfg (to be claimed in all connected domains)    

CfgAddEntry( hCfg, CFGTAG_SYSINFO, CFGITEM_DHCP_HOSTNAME, 0,                  strlen(HostName), (UINT8 *)HostName, 0 );

    // If the IP address is specified, manually configure IP and Gateway    

if( inet_addr(LocalIPAddr) )     {         CI_IPNET NA;         CI_ROUTE RT;         IPN      IPTmp;

        // Setup manual IP address    

     bzero( &NA, sizeof(NA) );         NA.IPAddr  = inet_addr(LocalIPAddr);         NA.IPMask  = inet_addr(LocalIPMask);         strcpy( NA.Domain, DomainName );         NA.NetType = 0;

        // Add the address to interface 1      

   CfgAddEntry( hCfg, CFGTAG_IPNET, 1, 0,                            sizeof(CI_IPNET), (UINT8 *)&NA, 0 );

        // Add the default gateway. Since it is the default, the         // destination address and mask are both zero (we go ahead         // and show the assignment for clarity).      

   bzero( &RT, sizeof(RT) );         RT.IPDestAddr = 0;         RT.IPDestMask = 0;         RT.IPGateAddr = inet_addr(GatewayIP);

        // Add the route         CfgAddEntry( hCfg, CFGTAG_ROUTE, 0, 0,                            sizeof(CI_ROUTE), (UINT8 *)&RT, 0 );

        // Manually add the DNS server when specified      

   IPTmp = inet_addr(DNSServer);      

   if( IPTmp )             CfgAddEntry( hCfg, CFGTAG_SYSINFO, CFGITEM_DHCP_DOMAINNAMESERVER,                          0, sizeof(IPTmp), (UINT8 *)&IPTmp, 0 );     }    

// Else we specify DHCP    

else     {         CI_SERVICE_DHCPC dhcpc;

        // Specify DHCP Service on IF-1         bzero( &dhcpc, sizeof(dhcpc) );    

     dhcpc.cisargs.Mode   = CIS_FLG_IFIDXVALID;         dhcpc.cisargs.IfIdx  = 1;         dhcpc.cisargs.pCbSrv = &ServiceReport;         CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPCLIENT, 0,                      sizeof(dhcpc), (UINT8 *)&dhcpc, 0 );     }

    //     // Configure IPStack/OS Options     //

    // We don't want to see debug messages less than WARNINGS

    rc = DBG_WARN;     CfgAddEntry( hCfg, CFGTAG_OS, CFGITEM_OS_DBGPRINTLEVEL,                  CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    //     // This code sets up the TCP and UDP buffer sizes     // (Note 8192 is actually the default. This code is here to     // illustrate how the buffer and limit sizes are configured.)     //

    // UDP Receive limit    

rc = 8192;    

CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_SOCKUDPRXLIMIT,                  CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

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

do     {              rc = NC_NetStart( hCfg, NetworkOpen, NetworkClose, NetworkIPAddr );        } while( rc > 0 );

    // Delete Configuration   

  CfgFree( hCfg );

    // Close the OS

main_exit:     NC_SystemClose();     return(0); }

// ====================================

//   --------   tcf file   ----------------------------------------

// ====================================

utils.loadPlatform("ti.platforms.evm6747");

/* The following DSP/BIOS Features are enabled.  */ bios.enableRealTimeAnalysis(prog); bios.enableRtdx(prog); bios.enableTskManager(prog);

bios.CLK.RESETTIMER = 1;

bios.HWI.instance("HWI_INT8").fxn = prog.extern("HWI_McASPRx"); bios.HWI.instance("HWI_INT8").interruptSelectNumber = 61; bios.HWI.instance("HWI_INT8").useDispatcher = 1;

bios.ECM.ENABLE = true;

// ===== ADD NDK ============

bios.PRD.create("TickForNDK"); bios.PRD.instance("TickForNDK").order = 1; bios.PRD.instance("TickForNDK").period = 100; bios.PRD.instance("TickForNDK").fxn = prog.extern("llTimerTick"); bios.HOOK.create("HookForNDK"); bios.HOOK.instance("HookForNDK").createFxn = prog.extern("NDK_hookCreate"); bios.HOOK.instance("HookForNDK").initFxn = prog.extern("NDK_hookInit"); bios.TSK.create("tskStartNDK"); bios.TSK.instance("tskStartNDK").order = 1; bios.TSK.instance("tskStartNDK").fxn = prog.extern("StackTest"); bios.TSK.instance("tskStartNDK").priority = 5; bios.TSK.instance("tskStartNDK").stackMemSeg = prog.get("SDRAM"); bios.TSK.instance("tskStartNDK").stackSize = 4096; //bios.TSK.instance("tskStartNDK").stackSize = 8192;

bios.MEM.NOMEMORYHEAPS = 0; bios.MEM.instance("SDRAM").createHeap = 1; bios.MEM.BIOSOBJSEG = prog.get("SDRAM"); bios.MEM.MALLOCSEG = prog.get("SDRAM"); bios.MEM.instance("SDRAM").heapSize = 0x00010000; bios.MEM.USEMPC = 1; bios.MEM.TEXTSEG = prog.get("SDRAM"); bios.MEM.SWITCHSEG = prog.get("SDRAM"); bios.MEM.BSSSEG = prog.get("SDRAM"); bios.MEM.FARSEG = prog.get("SDRAM"); bios.MEM.CINITSEG = prog.get("SDRAM"); bios.MEM.PINITSEG = prog.get("SDRAM"); bios.MEM.CONSTSEG = prog.get("SDRAM"); bios.MEM.DATASEG = prog.get("SDRAM"); bios.MEM.CIOSEG = prog.get("SDRAM");

// Init of DSP modules (e.g. McASP and AIC3106) is made in main() and EVM_Init() functions bios.GBL.CALLUSERINITFXN = 1; bios.GBL.USERINITFXN = prog.extern("EVM_Init");

// ===============

// 128k of L2 for Cache

bios.MEM.instance("IRAM").len = 0x00020000; bios.GBL.C64PLUSL2CFG = "128k";

// ================

// all external memory is cacheable (set all bits of MAR-registers to 1 ... CPU load is gecreased significantly ... ) bios.GBL.C64PLUSMAR0to31 = 0xffffffff; bios.GBL.C64PLUSMAR32to63 = 0xffffffff; bios.GBL.C64PLUSMAR64to95 = 0xffffffff; bios.GBL.C64PLUSMAR96to127 = 0xffffffff; bios.GBL.C64PLUSMAR128to159 = 0xffffffff; bios.GBL.C64PLUSMAR160to191 = 0xffffffff; bios.GBL.C64PLUSMAR192to223 = 0xffffffff; bios.GBL.C64PLUSMAR224to255 = 0xffffffff;

bios.LOG.create("trace"); bios.LOG.instance("trace").bufLen = 128; bios.LOG.instance("trace").bufSeg = prog.get("SDRAM"); // !GRAPHICAL_CONFIG_TOOL_SCRIPT_INSERT_POINT! prog.gen();

// ====================================

//   --------   HWI routine ----------------------

// ====================================

int pn32Buf[400];

int pn32CounterForBuf = 0; int n32Temp;

void HWI_McASPRx(void) {     extern MCASP_Handle mcasp;     n32Temp = mcasp->regs->RBUF0;     pn32Buf[pn32CounterForBuf++] = n32Temp;

    if(pn32CounterForBuf >= 400)     

         pn32CounterForBuf = 0;

    mcasp->regs->XBUF5 = n32Temp;

}

I have tried also to increase stack size for tskStartNDK from 4096 to 8192 MAUs.
Doesn't help.

Vitalii Kukush said:

in HWI put next waiting cycle before copying Rx count to TX: while( ! ( mcasp->regs->SRCTL5 & 0x10 ) );  // Check for Tx ready

...

1. I use only HWI for "processing". For experiments I have created a simple DSP/BIOS-based project. Purpose of project: perform audio-loopback in background of TCP/IP stack functions (now only NDK initialisation ). So under "processing" I mean simple copying Rx to Tx;

Please make sure you don't have a while loop like this in your ISR!  This could potentially block other HWIs from being handled properly in your app.  I think you should try moving all of the "processing" that you are doing in the HWI ISR into a SWI ISR.  Then in your HWI ISR, you will just call SWI_post() to cause the SWI ISR to run (and process...).

Vitalii Kukush said:

And... sound reproduction is stopped after printf(VerStr) !!!! During initialization NDK widely uses printf for displaying of process stages. It seems that due to calls of printf() stops sound loopbacking... Why??? I have tried to replace this first call of printf by LOG_printf() - don't help. This call also stops loopbacking.... WHY and HOW fix this problem? ;

Hmm.  printf() will halt the processor, but not LOG_printf().  Did you notice any difference if you remove the print statement completely?  (meaning don't call printf()nor LOG_printf())

Vitalii Kukush said:

and then it stops playing after 30 seconds

Did you mean after 10 seconds?  I was expecting 10 seconds, since that's the amount of time in your TSK_sleep() call?

Vitalii Kukush said:

2. The changes in p.1 and all SDRAM is marked as cacheable (all bits in MAR registers are set to 1 (it was done also in the properties of the "Global Settings" in the tconf tool. All MAR bitmasks are set to 0xffffffff ) ). The CPU load is decreased significantly (from 22.8...23.4% to 3.3...3.4%). But the problem isn't solved.... 10 second of sound, then silence with NDK succesfull initialization;

You might try disabling the cache completely.  Performance will degrade, but it may help you rule out if it's a cache related problem or not.

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

Also ...

Can you try setting some break points?

Put break points at each ISR - the EMAC ones HwRxInt, HwTxInt as well as your audio processing ones.

First, can you set these breakpoints at the very beginning of the program.  Then, run the app and make sure that you hit all of them at least once

What's the value of the GIE register?  Are all of the HWIs enabled as expected?

Now, disable those break points and let the program run until the problem occurs.  When the problem happens, halt the target and then re-enable those break points.

Do you still hit the break points if you run again?

Also, what's the value of the GIE register this time?  Are all of the HWIs enabled as expected?

Dear Steve!

Thank You for advices and sorry for two-day pause...

Thank Your for remark about waiting cycle in a HWI ISR. I understand. It was made only for "experiment".

Yes, sorry. I mean 10 s.

I have tried:

1. Move all of the "processing" that I'm doing in the HWI ISR into a SWI ISR. In HWI ISR is only SWI_post(). Don't help.

2. Disabling the cache completely (even L1) doesn't help. Result the same.

3. About printf(). I was wrong. Using LOG_printf() instead printf() DOESN'T STOP loopbacking!!! But I can replace only two occurences in printf() during NDK initialization ( printf(VerStr) and printing of the MAC address ). All other occurences are made in NDK LIBs... How can I replace or disable them? ... Must I rebuild NDK LIBs or download some "special" version? (As I know, not all NDK LIBs are avaliable in src).

4. Before and after the stop of audio reproduction the program hits break points at HwRxInt and my HWI_McASPRx. Program doesn't hit at HwTxInt ... . GIE is always == 1 (in CSR, TSR, ITSR). IER shows, that HwRxInt, HwTxInt, McASPRx   interrupts are active;

5. I have created more simple DSP/BIOS project. Same audio loopback and TSK, that periodically (T=10 seconds) calls printf("HelloWorld\n") or LOG_printf(&trace, "HelloWorld\n"). Without NDK. Result:  audio reproduction stops after first call of printf(). But the using of LOG_printf don't affects on audio reproduction. So it seems that the my problem is caused buy calls of printf() in the NDK;

6. Strange phenomenon. When I set breakepoint during running of program (by doubleclick on appropriate string of code) - loopback stops. When I set breakepoint before start of program and then run it - loopback works untill hit. When continue after this hit - loopback doesn't work. I need to restart the program.

It would be great, if You could help with these "anomalies"

Thank You very much!

Vitalii

Vitalii Kukush said:

I have tried to import NDK to the DSP/BIOS project with simple audio-loopback (as it is described in SPRU523G)

Which section is this in?  I was searching for "audio" and "loopback" in version G of the User's Guide but didn't see this.

Vitalii Kukush said:

3. About printf(). I was wrong. Using LOG_printf() instead printf() DOESN'T STOP loopbacking!!! But I can replace only two occurences in printf() during NDK initialization ( printf(VerStr) and printing of the MAC address ). All other occurences are made in NDK LIBs... How can I replace or disable them? ... Must I rebuild NDK LIBs or download some "special" version? (As I know, not all NDK LIBs are avaliable in src).

Yes, unfortunately, to modify the NDK printf calls you would need to modify the code and rebuild the libraries.

Vitalii Kukush said:

5. I have created more simple DSP/BIOS project. Same audio loopback and TSK, that periodically (T=10 seconds) calls printf("HelloWorld\n") or LOG_printf(&trace, "HelloWorld\n"). Without NDK. Result:  audio reproduction stops after first call of printf(). But the using of LOG_printf don't affects on audio reproduction. So it seems that the my problem is caused buy calls of printf() in the NDK;

6. Strange phenomenon. When I set breakepoint during running of program (by doubleclick on appropriate string of code) - loopback stops. When I set breakepoint before start of program and then run it - loopback works untill hit. When continue after this hit - loopback doesn't work. I need to restart the program.

This makes sense.  A break point causes the processor to halt, just as a printf statement does.

What happens if you move your audio processing to a TSK function? So that it runs in TSK context?

Lastly, can you confirm if the PSP drivers you are using have cache enabled?

Steve

Steven Connell said:

Yes, unfortunately, to modify the NDK printf calls you would need to modify the code and rebuild the libraries.

I jumped the gun on this!  I forgot that the prints in NDK are configurable.  You can configure these in XGCONF (open your project's *.cfg file in XGCONF in CCS).  Please see the below screen shot.  You want "message level" set to  "DBG_NONE".

Steve

oops ... I goofed again.  That above config won't work for you since you are on earlier 2.0.0 version of the NDK.

You need the following code which should be equivalent.  You should add this into your tskStartNDK thread:

    int rc = 3;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_DBGPRINTLEVEL,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

Steve

Steve, thank you for reply!

1. Sorry please for my incorrect explanation! In SPRU523G I found how to integrate NDK in any DSP/BIOS-based project (Chapter 3 "Network application development"). And I decided to integrate NDK to the audio-loopback project. ... my future application must perform audio input/output and interface with remote TCP-server. SPRU523G  hasn't any reference to audio loopback;

2. PSP drivers and their cache ... probably here my error is hidden ... I don't know ... In my previous standalone DSP application I configured necessary DSP modules (IDMA, EDMA3, McASP, UART) directly through their registers (using overlay structures defined in CSL or BSL headers). Audio codec TLV320AIC3106 was configured using BSL function Int16 EVMC6747_I2C_write(AIC3106_I2C_ADDR, cmd, 2). It helped me to set necessary values in registers of codec... As example of configuring I used test codes shipped with my EVM from Spectrum Digital. I thought, that same kind of initialisation could be performed in the DSP/BIOS based application. So now, in the DSP/BIOS based project, I perform SAME initialisation of McASP and codec TLV320AIC3106, as in my past standalone project. All initialisation is made in main() (or in the EVM_Init() that is necessary for NDK ). In my tcf file first line is  " utils.loadPlatform("ti.platforms.evm6747"); "  ... so I specify the platform for DSP/BIOS. Could I make such kind of the DSP-modules initialisation ? I thought yes, because in SPRAAX4 is described same kind of initialization (using CSL) for the "Audio path thru" application. And in LAB 4 "Audio path thru" application was merged with NDK. But I didn't saw the sources for these labs.... possible it is my error.... . So I don't know, how to answer to Your question about PSP drivers and their cache....

Put me on the right way, please! If it can help, I could attach listings of these initialisation functions and entire project. I'm sorry, may be I must attach it earlier .... But it seems that I don't understand some conceptual aspects...

3. Thank You for advice for disabling printf() in NDK. I will try. Yesterday I have found additional "method" of the printf() disabling in the Wiki TI "Tips for using printf". I don't allow debugger to set of CIO breakepoints at load. With this "blockage" loopback works before and after NDK initialization!!!! Wonderfull !!! I was so happy :-)

----------

I will try:

1. to disable printf in NDK as you have written;

2. to move my audio processing to a TSK function;

3. to perform connection to a TCP Server (as single task, with NDK socket API, when printf() is disabled).

Many thanks for your work!

Vitalii

Dear Steven !

I have tried to add:

rc = 3;

CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_DBGPRINTLEVEL,                  CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

direct after

hCfg = CfgNew();

in the  StackTest() function (which initializes NDK).

Unfortunately, it doesn't help.

During the initialization the NDK prints in CIO console of debugger:

"EMAC should be up and running"

"EMAC has been started successfully"

"Registeration of the EMAC Successful"

These printfs are built in the hal_eth_c6747.lib All other printfs (with used MAC and obtained IP) are replaced by LOG_printf().

So after end of the NDK initialization my audio loopback program works ONLY when CCS Option "Do not Set CIO Breakpoint At Load" is checked.  ...breakpoints stop audioloopback....

Thank your for advice!

Vitalii

Steven, thank You for optimistic answer!

1. Could You comment my doubts about the configuring of DSP modules through registers with CSL, BSL instead the using of PSP-drivers, please? (see my yesterday post). How can I control the PSP cache? (May be You can recommend appropriate documents on this point…);

2. Can You advice some instruction on rebuilding NDK2.0.0? I saw post on this topic with your answer… But sorry please, I can’t find it now … 

I have tried to remove hal_eth_c6747.lib from my project and to copy instead all sources and headers from …ndk\src\hal\evm6747\eth_c6747\ folder. All this sources are added to the project. The attempt of build gives me an error “#error NO CHIP DEFINED (use –dCHIP_XXXX where XXXX is chip number)”. Before main() or direct in the eth_c6747 sources I have written “#define CHIP_6747” – compiler gives me the same error. Also have tried to predefine my chip in project->build options -> preprocessor-> predefined symbol field as “CHIP_6747” – result the same.

Vitalii

Steven!

Thank You for comment about the PSP! Yes, I didn’t rebuild PSP code … I even don’t know whether I use PSP in my project (yes, CSLr is a part of PSP package)… 

About the rebuilding of hal_eth_c6747.lib. This problem seems to be in CSL installed within the CCS directory. I use CCS3.3, BIOS, PSP drivers from the CD shipped with EVM form the Spectrum Digital. The full build output is attached to the end of this message.

Thank You for help and have a nice weekend!

Vitalii

============== Output during build ===================

== (When hal_eth_c6747.lib is excluded from the project and its sources are attached to the project instead) ==

--------------------------  helloWorld.pjt - Custom  --------------------------

[csl_emac.c] "C:\CCStudio_v3.3\C6000\cgtools\bin\cl6x" -g -o2 -fr"F:/DieArbeit/ProjCCS/MySimpleTCPIP_Client_TryToRebuildHAL/debug" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/inc" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/example/tools" -i"/dsp/include" -d"CHIP_C6747" -d"_INCLUDE_NIMU_CODE" -d"_INCLUDE_IPv6_CODE" -d"_NDK_EXTERN_CONFIG" -mv6400+ -@"Custom.lkf" "csl_emac.c"

"C:/CCStudio_v3.3/C6000/csl/include/csl_chiphal.h", line 267: fatal error: #error NO CHIP DEFINED (use -dCHIP_XXXX where XXXX is chip number, i.e. 6201)

1 fatal error detected in the compilation of "csl_emac.c".

Compilation terminated.

>> Compilation failure

[csl_mdio.c] "C:\CCStudio_v3.3\C6000\cgtools\bin\cl6x" -g -o2 -fr"F:/DieArbeit/ProjCCS/MySimpleTCPIP_Client_TryToRebuildHAL/debug" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/inc" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/example/tools" -i"/dsp/include" -d"CHIP_C6747" -d"_INCLUDE_NIMU_CODE" -d"_INCLUDE_IPv6_CODE" -d"_NDK_EXTERN_CONFIG" -mv6400+ -@"Custom.lkf" "csl_mdio.c"

"C:/CCStudio_v3.3/C6000/csl/include/csl_chiphal.h", line 267: fatal error: #error NO CHIP DEFINED (use -dCHIP_XXXX where XXXX is chip number, i.e. 6201)

1 fatal error detected in the compilation of "csl_mdio.c".

Compilation terminated.

>> Compilation failure

[ethdriver.c] "C:\CCStudio_v3.3\C6000\cgtools\bin\cl6x" -g -o2 -fr"F:/DieArbeit/ProjCCS/MySimpleTCPIP_Client_TryToRebuildHAL/debug" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/inc" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/example/tools" -i"/dsp/include" -d"CHIP_C6747" -d"_INCLUDE_NIMU_CODE" -d"_INCLUDE_IPv6_CODE" -d"_NDK_EXTERN_CONFIG" -mv6400+ -@"Custom.lkf" "ethdriver.c"

"C:/CCStudio_v3.3/C6000/csl/include/csl_chiphal.h", line 267: fatal error: #error NO CHIP DEFINED (use -dCHIP_XXXX where XXXX is chip number, i.e. 6201)

1 fatal error detected in the compilation of "ethdriver.c".

Compilation terminated.

>> Compilation failure

Build Complete,

  3 Errors, 0 Warnings, 0 Remarks.

Can you try changing it to "-dCHIP_6747"?  (instead of "CHIP_C6747")

It doesn’t help. See please “part of the compiler output with –dCHIP_6747” at the end of this message.

It seems, that csl_chiphal.h from the “C:\CCStudio_v3.3\C6000\csl\include\” directory doesn’t support my C6747. See please “Beginning and a part from csl_chiphal.h” at the end.

When I use one of the supported chips, for example use the preprocessor predefined symbol  CHIP_6413, the is no error “NO CHIP DEFINED”. But compiler returns more than 100 error messages like: 

"csl_mdio.c", line 45: error: identifier "MDIO_Device" is undefined

"csl_mdio.c", line 46: error: identifier "MDIO_Device" is undefined

"csl_mdio.c", line 49: error: identifier "RMII" is undefined “”…..

Vitalii

===== part of the compiler output with –dCHIP_6747 ==========

[csl_mdio.c] "C:\CCStudio_v3.3\C6000\cgtools\bin\cl6x" -g -o2 -fr"F:/DieArbeit/ProjCCS/MySimpleTCPIP_Client_TryToRebuildHAL/debug" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/inc" -i"C:/CCStudio_v3.3/AdditionalLibs/ndk_2_0_0\\packages/ti/ndk/example/tools" -i"/dsp/include" -d"CHIP_C6747" -d"CHIP_6747" -d"_INCLUDE_NIMU_CODE" -d"_INCLUDE_IPv6_CODE" -d"_NDK_EXTERN_CONFIG" -mv6400+ -@"Custom.lkf" "csl_mdio.c"

"C:/CCStudio_v3.3/C6000/csl/include/csl_chiphal.h", line 267: fatal error: #error NO CHIP DEFINED (use -dCHIP_XXXX where XXXX is chip number, i.e. 6201)

1 fatal error detected in the compilation of "csl_mdio.c".

Compilation terminated.

=============== Beginning and a part from csl_chiphal.h =======

/******************************************************************************\

*           Copyright (C) 2000 Texas Instruments Incorporated.

*                           All Rights Reserved

*------------------------------------------------------------------------------

* FILENAME...... csl_chiphal.h

* DATE CREATED.. 14 Aug 2000

* LAST MODIFIED. 14 Jan 2004 Adding support for DRI300 versions (6410, 6413)

*                05 Aug 2003 Removing external control cregisters EM,ER,IN,OUT and DIER.

*                26 Jun 2003 Added support for 6411

*                17 Jun 2003 Added support for 6712C

*                28 May 2003 Added support for 6711C

*                05 Nov 2001 DM642 , 6411 remove 6400

*                03 Oct 2001 - CHIP_6713 - MCASP_SUPPORT - IIC_SUPPORT

*                           - PERCFG register

*                           - redefinition of CHIP_RSET() / CHIP_RGET()

*                           - new CHIP_CRSET() / CHIP_CRGET() => modification of csl_irq.h

*                04 Apr 2004-  Removing external control cregisters EM,ER,IN,OUT and DIER.

*                12 Jan 2005-  Removing external control cregisters FMCR,FADCR,FAUCR and GFPGFR

*                06 Apr 2005-  Removing the macros ATLEN,ATLMEN and ADIV according to data manual 

*                              tms320c6410(13)-sprs247 dated: Feb26 2004 specifications. 

* 26 Jul 2005-  Added C++ support.

*------------------------------------------------------------------------------

#define CHIP_OROFALL (\

  CHIP_6201 | \

  CHIP_6202 | \

  CHIP_6203 | \

  CHIP_6204 | \

  CHIP_6205 | \

  CHIP_6211 | \

  CHIP_6701 | \

  CHIP_6711 | \

  CHIP_6712 | \

  CHIP_6713 | \

  CHIP_DA610 | \

  CHIP_DM642 | \

  CHIP_DM641 | \

  CHIP_DM640 | \

  CHIP_6412 | \

  CHIP_6414 | \

  CHIP_6415 | \

  CHIP_6416 |  \

  CHIP_6711C | \

  CHIP_6712C | \

  CHIP_6411 |\

  CHIP_6410 |\

  CHIP_6413 |\

  CHIP_6418 \

)

#if (CHIP_OROFALL==0)

  #error NO CHIP DEFINED (use -dCHIP_XXXX where XXXX is chip number, i.e. 6201)

#endif

======================================                              LL (\

Vitalii Kukush said:

* FILENAME...... csl_chiphal.h

* DATE CREATED.. 14 Aug 2000

* LAST MODIFIED. 14 Jan 2004 Adding support for DRI300 versions (6410, 6413)

Which version of CSL are you using?  And where does it come from?  (e.g. which product or where did you download it?)

I don't see CHIP_6747 in that macro list.  That CSL looks old and based on the revision history, it was last updated 10 years ago, and this is *before* the OMAPL137 even existed!

I think you need a newer CSL version that has support for the chip you are using!

Please move to a newer CSL.  Moving to the right CSL will probably enable you to get past this build issue you are having.

However, if moving to a new CSL does NOT work, then ...

I thought of another method that might get you past this mess.  It may be a little bit more work, but should get you building.

My idea is for you download the NSP for the OMAPL138 (which is a separate product containing drivers and examples for that board) and try rebuilding that.  This product is newer than NDK 2.0.0 but it shouldn't matter.

If you are able to successfully rebuild the OMAPL138 driver, then what you can do is copy in the OMAPL137 driver sources (from NDK 2.0.0) into this new NSP and put it "next to" the OMAPL138 driver directory.  If you copy over the build script files from the 138 directory and into the 137 directory, and modify them (change instances of 138 -> 137) then you should be able to build the NDK 2.0.0 driver in this new NSP, taking advantage of its build system.

Here's the overview of that:

1. Download the OMAPL138 NSP (1.10.00.03) here.
2. Follow the steps in the release notes of the NSP to rebuild the OMAPL138 driver. You may want to point to your NDK 2.0.0 installation, or you could install the newer NDK that the NSP recommends.
3. If you are able to rebuild successfully, then copy over the OMAPL137 sources from NDK 2.0.0 into the NSP tree.  You should model the directory structure to be just like the OMAPL138 that comes standard with the NSP.
4. Copy the build scripts (package.bld, package.xs, etc.) from the OMAPL138 driver into the OMAPL137 driver directory that you made.  Modify them to update file names and any instance of "138" to be "137"
5. Build the 137 driver using the same method you used to build rebuild the 138 driver (in step 2).  You may want to point to your NDK 2.0.0 installation (moving to a newer NDK here might not be wise, yet, as this is adding another variable into the mix)

Steve

One other thing ... I just want to be sure you saw this FAQ describing how to fix the issue.  Can you please double check that?

Hi Steven!

Thank You for reply.

1. About CSL I use following CSL: 1.1. CSL from "C6000 CSL Library Installation" (sprc090.zip). It has the csl_chiphal.h, but this header isn't support my device (TMS320C6747) 1.2. pspdrivers_01_30_01_rCSL for C674x (http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/index.html) ( !!! the CSLr directory hasn't csl_chiphal.h !!! ). ... I don't know where I can get CSL with "new" csl_chiphal.h ....

2. Thank You for advice with the NSP for the OMAPL138. ... But for rebuilding it needs CCSv4 or higher.. but I'm using CCS3.3 shipped with my board... I'm waiting for new problems...

3.  Thank You for "FAQ describing how to fix the issue" (your previous post). I don't use PSP EDMA3 LLD ... I have directly program its register. And I have already patched NDK with "ndk2.0_omapl137_ethdriver_patch.exe" (to fix a "EDMA3 bug" in NDK).

Now I have already integrated to the project with NDK my standalone project, which performs EMDA3 and IDMA transfers.... 

SUCESSFULLY!!!!

NDK works as "transparent add-on". It works after CIO is disabled (Option -> Customize -> Program/Project Load -> Program. The "Do Not Set CIO Breakpoint At Load" is checked). ... ()

Really, the reason of my problem are printf calls. Thank You very much for  identification of this problem !!!

But, it would be greate to exclude the printf calls from NDK. I can't do it now....

So the problem isn't 100% solved

Thank You, Vitalii

That's great news!

Vitalii Kukush said:

2. Thank You for advice with the NSP for the OMAPL138. ... But for rebuilding it needs CCSv4 or higher.. but I'm using CCS3.3 shipped with my board... I'm waiting for new problems...

You don't need CCSv4.  The driver is rebuilt on the command line.  It only depends on NDK and XDCtools (versions shown in the release notes).  I think you should give the rebuild a try, it's not too difficult.

OK! Thank You!

I will try to rebuild NDK ! I will report you a little bit later! (And, I hope, will "verify" Your recommendations)

Thank You for support, Steven !!!

Vitalii

Dear Steven!

At last I have success with rebuilding NDK HAL libs!!!

The problem was in wrong values in the "Include Search Path (-i)" field in the Project -> Build Options -> Compiler -> Preprocessor. I shouldn't copy headers from HAL scr to the project. Path to these headers must be included to the Project -> Build Options -> Compiler -> Preprocessor: -i"C:\CCStudio_v3.3\AdditionalLibs\NDK_2_0_0\packages\ti\ndk\src\hal\evm6747\eth_c6747\inc\

So the problem seems to be solved now.

I shall try to summarize our discussion:

The main instruction how to add NDK to the project can be found in Chapter 3 "Network application development" of SPRU532G. But HAL library of NDK contains calls of CIO printf(). These printfs are called NOT from TSK context of DSP/BIOS and can cause a problems during processing interrupts in a user-program (In my case it was the problem with realisation of the audio-loopback, which simply copies Rx counts to Tx buffer of McASP module of DSP). To avoid this problem I musted  disable the printf calls (disable CIO breakepoints), replace printf calls to the LOG_printf calls in the sources of the HAL NDK library and rebuild HAL NDK library.

So after performing actions described in the Ch 3 of 532G it was necessary:

1) to exclude hal_eth_c6747 from the project, instead  it copy and add to the project next files from the C:\CCStudio_v3.3\AdditionalLibs\NDK_2_0_0\packages\ti\ndk\src\hal\evm6747\eth_c6747: - csl_emac.c; - csl_mdio.c; - ethdriver.c; nimu_eth.c. (here "C:\CCStudio_v3.3\AdditionalLibs" is the directory, where NDK was installed);

2) add next directives to the Project -> Build Options -> Compiler (simply type them in the edit box): -d"_INCLUDE_NIMU_CODE" -d"_INCLUDE_IPv6_CODE" -d"_NDK_EXTERN_CONFIG" -d"CHIP_C6747" -d"CHIP_6747" -i"C:\CCStudio_v3.3\AdditionalLibs\NDK_2_0_0\packages\ti\ndk\inc\" -i"C:\CCStudio_v3.3\AdditionalLibs\NDK_2_0_0\packages\ti\ndk\src\hal\evm6747\eth_c6747\inc\"

(here "C:\CCStudio_v3.3\AdditionalLibs" is the directory, where NDK was installed);

3) to include the header generated by the DSP/BIOS tconf tool   in the ethdriver.c and nimu_eth.c. (In my case it was #include "DSPBIOS_configcfg.h", name of the DSP/BIOS configuration is DSPBIOS_config.tcf);

4) to replace ALL calls of the printf(...) to the LOG_printf(&trace, ...) in the ethdriver.c and nimu_eth.c (in all project). Here "trace" is the  LOG item created in the DSP/BIOS configuration ( in my case in the DSPBIOS_config.tcf);

5) to rebuild all project;

6) to disable CIO (printf) by checking "Do Not Set CIO Breakpoint At Load" in the Option -> Customize -> Program/Project Load -> Program (may be now it isn't so necessary .... but it is more preferable to use LOG_printf instead printf to avoid similar problems).

Once more, Steven, thank You very much for support and help!

With best regards,

Vitalii