Hi Rob,
I haven't observed recovery after execution resume. When RBUS is set only
reset can help. But RBUS set is always preceded by pbuf_alloc returning NULL
a few times in low_level_input. Therefore I think the problem is with memory
management in first place, at least in my case. RBUS bit being set is just a
consequence. Probably there is some race condition and PBUFs are not freed
correctly. During today's tests I observed stall caused by Hard Fault. It
happend inside ethernet_input function (etharp.c) at this line:
if (p->len <= SIZEOF_ETH_HDR) {
during p pointer dereference. The problem can be in HAL or somewhere between
FreeRTOS and lwIP.
Pozdrawiam,
Grzegorz Niemirowski
http://www.grzegorz.net/
----- Wiadomość oryginalna -----
Od: rmawatson rmawatson
Do: Mailing list for lwIP users
Wysłano: 8 października 2014 12:09
Temat: Re: [lwip-users] lwip stall
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
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
