Trouble with the tcp/udp communication on the chip of TM4C1294NCPDT

Hi Nancy,
Are you saying that the tcpEcho example shipped with TI-RTOS is not working on your TM4C1294NCPDT? I have not seen the tcpEcho example fail on my board, so I just wanted to clarify with you whether or not it is working for you.

Thanks,
Janet

Hi janet,

  I test the ti-rtos tcpEcho example both on the LaunchPad(TM4C129XNCZAD) and on my own demo board(TM4C1294NCPDT).Of course,i use different chip example:

Ti supply the four different chip example.I test the TM4C1294NCPDT  tcpEcho example on my demo board(TM4C1294NCPDT),but it can not succed.The code block at the accept() function. 

Hi Janet,

   My trouble is very important to me.

Can you kindly help test the TM4C1294NCPDT tcpEcho example on your EK-TM4C1294XL developement board to have a contrast with my own demo board)?

I only have the TM4C129X Development Board.We know that the two chips(TM4C1294NCPDT and TM4C129XNCZAD)  show little difference.

Hi Nancy,
I have tested the tcpEcho on the TM4C1294NCPDT EK-TM4C129XL board and it works fine.
Can you send us a WireShark capture for both the ping example and the tcpEcho example?
Thanks,
Janet

Hi janet,

Thanks a lot!

According to your suggestion, i use the WireShark capture both on Ti LaunchBoard(TM4C129XNCZAD)  and on my own demo board(TM4C1294NCPDT).

The ICMP(also called the ping command) and tcp  packet capture are attached as follows:

2318.TM4C129XNCZAD.zip

1651.TM4C1294NCPDT.zip

Hi Nancy,
None of the WireShark captures are showing that the tcpEcho example has been run. Does the tcpEcho example work on your TM4C129XNCZAD? I was under the impression that it was working for that board. If so, please send a WireShark capture when you run tcpEcho on the TM4C129XNCZAD.
Also, please send a WireShark capture when running tcpEcho on the TM4C1294NCPDT. It looks like the WireShark captures in your post just have pings.
Thanks,
Janet

Hi janet,

    Thanks!

    I download the tcpEcho example, debug run the program on the Ti developement board(TM4C129XNCZAD) and on my own demo board( TM4C1294NCPDT).I also creat a socket client with my PC socket debug assistant.When I send some data to the TM4C129XNCZAD,it echo the data to me.So the tcpEcho example do run on the Ti board.There might be something wrong with my capture ways.  I do the capture again.Here is my new capture:

3482.tcpEcho.zip

Hi Nancy,
Can you run the tcpSendReceive app from your PC and send a WireShark capture of that. You should try something like this example:

C:\ti\ccsv6.1.3.00033\tirtos_tivac_2_20_00_06\packages\examples\tools> .\tcpSendReceive 146.252.163.172 1000 l -s100

Then we can verify that the tcpEcho is working.
Thanks,
Janet

Hi janet,

   When I see  WireShark capture and the tcpSendReceive the app picture I sent you before. I have the same impression with that the tcpEcho does not run on my demo board.Here are the  tcpSendReceive app and my operastion in ccs pictures:

7245.run_tcpEcho.zip 

I do run the project in ccs.I don't understand what the ICMP capture(the ping command) really means.It seems that the ping is much easy to access,but the tcp socket must have much application condition to meet.

Hi Nancy,

We see from the WireShark capture for the TM4C1294NCPDT, that it has a MAC address of ff:ff:ff:ff:ff:44, which looks suspicious.  I noticed in your screenshot of the CCS console, that the program doesn't appear to be getting the MAC address from Flash.  Are you setting the MAC address in the board file?

Can you try a different unique MAC address that does not have the leading ff:ff:ff?

Thanks,

Janet

Hi janet,

Thanks!

Yes, when I try to debug the tcpEcho exampel on my demo board(TM4C1294NCPDT) the first time,the css  inform me of changing the ff:ff:ff:ff:ff:ff to other  mac address.The code as below:

I try to look at on the registers,it shows that my chip doesn't have mac address in flash register when  Factory setting.I also have a look at on the Ti DK_129XNCZAD,it is set to a unique mac:00-1a-b6-02-91-2d. Obviously,its flash might be download some software when it is shipped to our customers .

   /* Get the MAC address */

   FlashUserGet(&ulUser0, &ulUser1);

   if ((ulUser0 != 0xffffffff) && (ulUser1 != 0xffffffff)) {

       System_printf("Using MAC address in flash\n");

       /*

        *  Convert the 24/24 split MAC address from NV ram into a 32/16 split MAC

        *  address needed to program the hardware registers, then program the MAC

        *  address into the Ethernet Controller registers.

        */

       macAddress[0] = ((ulUser0 >>  0) & 0xff);

       macAddress[1] = ((ulUser0 >>  8) & 0xff);

       macAddress[2] = ((ulUser0 >> 16) & 0xff);

       macAddress[3] = ((ulUser1 >>  0) & 0xff);

       macAddress[4] = ((ulUser1 >>  8) & 0xff);

       macAddress[5] = ((ulUser1 >> 16) & 0xff);

   }

   else if (macAddress[0] == 0xff && macAddress[1] == 0xff &&

            macAddress[2] == 0xff && macAddress[3] == 0xff &&

            macAddress[4] == 0xff && macAddress[5] == 0xff) {

       System_abort("Change the macAddress variable to match your boards MAC sticker");

   }

What differences between the developement board's microcontoller chip and the only chip bought?

Hi Tod and janet,

Thanks!

When  I had a careful look at the mac address of the Ti board and my demo board yesterday, I found the root cause.Though we don't apply for a  vendor specific OUI,I should set the mac address to a uincast address like most networkcards on pc:

x0:xx:xx:xx:xx:xx, x2:xx:xx:xx:xx:xx ,x4:xx:xx:xx:xx:xx and so on.

when i carelessly set the mac to multicast address:like ff:ff:ff:ff:ff:44, it can only be detinantion mac.