AnsweredAssumed Answered

LwIP / RTOS netconn thread hang

Question asked by smith.greg.005 on May 26, 2015
Latest reply on Aug 5, 2015 by Bettega Stefano
I'm hoping someone can help me out here.
I have:
- App running LwIP/FreeRTOS (generated from Cube MX
- tcpip thread running at real time priority
- application thread using netconn to send/receive, at a priority above normal

Intermittently the application thread gets stuck. After much debugging, I've found the problem is the tcpip_thread interrupting the application thread, and screwing up the semaphores that signal when an operation is done.

- The application thread ends up calling do_writemore(), which when data is all sent calls sys_sem_signal(&conn->op_completed)

- The tcpip_thread calls do_recv(), which at the end, it does a TCPIP_APIMSG_ACK(msg) which is also a sys_sem_signal(&m->conn->op_completed)

Normally the sequence is:
- app thread: send start
- app thread: send op_completed comes back
- tcp thread: receive start
- tcp thread: receive op completed comes back

When it hangs, the order is:
- app thread: send start
- tcp thread: receive start
- tcp thread:receive op completed          
         sys_mutex_unlock() fails here, xSemaphoreGive() returns queue full error

- send op_completed never arrives, application thread hangs for ever

If I change my application thread to the same priority as the tcpip_thread(), its seems to fix the issue.

Debugging shows this: api_msg.c:
if (write_finished) {
    /* everything was written: set back connection state
       and back to application task */
    conn->current_msg->err = err;
    conn->current_msg = NULL;
    conn->state = NETCONN_NONE;
         ** context switch occurs here **
    if ((conn->flags & NETCONN_FLAG_WRITE_DELAYED) != 0)

It switches context to the tcpip_thread() after setting the NETCONN_NONE state, but before signaling the operation is complete.

Am I missing something here?