Getting hardfault after calling FROMISR API from ISR

haditj66 wrote on Saturday, August 10, 2019:

FreeRTOS V9.0.0
I am getting a hardfault after a while of calling the following simplified code within an ISR.
Am I getting the settings wrong in the config settings for ISR priorities? or am I calling the FROMISR API incorrectly?

the ISR:

void ISRCallback()

BaseType_t  xHigherPriorityTaskWoken = pdFALSE;
		for (int i = 0; i < NUMOFACTIVEOBJECTS; i++)
			if (EventSubscribers[evtId][i])
				xQueueSendToBackFromISR(AEAO::AllAO[i]->queueExecuteForEvt, &AddingsubscriberArgs->Arg4, &xHigherPriorityTaskWoken); 
        		   if( xHigherPriorityTaskWoken )
                    /* Actual macro used here is port specific. */
                      portYIELD_FROM_ISR (xHigherPriorityTaskWoken);

it is sending an object to one or more queues. After this ISRcallback is executed exactly 31 times, a hardfault occurs at this line of code in the timers.c file at line 618

hardfault location:

			if( xTaskResumeAll() == pdFALSE )
					/* Yield to wait for either a command to arrive, or the
					block time to expire.  If a command arrived between the
					critical section being exited and this yield then the yield
					will not cause the task to block. */

It must be something to do with the way I am calling the xQueueSendToBackFromISR API because when I remove all mentions of this, the hardfault does not happen anymore.

here are the relevant settings I have for the NVIC:


for the ISR:

    HAL_NVIC_SetPriority(USART2_IRQn, 5, 0);

for the tasks that the queues the isr sends to :

for the freertosconfig:

#define configMAX_PRIORITIES                     ( 16 )
#define configUSE_TIMERS			1
#define configTIMER_TASK_PRIORITY		( configMAX_PRIORITIES - 1 )
 #define configPRIO_BITS         4 
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See */

rtel wrote on Saturday, August 10, 2019:

Nothing obviously wrong on a first read. Not relevant to the issue you
are facing but there is no need to test xHigherPriorityTaskWoken before
passing it to portYIELD_FROM_ISR() as the test is performed inside the

Have you tried the normal things, like checking for stack overflows,
etc.? I suspect so given the
information you provided in your post…in which case try updating the
source files in the FreeRTOS/Source directory to the latest version from
SourceForge as that contains a lot more configASSERT() statements
designed to try and catch misconfigurations in the Cortex-M priorities.

haditj66 wrote on Saturday, August 10, 2019:

Thanks for the response. I found the problem. It was a stack overflow on one of the stacks that I had thought I removed from a while ago.
Is there a better way to check for stack overflows other than using uxTaskGetStackHighWaterMark. The way I had been doing it from before is just sprinking in uxTaskGetStackHighWaterMark across tasks I wanted to check, However as you saw, that is error prone.

haditj66 wrote on Saturday, August 10, 2019:

richard_damon wrote on Saturday, August 10, 2019:

There is a configCHECK_FOR_STACK_OVERFLOW which will check the stack of the task that is being swapped out for overflow.