I’m currently studying the possibility of migrating some of our projects from Nucleus to FreeRTOS on an LPC43xx µC.

One of my main concerns is the limitation of use on ISR with higher priority than the FreeRTOS kernel. I need to keep an ISR uninterruptible / non-disabled with higher priority than the kernel one’s (due to hard real time constraints).

I have read the documentation of FreeRTOS and read some post related to my concern on the forum (for example https://sourceforge.net/p/freertos/discussion/382005/thread/670bab1e/#b281 ) without finding a way to communicate between that ISR and FreeRTOS.

Is there an issue to that problem? Can I use a mechanism to synchronize FreeRTOS tasks with that ISR? Can I raise another lower priority ISR or any other mean (synchronization flag…) that could allow me to reenter in the FreeRTOS world?

Thank you for any help.

I'm afraid I don't fully understand your question.

On ARM Cortex-M devices, FreeRTOS has a configuration setting called configMAXSYSCALLINTERRUPT_PRIORITY which the application writer can set to a value of their choosing (although the hardware itself prevents it being set to 0). Interrupts at or below that priority are can use the interrupt safe API, but are effected by kernel critical sections. Interrupts above that priority are never disabled [unless you application code disables them] but cannot use the interrupt safe FreeRTOS API.

Is your question how to use the FreeRTOS API from an interrupt above configMAXSYSCALLINTERRUPT_PRIORITY?

If that is your question, the answer is quite a simple "you can't". If you could, then configMAXSYSCALLINTERRUPT_PRIORITY would not exist.

If you could describe your particular use case (for example, what is the interrupt doing, what are its timing constraints, etc.) then perhaps we could suggest an option for you.

An interrupt with a priority above configMAXSYSCALLINTERRUPT_PRIORITY can't use the API because it is not disabled when FreeRTOS is manipulating internal structures that need to be able to be updated atomically. Either you need to place your ISR priority under the limit, and make sure your code uses similar restraint as the kernal (it only blocks the interrupts for very short periods), or if you absolutely can't tolerate even very short deays, that ISR needs to trigger a lower priority interrupt (otherwise unused) that make the communication to FreeRTOS.