lwip_tcpecho_freertos stops responding on LPC1769

[lpcware]

Content originally posted in LPCWare by deffi on Tue May 19 02:58:20 MST 2015
Good Morning,

Short summary: lwip_tcpecho_freertos stops working after echoing about 4 kBytes of data. lwip_tcpecho_sa works fine in the same scenario.

Full length version: I compiled the lwip_tcpecho_freertos example project included with LPCOpen for LPCXpresso 1769 (details below). The only changes I made was to disable DHCP and change the IP address to match my local network.

I send some data using netcat, and indeed this works well for small amounts of data, for example, 5 lines:

$ seq 5 | netcat 1.1.1.2 7
1
2
3
4
5
$

For larger amounts of data, the program stops working at some point:

$ seq 10000 | netcat 1.1.1.2 7
1
2
3
[and so on]
1096
1097
10

At this point, the netcat process just sits there waiting for a response. I cannot make another connection until I reset the LPC1769, even if I close the original connection by terminating the netcat process. Wireshark shows some duplicate ACK packages from the device and some TCP retransmissions from the host. The ethernet link detection (which turns on and off the LED on the board when the link status changes) still works.

The same procedure works fine for the lwip_tcpecho_sa (standalone, i. e. without FreeRTOS) example project (I tested up to a million lines).

Some more details about the environment: I'm using LPCXpresso v7.7.2 [Build 379] [2015-03-31] on Ubuntu 15.04. The demo projects are from the lpcopen_2_10_lpcxpresso_nxp_lpcxpresso_1769.zip file the the LPCXpresso examples directory. The compiler is arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]. The hardware is an LPCXpresso LPC1769 board, Revision C (with SMSC PHY).

Could this be a bug in the lwip_tcpecho_freertos, potentially a RAM issue?


Regards,
Martin

[lpcware]

Content originally posted in LPCWare by deffi on Tue May 19 07:37:29 MST 2015
I took a closer look at the code, and it turns out that the TCP echo thread hangs during the following call in the tcpip_apimsg function (defined in tcpip.c), while waiting for a sempahore:

sys_arch_sem_wait(&apimsg->msg.conn->op_completed, 0);

So it seems that this call succeeds a couple of times, but then, after some amount of data has been received, this semaphore is never freed.

The line above is reached via tcpecho_thread (tcpecho.c) -> netconn_write (api.h) -> netconn_write_partly (api_lib.c) -> TCPIP_APIMSG (tcpip.h) -> tcpip_apimsg (tcpip.c).

What's going on here? Could it be a thread priority issue?

[lpcware]

Content originally posted in LPCWare by starblue on Tue May 19 07:29:03 MST 2015
My first guess is that the application doesn't acknowledge the data, so after the TCP window is used up no more data is transmitted.  The exact amount transmitted is 4380 bytes, which is 3 times the MSS of 1460 bytes, a plausible value for the TCP window.

I have no idea why the two examples differ in this respect.