Problem with LwIP and EMAC

[lpcware]

Content originally posted in LPCWare by jackandrews on Tue Sep 10 07:42:57 MST 2013
Hi,

I've been testing the TCP echo FreeRTOS demo and everything is working.  I'm now trying to connect a server and stream data out.  I've added the following task which is created with priority 2 after an IP address has been assigned:
http://pastebin.com/Bfbx54zJ

I have a python script listening on port 8000.  The above code successfully connects and I see the data in the python script, however after a few iterations it hangs.  I've noticed that if I place a breakpoint on netconn_write and allow it to slowly execute it works.  It also works by adding a 10 ms delay.

However, without a delay it gets stuck waiting for free tx descriptors to become available (i.e. semaphore: xSemaphoreTake(lpc_enetif->xtx_count_sem, 0) is never taken).  It would appear that the tx IRQ is never firing and/or the tx_cleanup task is not working properly.

Any ideas on how to debug this?

Thanks very much,

Jack

[amorgan]

Was this issue ever resolved and if so is there a link to an update on this? The above link seems broken.

If not resolved, any help towards resolving this?

[lpcware]

Content originally posted in LPCWare by wellsk on Wed Sep 11 15:15:28 MST 2013
This seems to be a known issue with the LWIP port and has been submitted by a number of users. This part is scheduled to be re-designed, but you'll have to use a workaround to get around the issue for now - or you will need to increase your TX DMA buffer count to a higher value (at the expense of memory).

The best approach so far seems to be this one: (18xx/43xx, but same design also applies to the 17xx/40xx)
http://lpcware.com/content/bugtrackerissue/lpcopen-v103-lwip-driver-lpc18xx43xxemacc-lockup-problem

Note you need to be logged in to see and track bug tracker issues.

[lpcware]

Content originally posted in LPCWare by jackandrews on Wed Sep 11 04:57:55 MST 2013
False alarm... still fails after a while.  Also, I think I've found a bug with the task priorities (I'm working from a clean version of LPCOpen 1.03)... specifically TCPIP_THREAD_PRIO is defined as 5, but configMAX_PRIORITIES is set to 5 which is beyond the maximum number of priorities (see http://www.freertos.org/RTOS-task-priority.html).  This was causing really weird behaviour with FreeRTOS (switching to tasks of lower priorities, etc.).

Anyway, attached a wireshark capture and EMAC debug output.  I added a stats_display() to lpc_rx_queue when it fails to allocate a pbuf.  It would seem I'm running out of memory, but why?  Any thoughts greatly appreciated!

Thanks,

Jack

[lpcware]

Content originally posted in LPCWare by jackandrews on Tue Sep 10 08:49:21 MST 2013
OK, a bit more info: disabling the Nagle algorithm (tcp_nagle_disable (xNetConn->pcb.tcp)) and reducing the test data length to 100 has got it working.  However, I'd still like to work out how to send larger packets (e.g. 1kB) to reduce overhead (and increase throughput).

Thanks,

Jack