I'm using FreeRTOS 7.6.0 on LPC1766, with Rowley Crossworks. I have a small program with one task adapted from a 'CORTEXLPC1768GCC_Rowley' demo (but with LPC1766 set in Crossworks).

I'm getting an exception (presumably an illegal memory access) at the statement <<<< below in uxListRemove.

unsigned portBASE_TYPE uxListRemove( xListItem * const pxItemToRemove ) { xList * pxList; pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious; pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext; <<<<

uxListRemove is called about 6 times before the crash. The particular time it is called and crashes comes from this line in the vTaskDelay which is in the main task loop: if( uxListRemove( &( pxCurrentTCB->xGenericListItem ) ) == ( unsigned portBASE_TYPE ) 0 )

Can anyone suggest what may be wrong or where I should look next.

Thanks Scott

Is your code using interrupts at all? Do you have configASSERT() defined? Have you gone through all the points in the following sub-page of the FAQ? Do you have stack overflow detection turned on? Are you sure your linker script is setup correctly as you are using a different part number?

Regards.

No I'm not using interrupts. I have configASSERT() defined like this: #define configASSERT( x ) if( x == 0 ) { taskDISABLEINTERRUPTS(); for(;;); } I have printed out and read the FAQ page but I need to re-read to get a better understanding. configCHECKFORSTACKOVERFLOW is set to 2 and INCLUDE_uxTaskGetStackHighWaterMark is set to 1 I'll check the linker script but Crossworks had a specific selection for the Olimex board I am using. Thanks. -Scott

SOLVED I think. I configured Crossworks to use the memory placement file that actually came with the FreeRTOS demo and that did the trick. Thanks for the suggestion. -Scott

Hi,

I'm using FreeRTOS V7.5.3 on LPC1778 with IAR embedded workbench. I am getting Hardfault from uxListRemove function. Bold Lettered Line shows the exact location.

/------------------------------ unsigned portBASE_TYPE uxListRemove( xListItem * const pxItemToRemove ) { xList * pxList; pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious; pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext; /--------------------- CallGraph:- "xPortSysTickHandler->xTaskIncrementTick->uxListRemove"

I have also defined configASSERT(), also checked with Interrupt Priority, configCHECKFORSTACK_OVERFLOW is set to 2 Also using interrupts and checked with their priority.

I am also having LWIP runing which sends around 1K data every second and receves 280 Bytes. I also use TLS/SSL library.

Note That the issue comes very rarely sometimes after testing 3-4 Hours.

Can anyone suggest anything i am missing?

Thanks in advance.

I'm not sure how much configASSERT() checking there is for incorrect priority assignments in version 7.5.3, which is quite old, 9.0.0 being the latest.

I am also having LWIP runing which sends around 1K data every second and receves 280 Bytes. I also use TLS/SSL library.

Note That the issue comes very rarely sometimes after testing 3-4 Hours.

Can anyone suggest anything i am missing?

You have a lot of code there copying data around and performing complex maths algorithms. It would seem that something is corrupting memory somewhere. With all that code running and no idea of your setup or application it is difficult (almost impossible) to say if you are missing something. The first thing would be to ask, what evidence is there that this is a FreeRTOS problem?

I am not sure whether this is FreeRTOS issue ot not but if i use bare metal firmware to do the same things, I never got hard fault.

this always happens at same location from freeRTOS as mention below. CallGraph:- "xPortSysTickHandler->xTaskIncrementTick->uxListRemove"

Note that sysTick Handler runs at lower priority than other interrupts

While debugging i found PC and LR address contains valid address and that is of SysTick Handler. at the time of hard fault I also checked with main Stack and other thread stack overflow issue but all seems ok.

please ask for more info if required.

Thanks in advance. Leo