Hi It is my first time to use FreeRTOS7.5 on STM32F103VC. In my system, I use EXTI INT as exception INT and I use xQueueSendFromISR() to post event to Exception Task in this INT handler. While some times, this INT occured when xPortSysTickHandler() exec and then system halt. So can anybody tell me how to config FreeRTOS’s INT priority to disable EXTI handler when xPortSysTickHandler() in processing? Thanks a lot.

If you are saying your system crashes when the EXTI interrupt nests with the xPortSysTickHandler() function then it must be your interrupts have bad priority values or your STM32 interrupt controller has not been configured to make the ST peripheral libraries stable. If the EXTI handler is using xQueueSendFromISR() then it must have a priority equal to or lower than a user defined constant set in FreeRTOSConfig.h. configMAXSYSCALLINTERRUPTPRIORITY and configMAXLIBRARYINTERRUPTPRIORITY are the two to look for. There are lots of different ways of setting the priority of the EXTI interrupt but I guess you are using the ST libraries. I can’t remember the name of the function they provide so you will have to look it up. Lots about this written on the following link http://www.freertos.org/RTOS-Cortex-M3-M4.html but the interrupt system on Cortex-M3 devices seems so dysfunctional to normal people it is not difficult to see why so many people don’t understand it and get it wrong. Luckily, if you are using FreeRTOS V7.5.2, then you can just define configASSERT() in FreeRTOSConfig.h and it will check the configuration for you as you application executes http://www.freertos.org/a00110.html#configASSERT

thank you very much. It is true that system crash if EXTI occured and SysTick handler is also in processing. 🙁 In my platform, there are USB,COM,EXTI INT. in USB INT Handler, I malloc buffer and send RX buffer pt to the USB RX task. The USB INT has the highest INT priority. I can reduce EXTI priority, but I cannot reduce USB INT priority. So I think the crash will happen if USB INT occured when SysTick handler is in processing. Is it right? The one method to avoid this is portDISABLEINTERRUPTS() when enter xPortSysTickHandler() and portENABLEINTERRUPTS() when leave xPortSysTickHandler(), am I right? Or another method, up the systick INT prio to the highest. am I right? thanks a lot.

but I cannot reduce USB INT priority

Why not? I’ve never heard of an interrupt on a Cortex-M3 that had a fixed priority. Is the USB interrupt using a FreeRTOS API function? If not, then its priority does not matter, if so, then as already said its priority must be equal to or below the configured maximum syscall priority. If the USB interrupt is using a FreeRTOS API function and its priority really cannot be changed (I would be amazed if it can’t) then you will have to raise the maximum syscall priority to equal the USB priority. That is done using the constants I noted in my first post. Do not change the SysTick priority. That would not fix anything anyway, just move the problem. Also do not call portDISABLEINTERRUPTS() in an interrupt. Only functions and macros that end in FromISR or FROMISR can be used in interrupts. If you need a critical section in an interrupt use portSETINTERRUPTMASKFROMISR()/portCLEARINTERRUPTMASKFROMISR() instead. In fact, portDISABLEINTERRUPTS() should not really even be called from a task unless you are an expert user. From a task you should use taskENTERCRITICAL()/taskEXIT_CRITICAL() to create a critical section. In this case calling portDISABLE_INTERRUPTS() would not change anything anyway as it would still leave non system call interrupts enabled.

thank you very much, I will try… thanks.