Andre replied to me directly. I've explained to him how to join the
mailing list and do this properly, but in the meantime, I've attached a
copy of his lwipopts.h and my subsequent reply follows, in the hope that
others can add their comments on the problem.
A second opinion from someone more familiar with the LWIP memory
allocator (we use a custom one so I haven't looked at LWIP's one in
detail) and your particular target's network driver would be helpful,
but from a quick look I think my theory about running out of pbufs is on
the right track.
Your PBUF_POOL_SIZE is only 6. Depending on the implementation of your
network driver and application, this pool may be used to store both
received packets and packets which are copied for transmission by
tcp_write().
With only 6 pbufs available for allocation and 3 of them occupied by
unacknowledged outgoing packets, you would only need 3 more allocated
anywhere else in the system to have none left for processing receive
packets, resulting in your network driver discarding all incoming
packets rather than being able to deliver them to ip_input().
As I alluded to in my first message, you should be able to confirm this
by looking at the data generated by LWIP_STATS and see if you are
getting memory allocation errors for the MEMP_PBUF_POOL type of memory
pool, which go up each time another packet is received if I'm right. To
see the error counting logic, follow the code through from
pbuf.c:pbuf_alloc() to memp.c:memp_malloc(), with reference to stats.h.
If that error is confirmed, you will need to identify where the other
three pbufs have got to and/or limit the number of consecutive calls you
make to tcp_write() whiledata has been acknowledged and/or increase
PBUF_POOL_SIZE (which would result in lwip being allocated more memory
overall), or come up with some other strategy to limit the conflicting
memory allocation.
On 2013-08-21 20:54, André P. wrote:
> Hi David,
>
> Thank you for your fast response. I have attached my lwipopts.h file.
On 2013-08-21 14:46, David Empson wrote:
On 2013-08-21 03:45, André P. wrote:
Hi,
I have an application where I stream data regularly from an LPC board to
a laptop. This works fine, until after some time the transmitter sends
two packets without waiting for an ACK, and the receiver almost
immediately acknowledges both using one packet. Somehow, the LWIP stack
does not accept this ACK, and keeps resending a package. I have attached
the Flow Graph. Why does LWIP not accept the ACK message 166213? It
keeps resending Seq 162622.
I am using LWIP 1.4.0. Thank you for your support.
The pattern looks like LWIP stopped processing the received ACK packets
after the one with Ack=162622. LWIP subsequently sent three packets with
new data (162622, 163648 and 165108), then timed out waiting for the ack
for the oldest unacknowledged packet (162622), resending it with slowing
retries: 1 second delay, then 3, 6, 12, 24, 48; all the subsequent ACKs
were not processed.
You'll probably need to look at LWIP's internal error counts to confirm
this, but my guess is that you ran out of pbufs, due to having three
outgoing packets occupying all remaining pbufs, and none are left to
store the received ACKs. If so, you need to allocate more pbufs and/or
limit the amount of transmit data you can have outstanding to ensure
there will always be free buffers for received packets.
A copy of your lwipopts.h might help to analyse the problem.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
/*
* @brief LWIP build option override file
*
* @note
* Copyright(C) NXP Semiconductors, 2012
* All rights reserved.
*
* @par
* Software that is described herein is for illustrative purposes only
* which provides customers with programming information regarding the
* LPC products. This software is supplied "AS IS" without any warranties of
* any kind, and NXP Semiconductors and its licensor disclaim any and
* all warranties, express or implied, including all implied warranties of
* merchantability, fitness for a particular purpose and non-infringement of
* intellectual property rights. NXP Semiconductors assumes no responsibility
* or liability for the use of the software, conveys no license or rights under
any
* patent, copyright, mask work right, or any other intellectual property
rights in
* or to any products. NXP Semiconductors reserves the right to make changes
* in the software without notification. NXP Semiconductors also makes no
* representation or warranty that such application will be suitable for the
* specified use without further testing or modification.
*
* @par
* Permission to use, copy, modify, and distribute this software and its
* documentation is hereby granted, under NXP Semiconductors' and its
* licensor's relevant copyrights in the software, without fee, provided that it
* is used in conjunction with NXP Semiconductors microcontrollers. This
* copyright, permission, and disclaimer notice must appear in all copies of
* this code.
*/
#ifndef __LWIPOPTS_H_
#define __LWIPOPTS_H_
//#define LWIP_DEBUG
/* RTOS build */
#define NO_SYS 0
/* Use LWIP timers */
#define NO_SYS_NO_TIMERS 0
/* Need for memory protection */
#define SYS_LIGHTWEIGHT_PROT 1
/* 32-bit alignment */
#define MEM_ALIGNMENT 4
/* pbuf buffers in pool. In zero-copy mode, these buffers are
located in peripheral RAM. In copied mode, they are located in
internal IRAM */
#define PBUF_POOL_SIZE 6
/* No padding needed */
//AP: #define ETH_PAD_SIZE 0
#define ETH_PAD_SIZE 0
#define IP_SOF_BROADCAST 1
#define IP_SOF_BROADCAST_RECV 1
/* The ethernet FCS is performed in hardware. The IP, TCP, and UDP
CRCs still need to be done in hardware. */
#define CHECKSUM_GEN_IP 1
#define CHECKSUM_GEN_UDP 1
#define CHECKSUM_GEN_TCP 1
#define CHECKSUM_CHECK_IP 1
#define CHECKSUM_CHECK_UDP 1
#define CHECKSUM_CHECK_TCP 1
#define LWIP_CHECKSUM_ON_COPY 1
/* Use LWIP version of htonx() to allow generic functionality across
all platforms. If you are using the Cortex Mx devices, you might
be able to use the Cortex __rev instruction instead. */
#define LWIP_PLATFORM_BYTESWAP 0
/* Non-static memory, used with DMA pool */
#ifdef __CODE_RED
// AP:
#define MEM_SIZE (10 * 1024)
//#define MEM_SIZE (12 * 1024)
#else
#define MEM_SIZE (12 * 1024)
#endif
/* Raw interface not needed */
#define LWIP_RAW 0
/* DHCP is ok, UDP is required with DHCP */
#define LWIP_DHCP 0
#define LWIP_UDP 0
/* Hostname can be used */
//#define LWIP_NETIF_HOSTNAME 1
//#define LWIP_BROADCAST_PING 1
/* MSS should match the hardware packet size */
#define TCP_MSS 1460
//AP: #define TCP_SND_BUF (2 * TCP_MSS)
#define TCP_SND_BUF (4 * TCP_MSS)
//AP: #define LWIP_SOCKET 1
#define LWIP_SOCKET 1
#define LWIP_NETCONN 1
#define MEMP_NUM_SYS_TIMEOUT 300
#define LWIP_STATS 1
#define LINK_STATS 0
#define LWIP_STATS_DISPLAY 1
/* There are more *_DEBUG options that can be selected.
See opts.h. Make sure that LWIP_DEBUG is defined when
building the code to use debug. */
#define TCP_DEBUG LWIP_DBG_OFF
#define ETHARP_DEBUG LWIP_DBG_OFF
#define PBUF_DEBUG LWIP_DBG_ON
#define IP_DEBUG LWIP_DBG_OFF
#define TCPIP_DEBUG LWIP_DBG_OFF
#define DHCP_DEBUG LWIP_DBG_OFF
#define UDP_DEBUG LWIP_DBG_OFF
/* This define is custom for the LPC EMAC driver. Enabled it to
get debug messages for the driver. */
#define EMAC_DEBUG LWIP_DBG_OFF
#define DEFAULT_THREAD_PRIO (tskIDLE_PRIORITY + 1)
#ifdef __CODE_RED
#define DEFAULT_THREAD_STACKSIZE (512)
#else
#define DEFAULT_THREAD_STACKSIZE (256)
#endif
#define DEFAULT_ACCEPTMBOX_SIZE 6
#define DEFAULT_ACCEPTMBOX_SIZE 6
#define DEFAULT_TCP_RECVMBOX_SIZE 6
#define DEFAULT_UDP_RECVMBOX_SIZE 6
/* TCPIP thread must run at higher priority than MAC threads! */
#define TCPIP_THREAD_PRIO (DEFAULT_THREAD_PRIO +
configMAX_PRIORITIES - 1)
#ifdef __CODE_RED
#define TCPIP_THREAD_STACKSIZE (512)
#else
#define TCPIP_THREAD_STACKSIZE (256)
#endif
#define TCPIP_MBOX_SIZE 6
#endif /* __LWIPOPTS_H_ */
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
