While implementing optimized critical section macros for the MSP430 port, I notice that xQueueCRSend and xQueueCRReceive use portDISABLE_INTERRUPTS()/portENABLE_INTERRUPTS() instead of portENTER_CRITICAL/portLEAVE_CRITICAL to implement a critical section (at least, in V7.1.1).
An unusual but valid design for MSP430 programs is to leave interrupts disabled at all times except when in low power mode. The new macros I’ve implemented restore the interruptibility state to what it was when the first critical section was entered, rather than unconditionally enabling interrupts, so FreeRTOS can be used with applications that follow this design.
Explicitly enabling interrupts in xQueueCRSend and xQueueCRReceive breaks this feature for MSP430 programs that use coroutines.
Since taskENTER_CRITICAL is defined in terms of portENTER_CRITICAL, I believe it should be possible to assume the port-named versions are available, and to use them (if the intent was to avoid “task*” invocations in coroutine support). Is there a reason why the existing critical section approach is required for these functions?