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
"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.
Regards, Marco
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.