Hi Grzegorz, Sometimes RBUS is set, sometimes not. I think this just depends whether i have broken into the code it when its in the middle of receiving some data. However, I *am* still receiving frames so I don't think there is any problem the receiving, even after the stall, the Rx Interrupt is firing, I am beginning to think the problems I am having are with either something subtle about the driver, or the PHY itself (seems less likely) . I have traced the outbound tcp packets with print statements, the whole way through the ip later to inside HAL_ETH_TransmitFrame() and it looks as though the packet is dispatched - or at least up to this point, the HAL does not present any errors. I am suspecting there is an error somewhere in the ETH_DMA that is not accounted for by stm's HAL, and the outbound packet is silently failing to send (I don't see it on wireshark). One thing to note is that if I pause execution of the mcu as soon as the 'stall' happens, and wait a few seconds, then resume, things will partially recover, although it will stall again with retransmits from the python side 3-5 seconds later, but more packets do get through the stack. Do you see similar behavior, and is your RBUS bit latched up when you get a stall? Rob.
From: [email protected] To: [email protected] Date: Wed, 8 Oct 2014 00:23:37 +0200 Subject: Re: [lwip-users] lwip stall It seems you have similar problem as me (Re: [lwip-users] lwIP hangs after some data transferred). When the stack stalls, what value do you have in the DMASR register (EthHandle.Instance->DMASR)? Is the RBUS bit set? Pozdrawiam, Grzegorz Niemirowski http://www.grzegorz.net/ ----- Wiadomość oryginalna ----- Od: rmawatson rmawatson Do: Mailing list for lwIP users Wysłano: 7 października 2014 19:33 Temat: Re: [lwip-users] lwip stall Thanks Michael, I had actually missed that and have now applied it, which seems to have fixed the intermittent speed problem, but I am still having some issues. After a number of successful packets, everything seems to stall. Looking at the wireshark capture, and TCP Output/ Input debugging here: https://docs.google.com/uc?authuser=0&id=0B9QDXbfPYFfeQVNyMG81MFdUMW8&export=download It looks as though lwip stops acking, and the python end keeps retransmitting the same packet. 58 2.257102 192.168.1.64 192.168.1.24 TCP 58 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4 59 2.556697 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4 60 3.156804 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4 61 4.356948 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4 In the lwip logs, all is well up until the first line saying: tcpip_thread : tcp_receive: duplicate seqno 664403702, so its receiving the retransmitions, however straight after this, the logging reports tcpip_thread : tcp_output: sending ACK for 664403706 which is in the function tcp_send_empty_ack() Presumably this ack has already been sent, along with the 2 byte reply data before (although this doesn't seem to be printed out as debug info), and due to there currently being more data to send, its just sending an empty ack() - fine. However, none of these acks appear on the wireshark trace. The filter is set to "eth.addr eq 22:a3:11:14:65:22", but even without any filtering and looking by eye, I cannot find these acks. I am suspecting this may well be a driver bug, but I have yet to manage to narrow it down. I've turned on all DMA error interrupts and have a handler with a loops in it that should get hit if there is anything wrong as far as the MAC goes, but so far it has not been hit. So its either the driver, or or a problem with lwip itself. But these packets never seem to get on the wire as far as I can see? Any suggestions would be greatly appreciated. Thanks Rob. > Date: Mon, 6 Oct 2014 08:36:39 -0700 > From: [email protected] > To: [email protected] > Subject: Re: [lwip-users] lwip stall > > Hi, > > actually, STM made only a partial bugfix. I've ran in the same mistake. The > do/while loop in ethernetif_input() is still missing in the CubeMX software. > > > void ethernetif_input( void const * argument ) > { > struct pbuf *p; > struct netif *netif = (struct netif *) argument; > > for( ;; ) > { > if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK) > { > do > { > p = low_level_input( netif ); > if (p != NULL) > { > if (netif->input( p, netif) != ERR_OK ) > { > pbuf_free(p); > } > } > }while(p!=NULL); > } > } > } > > > > -- > View this message in context: http://lwip.100.n7.nabble.com/lwip-stall-tp23366p23370.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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
