Stuck in configAssert of function xTaskRemoveFromEventList (tasks.c)

Partners & Sponsors ST
1

I set-up a project based on the one generated by CubeMX using FreeRTOS (CMSISv2) and lwIP for STM32F4. Everything works fine as long as I send one tcp/ip packet after each other (like in case of ping) .

But if I put more stress on the device I always get stuck in the eth receive callback that tries to release a semaphore the receive task is waiting for. The queue length is ‘1’ as expected, but somehow there is no owner to the entry… Does anybody have an idea how this can happen?

I’m using V10.3.1 of FreeRTOS and v2.1.2 of lwIP.

image

any ideas or comments would very well be appreciated.

2

There are lots of asserts in the code, which are you stuck in?

3

RIght in the first one

	pxUnblockedTCB = listGET_OWNER_OF_HEAD_ENTRY( pxEventList ); /*lint !e9079 void * is used as this macro is used with timers and co-routines too.  Alignment is known to be fine as the type of the pointer stored and retrieved is the same. */
	configASSERT( pxUnblockedTCB );
4

I implemented the following input packet handling (following the generated example code)

init:

  • create semaphore (osSemaphoreNew(1, 1, NULL):wink:
  • create and start input handler task

input handler task:

  • tries to acquire the semaphore

receive irq:

  • release the semaphore

might it be possible that a second receive irq will result in the above behavior?

The task that processes the first received package acquired the semaphore and might be still active. Does that mean that the TCB is blocked?

5

ok, I discovered a wrong irq priority in the lwip thread config. Now at least I pass the assert but never the less I have somehow corrupted memory since I get stuck within the call of uxListRemove. The address that returned by listGET_OWNER_OF_HEAD_ENTRY is strange because it points somewhere into the ROM and so the containing information is also not right.

image
image1783×634 57.9 KB