0
votes

I can receive and send TCP frames with no problem. But after a random time (everything from 1 minute to 1 hour), the program fail, getting stuck in a for loop in vListInsert.

In the tcpip thread the code waits for a frame. This is done with

    sys_mbox_fetch(mbox, (void *)&msg);

which is defined in the sys_arch.c When called I get an exception. I have checked that the mbox has been initialized and can trace the fault to a list iteration in vListInsert (called in vTaskPlaceOnEventList)

    for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )
    {

        /* There is nothing to do here, we are just iterating to the
        wanted insertion position. */

    }

As I can see the list pointers are messed up as this point giving the exception. I have not been able to figure out why yet.

Call stack is

  • tcpip_thread
  • sys_mbox_fetch
  • sys_arch_mbox_fetch
  • xQueueGenericReceive
  • vTaskPlaceOnEventList

I have tried to increase and decrease TCPIP_THREAD_STACKSIZE (from 600 to 4k) and MEM_SIZE to 12k in lwIP, with no luck.

Priorities used are the following 3 by; tskIDLE_PRIORITY+1 tskIDLE_PRIORITY+2 and 5 (no tskIDLE_PRIORITY in this)

Using Cortex M4 running on the FRDM-K64F board.

Using Netconn API and non-preemptive.

Any idea what to do and an explanation of what to try next? been stuck here for 5 days...

EDIT: Sending up to 50 packets, 224bytes packets and wait for answer from the server, which is 191bytes before sending the next packet. This is done each 1.5 sec (at most output)

1

1 Answers

0
votes

This issue is normally a symptom of an invalid interrupt priority breaking the full interrupt nesting model used by FreeRTOS. This is a common cause of support request, so there is a web page dedicated to it, and newer versions of FreeRTOS contain many assert points that are placed specifically to catch this type of mis-configuration instantly, and show you exactly where it is.