Hi,

I use freeRTOS on an LPCXpresso Board with LPC1769.

But I have a Problem with my code. I got some HardFaults, so I started debugging. Now I have only one task left which does nothing but waiting with "vTaskDelayUntil" and everything is fine. But if I call "uxTaskGetStackHighWaterMark(TASK_NAME)" I get into the HardFault-Handler. I found that "pcEndOfStack" in the function is the problem. My debugger shows:

Name : pcEndOfStack
Details:0x14f04f46 

Default:0x14f04f46 

Decimal:351293254

And because of that, "*pucStackByte == tskSTACK_FILL_BYTE" in "usTaskCheckFreeStackSpace" fails and I get the HardFault.

What could be the Problem?

Do you have stack overflow checking switch on?
Can you post the code used to create the task.

Yes, stack overflow check is set in FreeRTOSConfig

#define configCHECK_FOR_STACK_OVERFLOW2

Here is the code which starts the Task:

xTaskCreate(IMU_Regler_Task, (signed char *) "IMU_Regler_Task", 400, NULL, uxPriority, (xTaskHandle *) NULL);

Any ideas what could be wrong?

If the fault always occurs when uxTaskGetStackHighWaterMark() is called I would suggest stepping into the function using the debugger to see what the code is doing at the time the hard fault occurs.

Regards.

I have already stepped into the function. The address stored in "pcEndOfStack" points to an address which is not accessible.

Name : pcEndOfStack Details:0x14f04f46 

But I don't know why it contains this wrong address.

pcEndOfStack is a stack variable that gets set to pxTCB->pxStack before being passed into usTaskCheckFreeStackSpace().

If pcEndOfStack correct (within bounds) when it is initially assigned from pxTCB->pxStack? If not, then it is likely that pxTCB->pxStack is corrupt.

pxTCB->pxStack is set when the task is created, and then not modified. As you are creating only a single task you will be able to see what pxTCB->pxStack is being set to by inspecting pxNewTCB->pxStack at the end of xTaskGenericCreate(). Does its value change between the end of xTaskGenericCreate() and uxTaskGetStackHighWaterMark() being called? If so, when does it get changed?

--

I have a lot of experience using the LPCXpresso board, and have not encountered this type of problem. It might be due to a linker script error (possibly, but doubtful). If you are using the LPCXpresso IDE do you have the project options set for the correct chip part and to allow the IDE to manage the linker script?

Regards.

Thanks for your detailed reply. Yes I have set the correct chip in the IDE and let the IDE also manage the linker script. I had after some days time to debug the code again.

I found out that

“pxTCB = prvGetTCBFromHandle( xTask )”

sets pxTCB to the value of xTask and not to the correct address. If I change manually the address of pxTCB to the one assigned during task creation, everything is fine. Why does prvGetTCBFromHandle doesn't work and how can I get it to work?

And one other question: Is it the normal behaviour that the processor doesn't start/run if I use printf, compile the code with newlib and semihosting enabled and don't debug? Just power off and on again?

Regards

Oh, I think I called uxTaskGetStackHighWaterMark() with the wrong parameter... I passed the pdTASK_CODE and not a handle... If I pass NULL everything works fine.

But the last question in my previous post still can be answered :)

“And one other question: Is it the normal behaviour that the processor doesn't start/run if I use printf, compile the code with newlib and semihosting enabled and don't debug? Just power off and on again?”

That really depends on how these things are implemented on your hardware by your build environment.

Raw newlib implementations can be extremely stack hungry and result in code bloat as soon as you go near printf() type functions, and that can cause stack overflows. However, if the stack is not overflowing in a debug build it is extremely unlikely that will be the problem in a release build.

If the semihosting is waiting for signals to/from the debugger, and the debugger is not connected, then that might be the cause of your issue.

Regards.