LwIP sample fail

15 replies [Last post]

Mon, 2012-07-02 07:27

tjoAG

Offline

Joined: 2012-05-30

I'm using the lwIP sample program to test my hardware.

I'm using LPC1788 at 120 MHZ and the DP83848 PHY

I use the EA1788 TCP Echo sample as a stand alone.

When I set it to 10 mbit (the PHY_USE_100MBS in the lpc_emac_config.h to zero) the sample program works fine.

But when I set it to 100 mbit (the PHY_USE_100MBS to 1) it will assert after few seconds.

It is something with the pBuf reference count.
"pbuf_free: p->ref > 0:628 in file ..\..\..\..\..\..\..\lwip_lpc\lwip-1.4.0\src\core\pbuf.c"

Same place every time.

Is it hardware issues?
Speed issues that the lwIP cant handle the pbufs fast enough?

From debug:

sys_timeout: 2000613c msecs=1000 handler=ip_reass_timer arg=00000000
sys_timeout: 20006128 msecs=5000 handler=arp_timer arg=00000000
sys_timeout: 20006114 msecs=60000 handler=dhcp_timer_coarse arg=00000000
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
Starting LWIP TCP echo server...
netif: IP address of interface set to 0.0.0.0
netif: netmask of interface set to 0.0.0.0
netif: GW address of interface set to 0.0.0.0
pbuf_alloc(length=153: en0
IP header:
+-------------------------------+
| 4 | 5 | 0x00 | 336 | (v, hl, tos, len)
+-------------------------------+
| 0 |000| 0 | (id, flags, offset)
+-------------------------------+
| 255 | 17 | 0xba9d | (ttl, proto, chksum)
+-------------------------------+
| 0 | 0 | 0 | 0 | (src)
+-------------------------------+
| 255 | 255 | 255 | 255 | (dest)
+-------------------------------+
netif->output()pbuf_free(20003244)
pbuf_free: deallocating 20003244
sct calling h=dhcp_timer_fine arg=00000000
tcpip: dhcp_fine_tmr()
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
sct calling h=ip_reass_timer arg=00000000
tcpip: ip_reass_tmr()
sys_timeout: 2000613c msecs=1000 handler=ip_reass_timer arg=00000000
sct calling h=dhcp_timer_fine arg=00000000
tcpip: dhcp_fine_tmr()
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
sct calling h=dhcp_timer_fine arg=00000000
tcpip: dhcp_fine_tmr()
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
sct calling h=ip_reass_timer arg=00000000
tcpip: ip_reass_tmr()
sys_timeout: 2000613c msecs=1000 handler=ip_reass_timer arg=00000000
sct calling h=dhcp_timer_fine arg=00000000
tcpip: dhcp_fine_tmr()
pbuf_alloc(length=308)
pbuf_alloc(length=308) == 20003244
pbuf_header: old 2000328c new 20003284 (8)
inet_chksum_pseudo(): checksumming pbuf 20003244 (has next 00000000)
inet_chksum_pseudo(): pbuf chain lwip_chksum()=20fb
pbuf_header: old 20003284 new 20003270 (20)
ip_output_if: en0
IP header:
+-------------------------------+
| 4 | 5 | 0x00 | 336 | (v, hl, tos, len)
+-------------------------------+
| 1 |000| 0 | (id, flags, offset)
+-------------------------------+
| 255 | 17 | 0xba9c | (ttl, proto, chksum)
+-------------------------------+
| 0 | 0 | 0 | 0 | (src)
+-------------------------------+
| 255 | 255 | 255 | 255 | (dest)
+-------------------------------+
netif->output()pbuf_free(20003244)
pbuf_free: deallocating 20003244
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
pbuf_alloc(length=308)
pbuf_alloc(length=308) == 20003244
pbuf_header: old 2000328c new 20003284 (8)
inet_chksum_pseudo(): checksumming pbuf 00015e (-14)
ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x0 (0x0, 0x0, 0xffffffff)
ip_input: UDP packet to DHCP client port 68
ip_input: DHCP packet accepted.
ip_input:
IP header:
+-------------------------in lwip_chksum()=7601
pbuf_header: old 200002f0 new 200002dc (20)
ip_output_if: en0
IP header:
+-------------------------------+
| 4 | 5 | 0x00 | 336 | (v, hl, tos, len)
+-------------------------------+
| f_free: deallocating 20000758
pbuf_header: old 20000d80 new 20000d8e (-14)
ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x0 (0x0, 0x0, 0xffffffff)
ip_input: UDP packet to DHCP client port 68
ip_input: netif->ip_addr 0x0 (0x0, 0x0, 0xffffffff)
ip_input: UDP packet to DHCP client port 68
ip_input: DHCP packet accepted.
ip_input:
IP header:
+-------------------------------+
| 4 | 5 | 0x00 | 328 | (v, hl, tos, len)
+-------------------------------+
| 17564 |000| 0 | (id, flags, offset)
+-------------------------------+
| 128 | 17 | 0xd7dd | (ttl, proto, chksum)
+-------------------------------+
| 10 | 35 | 19 | 9 | (src)
+-------------------------------+
| 255 | 255 | 255 | 255 | (dest)
+-------------------------------+
ip_input: p->len 328 p->tot_len 328
pbuf_header: old 200013a6 new 200sct calling h=dhcp_timer_fine arg=00000000
tcpip: dhcp_fine_tmr()
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 20000140
pbuf_free(20000140)
pbuf_free: 20000140 has ref 1, ending here.
sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
pbuf_free(20000140)
pbuf_free: deallocating 20000140
pbuf_free(20001fb8)
pbuf_free: deallocating 20001fb8
pbuf_header: old 200025e0 new 200025ee (-14)
ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x0 (0x0, 0x0, 0xffffffff)
ip_input: UDP packet to DHCP client port 67
ip_input: packet not for us.
pbuf_free(200025d0)
pb)=ffff
pbuf_header: old 20002c1a new 20002c22 (-8)
pbuf_free(20002be8)
pbuf_free: deallocating 20002be8
pbuf_header: old 20000150 new 2000015e (-14)
IP (len 352) is longer than pbuf (len 28), IP packet dropped.
pbuf_free(20000140)
pbuf_free: p->ref > 0:628 in file ..\..\..\..\..\..\..\lwip_lpc\lwip-1.4.0\src\core\pbuf.c

Average:

Your rating: None

Mon, 2012-07-02 10:15

wellsk

Offline

Joined: 2011-05-17

I'll try this here on my board and see if I can replicate and isolate the issue. I do see an issue in the log you posted that is very helpful.

A few questions on your setup...
Are you using the default Keil project with default optimization? If not, which toolchain are you using (IAR, or GNU) or what is the current optimization level?
Can you attach your lwipopts.h and lpc_emac_config.h files to this post for the LWIP/PHY/EMAC build options?
Which configuration are you using (DRAM, IRAM, FLASH)? This looks like the FLASH or IRAM build.
Are you running this with the Embedded Artists LCP1788 based board?

Enabling the "UDP_LPC_EMAC" debug option in lwipopts.h will turn on driver debug messages and help with driver level pbuf debugging for the transmit pbuf reclaim function.

pbuf_alloc(length=42) == 20000140

This looks like the DHCP out pbuf for transmit.

pbuf_free(20000140)
pbuf_free: 20000140 has ref 1, ending here.

The zero-copy transmit function adds a ref to the count, so on transmit exit, the pbuf can't be de-allocated yet. This is normal. The intention is for the transmit pbuf to be de-allocated only when it has actually been transmitted.

sys_timeout: 20006100 msecs=500 handler=dhcp_timer_fine arg=00000000
pbuf_free(20000140)

I see a free of the transmit pbuf here, but can't tell from the debug log whether the pbuf is being de-allocated due to transmit or from something else. Maybe the DHCP code is de-allocating the buffer before it's being sent? I'm not sure what this free() is here.

pbuf_free(20000140)

I see a de-allocation of this pbuf again, but it doesn't exist at this point - it was de-allocated on the 2nd pbuf_free() - so LWIP throws an assertion. Like the previous pbuf_free(), I'm not sure what called this one.

The issue appears to be something else de-allocating the pbuf while it's in the transmit queue. Having the call dump from the assertion would be very helpful here, but I can figure that out if I can repeat this issue. The driver doesn't handle any transmit timeout options and will always attempt to re-send a pbuf/packet until it succeeds. The driver also assumes it controls the free ot the pbuf after it has been queued for transmit.

If you disable DHCP and use a static IP, does everything work normally?
...Or if you make the following modification to the dhcp_delete_msg() function in the dhcp.c file, does it work correctly? (I'm really not sure this issue is DHCP pbuf related yet, so please take this change lightly).

/**
 * Free previously allocated memory used to send a DHCP request.
 *
 * @param dhcp the dhcp struct to free the request from
 */
static void
dhcp_delete_msg(struct dhcp *dhcp)
{
  LWIP_ERROR("dhcp_delete_msg: dhcp != NULL", (dhcp != NULL), return;);
  LWIP_ASSERT("dhcp_delete_msg: dhcp->p_out != NULL", dhcp->p_out != NULL);
  LWIP_ASSERT("dhcp_delete_msg: dhcp->msg_out != NULL", dhcp->msg_out != NULL);
#if 0 // Added this to remove DHCP pbuf de-allocaiton
  if (dhcp->p_out != NULL) {
    pbuf_free(dhcp->p_out);
  }
#endif
  dhcp->p_out = NULL;
  dhcp->msg_out = NULL;
}

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Tue, 2012-07-03 00:01

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin Wells

I'm using the default KEIL project with default optimization level. I think is set at level 3 (max)
I using the FLASH configuration and have also tried the IRAM config. Same result. It is as default as possible.
I'm not running the EA LPC1788 board but a custom one. It is a "upgrade" from a old one we have running with LPC2478 MCU.
I guess it is pretty similar to the EA platform... (Haven't seen the schematics)

I have attachef the lwiopts.h and the lpc_emac_config.h

I have enabled the UDP_LPC_EMAC and added the debug messages to this post.. See below.
I also have added the call stack. Maybe it helps..

I do have made some small modification.

1: I have redirected the debug output from the UART to the ITM (Serial out). I think it has nothing to do with the issue
2: I have changed the members of PHY_STATUS_TYPE structure. (Old: phy_speed_100mbs:1, changed to phy_speed_100mbs:2) It seems that in the "lpc_phy_init", there value is init to 2. But that never did happen because of the ":1"? So when it was set to 10 mbit and no duplex in the header file, the init code never set the LPC register for that
("if (physts.phy_speed_100mbs != olddphysts.phy_speed_100mbs)" and "if (physts.phy_full_duplex != olddphysts.phy_full_duplex)" was never true, so register never set in EMAC register)

So the question is why does this only happen with the speed of 100 mbit and not by 10 mbit? For me it seems to be something with the increased speed and the buffer handling?

I will try the suggestion with the static IP and the code patch later. I will post the results as soon as possible

Thanks for the help

Thomas

Debug with UDP_LPC_EMAC:

Preview	Attachment	Size
	lpc_emac_config.h	3.66 KB
	lwipopts.h	3.76 KB
	call stack.png	34.86 KB

Tue, 2012-07-03 00:06

tjoAG

Offline

Joined: 2012-05-30

Forgot one important detail :-)

The RMII signals are routed through a high speed buffer (74CBTLV16929). It has signal latency of 0.25 ns, so it should not matter.

Thomas

Tue, 2012-07-03 00:15

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin

I finished the other tests.

Using static IP did not work, either did the dhcp_delete_msg patch

Debug when using static IP

sys_timeout: 200060b0 msecs=1000 handler=ip_reass_timer arg=00000000
sys_timeout: 2000609c msecs=5000 handler=arp_timer arg=00000000
Starting LWIP TCP echo server...
netif_set_ipaddr: netif address being changed
netif: IP address of interface set to 10.35.16.200
netif: netmask of interface set to 255.255.255.0
netif: GW address of interface set to 10.35.19.1
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000138
lpc_rxqueue_pbuf: pbuf packet queued: 20000138 (free desc=7)
pd interface en IP addr 10.35.16.200 netmask 255.255.255.0 gw 10.35.19.1
netif: setting default interface en
sct calling h=ip_reass_timer arg=00000000
tcpip: ip_reass_tmr()
sys_timeout: 200060b0 msecs=1000 handler=ip_reass_timer arg=00000000
sct calling h=ip_reass_timer arg=00000000
tcpip: ip_reass_tmr()
sys_timeout: 200060b0 msecs=1000 handler=ip_reass_timer arg=00000000
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 200031f8
lpc_low_level_output: pbuf packet(20003208) sent, chain#=0, size = 42 (index=0)
pbuf_free(200031f8)
pbuf_free: 200031f8 has ref 1, ending here.
lpc_tx_reclaim_st: Freeing packet 200031f8 (index 0)
pbuf_free(200031f8)
pbuf_free: deallocating 200031f8
lpc_rxqueue_pbuf: pbuf packet queued: 20000138 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(20000138)
pbuf_free: deallocating 20000138
lpc_rxqueue_pbuf: pbuf packet queued: 20000750 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(20000750)
pbuf_free: deallocating 20000750
lpc_rxqueue_pbuf: pbuf packet queued: 20000d68 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 20000d78 new 20000d86 (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20000d68)
pbuf_free: deallocating 20000d68
sct calling h=ip_reass_timer arg=00000000
tcpip: ip_reass_tmr()
sys_timeout: 200060b0 msecs=1000 handler=ip_reass_timer arg=00000000
lpc_rxqueue_pbuf: pbuf packet queued: 20001380 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 20001390 new 2000139e (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20001380)
pbuf_free: deallocating 20001380
lpc_rxqueue_pbuf: pbuf packet queued: 20001998 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 200019a8 new 200019b6 (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20001998)
pbuf_free: deallocating 20001998
lpc_rxqueue_pbuf: pbuf packet queued: 20001fb0 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 20001fc0 new 20001fce (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20001fb0)
pbuf_free: deallocating 20001fb0
lpc_rxqueue_pbuf: pbuf packet queued: 200025c8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(200025c8)
pbuf_free: deallocating 200025c8
lpc_rxqueue_pbuf: pbuf packet queued: 20002be0 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(20002be0)
pbuf_free: deallocating 20002be0
lpc_rxqueue_pbuf: pbuf packet queued: 20000138 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 20000148 new 20000156 (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20000138)
pbuf_free: p->ref > 0:628 in file ..\..\..\..\..\..\..\lwip_lpc\lwip-1.4.0\src\core\pbuf.c

Tue, 2012-07-03 10:14

wellsk

Offline

Joined: 2011-05-17

>I'm not running the EA LPC1788 board but a custom one. It is a "upgrade" from a old one we have running with LPC2478 MCU.
Which 17xx device is on that board? There are different variations of the device which will have an effect on LWIP operation (different amounts of memory).

>lpc_low_level_input: Packet dropped with errors (0xffffffff)
The packet storage area seems to be corrupt or the incoming packet via MII is really messed up. Packets -are- being received, but being DMA'd to memory that might not be usable with the MAC controller.

In the 17xx, MAC descriptors and buffers can only be located in peripheral IRAM (address 0x4000xxxx) or off-chip memory (address 0x8xxxxxxx - 0xDxxxxxxx). The 17xx projects are careful to place EMAC descriptors and buffers into either of these regions. See the typical scatter map below for FLASH/IRAM use.

;   Keil scatter loading file
;-------------------------------------------------------------------------------------

; Load region is in internal FLASH, 256KBytes
FLASH 0x00000000 0x40000 {
  ; All code and RO data in in FLASH
  ER_RO 0x00000000 0x10000 {
    startup_ea1788.o (RESET, +FIRST)
    *.o (+RO)
  }

    ; All non-DMA related RW/ZI data is in internal IRAM
  ISRAM 0x10000000 0x10000 {
    *.o (+RW)
    *.o (+ZI)
  }

  ; DMA buffers need to be located in peripheral RAM
  PIRAM 0x20000000 0x8000 {
    lpc17_emac.o (+RW, +ZI)
	mem.o (+RW, +ZI)
	memp.o (+RW, +ZI)
  }
}

>2: I have changed the members of PHY_STATUS_TYPE structure. (Old: phy_speed_100mbs:1, changed to phy_speed_100mbs:2) It seems that in the "lpc_phy_init", there value is init to 2. But that never did happen because of the ":1"? So when it was set to 10 mbit and no duplex in the header file, the init code never set the LPC register for that
>("if (physts.phy_speed_100mbs != olddphysts.phy_speed_100mbs)" and "if (physts.phy_full_duplex != olddphysts.phy_full_duplex)" was never true, so register never set in EMAC register)
>
>So the question is why does this only happen with the speed of 100 mbit and not by 10 mbit? For me it seems to be something with the increased speed and the buffer handling?
This is odd, I can't explain this yet. I'll look at this bit here and apply a fix if needed.

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Wed, 2012-07-04 04:36

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin Wells

>Which 17xx device is on that board? There are different variations of the device which will have an effect on LWIP operation (different amounts of memory).

The MCU is the LPC1788 FBD208 with 512 kB flash

>The packet storage area seems to be corrupt or the incoming packet via MII is really messed up. Packets -are- being received, but being DMA'd to memory that might not be usable with the MAC controller.

The lpc1788 has usable PRAM for EMAC at:
0x20000000 - 0x20001FFF
0x20020000 - 0x20003FFF
0x20004000 - 0x20007FFF

The scatter file in the TCPEcho sample set the lpc17_emac.0 to address 0x20000000. So that should be fine
In KEIL it is possible to memory assign C-files to specific regions in memory from within the GUI. Isn't that the same as set it in a scatter file?

Would it be an idea to move the lpc17_emac.0 to address 0xA0000000 in external SDRAM to see if that helps? (I would like using the PRAM because of the speed)

Even if the received packet is badly corrupted, why is result a missing ref count in a structure? Receiving corrupted frames will eventually happen on a network::

Thomas

EDIT:

I have tried reading out status from the PHY when the error occur. No remote faults or other faults reported by the PHY. Speed settings, link status etc. seems to be ok.

mem_free: mem->used ASSET:

New debug trace, where I had a breakpoint in the "lpc_update_phy_sts". After I have run a few time from the break point I get this when in 100 mbit mode. Does not happen in 10 MBit mode

Starting LWIP TCP echo server...
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 200000c8
lpc_rxqueue_pbuf: pbuf packet queued: 200000c8 (free desc=3)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 200006e0
lpc_rxqueue_pbuf: pbuf packet queued: 200006e0 (free desc=2)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000cf8
lpc_rxqueue_pbuf: pbuf packet queued: 20000cf8 (free desc=1)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20001310
lpc_rxqueue_pbuf: pbuf packet queued: 20001310 (free desc=0)
lpc_rxqueue_pbuf: pbuf packet queued: 200000c8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(200000c8)
pbuf_free: deallocating 200000c8
lpc_rxqueue_pbuf: pbuf packet queued: 200006e0 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(200006e0)
pbuf_free: deallocating 200006e0
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 200000c8
lpc_low_level_output: pbuf packet(200000d8) sent, chain#=0, size = 42 (index=0)
pbuf_free(200000c8)
pbuf_free: 200000c8 has ref 1, ending here.
lpc_rxqueue_pbuf: pbuf packet queued: 20000cf8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_free(20000cf8)
pbuf_free: deallocating 20000cf8
lpc_tx_reclaim_st: Freeing packet 200000c8 (index 0)
pbuf_free(200000c8)
pbuf_free: deallocating 200000c8
lpc_rxqueue_pbuf: pbuf packet queued: 20001310 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
pbuf_header: old 20001320 new 2000132e (-14)
ip_input: iphdr->dest 0xff13230a netif->ip_addr 0xc810230a (0x13230a, 0x10230a, 0xff000000)
ip_input: packet not for us.
pbuf_free(20001310)
pbuf_free: deallocating 20001310
lpc_rxqueue_pbuf: pbuf packet queued: 200000c8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_low_level_output: pbuf packet(200000d8) sent, chain#=0, size = 42 (index=1)
pbuf_free(200000c8)
pbuf_free: deallocating 200000c8
mem_free: mem->used:336 in file ..\..\..\..\..\..\..\lwip_lpc\lwip-1.4.0\src\core\mem.c

Thu, 2012-07-05 12:36

wellsk

Offline

Joined: 2011-05-17

Hi Thomas,

Forget anything I ever said about the PRAM, your are right here, your memory is setup correctly. Sorry about going in the wrong direction here.

>The MCU is the LPC1788 FBD208 with 512 kB flash
I was interested in the device number to get an idea of how much internal memory was supported. The following debug messages...

lpc_low_level_input: Packet dropped with errors (0xffffffff)

...usually occur when buffers are attempted to be used with memory that cannot be used for DMA with Ethernet and were pre-populated with 0xFF's. I don't think this is the case here, but just wanted to make sure there was enough memory mapped there. There is probably enough memory, I think your ok here.

>In KEIL it is possible to memory assign C-files to specific regions in memory from within the GUI. Isn't that the same as set it in a scatter file?
With the 17xx, to get the most out of internal IRAM, you'll need to use a scatter file. For RW/ZI data is assigned to IRAM that can't be used for DMA. pbufs, memory allocaiton, descriptors/buffers are assigned to DMA-capable IRAM. For the 18xx/43xx, the dialog can be used.

>Would it be an idea to move the lpc17_emac.0 to address 0xA0000000 in external SDRAM to see if that helps? (I would like using the PRAM because of the speed)
Probably not unless you really need the extra memory, I don't think the issue is memory or placement related.

>Even if the received packet is badly corrupted, why is result a missing ref count in a structure? Receiving corrupted frames will eventually happen on a network::
This is a legitimate bug. I *can* repeat this issue here, and will provide a fix (see below) for this. This issue occurs when a RX packet fails, the RX packet queue is reset, and a non-NULL pointer is returned to the caller in this condition. When this failure occurs, the input function is supposed to return a NULL pointer indicating the failure, but this seems to have been missed. The fix is below (see update line):

			LWIP_DEBUGF(UDP_LPC_EMAC | LWIP_DBG_TRACE,
				("lpc_low_level_input: Packet dropped with errors (0x%x)\n",
				lpc_enetif->prxs[idx].statusinfo));
			
			p = NULL; /* UPDATE: Add this line to return NULL on failure */
		} else {
			/* A packet is waiting, get length */
			length = (lpc_enetif->prxs[idx].statusinfo & 0x7FF) + 1;

A big thanks for helping to identify this issue! But this won't specifically fix the issue you are seeing, which is non-reception of packets (and possibly no transmit of packets). The incoming packet status (lpc_low_level_input: Packet dropped with errors (0xffffffff)) for you indicates something is wrong somewhere. You mentioned earlier you were using high-speed buffers for the MII signals? I'm not sure this is really needed and may be causing problems with clock skew between the chip/PHY. It may be something to check - youu might try pulling the buffer and routing jumpers instead to see it it helps.

I ran your posted configurations on my EA1788 board with the FLASH variant, Keil toolchain, and the TCP Echo standalone example.
Here is what I see via debug with your attached configuration. It seems to run fine.

Starting LWIP TCP echo server...
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000118
lpc_rxqueue_pbuf: pbuf packet queued: 20000118 (free desc=7)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000730
lpc_rxqueue_pbuf: pbuf packet queued: 20000730 (free desc=6)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000d48
lpc_rxqueue_pbuf: pbuf packet queued: 20000d48 (free desc=5)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20001360
lpc_rxqueue_pbuf: pbuf packet queued: 20001360 (free desc=4)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20001978
lpc_rxqueue_pbuf: pbuf packet queued: 20001978 (free desc=3)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20001f90
lpc_rxqueue_pbuf: pbuf packet queued: 20001f90 (free desc=2)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 200025a8
lpc_rxqueue_pbuf: pbuf packet queued: 200025a8 (free desc=1)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20002bc0
lpc_rxqueue_pbuf: pbuf packet queued: 20002bc0 (free desc=0)
pbuf_alloc(length=308)
pbuf_alloc(length=308) == 2000321c
pbuf_header: old 20003264 new 2000325c (8)
pbuf_header: old 2000325c new 20003248 (20)
ip_output_if: en0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |       336     | (v, hl, tos, len)
+-------------------------------+
|        0      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |   17  |    0xba9d     | (ttl, proto, chksum)
+-------------------------------+
|    0  |    0  |    0  |    0  | (src)
+-------------------------------+
|  255  |  255  |  255  |  255  | (dest)
+-------------------------------+
netif->output()pbuf_free(2000321c)
pbuf_free: deallocating 2000321c
pbuf_alloc(length=308)
pbuf_alloc(length=308) == 2000321c
pbuf_header: old 20003264 new 2000325c (8)
pbuf_header: old 2000325c new 20003248 (20)
ip_output_if: en0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |       336     | (v, hl, tos, len)
+-------------------------------+
|        1      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |   17  |    0xba9c     | (ttl, proto, chksum)
+-------------------------------+
|    0  |    0  |    0  |    0  | (src)
+-------------------------------+
|  255  |  255  |  255  |  255  | (dest)
+-------------------------------+
netif->output()pbuf_header: old 20003248 new 2000323a (14)
lpc_low_level_output: pbuf packet(2000323a) sent, chain#=0, size = 350 (index=0)
pbuf_free(2000321c)
pbuf_free: 2000321c has ref 1, ending here.
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 200033a0
lpc_low_level_output: pbuf packet(200033b0) sent, chain#=0, size = 42 (index=1)
pbuf_free(200033a0)
pbuf_free: 200033a0 has ref 1, ending here.
lpc_low_level_input: Packet received: 20000118, size 594 (index=0)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 200033e4
lpc_rxqueue_pbuf: pbuf packet queued: 200033e4 (free desc=0)
pbuf_header: old 20000128 new 20000136 (-14)
ip_input: iphdr->dest 0x200a010a netif->ip_addr 0x0 (0x0, 0x0, 0x200a010a)
ip_input: UDP packet to DHCP client port 68
ip_input: DHCP packet accepted.
ip_input:
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |       576     | (v, hl, tos, len)
+-------------------------------+
|        0      |000|       0   | (id, flags, offset)
+-------------------------------+
|   64  |   17  |    0x508b     | (ttl, proto, chksum)
+-------------------------------+
|   10  |    1  |   10  |    1  | (src)
+-------------------------------+
|   10  |    1  |   10  |   32  | (dest)
+-------------------------------+
ip_input: p->len 576 p->tot_len 576
pbuf_header: old 20000136 new 2000014a (-20)
pbuf_header: old 2000014a new 20000152 (-8)
pbuf_alloc(length=308)
pbuf_alloc(length=308) == 20000380
pbuf_header: old 200003c8 new 200003c0 (8)
pbuf_header: old 200003c0 new 200003ac (20)
ip_output_if: en0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |       336     | (v, hl, tos, len)
+-------------------------------+
|        2      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |   17  |    0xba9b     | (ttl, proto, chksum)
+-------------------------------+
|    0  |    0  |    0  |    0  | (src)
+-------------------------------+
|  255  |  255  |  255  |  255  | (dest)
+-------------------------------+
netif->output()pbuf_header: old 200003ac new 2000039e (14)
lpc_low_level_output: pbuf packet(2000039e) sent, chain#=0, size = 350 (index=2)
pbuf_free(20000380)
pbuf_free: 20000380 has ref 1, ending here.
pbuf_free(20000118)
pbuf_free: deallocating 20000118
lpc_tx_reclaim_st: Freeing packet 2000321c (index 0)
pbuf_free(2000321c)
pbuf_free: deallocating 2000321c
lpc_tx_reclaim_st: Freeing packet 200033a0 (index 1)
pbuf_free(200033a0)
pbuf_free: deallocating 200033a0
lpc_tx_reclaim_st: Freeing packet 20000380 (index 2)
pbuf_free(20000380)
pbuf_free: deallocating 20000380
lpc_low_level_input: Packet received: 20000730, size 594 (index=1)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000118
lpc_rxqueue_pbuf: pbuf packet queued: 20000118 (free desc=0)
pbuf_header: old 20000740 new 2000074e (-14)
ip_input: iphdr->dest 0x200a010a netif->ip_addr 0x0 (0x0, 0x0, 0x200a010a)
ip_input: UDP packet to DHCP client port 68
ip_input: DHCP packet accepted.
ip_input:
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |       576     | (v, hl, tos, len)
+-------------------------------+
|        0      |000|       0   | (id, flags, offset)
+-------------------------------+
|   64  |   17  |    0x508b     | (ttl, proto, chksum)
+-------------------------------+
|   10  |    1  |   10  |    1  | (src)
+-------------------------------+
|   10  |    1  |   10  |   32  | (dest)
+-------------------------------+
ip_input: p->len 576 p->tot_len 576
pbuf_header: old 2000074e new 20000762 (-20)
pbuf_header: old 20000762 new 2000076a (-8)
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 20000998
lpc_low_level_output: pbuf packet(200009a8) sent, chain#=0, size = 42 (index=3)
pbuf_free(20000998)
pbuf_free: 20000998 has ref 1, ending here.
pbuf_free(20000730)
pbuf_free: deallocating 20000730
lpc_tx_reclaim_st: Freeing packet 20000998 (index 3)
pbuf_free(20000998)
pbuf_free: deallocating 20000998
pbuf_alloc(length=42)
pbuf_alloc(length=42) == 20000730
lpc_low_level_output: pbuf packet(20000740) sent, chain#=0, size = 42 (index=0)
pbuf_free(20000730)
pbuf_free: 20000730 has ref 1, ending here.
lpc_tx_reclaim_st: Freeing packet 20000730 (index 0)
pbuf_free(20000730)
pbuf_free: deallocating 20000730
lpc_low_level_input: Packet received: 20000d48, size 96 (index=2)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000730
lpc_rxqueue_pbuf: pbuf packet queued: 20000730 (free desc=0)
pbuf_header: old 20000d58 new 20000d66 (-14)
ip_input: iphdr->dest 0xff0a010a netif->ip_addr 0x200a010a (0xa010a, 0xa010a, 0xff000000)
ip_input: packet accepted on interface en
ip_input:
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        78     | (v, hl, tos, len)
+-------------------------------+
|        0      |010|       0   | (id, flags, offset)
+-------------------------------+
|   64  |   17  |    0x118b     | (ttl, proto, chksum)
+-------------------------------+
|   10  |    1  |   10  |   20  | (src)
+-------------------------------+
|   10  |    1  |   10  |  255  | (dest)
+-------------------------------+
ip_input: p->len 78 p->tot_len 78
pbuf_header: old 20000d66 new 20000d7a (-20)
pbuf_free(20000d48)
pbuf_free: deallocating 20000d48
lpc_low_level_input: Packet received: 20001360, size 64 (index=3)
pbuf_alloc(length=1536)
pbuf_alloc(length=1536) == 20000d48
lpc_rxqueue_pbuf: pbuf packet queued: 20000d48 (free desc=0)
pbuf_free(20001360)
pbuf_free: deallocating 20001360

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Thu, 2012-07-05 12:41

wellsk

Offline

Joined: 2011-05-17

>I'm not sure this is really needed and may be causing problems with clock skew between the chip/PHY. It may be something to check - youu might try pulling the buffer and routing jumpers instead to see it it helps.
With the RMII configuration and a 50MHz RMII clock, the buffer will almost definitely cause problems with MAC IF/PHY signal synchronization. :( Maybe there are some hardware developers on the site here that can comment more on it?

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Thu, 2012-07-05 12:47

wellsk

Offline

Joined: 2011-05-17

>>Even if the received packet is badly corrupted, why is result a missing ref count in a structure? Receiving corrupted frames will eventually happen on a network::
>This is a legitimate bug. I *can* repeat this issue here, and will provide a fix (see below) for this. This issue occurs when a RX packet fails, the RX packet queue is reset, and a non-NULL pointer is returned to the caller in this condition. When this failure occurs, the input function is supposed to return a NULL pointer indicating the failure, but this seems to have been missed.

The fix is available in the LWIP_LPC GIT repo at
http://sw.lpcware.com/?p=lwip_lpc.git&a=commit&h=b4f76d60c46968527b9f1b0...

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Fri, 2012-07-06 00:47

#10

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin

Thanks for all you work to support me.

I also think that PRAM is setup correctly. Everything is fine at 10 Mbit, so the buffers must be placed right.

Regarding the buffer. I have removed it. Same thing. So that wasn't it.

I did apply your fix. Now I have no Assertions. That is good, because no bad packet may cause a stack to crash.
Still I have no go at 100 Mbit.

Debug print snippet:
.
...
...
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_rxqueue_pbuf: pbuf packet queued: 20000cf8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_rxqueue_pbuf: pbuf packet queued: 20001310 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
..
..
Continues forever.... I think :-)

So every single frame received are corrupted (CRC error)

I have placed a break-point in the lpc_low_level_input function.

The "lpc_enetif->prxs[idx].statusinfo" is 0xCCE00054. That is error EMAC_RINFO_CRC_ERR and EMAC_RINFO_ALIGN_ERR.

I do have some HW issues in my custom board. That's for sure.

I tried the EasyWEB sample from KEIL. It is for the MB1700 eval board, so I just "adjusted" it to run on my board.
But with that sample I sort off can run at 100 Mbit.

Well, not as good as it should, but still it was possible to RX/TX at 100 MBit.
If I ping the target @100 MBit there are some ping timeouts. Actually very often. Every 20-30 ping or something like that.
Also, some of the http request for the WEB browser did fail

At 10Mbit, ping has no timeout's and there is no HTTP timeouts. So it runs best with 10 MBit.

One good question is, why can the EasyWEB sample get "some" TX/RX transmission going at 100 Mbit and not the TCP Echo sample.?

I have connected the target to my PC with an Ethernet cable and used Wireshark to see if I could capture the TX packet send from the target. I could not capture one. But It seems the TCP echo sample connects to it self, so no packet are send on the wire.

We have followed every design rule specified in the PHY datasheet (after we have remmoved the buffer :-)).

Maybe some HW guru has something to add??

Thomas

PS: What does the "APP_PRINT_IP(&ipaddr);" in the EA1788_tcpecho_sa.c do? I can't compile unless it commented out. If I search all the code file, there are no reference to the "APP_PRINT_IP" macro?

Mon, 2012-07-09 11:06

#11

wellsk

Offline

Joined: 2011-05-17

>One good question is, why can the EasyWEB sample get "some" TX/RX transmission going at 100 Mbit and not the TCP Echo sample.?
This isn't one I can't easily answer. The code base for these does vary and the board setup for the easyweb and lwip examples might be very different, I'm not too familiar with the easyweb demo. Check your pin muxing very carefully, maybe something is wrong there or multiple pins are configured to the same function.

>I have connected the target to my PC with an Ethernet cable and used Wireshark to see if I could capture the TX packet send from the target. I could not capture one. But It seems the TCP echo sample connects to it self, so no packet are send on the wire.
If you are using the default configuration, you should get a broadcast at the board's MAC address every time you plug in the cable.

>PS: What does the "APP_PRINT_IP(&ipaddr);" in the EA1788_tcpecho_sa.c do? I can't compile unless it commented out. If I search all the code file, there are no reference to the "APP_PRINT_IP" macro?
This was a helper macro that displayed the IP address. I commented out this call during my testing since I get the IP address from Wireshark, but keep forgetting to check in the changes. You can either remove the functions or add the following line to print the IP address:

/** \brief  Print out an IP address with carriage return
 */
 #define APP_PRINT_IP(ip) APP_DEBUG("%d.%d.%d.%d\n", ip4_addr1(ip), \
        ip4_addr2(ip), ip4_addr3(ip), ip4_addr4(ip));

If your willing, post the ethernet part of your schematic and it can be browsed for any problems.

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Mon, 2012-07-09 23:22

#12

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin

>>One good question is, why can the EasyWEB sample get "some" TX/RX transmission going at 100 Mbit and not the TCP Echo >>sample.?
>This isn't one I can't easily answer. The code base for these does vary and the board setup for the easyweb and lwip >examples might be very different, I'm not too familiar with the easyweb demo. Check your pin muxing very carefully, maybe >something is wrong there or multiple pins are configured to the same function.

I have checked the setup from both samples and they seem to be the same. I will double check later today.
Also, I have verified the pin muxing using the "peripherals" feature in KEIL, to check the pins configuration.

See the attached schematics. Keep in mind, that the buffer has been removed on the board i'm using for test. But it worked ok with it also.

Thomas

Preview	Attachment	Size
	ethernet_sch.png	300.98 KB

Wed, 2012-07-11 10:41

#13

wellsk

Offline

Joined: 2011-05-17

The APP_PRINT_IP call has been removed in update http://sw.lpcware.com/?p=lwip_lpc.git&a=commitdiff&h=76ddd26b208e02fa7ae...
Note there are several other new files that also use this macro that will be fixed in an upcoming patch..

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Fri, 2012-07-13 03:57

#14

tjoAG

Offline

Joined: 2012-05-30

Hi Kevin

Just whant to inform, that I have got it to work.

There was some HW bug witht he 50 MHz used for the PHY and the EMAC.
So I made the HW change my self (HW department on summer holiday) and now 100 mbit works:-)
It will not win any prices for HW fixes but it work

Thanks a lot for you help.

Thomas

Mon, 2012-07-16 07:58

#15

wellsk

Offline

Joined: 2011-05-17

I'm glad it's up and running reliably. And thanks for helping identify the other issues!

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

LwIP sample fail

Comment viewing options

Languages

User login

LPCXpresso forums

New forum topics

Active forum topics