Endless loop at configASSERT( pxQueue->uxItemSize == 0 );

[MFäh.1]

Hi all

I'm pretty sure this was already a topic, but i haven't found a solution yet. Since i'm a beginner i definitely need some help here.

I'm sending UDP data with LWIP and FreeRTOS. It works, but after some (random) time the code gets stuck at  

 

 

configASSERT( pxQueue->uxItemSize == 0 );

 

I tried some settings but nothing helps. It is stopping even if I do not send data .

 

Any ideas?

 

Cheers

[hs2]

A stack overflow might cause this kind of internal data corruption. Did you enable stack checking ? See https://www.freertos.org/Stacks-and-stack-overflow-checking.html

[MFäh.1]

Thank you for your reply.

 

Yes, i did. My ioc file has following FreeRTOS settings (maybe this helps)

FREERTOS.FootprintOK=true
FREERTOS.IPParameters=Tasks01,configMINIMAL_STACK_SIZE,configUSE_NEWLIB_REENTRANT,copyHeapFile,FootprintOK,configENABLE_FPU,configCHECK_FOR_STACK_OVERFLOW,configQUEUE_REGISTRY_SIZE
FREERTOS.Tasks01=defaultTask,24,256,StartDefaultTask,Default,NULL,Dynamic,NULL,NULL;
FREERTOS.configCHECK_FOR_STACK_OVERFLOW=1
FREERTOS.configENABLE_FPU=1
FREERTOS.configMINIMAL_STACK_SIZE=256
FREERTOS.configQUEUE_REGISTRY_SIZE=0
FREERTOS.configUSE_NEWLIB_REENTRANT=0
FREERTOS.copyHeapFile=1

 

Cheers

 

[David Littell]

This might be a buffer overrun resulting in the memory at pxQueue being stomped.  I'd suggest looking at what's in memory prior to pxQueue for clues.

[hs2]

Also try FREERTOS.configCHECK_FOR_STACK_OVERFLOW=2 and ensure that you have configASSERT defined. (sorry, I’m not familiar with cube)

BTW what’s the stack size(s) you’re using for your task(s) ?

[MFäh.1]

Thank you both for your replies. I try to test both, not sure if I do it correctly ;-). 

@David Littell : "I'd suggest looking at what's in memory prior to pxQueue for clues". Does this help somehow: 

 

Stack size for the taks is, if I'm correct 256 (words).

Cheers

[David Littell]

It does look like the queue structure in memory is being stomped by something.  As a quick test you could try 4x all the stacks.  You can also convert the uxMessagesWaiting value to hex and see if that's a memory address you can examine.

Issues like this force you to dig around and work to really understand what's being allocated versus statically defined in memory - simple IDE debugger snippets aren't usually enough.

[Roberto C]

Hello,

I'm having the same problem.

how have you solved it?

 

Best regards.

 

[Mikey]

I had this problem today. It is most likely stack overflow as mentioned in other threads.

First, confirm stack overflow, e.g. assuming you are also using FreeRTOS, in your `FreeRTOSConfig.h` add `#define configCHECK_FOR_STACK_OVERFLOW 2`, and somewhere define the callback:

void vApplicationStackOverflowHook (TaskHandle_t xTask, signed char *pcTaskName)
{
	printf("Stack overflow: %s", pcTaskName);
	for(;;){}
}

See here for details. Then put a breakpoint there, you can see if the task `pcTaskName` had a stack overflow. Then increase its allocated stack. In my case, the "EthIf" task in ethernetif.c only had 350 bytes allocated, increasing that resolved the issue.

[Roberto C]

Hell @Mikey 

In my case it was'n a stack size problem (I increased it...), and, after isolating  more where the

problem started, my software didn't jump  anymore in vApplicationStackOverflowHook function,

but before of it jumped into a ASSERT (coused by variables in one structure with crazy values...)

 

I didn't found the reason, but I solved using a different library version....

from version FW_H7_V1_9_1 to FW_H7_V1_11_2.

 

With the new library that problem seems to be solved (crossing my fingers)

Best Regards