STM32F4xx __disable_interrupt issue when using SafeRTOS

I have an issue when I call the taskENTER_CRITICAL() function to prevent RTOS preemption after I have called the STM32F4xx intrinsic function __disable_interrupt(). The processor goes to the HardFaultHandler() function after it processes the taskENTERCRITICAL() function. The function call sequence is shown below. It is executed from the RTOS IDLE task. static void prvIdleHook( void ) { vTaskSuspendScheduler(); // Suspend scheduler
__disable_interrupt();  // Disable all interrupts on the ARM

taskENTER_CRITICAL(); // Goes to the HardFault_Handler() after this call

(Task critical code here)

taskEXIT_CRITICAL();


__enable_interrupt();

xTaskResumeScheduler(); // Resume scheduler
}

STM32F4xx __disable_interrupt issue when using SafeRTOS

Hi, I’m not sure why it gives a fault, but when calling taskENTER_CRITICAL(), it isn’t necessary to also call __disable_interrupt(). The function of taskENTER_CRITICAL() is to disable interrupts and it keeps a count (uxCriticalNesting) of how many times a critical section was entered. taskEXIT_CRITICAL() decreases that count and when it reaches zero, interrupts will be switched on again. So you can just leave out “__disable_interrupt()” Regards.

STM32F4xx __disable_interrupt issue when using SafeRTOS

As Hein has already mentioned, if you have a double critical section, which means much of your code is obsolete (doesn’t do anything useful) anyway, but further to that: 1) It is not recommended to manipulate the interrupt settings in the core other than through the use of the FreeRTOS API. The enter/exit critical macros manage nesting of critical sections, whereas your calls to __disable/enable_interrupt() don’t. 2) __disable/enableinterrupt() will globally disable interrupts, which in many applications is a bad thing. The enter/exit critical macros will only mask interrupts up the the user set configMAXSYSCALLINTERRUPTPRIORITY priority, leaving higher priority interrupt completely unaffected by running FreeRTOS. 3) As a general rule, FreeRTOS API functions should not be called when the scheduler has been suspended. This rule can be relaxed if you are an expert user only (that is, if you understand what the API functions are doing and how not being able to perform a context switch during their execution will have). Regards.

STM32F4xx __disable_interrupt issue when using SafeRTOS

I’ve just noticed your question is in relation to SafeRTOS, not FreeRTOS – in which case you can discount my last answer. This forum does not provide support for SafeRTOS. Regards.