HardFault at the call of vListInsertEnd

Hi there, I’m having a Hard Fault while the vListInsertEnd function is called. The program currently just runs two takes: Main Task gives every second a semaphore so that Task2 can run. I have disabled all IRQ to be sure that is not a IRQ priority issue. I have also increase the size of the stack for each task to be sure that there is no stack overflow. Do you have some other idea to debug this hard fault ? PS: I’m running FreeRTOS 8.0.1 on a samr21 from atmel (cortex-M0+) Many thanks

HardFault at the call of vListInsertEnd

  • What is executing when the hard fault occurs – there are many calls to vListInsertEnd() in the code – what is the call stack?
  • Is this repeatable?
  • Does this occur the first time you give the semaphore, or does it run for a while before the problem occurs?
  • Do you have configASSERT() defined?
  • Have you read through the “my application does not run, what could be wrong” page of the FAQ?

HardFault at the call of vListInsertEnd

The problem is very repeatable. The application is running properly for two semaphore give/take cycle. It does the following: – Main task gives Semaphore – Task2 takes Semaphore – Task2 waits for Semaphore – Main task gives Semaphore – Task2 takes Semaphore – Hard fault Here is my call stack :
HardFaultHandlerC:368(hardfaultargs=0x20005fa8) :368() vListInsertEnd:104(pxList=0xa002ec90, pxNewListItem=0x200021fc <ucHeap+8532>) xTaskIncrementTick:1937() SysTick_Handler:344() :344() ucHeap:344()
No configAssert are defined in the vListInsertEnd() function. Thanks

HardFault at the call of vListInsertEnd

No – there are no asserts in the vListInsertEnd() function – but there are plenty of asserts elsewhere in the code that might trap whatever has gone wrong before vListInsertEnd() was called. You didn’t say if you have configASSERT() defined. Regards.

HardFault at the call of vListInsertEnd

configASSERT is defined as follow

define configASSERT( x )

    if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
But does not trap the problem Many thanks