I have been trying to create a TCP server for some time now with my M52233DEMO board. I am using InterNiche Lite's minisockets and Niche Task. I have tried to modify the HTTP server used in the example application (freescale_http_server) to be a simple TCP server listening on port 5005. When it receives data on this port it should then be outputted on the serial port (UART1). The changes I have made to the HTTP server include:
changing the port number
changing the http_init() function to exclude menu initialisation
changing the state machine (freescale_http_process() ) to exclude file uploads, and flash erasing and file sending)
modifying the read header function (freescale_http_read_header() ) to simply output any received data to the serial port.
My code for this task is attached
I can connect to the server and send data to it but herein lies my problem:
Connection works fine, but when I try to send data to the server, it takes at least 3 seconds for the server to receive and output this data (m_listen callback function is not called for received data) on the serial port. thereafter data is received and retransmitted quickly. The delay only happens for the first data load. The socket also doesn't close properly. (m_listen callback function is not called).
What could I be doing wrong? The HTTP server works correctly and is almost exactly the same.
I could run your test code and it works fine here. I noticed a few times the problem you mentioned.
If you plug a serial cable on the uart connector and open your serial in 115200, 8, N, 1 you´ll be able to see the debug information.
When the problem you mentioned occurs, i noticed on the serial output it keeps writing messages like " illegal instruction" or "error on operand read" and things like that. It also quit pinging, listening on the tcp server routine and listening on the http server routine also.
I don´t know what made it act like this, but a good way to simulate it is to open, close and reopen the connection on port 5005 in a fast way.
Please, if someone can explain what possibly could be happening i would apreciate a lot.
Bad news, I ran your code without duplicating the problem you described. Attached is the complete project used to test your code. I loaded the code into flash and reset. I then used Hyperterm to send randomly typed characters. I used Ethereal to monitor activity. From the time I connected to the server and typed the first character was about 2.8 seconds. From the first character to ACK from the server was about 0.00072 seconds. I did not notice any delay in the character showing up in another Hyperterm window on COM2 monitoring serial data.
I did change the "outchar" function call to "out_char". This was due to a compile error not finding outchar. I looked in io.c and found a reference to out_char so I used that.
Some time later I made the following changes.
The 'for' loop use to send data to the serial port was changed to "for (j=0;j<length;j++)" from "for (j=0;j<=length;j++)". This was causing a buffer overread and resulted in random characters being displayed on the serial port.
I also attached the Ethereal output from the latest test. Maybe too much data.
Do you still have the http server running. The TCP server works fine for me when the http task is running but not when I disable it. Please try running the TCP server with the http server disabled. Try putting printf("close") in the callback function under CLOSE. to see if the socket closes properly when you hit disconnect in hyperterminal. Try having hyperterminal open in the disconnected state, then typing a character. In my case, hyperterminal connects and then waits for 3 seconds and then sends the character. With the http server running the character is sent immediately. I think it has something to do with the install menu function in the http_init function of the http server because if i comment this out i get the same TCP server problem, even when the http server is running.
I have been doing some debugging and found that when the install menu command is present the TCP server advertises to hyperterminal that the window size is 4656. When the install menu command is commented out, the advertised window size is 0. Hence hyperterminal waits for some time before sending data.
It makes no sense to me at the moment so any ideas will be appreciated.
I saw that Kremer tried the program with the http task disabled. I did the same. I also tried just commenting out the install menu command for the http server and it ran with no observable delays. I tried having hyperterm disconnected and started typing, this yielded a connection time of less than 1ms before the first character was sent, too fast to even notice. The characters showed up on the serial port with no noticeable delay.
I have been experimenting with Kremers version and found that if I connect and disconnect very quickly the demo board will eventually start giving error messages. This is indicative of what I saw when I did not get the proper open/close sequencing. Probably not helpful for your issue as his code is using session structures based on the http code.
Attached is the capture with the menu disabled and the capture with the HTTP server task disabled.
Being somewhat new to network programming, I can only suggest that the problem you are seeing may have something to do with the switch between your computer and the demo board, or something to do with high volume network traffic, or .... Hmmmm. I really don't have many ideas to help on this one. I'm running windows XP Pro on a very fast machine (Dell Precision 690 Dual processor) with a 1G network card. There is a 10/100 switch between the PC and the demo board.
I disabled the http server as you mentioned (commented the newtasking on tk_misc.c for the EMG) but i had no problems with the tcp server. Even when i tried to fast disconnect and reconnect.
Did you check if, when those delays happens, the demo board is printing random messages on it´s uart like i mentioned in my previous post?
Basically, if you are running the project ColdFire_Lite.mcp and you just added a TCP_server.c to it (i just did it) you must define the macro NPDEBUG to see the results of the serial debug messages on the uart (115200, 8 , N, 1).
#define NPDEBUG 1 /* turn on debugging dprintf()s */
Please check if the chip is printing those messages when the problem happens there.
It happens randomly here, but quite often. Any help solving this undefined state is apreciated.