HardFault: pcEndOfStack out of bounds

splashx11 wrote on Tuesday, February 19, 2013:

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 <Address 0x14f04f46 out of bounds>
	Default:0x14f04f46 <Address 0x14f04f46 out of bounds>
	Decimal:351293254

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

What could be the Problem?

edwards3 wrote on Tuesday, February 19, 2013:

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

splashx11 wrote on Tuesday, February 19, 2013:

Yes, stack overflow check is set in FreeRTOSConfig

#define configCHECK_FOR_STACK_OVERFLOW	2

Here is the code which starts the Task:

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

splashx11 wrote on Thursday, February 21, 2013:

Any ideas what could be wrong?

rtel wrote on Thursday, February 21, 2013:

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.

splashx11 wrote on Thursday, February 21, 2013:

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

Name : pcEndOfStack Details:0x14f04f46 <Address 0x14f04f46 out of bounds>

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

rtel wrote on Thursday, February 21, 2013:

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.

splashx11 wrote on Wednesday, February 27, 2013:

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

splashx11 wrote on Wednesday, February 27, 2013:

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 :slight_smile:

rtel wrote on Thursday, February 28, 2013:

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.