Hard Fault when using two tasks and suspending debugger

flewz2010 wrote on Wednesday, November 20, 2019:

I use an STM32F4 µC, with FreeRTOS. Now when I am using two tasks, and suspend the execution in eclipse to debug the Hard Fault Handler triggers, however this primarily happens when I halt for longer than a second or so. Additionally, this only happens, when I add the second task to the application, with one task everything runs fine. Both tasks are set at tskIDLE_PRIORITY+1 and suspend and resume themselves after a specified time interval.
The Hard Fault Handler does not show any usable PC, but gives the usage fault: “Attempt to do exception with bad value in EXEC_RETURN number”. If you need any more info, I’l be happy to provide.

rtel wrote on Wednesday, November 20, 2019:

I use an STM32F4 µC, with FreeRTOS. Now when I am using two tasks, and
suspend the execution in eclipse

do you mean break in the debugger, so stop the program running in the
debugger?

to debug the Hard Fault Handler
triggers,

So the hard fault triggers after the program was stopped? If so the
program cannot have stopped running. Do you have the debugger set to
stop timers when you are stepping through the code?

however this primarily happens when I halt for longer than a

second or so. Additionally, this only happens, when I add the second
task to the application,

…and the second task is the same as the first task? If not, what are
the differences?

flewz2010 wrote on Thursday, November 21, 2019:

do you mean break in the debugger, so stop the program running in the
debugger?
Yep, when I try to stop the program to step through the code, I can make one step in the best case scenario until the hard fault triggers
Do you have the debugger set to stop timers when you are stepping through the code?
How do I set this? I only have this assert defined per the instructions for the m4

#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}

…and the second task is the same as the first task? If not, what are
the differences?
The thing about the two tasks was a wrong assumption on my part. I eliminated one task and I still have the problem, I even removed the TaskDelayUntil and Semaphore I used previously to synchronize my tasks, so now it just runs continuously.

const TickType_t xFrequencySend = 10;
//	xLastWakeTimeSend = xTaskGetTickCount();
	for(;;)
	{
//		xLastWakeTimeSend = xTaskGetTickCount();
		if(xQueueReceive(sendCmdQ, &cmd, 0) == pdTRUE)
		{
//			if( xSemaphoreTake( xSendSemaphore, (TickType_t) 500) )
//			{
				switch(cmd)
				{
				case CONNECT:
					connect();
					break;
				case START:
					start();
					break;
				}
//				xSemaphoreGive(xSendSemaphore);
//			}
		}
//		else
//		{
//			vTaskDelayUntil( &xLastWakeTimeSend, xFrequencySend );
//		}
	}

This is my task, although a bit simplified. the connect() and start() functions look a bit like this:

uint8_t data[2] ={CONNECT, 0x80};
	HAL_UART_Transmit(&huart6, (uint8_t *) pData, size, 5000);
	while(!Connected)
	{
		Connected = connectCheck();
	}

the start() function is analogous in sending out data over UART and checking received packages for a response.
The UART interrupt is set to lowest priority (15,0), although I also had it at (10,0)

rtel wrote on Thursday, November 21, 2019:

do you mean break in the debugger, so stop the program running in the
debugger?
Yep, when I try to stop the program to step through the code, I can
make one step in the best case scenario until the hard fault triggers

This doesn’t sound like a FreeRTOS issues then, not directly anyway, but
some interaction between the development tools, the debug interface and
the target. Most likely scenarios would be something the debugger is
doing is causing a fault (like it is trying to read values from
misaligned addresses, or invalid addresses), or timers are continuing to
run while stepping through code generating interrupts that the debugger
is preventing from running or are continuously re-entering.

flewz2010 wrote on Wednesday, November 27, 2019:

Just to close this topic. It was indeed a problem with my IDE and not with FreeRTOS. Opening a new workspace solved my problem.

rtel wrote on Wednesday, November 27, 2019:

Thanks for taking the time to report back.