# Getting hardfault after calling FROMISR API from ISR

**URL:** <https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007>\
**Category:** Kernel\
**Created:** [August 10, 2019, 3:26pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007 "2019-08-10T15:26:21Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [August 10, 2019, 3:26pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007/1 "2019-08-10T15:26:21Z")

</div>

**[haditj66](https://sourceforge.net/u/haditj66/)** wrote on [Saturday, August 10, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/4e36d7a7eb/#5066):

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:

```auto

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:

```auto
			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:

```auto
 NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

```

for the ISR:

```auto
    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:

```auto
#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) )

```

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [August 10, 2019, 4:01pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007/2 "2019-08-10T16:01:32Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, August 10, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/4e36d7a7eb/#5066/877f):

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](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.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [August 10, 2019, 9:34pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007/3 "2019-08-10T21:34:39Z")

</div>

**[haditj66](https://sourceforge.net/u/haditj66/)** wrote on [Saturday, August 10, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/4e36d7a7eb/#5066/877f/0684):

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.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [August 10, 2019, 9:34pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007/4 "2019-08-10T21:34:43Z")

</div>

**[haditj66](https://sourceforge.net/u/haditj66/)** wrote on [Saturday, August 10, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/4e36d7a7eb/#5066/877f/a94a):

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [August 10, 2019, 9:47pm UTC](https://forums.freertos.org/t/getting-hardfault-after-calling-fromisr-api-from-isr/8007/5 "2019-08-10T21:47:23Z")

</div>

**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Saturday, August 10, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/4e36d7a7eb/#b420):

There is a configCHECK\_FOR\_STACK\_OVERFLOW which will check the stack of the task that is being swapped out for overflow.