Questions about NDK helloWorld example

David Aldrich92784

I am writing a TCP server application for C66x, using CCS5.3 and NDK v.2.22.0.06. I have based the application on TI's NDK helloWorld example and have some questions regarding it.

Firstly, the NDK User's Guide seems to prefer using XGCONF to configure the NDK. The helloWorld example seems to use the older method of configuring NDK in C code. Is an NDK example available that uses XGCONF and that would be suitable for using as the basis of a TCP server?

Secondly, my app is working fine for small messages. It simply receives a message and echoes it back to the client. For small (1000 byte) messages this works fine - it works reliably for many messages. But for 2000 byte messages the code hangs after receiving 16 messages (i.e. 32k octets total). This implies a buffer size problem. Please can anyone suggest which buffer parameter may need adjusting?

Lastly, the user guide infers that the NDK sends debug messages to a log. Perhaps those messages would help me diagnose my problem. How would I access the log?

David

over 12 years ago

0 Ashish Kapania over 12 years ago

TI__Mastermind 21645 points

Hi David,

You can try getting the NDK examples from the NSP package (nsp_1_10_01_06\packages\ti\ndk\examples). These examples use a *.cfg file to configure the App and can therefore be configured using XGCONF. You can get NSP from here : http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html

The user guide suggests that all debug messages are printed on the console by default.. Have you gone over Section 3.5.2 (Controlling Debug Messages) of the NDK User's Guide ?

I will need to check with our NDK expert to answer your second question. I will get back to you on that one.

Best,

Ashish

0 Steven Connell over 12 years ago

TI__Mastermind 45025 points

Hi David,

Are you using the MCUSDK?

David Aldrich92784 said:
the user guide infers that the NDK sends debug messages to a log. Perhaps those messages would help me diagnose my problem. How would I access the log?

In NDK 2.22.x, debug output is redirected to the SysMin buffer. This buffer will be flushed when System_flush() is called. But if it is not called, you can view the SysMin buffer when the target is halted using ROV. Once ROV is open, browse down and find SysMin, then look at the OutputBuffer tab.

David Aldrich92784 said:
my app is working fine for small messages. It simply receives a message and echoes it back to the client. For small (1000 byte) messages this works fine - it works reliably for many messages. But for 2000 byte messages the code hangs after receiving 16 messages (i.e. 32k octets total). This implies a buffer size problem. Please can anyone suggest which buffer parameter may need adjusting?

Are you able to run a wireshark capture for this problem? If so, could you please attach the capture file? Actually, if you could provide a capture of both scenarios - the 1000 byte message (working case) and the 2000 byte message (failure case).

What are the sizes of your TCP send and receive buffers? These are probably configured at run time if you're using the MCUSDK with statements similar to the following:

        Int transmitBufSize = 512;
        CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_SOCKTCPTXBUF,
                CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&transmitBufSize, 0);

        Int receiveBufSize = 512;
        CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_SOCKTCPRXBUF,
                CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&receiveBufSize, 0);

E.g. the above would set the buffer sizes to be 512 bytes. You can set them up to 64K bytes.

Another thing to note is the difference in size of the buffers for the fail case and the working case.

In the working case, your buffers are 1000 bytes. This is less than the maximum TCP payload in an Ethernet frame of 1460 bytes. (I.E. your entire 1000 byte buffer of data will fit into a single 1500 byte Ethernet frame).

In the failure case, your buffer size is 2000 bytes and that's bigger than the max TCP payload of 1460. So, the stack will internally break the 2000 bytes up into multiple packets. This may have something to do with the problem you're seeing.

Steve

Processors

Processors forum

Questions about NDK helloWorld example