Sergio R. Caprile wrote >>>/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./ >>So no, this does not seem to be the standard STM issue... > > Oh, I see, missed that part. Should we believe the vendor ? (terrified > face)
I think there is another related bug as well. The semaphore to signal new packets is a binary one. It should be a counting one. I had it at least once, that there was a full semaphore due to really fast packages and the latter one got eventually lost. ethernetif.c Line 280 in low_level_init(): s_xSemaphore = osSemaphoreCreate(osSemaphore(SEM) , 1 ); should be: s_xSemaphore = xSemaphoreCreateCounting(ETH_RXBUFNB, 0); Sergio R. Caprile wrote > - Frame 16: bad FCS on ARP response from MCU to PC, why ? Good one! I had an old version of Wireshark, not reporting this one. Currently I'm doing a bit of research and it seems that I have a erroneous calculation of the total length of the pbuf in my RX driver. Later on, the packet is reused by etherarp for the response. I guess this could lead to the wrong CRC value. On the other hand, the CRC is calculated by HW, this should always be correct, right? What happens when LwIP or the ETH detects a corrupt CRC on RX? the packet is lost or dropped? Sergio R. Caprile wrote > - Your DHCP on UDP port 55555, turn it off, just in case, you don't seem > to be using it The UDP 55555 broadcast is a discovery broadcast of our application protocol and used. Turning of DHCP made no difference. Sergio R. Caprile wrote > - Frame 2094: Yes, 2058's ACK has been seen, but 2057's not. Then, Seq#s > jump at sometimes more than 1460, so some frames were lost, some not. > > - Frame 2162(3,5) ARP request is not seen by lwIP, frame loss > You are definitely having an event that triggers frame losses. Where is > it, I can tell. > You said this is a custom board, I had once something like this where my > driver went out of sync with the eth chip by incorrectly reading available > bytes. > Please run known to work code first, this looks to me like an > eth driver > problem I will have a closer look and eventually switch back to the original driver. Sergio R. Caprile wrote > - You say you are using tcp_poll() to enqueue data. Don't do that if you > aim for performance, that is just to avoid state machines on connection > closures and some other good stuff, not for streaming data. > You should start sending your data from your tcp_recv() parsing the > request and then keep steady sending from your tcp_sent() So, how is the best way to handle the following scenarios? The device is a measurement device, always acquisitioning data from external ADCs at 5-20 kHz, normally 18 bytes per sample. It is transfered by SPI and DMA to a cache in a FMC connected SD-RAM. The pointer handling must be done at highest priority IRQ level, even higher then ETH. a) The Client (PC) requests a large file from the SD card. Currently, I pass the request from tcp_recv() to the SD Card gatekeeper task, which reads the data page per page (64k). As soon as one page has been read, it queues a structure with some commands and control variables and as well as the pointer to the memory. That command from the queue is read by tcp_poll() and the data written using tcp_write(). Eventually, the data is freed in tcp_sent(). Also, if there was a full sndbuffer, tcp_sent() would enqueue the missing data. Between the initial request from the client and the end of transfer, I don't get any new client-requests. b) Nearly the same scenario, but the data is not from the SD-Card but directly from the SD-RAM of the current acquisition. As soon as there is a big block of data available, a command like in case a) is posted in the same queue. Scenario b) can occur by Client request or due to an external trigger signal. The responsible tasks are running on a lower priority as the tcp-thread. Sergio R. Caprile wrote >> According to lwip_stats there is no memory leak and no packet drop > Well, lwIP can only count *packet* drops, not *frame* loss. > And memory leak is tricky, is it possible you are freeing a wrong pointer > or in the wrong place ? Try sending and freeing at the same place, that is > tcp_sent(), let tcp_poll() aside for now. > Check the web server or smtp client sending functions. Currently I don't believe there is an memory issue. The behavior is independent from the amount of used data. However - for some reason there lost frames, I agree. I'll have a closer look on the drivers again, then go back to the examples. Thanks for you input! -- View this message in context: http://lwip.100.n7.nabble.com/TCP-retransmission-flooding-at-end-of-stream-tp23275p23311.html Sent from the lwip-users mailing list archive at Nabble.com. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
