32F417: trying to interrupt from PE12 rising edge

[PHolt.1]

Post edited by the ST moderator to be inline with ST community rules especially for the code. Please use </> button to paste your code. 

Hello :)

I almost have this working. In fact I had the ISR running and incrementing an integer. Then I went to the next stage and put in the xTaskResumeFromISR() but that crashes in configASSERT( xTaskToResume ).

Can anyone see any problems with this code?

Init:

__disable_irq();

GPIO_InitTypeDef GPIO_InitStruct = {0};

// Configure PE12

GPIO_InitStruct.Pin = GPIO_PIN_12;

GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING; // Interrupt on rising edge

GPIO_InitStruct.Pull = GPIO_PULLDOWN; // pulldown

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; // This does nothing on an input pin

HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

// Configure NVIC

HAL_NVIC_SetPriority(EXTI15_10_IRQn, 10, 0);   // Maybe the priority is not suitable for xTaskResumeFromISR ?

HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

__enable_irq();

Vector table piece:

.word USART2_IRQHandler /* USART2 */

.word USART3_IRQHandler /* USART3 */

.word EXTI15_10_IRQHandler /* EXTI15_10_IRQHandler External Line[15:10] used for PE12 (TE) interrupt */

.word 0 /* RTC_Alarm_IRQHandler RTC Alarm (A and B) through EXTI Line */

.word 0 /* OTG_FS_WKUP_IRQHandler USB OTG FS Wakeup through EXTI line */

ISR:

// Handler for TE (PE12=1) interrupt.

// This restarts the xLCDHandle task which was suspended with vTaskSuspend(NULL).

void EXTI15_10_IRQHandler(void)

{

// Check if interrupt is from EXTI12 (PE12)

if (EXTI->PR & (1 << 12))

{

// Clear the interrupt pending bit

EXTI->PR = (1 << 12);

// Restart the suspended LCD task. If task not suspended, nothing happens

//xTaskResumeFromISR( xLCDHandle ); // uncommenting this breaks it

}

}

Currently I have no tasks suspended (so nothing to resume) but xTaskResumeFromISR should then just return False.

Digging around I found this

// Restart the suspended LCD task. If task not suspended, nothing happens

xYieldRequired = xTaskResumeFromISR( xLCDHandle );

if ( xYieldRequired == pdTRUE )

{

portYIELD_FROM_ISR( xYieldRequired );

}

but it doesn't help because the crash happens inside xTaskResumeFromISR.

Thank you very much for any input.

[Pavel A.]

> It means: "The LOWEST priority (highest number) that can call FreeRTOS APIs"

It means the highest priority (lowest number) that can call RTOS API. At this level the synchronization occurs: this level and lower (greater numbers) are masked inside RTOS calls. Higher priority handlers (smaller numbers) are not masked so they run undelayed but cannot call the RTOS.

[PHolt.1]

"Higher priority handlers (smaller numbers) are not masked so they run undelayed but cannot call the RTOS."

I think you have it the other way round.

In reality, numbers higher than 5 (lower priority than 5) cannot call the RTOS.

[TDK]

> I think you have it the other way round.

> In reality, numbers higher than 5 (lower priority than 5) cannot call the RTOS.

Documentation does not support this statement. @Pavel A. is correct.

configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest interrupt priority from which interrupt safe FreeRTOS API functions can be called.

Customization - FreeRTOS™

Logically, higher priority interrupts have more restrictions on what they can call, not fewer.

You should mark your post above about HAL_NVIC_SetPriorityGrouping(0) being the problem as the solution. If you had shown that in the original post, I'm sure it would have been caught.

[Chris21]

As OP already posted:

/* The highest interrupt priority that can be used by any interrupt service
routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL
INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER
PRIORITY THAN THIS! (higher priorities are lower numeric values. */
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

As to why it seems backwards, I suspect FreeRTOS was not originally developed for ARM Cortex devices, some other micros have interrupt priorities where higher priorities are higher numeric values.

[PHolt.1]

Yes, could be a fossil comment. Software is full of these.

Experimental evidence is what is needed, and mine is that the comment is backwards in its English meaning - at least when the ISR is calling a FreeRTOS function whose name includes "fromISR" and to which the following FR comment applies:

Only FreeRTOS functions that end in FromISR can be called
      from interrupts   that have been assigned a priority at or (logically)
      below the maximum system call interrupt priority. 

An ISR with a priority lower (i.e. a higher number) crashes the system when it calls that FreeRTOS function.

I suspect that others have discovered this before, because googling (and Claude) return the same thing.