STM32F4xx __disable_interrupt issue when using SafeRTOS

franchise98bjn wrote on Thursday, June 12, 2014:

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 HardFault_Handler() function after it processes the taskENTER_CRITICAL() 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)



xTaskResumeScheduler(); // Resume scheduler


heinbali01 wrote on Thursday, June 12, 2014:


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()”


rtel wrote on Friday, June 13, 2014:

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/enable_interrupt() 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 configMAX_SYSCALL_INTERRUPT_PRIORITY 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).


rtel wrote on Sunday, June 15, 2014:

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.