The TCP connection will stop after running for some times - NE64.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

The TCP connection will stop after running for some times - NE64.

4,543 Views
Malaysia
Contributor I
Hi,
 
   I'm tried to using the NE64 with the Eval board bought from Freescale, to connect to Ethernet. Right now, I'm able to make the connection on the attached file, and also can received and sending TCP packet to and from PC. But there is some things happens is where after I run for sometimes, the devices was received packet from pc and send back the original packet data back to pc, was stop where can't received the packet. When this occurs, I can't make the connection from PC to devices. Below are portion of the code that I've modified from original demo file Freescale, and the file name is udpinterface.c:-
 
 
  case TCP_EVENT_DATA:
   DEBUGOUT("TCP: Data arrived!\r\n");
   /* read data that was received (and
    * probably do something with it
    */
          for(i=0;i<par1;i++)
          {
            TCP_In_Msg[i]=RECEIVE_NETWORK_B();
          }
         
          if(TCP_In_Msg[8]=='9')
          {
           Bit1_NegVal();
          }
         
          //RS232_Puts_Char(TCP_In_Msg);

          
          (void)memcpy(&net_buf[TCP_APP_OFFSET],TCP_In_Msg,sizeof(TCP_In_Msg));
         
          tcp_send(tcp_soch, &net_buf[TCP_APP_OFFSET], NETWORK_TX_BUFFER_SIZE - TCP_APP_OFFSET, sizeof(TCP_In_Msg));
 
   Intially, I was make the connection where when I recived the data from PC through TCP connection, I send out to the Serial Comm port. For this testing, the devices don't have any problem.
 
   Right after, I've tried to make the testing where when I receive the packet from TCP packet, then I send packet data back to the original port. Intially, the devices was able to receive the packet from PC and sending back the packet back to the same port. However, after sometimes, the devices cannot receive the packet.
 
   Did the way I've wrote the code was wrong? Can someone help to fix the problem? Thanks.
 
Message Edited by t.dowe on 2009-10-20 11:09 PM
Labels (1)
0 Kudos
12 Replies

1,375 Views
williamskj
Contributor I
I think you may be having the same problem as me ....
http://forums.freescale.com/freescale/board/message?board.id=16BITCOMM&message.id=424

I may be wrong but it looks like a hardware problem to me (see post above). I currently have a support case open with Freescale and I am waiting for them to come back to me.

What sort of interval are you leaving between each transmission from the PC to the NE64 ? If you increase the interval to >250ms, does your problem go away ?

I have also looked at the packets with Ethereal and some strange things start happening when the interval between messages is 250ms so it may still be a problem with the OpenTCP stack rather than hardware.

Has anyone out there got an application working successfully with an interval between messages around 150ms ? If so, which TCP stack are you using ?

Karl
0 Kudos

1,375 Views
Malaysia
Contributor I

Hi Karl,

    Thanks for your reply. Sorry for I can't follow u right now. You did mention the increase the interval > 250ms, where can I change the value, or how? Can you show me where to change the interval >250ms so that I'm also can test it and let you know the result.

   I've tried the demo program that I've download from the sourceforce website, where the name is "NE64_Vend_OpenTCP", and I just program into the eval board and when I connect from the PC using the TCP client software, I can see the program are keep sending data to the server. May I know how they do it? Thanks.

KahJoo

0 Kudos

1,375 Views
williamskj
Contributor I

Hi KahJoo,

I've never used NE64_Vend_OpenTCP so I cannot comment on it.
 
You referred to 'TCP client software' and 'I can see the program are keep sending data to the server'. My suggestion was to try to alter the rate at which this TCP client software sends the data to the NE64 server. Do you have the source code for this application ? There should be a loop someone in the code that calls a function to send the data. If possible, you need to find this loop and put in a delay.
 
I wrote my own test client app and the code that sends each message is triggered by a configurable timer.
 
It may not be worth spending lots of time on this though. I just thought it might be useful to know if your problem is speed related too.
 
 
Karl
0 Kudos

1,375 Views
Malaysia
Contributor I
Hi Karl,
 
    Thanks for your reply. Initially I'm using the demo project file of NE64_Vend_OpenTCP as the reference for me to implement the TCP connection. However I'm still finding why the sending packet function are not working well. In initial testing of my program, I'm able to sending the data received from Ethernet and sending data out to through RS232 without any problem and I've test it for 100000++ packet data was send.
 
    After that, I tried to resend back the packet received back to the server. I've let it run for a while until I encounter the PC, which act as the server, can't even send the packet to the NE64.
 
    However, I don't know wheather the application that I wrote are speed related to.
 
    By the way, my source code are attached on my 1st message. However, I'll tried to do somemore testing on it.
 
    However, how I going to disable the timer of the TCP connection not to force to disconnect from the TCP connection if there is no packet are receiving?
 
Thanks.
 
KahJoo
0 Kudos

1,375 Views
williamskj
Contributor I

Hi KahJoo,

I think you may have misunderstood me. My suggestion was to change the code running on the PC, not the code running on the NE64.

The code you included in your first post is running in the NE64 and is similar to the code I have running on my NE64.

Freescale are still looking into this problem.

They are trying to investigate just using pings from the PC to the NE64 rather than using an application on the PC. I've tried this too and I can get the NE64 to time-out once the buffer length goes over 1600 bytes. For example...

800 bytes seems fine...

ping 192.168.2.3 -t -w 1000 -l 800

1600 bytes and you get time-outs

ping 192.168.2.3 -t -w 1000 -l 1600

This doesn't seem quite right to me. It may not necessarily be the same issue as the speed test but something's not right.

I've done this with 2 completely different sets of code in the NE64 and  the result is the same. One set of code uses the OpenTCP stack but the other set of code is based on the example that comes with the demo box so it doesn't even use OpenTCP.

Perhaps you could try this ping test and see if you get time-outs too ?

Regards,

Karl

 

 

 

 

 

 

 

0 Kudos

1,375 Views
Spaceball1
Contributor I

I too noticed my Pings to the NE64 would be dropped at certain times during the day.
Turned out it was checksum building alg that the NE64 using that has a bug in it, after I rewrote it, it worked like a charm now.

 

I don’t remember the details now, but if you need more info let me know.

0 Kudos

1,375 Views
Malaysia
Contributor I
Hi spaceball1,
 
   Thanks for your reply. I've stuck in the design with NE64 and the OpenTCP. Right now, I'm just able to received the packet and send the data out from Serial Comms. However, I do tried to received the packet and resend the packet to the PC, then come to error.
 
   Can you let me know you work it. Thanks.
 
Regards,
 
KahJoo
0 Kudos

1,375 Views
b36009
Contributor I
I've seen the same problem with my software. The stack works fine for a while, and then stops working eventually and never recovers. I've found that when it is not working, then both receive buffer interrupts are disabled, and the processor is no longer able to receive anything. It can still send data however. Interrupts are disabled in NE64Receive(), and enabled again in NE64FreeReceiveBuffer(). I'm sure this can be fixed, but I don't think it's worth the effort. There are many TODO comments in the code, obviously because it was never really finised.

After spending way too much time on this and fixing several other problems with DHCP, ARP, and timers, I've come to the conclusion that the OpenTCP stack is garbage and not worth any more time. I'm going to buy a stack from someone else. CMX looks pretty good.
0 Kudos

1,375 Views
williamskj
Contributor I
Just to keep this post up-to-date...

Freescale Support have reproduced my problem. They have forwarded the case to the design centre to check the hardware.

Karl
0 Kudos

1,375 Views
Malaysia
Contributor I

Hi Karl,

   I think I miss out your point. I'll tried to use the ping function that you show to me to test on the NE64 board, and also test on the module that I've develope up, and going to finish of the 8 bit MCU with Ethernet function. Right now my devices Ethernet module are under testing and up to now working quite good with no problem. But the limitation is the Ethernet module that I've develope are working on 10Bast-T, so is suitable just for data command sending.

   Sorry for that I'm quite not understand what's is the meant of the red colour and bold term that you show me:-     ping 192.168.2.3 -t -w 1000 -l 800 ?

   By the way, right now I'm understand what's your concern about. However I'll test it on my side and will let you know the result. Besides, if you have any updated information, please let me know. Thanks.

KahJoo

0 Kudos

1,375 Views
williamskj
Contributor I

For anyone still interested in this....

I've had a Freescale service request open for several weeks regarding my speed / buffer length issue.  (Note that this may not be the same problem that  Malaysia / KahJoo is suffering from)

Freescale managed to replicate the problem. The case was forwarded to the design centre so that the hardware could be checked. There was no fault found in the hardware. Freescale then tried a similar set of tests but the NE64 code was built using the CMX TCP/IP stack rather than the OpenTCP stack. The fault could no longer be replicated. The conclusion therefore is that this behaviour is due to a bug in the OpenTCP stack. Unfortunately, Freescale can no longer provide support for the OpenTCP stack since Viola Systems have started charging 20,000 Euros for the product. Since I don't have the time or expertise to debug the OpenTCP stack, we have decided to try the CMX stack which is not cheap but its a lot less expensive than the new (?) 'supported' OpenTCP stack.

0 Kudos

1,375 Views
Malaysia
Contributor I

Hi Karl,

   Thanks for your update and sorry for late reply. On my side, I've test out the decive as below:-

   1) I tried to ping the decives and it can be done and the reply time was ~10ms by using the cross cable.

   2) I tried to send the packet from PC to the devices and the data was out from the COMM port, and it works even I tried to send every packet by delay of 50ms. However I don't know I right or not. Here are the code that I've wrote for the testing:-

       for(i=0;i<par1;i++)
          {
            TCP_In_Msg[i]=RECEIVE_NETWORK_B();
             while(!SCI0SR1_TDRE);
             AS1_SendChar(TCP_In_Msg[i]);           
          }
         
          if(TCP_In_Msg[8]=='9')
          {
           Bit1_NegVal();
          }

For me I'm just received the packet from PC Server and then transfer out from the RS232. Am I follow you.

   3) However I tried to resend back the packet, as long as reseived the data packet from PC Server, to PC server, but after a while the MCU was look hang on there and can't receiving any more packet. I've tried to increase the delay time between data packet sending from PC server to 1s even more to 2s, the situation was same that the MCU will stop receving packet and as well sending packet back to PC server.

   4) Currently I want to test where I received the data from RS232 and send the data back to PC server and would like to see what will happens. By the way can you show me how to receive the RS232 in Interrupt Mode to received the data and send the data to PC server?

   5) The final testing that I want to tried is the MCU will just sending the data packet to PC server, preset the data need to be send like the example code from NE64_Vend_Demo project file, and find out will the sending packet will occur any problem?

   I've attached my project file to have a check if needed. Thanks.

Regards,

KahJoo

 

InternetTesting1.zip

Message Edited by t.dowe on 2009-10-20 11:04 PM
0 Kudos