SYS/BIOS NDK Ethernet Log_print0() and the DSK6455

Also, I should mention some platform details.

Host machine : Linux Ubuntu

CCSv5.1.1.xxxxxxxxx

SYS/BIOS 6.32.5.54

UIA 1.0.3.25

NDK 2.20.4.26

Compiler : v7.3.0

In my SYS/BIOS .cfg file I've got the following.

var System = xdc.useModule('xdc.runtime.System');
var SysStd = xdc.useModule('xdc.runtime.SysStd');
System.SupportProxy = SysStd;

/* The xdc.runtime.Log module provides APIs to log prioritized events (errors, 
 * warnings, and info) as well as generic APIs to log events (Log_writeN,
 * Log_printN) 
 */
Timestamp = xdc.useModule('xdc.runtime.Timestamp');
var Log = xdc.useModule('xdc.runtime.Log');

/* ================ Logger configuration ================ */
/*
 * The target's Log records are read while the target is running. Note: this mode
 * is only supported for CPUs that support real-time JTAG accesses such as
 * those in the C6X family (e.g. C64X+ and C66 CPUs). 
 *
 * Configuration done by the application is still honored (e.g. setting
 * up the common$.diags mask).
 *
 * Please refer to the ti.uia.sysbios.LoggingSetup module for more
 * details and configuration options.
 */
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
/*LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGRUNMODE;*/
LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_NONJTAGTRANSPORT;
LoggingSetup.loadLoggerSize = 1024;
LoggingSetup.mainLoggerSize = 32768;
LoggingSetup.sysbiosLoggerSize = 32768;

var loggerSys0Params = new LoggerSys.Params();
loggerSys0Params.instance.name = "loggerSys0";
Program.global.loggerSys0 = LoggerSys.create(loggerSys0Params);

/* ======================= NDK logging support ============ */
/* NDK ethernet logging changes. We have to add a UIA ServiceMgr
 * as well as setup the NDK for use as the transport type.  */
var Global = xdc.useModule('ti.ndk.config.Global');

var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.transportType = ServiceMgr.TransportType_ETHERNET;
var NdkConfig = xdc.loadPackage('ti.ndk.config');
var Ip = xdc.useModule('ti.ndk.config.Ip');
var Udp = xdc.useModule('ti.ndk.config.Udp');

Then I setup the System Analyzer. I made a UIA config file. I followed the instructions (http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorial_3B) from that same tutorial. (Incidentally, they don't agree with the image above them in terms of UDP vs TCPIP for the control and event transport endpoints.)

2. Add an Event Transport 

• Right click on the table and select "Add an event transport".
• Transport Type : UDP
• Address : If you have configured your target with a static IP address or know what address has been assigned, enter the IP address in the Address field. Otherwise, enter 127.0.0.0 for now (we can change it later in the Tools / System Analyzer / Live dialog).
• Port Number : 1235.

• (Note that this is currently hard-coded in releases up to and including uia_1_00_02_22; other port numbers are not supported)

• click OK

3. Add a Control & Status Transport

• Right click on the table and select "Add a Control & Status Transport"
• Transport Type : TCPIP
• Address : enter the same value you entered for the Event transport
• Port Number : 1234.

• (Note that this is currently hard-coded in releases up to and including uia_1_00_02_22; other port numbers are not supported)

• click OK

4. Add an Endpoint...

When I try to connect via Tools->System Analyzer->Live and "Run", I get the following error.

"Please Check the configuration and restart UIA.  Unable to open Message Transport 192.168.1.164:1234 : Connection Refused."

And the error log gets populated with the same error under "UIA Session Summary".  

Hmmm.  Any clue what I'm doing wrong?

Can you confirm that "ping 192.168.1.164" works? Are you getting this address dynamically or statically?

Todd

Hey Todd,

     Thanks for the quick reply.  ping does work.  I don't have the console up anymore where I did it, but I did test that.  It is set statically in c code like this... (taken from NDK example code and adapted slightly.)

char *HostName = "tidsp";
char *LocalIPAddr = "192.168.1.164"; // Set to "0.0.0.0" for DHCP
//char *LocalIPAddr = "0.0.0.0"; // Set to "0.0.0.0" for DHCP
char *LocalIPMask = "255.255.254.0"; // Not used when using DHCP
char *GatewayIP = "0.0.0.0"; // Not used when using DHCP
char *DomainName = "demo.net"; // Not used when using DHCP
char *DNSServer = "0.0.0.0"; // Used when set to anything but zero

...

...

// 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 );
 }

//
 // Configure IPStack/OS Options
 //

// We don't want to see debug messages less than WARNINGS
 rc = DBG_INFO;
 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.)
 //

// TCP Transmit buffer size
 rc = 8192;
 CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_SOCKTCPTXBUF,
 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

// TCP Receive buffer size (copy mode)
 rc = 8192;
 CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_SOCKTCPRXBUF,
 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

// TCP Receive limit (non-copy mode)
 rc = 8192;
 CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_SOCKTCPRXLIMIT,
 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

// 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 );
 TRACE("NC_NetStart Loop\n");
 } while( rc > 0 );

// Delete Configuration
 CfgFree( hCfg );

// Close the OS
main_exit:
 NC_SystemClose();
 return(0);

Also, I took the device off the network, powered it down etc etc, and verified ping no longer works.  We're on a subnet and there are very few devices on it.  (like 4 or 5.)  So it's highly likely I'm not accidentally talking to some other ethernet-enabled device.

FastFourier,

Can you please provide some more details on the above code?  Is this code in a C file that you created for your project?  What is the name of the function that the above code is in?  Did you create a Task for it?

The 2.20x NDK for SYS/BIOS 6.x works a little differently than it did previously.  In particular, the code for the main NDK stack task is generated for the user.  This code generation is governed by the configuration parameter "enableCodeGeneration" in the Global.xdc NDK module.

I see that in your *.cfg file, you are using the Global module, but I didn't see "enableCodeGeneration" being set to false anywhere.

So, I'm wondering if there are 2 instances of the NDK stack being brought up in your program - one that is generated by the NDK Global module, and another that you are creating in the above code.

If the above code is in fact a Task that you have written and configured yourself, then you should set the following in your config file (*.cfg):

var Global = xdc.useModule('ti.ndk.config.Global');
Global.enableCodeGeneration = false;

Steve

Hi Steve, and thanks for the reply.  Well, I'll admit, I don't know anything about the NDK and one of our other developers got that part up and running months ago.  (See how I just passed the buck?)  ;)  To answer your questions though,

1.) The function that code was lifted from is named "StackTest()" in client.c.  I was under the impression this was boilerplate code and we inherited it from TI examples or something.  But maybe one of our guys wrote it.  However, I think the more likely scenario is that it was lifted from example code in some NDK somewhere.

2.) Yes.  Our .cfg file does create a task for it.  (I didn't paste the entire .cfg.  It's lengthy.)

var ndkTskParams = new Task.Params();
ndkTskParams.instance.name = "ndkTsk";
ndkTskParams.priority = 1;
ndkTskParams.stackSize = 4096;
Program.global.ndkTsk = Task.create("&StackTest", ndkTskParams);

3.) Further down in the .cfg file, we have the following.  This was also here when I inherited this piece.  So it looks like Code Gen is off.  These are the entirety of references to Global in the .cfg.

Global.enableCodeGeneration = false;
Global.netSchedulerPri = Global.NC_PRIORITY_HIGH;
Global.netSchedulerOpMode = Global.NC_OPMODE_INTERRUPT;

Thanks for the suggestions.  I really appreciate the input.  I'm wondering now if the NDK setup was done manually when it could have been done via Code Generation, and if there is something that isn't setup or some setup that conflicts with the UIA logging features.  There's a LOT of Ethernet-related code in this project.  It looks like 6 different .c files are all doing Ethernet related work.  For example, there's another task someone created called "gpp_client_task()" syn'c up and then whiles away waiting for messages and then calls some handlers in our code to process the messages/data.  I'm assuming we wrote all of that as well.

Also, one more piece of info.  In our end design, we're going to be directly connected to a GPP, and there won't be a network in between.  So the decision was made to use UDP for all of our work since the amount of processing in the stack is greatly reduced.  So, in all of our messaging, we use UDP.  I'm also wondering if some setup somewhere turned off TCP.  I'm just brainstorming here.  But if TCP were needed, and we had disabled it, then obviously that would be a problem.  If that's the case, what can I look for to see if that's happening?

Currently CCS requires TCP for the control messages (connect, start, stop, etc.) and UDP for the events.

Regarding the original problem...do you happen to have WireShark installed on your PC. Sometimes the easiest way to debug this is to look at the packets flowing between the target and CCS. WireShark is free and a great networking tool.

Todd

FastFourier,

I think your NDK setup looks correct.

FastFourier said:

1.) The function that code was lifted from is named "StackTest()" in client.c.  I was under the impression this was boilerplate code and we inherited it from TI examples or something.  But maybe one of our guys wrote it.  However, I think the more likely scenario is that it was lifted from example code in some NDK somewhere.

Yes, StackTest is the name of main NDK thread.  This code was taken from an NDK example, as you have suspected.

FastFourier said:

2.) Yes.  Our .cfg file does create a task for it.  (I didn't paste the entire .cfg.  It's lengthy.)

var ndkTskParams = new Task.Params();
ndkTskParams.instance.name = "ndkTsk";
ndkTskParams.priority = 1;
ndkTskParams.stackSize = 4096;
Program.global.ndkTsk = Task.create("&StackTest", ndkTskParams);

3.) Further down in the .cfg file, we have the following.  This was also here when I inherited this piece.  So it looks like Code Gen is off.  These are the entirety of references to Global in the .cfg.

Global.enableCodeGeneration = false;
Global.netSchedulerPri = Global.NC_PRIORITY_HIGH;
Global.netSchedulerOpMode = Global.NC_OPMODE_INTERRUPT;

This configuration looks good.  The key thing to point out is that when creating your own NDK stack thread ("StackTest" in this case) you must disable code generation as well, which is being done correctly in the above configuration code.

FastFourier said:

I'm wondering now if the NDK setup was done manually when it could have been done via Code Generation, and if there is something that isn't setup or some setup that conflicts with the UIA logging features.

Yes, the NDK code could have been auto generated for you.  But it's perfectly OK to do it the way that your application is doing it, too.  The choices only need to be mutually exclusive.  I'd recommend leaving it as it is for now.

Also, in case you wanted to know something more about the NDK configuration, you can have a look at the documentation found in the following file.  The "Global" module is the best starting point: C:\Program Files\Texas Instruments\ndk_2_20_03_24\docs\cdoc\index.html

Steve

fourier $ which wireshark
/usr/bin/wireshark

Yep.  I'll see if I can try to grab some captures in a little while.

I just got a few minutes to load up Wireshark and I ran some captures.  I set ip.dst == 192.168.121.164 || ip.src == 192.168.121.164 as the filter.  So anything going to or coming from the DSK board address. (.164 is the DSK board.)  

When I started Code Composer and ran the project, it looks like CCS started ICMP pinging the device.  On wireshark, I saw these all popup as "Destination unreachable (Port unreachable.)"  

While that was still running, I started up a ping from the console, and that succeeded.  

fourier:scripts $ ping 192.168.121.164
PING 192.168.121.164 (192.168.121.164) 56(84) bytes of data.
64 bytes from 192.168.121.164: icmp_req=1 ttl=255 time=0.110 ms
64 bytes from 192.168.121.164: icmp_req=2 ttl=255 time=0.104 ms
64 bytes from 192.168.121.164: icmp_req=3 ttl=255 time=0.150 ms
64 bytes from 192.168.121.164: icmp_req=4 ttl=255 time=0.106 ms
64 bytes from 192.168.121.164: icmp_req=5 ttl=255 time=0.154 ms
64 bytes from 192.168.121.164: icmp_req=6 ttl=255 time=0.148 ms
64 bytes from 192.168.121.164: icmp_req=7 ttl=255 time=0.157 ms
64 bytes from 192.168.121.164: icmp_req=8 ttl=255 time=0.150 ms
64 bytes from 192.168.121.164: icmp_req=9 ttl=255 time=0.149 ms
64 bytes from 192.168.121.164: icmp_req=10 ttl=255 time=0.105 ms
^C
--- 192.168.121.164 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8991ms
rtt min/avg/max/mdev = 0.104/0.133/0.157/0.024 ms

I saw them succeed in wireshark as well... right in between failing pings from CCS.  That strikes me as very odd.  

When I pause CCS, the failing pings stop posting to Wireshark.  When I CTRL+C the command line ping, the succeeding ping stop posting.  

I'm wondering if CCS is doing something like trying to route ICMP traffic through our proxy.  My DSK board is on a switch on my desk.  My machine plugs into the same switch.  But if CCS is respecting some proxy settings, it could route all traffic through the proxy which would block this.

Incidentally, the only way I could get the CCS updates to work was to write a script that does the following.

unset https_proxy
unset http_proxy
unset LD_LIBRARY_PATH
/opt/CCSv5_1_1/ccsv5/eclipse/ccstudio &

I'm wondering if that has anything to do with this.  Or maybe I'm way off base.

I've tried tinkering with CCS's proxy settings and specifically adding the IP of the DSK board as a no-proxy exception.  No luck.  I'm about to try the other ethernet hole and a crossover cable.

My dev box has two ethernet holes. Eth0 and Eth1. I hooked up a crossover cable from the DSK to Eth0 and set Eth0 to statically be 10.5.1.1 and the DSK to be 10.5.1.2.

I started off with just a command line ping, and that succeeds. Then I turned on System Analyzer and immediately got a UIA error that connection was refused. Attached is the wireshark log of the whole encounter.

I'm at a loss folks.  There couldn't be a simpler network configuration than that.  What am I doing wrong?

Simplifying the capture a little...

ARP... nothing special

1 0.000000 Dell_ff:a8:42 Broadcast ARP Who has 10.5.1.2?  Tell 10.5.1.1

ARP reply... still nothing special

2 0.000117 Spectrum_02:7d:78 Dell_ff:a8:42 ARP 10.5.1.2 is at 00:0e:99:02:7d:78

I start up CCS, launch my code.  Then, when I turn on System Analyzer live, CCS tries to connect as follows.

3 0.000127 10.5.1.1 10.5.1.2 TCP 53968 > search-agent [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSV=9381455 TSER=0 WS=7

However, the DSK6455 rejects it.  :(  Whaaaaa?

4 0.000227 10.5.1.2 10.5.1.1 TCP search-agent > 53968 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

FYI: We are trying to reproduce this.

OK.  Sounds great.  I appreciate the help.  I'm wondering if there's an easy way to tell what parts of the NDK are built into my project.  i.e. is it possible that we've inadvertently excluded necessary services or capabilities by misconfiguring the NDK?  Is there a good place to check that?

Also, I wondered if I had iptables rejecting incoming or getting in the way.  I had iptables stopped.  :/

Can you attach the UIA Config file you are using with System Analyzer?

Todd

Absolutely.  See attached.

1803.network_uia_session.txt

The file looks ok. Which CCS version are you using?

Can you try running one of our debug scripts to see if it works? In the ti/uia/scripts directory there is a UIAHost.xs file. Please edit this to put in the correct IP address (line 28) and file names (lines 18 and 19).

To run (first make sure XDCtools is on your path)

xs -f UIAHost.xs -s

You should have WireShark running to see if we get the same problem.

Thanks,
Todd

OK, I'm on it.

Code Composer Studio

Version: 5.1.1.00033

These lines?  Looks like your V: hard drive is famous Todd.  :)  I'll try it out and get back to you.

var executable = "V:/toddm/uia/src/ti/uia/examples/evm6472/ti_platforms_evm6472_core0/debug/stairstepOneCore.x64P";
var rtaXml = "V:/toddm/uia/src/ti/uia/examples/evm6472/package/cfg/ti_platforms_evm6472_core0/debug/stairstepOneCore_x64P.rta.xml";

Well, the script bombs.  Maybe I'm setting it up wrong.

/* These are my changes.  */
var executable = "/opt/svn/branches/dsp6455_devel/debug/binary.out";

/* Is this the right file?  This is the UIA session config file. */
var rtaXml = "/opt/svn/branches/dsp6455_devel/network_uia_session.usmxml";

/* NULL, unchanged from your file. */
var outputFile = null;

fourier:scripts $ ../../../../../xdctools_3_22_04_46/xs -f UIAHost.xs -s
js: "./UIAHost.xs", line 49: null
"./UIAHost.xs", line 41
org.mozilla.javascript.WrappedException: Wrapped java.lang.NullPointerException (./UIAHost.xs#49)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1773)

...

...

The line it dies on is...

var processor = new Packages.ti.uia.scripts.PacketProcessor( executable, rtaXml, outputFile );

It's complaining about "Null".  Is it that "outputFile" that's causing the problem?  I'll try setting it to something real.

Modified the UIA script as follows...

var outputFile = "/opt/workspace/dvt/temp.out";

Still bombs in the same way.  :(

The whole error...

@fourier:scripts $ ../../../../../xdctools_3_22_04_46/xs -f UIAHost.xs -s
js: "./UIAHost.xs", line 49: null
 "./UIAHost.xs", line 41
org.mozilla.javascript.WrappedException: Wrapped java.lang.NullPointerException (./UIAHost.xs#49)
 at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1773)
 at org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:202)
 at org.mozilla.javascript.NativeJavaClass.constructSpecific(NativeJavaClass.java:281)
 at org.mozilla.javascript.NativeJavaClass.construct(NativeJavaClass.java:200)
 at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3377)
 at script.run(./UIAHost.xs:49)
 at script(./UIAHost.xs:41)
 at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
 at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:178)
 at org.mozilla.javascript.Context.evaluateReader(Context.java:1135)
 at config.Shell.evaluateLoad(Shell.java:771)
 at config.Shell.processLoad(Shell.java:658)
 at config.Shell.load(Shell.java:1190)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:592)
 at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161)
 at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:413)
 at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
 at script(/opt/CCSv5_1_1/xdctools_3_22_04_46/include/utils.tci:662)
 at script(/opt/CCSv5_1_1/xdctools_3_22_04_46/packages/xdc/xs.js:150)
 at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
 at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
 at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:398)
 at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3065)
 at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:175)
 at org.mozilla.javascript.Context.evaluateReader(Context.java:1135)
 at config.Shell.evaluateReader(Shell.java:822)
 at config.Shell.processReader(Shell.java:491)
 at config.Shell.processFile(Shell.java:550)
 at config.Shell.exec(Shell.java:755)
 at config.Shell.main(Shell.java:1337)
Caused by: java.lang.NullPointerException
 at xdc.rta.MetaData.getProperty(MetaData.java:229)
 at xdc.rta.MetaData.parseTargetProps(MetaData.java:654)
 at xdc.rta.MetaData.parse(MetaData.java:395)
 at ti.uia.scripts.PacketProcessor.<init>(PacketProcessor.java:59)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:501)
 at org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:194)
 ... 27 more
Thu May 17 @ 01:26 PM

The rtaXml file on line 19 is the rta.xml file (not the CCS one). This is one of the file you set up in your CCS UIA config file. I believe it is:
/opt/svn/branches/dsp6455_devel/debug/configPkg/package/cfg/rtos_p64Pe.rta.xml

Todd

Indeed.

fourier:scripts $ xs -f UIAHost.xs -s
UIA Client started.
Opening UDP sockets.
js: "./UIAHost.xs", line 54: Connection refused
"./UIAHost.xs", line 41
org.mozilla.javascript.WrappedException: Wrapped java.net.ConnectException: Connection refused (./UIAHost.xs#54)

So I had CCS up and running in a debug session.  I had my rtos.cfg setup as previously mentioned with ethernet printf support.  Wireshark looked like the following...

All of the ICMP traffic starts when CCS starts its debug session.