Getting hardfault after calling FROMISR API from ISR

haditj66 wrote on Saturday, August 10, 2019:

FreeRTOS V9.0.0
stm32f411
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. */
					portYIELD_WITHIN_API();
				} 

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:

 NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

for the ISR:

    HAL_NVIC_SetPriority(USART2_IRQn, 5, 0);
  HAL_NVIC_EnableIRQ(USART2_IRQn); 

for the tasks that the queues the isr sends to :
PRIORITY 10

for the freertosconfig:

#define configMAX_PRIORITIES                     ( 16 )
 
#define configUSE_TIMERS			1
#define configTIMER_TASK_PRIORITY		( configMAX_PRIORITIES - 1 )
 
 #define configPRIO_BITS         4 
 
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY   15
 
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
 
#define configKERNEL_INTERRUPT_PRIORITY 		( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 	( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

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
macro.

Have you tried the normal things, like checking for stack overflows,
etc.? https://www.freertos.org/FAQHelp.html 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.