I have an issue when I call the taskENTERCRITICAL() function to prevent RTOS preemption after I have called the STM32F4xx intrinsic function __disableinterrupt().

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

}

Hi,

I'm not sure why it gives a fault, but when calling taskENTERCRITICAL(), it isn't necessary to also call __disableinterrupt().

The function of taskENTER_CRITICAL() is to disable interrupts and it keeps a count (uxCriticalNesting) of how many times a critical section was entered.

taskEXITCRITICAL() decreases that count and when it reaches zero, interrupts will be switched on again. So you can just leave out "__disableinterrupt()"

Regards.

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/enableinterrupt() 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 configMAXSYSCALLINTERRUPT_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).

Regards.

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.