Hello,
I'm trying to write a firmware update through Web server on the board AT91SAM9620. For this I'm using a form with ENCTYPE="multipart/form-data" and a function cgi_process_data(). Very often the file has been damaged. (crc32 checking don't pass) It looks like that the file uploading session has been terminated incorrect (the web server does not reloads the page.) I've tried with IE, FireFox and Chrome a result is the same. I've noticed that with FireFox these problem is more often. The file size is about 200KB. Using debug version TCP/IP library in terminal window appear:"TCP ERR: Out of range sequence number received" at the time of the file is uploading. I think that these errors is the reason of file damage. I'm using RL-ARM v4.12 Has anyone tried to send the file through http on the board AT91SAM9620 ? How can I fix this problem? Any ideas please?
Best regards Taris T
I have the same problem. I also try to upload a file through the Webserver. After receiving 3 or 4 TCP Frames I get an "TCP ERR: Out of range sequence number received" error. My Testfile has a Size of 9KB. It tried to upload with Firefox 6 and with IE8.
What causes this problem? Any ideas? What can I try?
I'm using RL-ARM 4.13 / MDK-ARM 4.22 with an Cortex M3 (LM3S9B90), LM3S_EMAC.C Rev.:V4.20 with Keil RTX
Regards, Marco
Hello again,
I have checked the communication between the Webserver and the Cortex-M3.
Wireshark marks the 4th TCP frame from the Webserver with "TCP Window Full". This frame doesn't show up in the debug view of the Cortex-M3. The next frame (5th) causes the "TCP ERR: Out of range sequence number received" error. This is correct, because the sequence number of the 5th frame is not the expected sequence number, because the 4th frame is missing...
The question is now: why does the Cortex-M3 lost the 4th frame? Maybe it has something to do with the "TCP Window Full" flag?
now I have seen, that the Cortex sends an ACK (A2) to frame 4. But frame 4 didn't show up in the Cortex debug view?!? Frame 3 is processed normally and ACK (A1) by the Cortex. Frame 4 is not processed but also ACK (A2) by the Cortex.
3 Webserver -> Cortex TCP [TCP segment of a reassembled PDU] Seq=2197 4 Webserver -> Cortex TCP [TCP Window Full] [TCP segment of a reassembled PDU] Seq=3657 A1 Cortex -> Webserver TCP [ACK] Seq=1 Ack=2197 Win=4380 Len=0 5 Webserver -> Cortex TCP [TCP Window Full] [TCP segment of a reassembled PDU] Seq=5117 A2 Cortex -> Webserver TCP [ACK] Seq=1 Ack=3657 Win=4380 Len=0
Hi,
is there anyone who has tried to to send a file through http sucessfully? Maybe there is a problem with the configuration of my ethernet controller?
I don't believe the error is in the Keil-Stack.
I have located where my problem is: the RX FIFO overflows! The FIFO has a size of 2 KB. Is it possible to reduce the tcp window size of the Webserver to 2 KB? I tried to change the TCP_DEF_WINSIZE from 4380 to 2000 but as i can see with Wireshark, the window size is still 4380.
"the RX FIFO overflows"
What "Rx FIFO" is that?
Isn't that just to do with receiving bytes from the line?
The "Window Size" is at the TCP layer: it is the number of unacknowledged TCP packets "in-flight" - so it shouldn't be related to Ethernet FIFO size...?
Hi Andrew,
thanks for your answer. It's the receive fifo of the ethernet controller of the Luminary LM3S9B90.
The PC tries to send me TCP packets until my window is "full" (4380 Bytes). But my receive fifo is just 2KB wide. The cortex has no chance to handle the received data, because the PC is to fast. The packets arrive in micro seconds...
0.025828 172.16.232.217 172.16.230.100 TCP 60 [ACK] Seq=1 Ack=737 Win=4380 0.000012 172.16.230.100 172.16.232.217 TCP 1514 [TCP segment] 0.000007 172.16.230.100 172.16.232.217 TCP 1514 [TCP Window Full] [TCP segment]
After I acknowledge the last packet, the PC sends me 2 TCP frames in 19 microseconds.
I thought now to reduce the window size to the size of the fifo, so the fifo won't overflow.
In 100 MBit ethernet 1500 bytes need about 120 us to propagate on the wires. So your timings are incorrect. They are measured when the packets are queued on PC, not when they are actually transmitted.
It must be something else, not the speed of PC, that is a problem.
Hi Franc,
what else could it be? I have only two tasks running (Keil RTX) und running the ethernet in interrupt mode (no polling). Task Ethernet:
__task void _task_ethernet (void) { if( ethernet_init () != ETHERNET_RET_OK ) { _DBG(EMERGENCY,"Ethernet init failed - Deleting _task_ethernet"); os_tsk_delete_self(); } while(1) { main_TcpNet (); os_tsk_pass(); } }
Task TCP_TICK:
__task void _task_tcp_tick (void) { os_itv_set (100); while(1) { timer_tick (); os_itv_wait (); } }
The function that processes the request is empty:
void cgi_process_data (U8 code, U8 *dat, U16 len) { /* This function is called by HTTP server to process the returned Data */ switch (code) { case 0: /* Url encoded form data received. */ break; case 1: /* Filename for file upload received as encoded by the browser. */ return; case 2: /* File content data received. Write data to a file. */ return; case 3: /* File upload finished. Close a file. */ return; case 4: /* XML encoded content type, last packet. */ return; case 5: /* XML encoded as under 4, but with more to follow. */ return; default: /* Ignore all other codes. */ return; } return; }
The tick interval in net_config.c is defined to 100ms:
#define TICK_INTERVAL 100
even with this configuration I get the RX-FIFO overflow. Maybe the 120us per packet are still to fast for the cortex? Do you have any idea what could cause this problem? Maybe I messed up something in the configuration of the cortex?
Take HTTP_upload demo example for ek-lm3s8962 and adapt it for your board. If this one runs, you have software problems in your application.
Check also the cpu frequency. Is it 50 MHz or more? LM3S9B90 can run at 80 MHz.
Thanks Franc,
you made my day!
I screwed up the clock configuration. I used a wrong flag... Now the cortex is running in fullspeed with 80 MHz. I can't believe that I didn't recognize this earlier.
Sometimes you lose sight of the forest for the trees :-)
Thanks a lot.