There’s a lot of documentation which specifies that FreeRTOS API functions must not be called from within a critical section. However, is there a way to actually detect/catch when this happens? Perhaps using configAssert?
For example, the portASSERT_IF_INTERRUPT_PRIORITY_INVALID facility is provided to detect incorrect interrupt priority assignment. Is there something similar for catching API calls from critical sections? Or is this a painstaking process of manually searching through several hundreds of lines of code?
It’s not recommended having lengthy code inside critical sections as they disable FreeRTOS covered interrupts and interfere with (real-time) responsiveness of the application. They should be kept very short and used thoughtful. Mutex protection is usually more suitable because it’s designed for this purpose.
Do you have many critical sections in your code with complex code inside ?
The project uses a lot of interrupts as well as third party libraries which are what make it difficult to manually scan through. Not to mention, there’s a lot of FreeRTOS APIs to search for (is there a list anywhere?), so the chances of missing an instance is high.
It’d be really useful if there was some facility which’d trap the invocation of a FreeRTOS API if say the configAssert is enabled.
Agreed. However, using a lot of interrupts isn’t a problem as it is not directly related to using critical sections where not needed or applicable. Especially when calling into unknown libraries/code inside critical sections.
Also I’d be very picky using many critical sections especially when using many interrupts.
If I were to go through the code manually, would it be fair to assume that all critical sections would be enclosed around taskENTER_CRITICAL() & taskEXIT_CRITICAL() calls and their “FromISR” counterparts?
Also, is there a place where I can get a list of all APIs which are not supposed to be invoked from critical sections? I’m guessing the brute force way of scanning through the code is probably my only option now (I’d be elated if you could point me to something better! ).
It should not be a problem having a third party library that enters critical sections because a context switch cannot occur while inside the critical section, so you are not going to switch away to a task where you don’t know if you are in a critical section or not. Critical sections in the code are short and (other than one place) indented so you can see clearly which taskEXIT_CRITICAL() matches with each taskENTER_CRITICAL.
As for API functions not to call in a critical section - anything that might attempt to block is a definite no as (as just mentioned), you can’t switch context in a critical section so the task that tries to block will just continue executing - generating a “logic error” in the code. API functions that might unblock another task are bad too for the same reason - if the code assumes the unblocked task will run right away (which it won’t if you are inside a critical section) there will be a logic error.
).