Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Am 04.01.2019 um 21:15 schrieb stevestrong: Jason, thanks for your comment. I saw that no Rx packets were ever lost, no Rx/TX buffer over- or under-flow ever occurred. That finally made me think on DMA and PHY. I realized that currently my PHY works in 100Mbp half-duplex mode, and that could eventually be a problem, when many packets arrive and the PHY tries to send some data in the same time (although the PHY should probably manage this). Actually, it is the MAC that has to handle half-duplex retransmission, not the PHY. The PHY can report "half duplex" via MDIO as a result of autonegotiation, but if the MAC is not set to half duplex, too, you'll get lost TX packets. Regards, Simon Then I found on Internet a site which offers a solution for DP83848, a patch for MBED ETH lib, to work in full-duplex mode. I implemented it, and ... voila: no more lost packets in 100 tries! No more delayed packets. Success! So I can conclude that the issue was most probably due to the heavy traffic when PHY is working in half-duplex mode. Does this make sense? Anyway, thank you all for the invested time and effort, I really appreciate it. Steve -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
It makes sense. We use the DP83848 in full duplex mode on several products (thankfully) with no problems. Out of curiosity what are you working on? (if you are able to share) Regards, -Jason White -Original Message- From: lwip-users On Behalf Of stevestrong Sent: Friday, January 4, 2019 3:15 PM To: lwip-users@nongnu.org Subject: Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1) Jason, thanks for your comment. I saw that no Rx packets were ever lost, no Rx/TX buffer over- or under-flow ever occurred. That finally made me think on DMA and PHY. I realized that currently my PHY works in 100Mbp half-duplex mode, and that could eventually be a problem, when many packets arrive and the PHY tries to send some data in the same time (although the PHY should probably manage this). Then I found on Internet a site which offers a solution for DP83848, a patch for MBED ETH lib, to work in full-duplex mode. I implemented it, and ... voila: no more lost packets in 100 tries! No more delayed packets. Success! So I can conclude that the issue was most probably due to the heavy traffic when PHY is working in half-duplex mode. Does this make sense? Anyway, thank you all for the invested time and effort, I really appreciate it. Steve ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Jason, thanks for your comment. I saw that no Rx packets were ever lost, no Rx/TX buffer over- or under-flow ever occurred. That finally made me think on DMA and PHY. I realized that currently my PHY works in 100Mbp half-duplex mode, and that could eventually be a problem, when many packets arrive and the PHY tries to send some data in the same time (although the PHY should probably manage this). Then I found on Internet a site which offers a solution for DP83848, a patch for MBED ETH lib, to work in full-duplex mode. I implemented it, and ... voila: no more lost packets in 100 tries! No more delayed packets. Success! So I can conclude that the issue was most probably due to the heavy traffic when PHY is working in half-duplex mode. Does this make sense? Anyway, thank you all for the invested time and effort, I really appreciate it. Steve -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Two suspects: 1. DMA/Buffer issue from LwIP into the Ethernet Peripheral. -> Because the behavior depends on packet/traffic loading -> Do other types of traffic produce the same effect? 2. Memory corruption (perhaps unlikely due to the fact that "most" packets are making it) -> Is loading your webpage accidentally overwriting some control structure in LwIP causing the stack to hiccup? -Jason White ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Now back again to the original issue. I upgraded to v2.1.2 and the problem shows now in different form, and less frequent (only once in 10 refreshes). It seems that the delayed frame from STM comes when one packet does not get received by the client (dropped? lost?), at least Wireshark does not see it. This packet is for sure Tx-ed by the DMA from the buffer, because the OWN status bit is cleared by the DMA (can be seen from debug log). The interesting part is that the packet in question is always the same. The web page in question loads tree object, one is not found, the second is a 2.6kB GIF file and the third is a 24kB large JPG image. The issue happens always when the client (PC) requests the GIF file, then right after that the JPG file, too. The STM detects the request for GIF, sends the data (+FIN,PSH,ACK) in two consecutive packets. Then STM detects the request for JPG, sends two consecutive data packets (+PSH,ACK), wherein the second packet, which is always 162 bytes long (despite that the JPG file is much larger - strange), gets lost. It is always this second smaller packet which (sometimes) gets lost (at least not detected) and causes obviously the delay. Other times this packet in the same configuration (as second consecutive data frame) is received and everything is ok, no delay. Any idea how can I improve the situation to avoid lost of this packet? An additional info: the PHY (DM83848) works in 100mbit, half-duplex mode. -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] STM32 + lwip(modbus tcp), always timeout
There is no modbusTCP on lwIP. Go to the ones who wrote that and ask them for help. 1.3.2 is a version perhaps older than the STM32 itself, you should get a more up to date framework for your endeavours. Before you do that, try to know at least if TCP is connecting. ModbusTCP is a simple protocol, a client connects to a server and sends a request; a timeout means that either the connection or the transaction did not succeed. You can debug either with the proper tools (wireshark) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problems with a HTTP server - DHCP - etharp.c - v2.1.2
stevestrong wrote: > Just as final comment to close this issue: > > In the new Version (2.x) the DHCP should not be stopped by the application > (*do not call dhcp_stop()*), as the STM32 application does for v1.4, when an > IP address has been assigned. That has nothing to do with the new version: you should never stop DHCP when using an address assigned by it! Maybe the old version had a bug that did not delete the address when stopping the client... > > So this is not a bug, it is a feature ;). > > PS. I will not delete this topic, should serve as information for anyone > else struggling with this. How could you delete a topic from a mailing list? Mails are sent out, the archive holds them. > -- > Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html Oh, you're using nabble... :-( Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problems with a HTTP server - DHCP - etharp.c - v2.1.2
Just as final comment to close this issue: In the new Version (2.x) the DHCP should not be stopped by the application (*do not call dhcp_stop()*), as the STM32 application does for v1.4, when an IP address has been assigned. So this is not a bug, it is a feature ;). PS. I will not delete this topic, should serve as information for anyone else struggling with this. -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
