I’ve run into a problem caused by my calling from an ISR a function that, ultimately, calls portENTERCRITICAL(), or more to the point, portEXITCRITICAL(), with the well-discussed effect that interrupts get enabled while still in the ISR. Fine, I understand the problem. My solution, for which I guess I’m seeking validation, was simply to increment uxCriticalNesting from within the FreeRTOS interrupthandler, after its original value has been saved. When interrupthandler finally unwinds, it restores uxCriticalNesting to its original value, and no one is the wiser, except that my code doesn’t crash. It seems to me that this is a legitimate use of uxCriticalNesting, and I can’t see any drawbacks, but then I didn’t write the Microblaze port, and I don’t like second-guessing published code. Am I all wet? Do I just not understand the point of uxCriticalNesting? I appreciate any thoughts on the subject. Thanks, -Nick FreeRTOS V8.1.2 Xilinx Spartan 6 MicroBlaze 8.50a Xilinx EDK 14.5

One issue that I can think of is that if your port allows for interrupts to nest, you still might need to use a critical section, only they are written differently in the interrupt context.

The Microblaze port does not (not yet, anyway) support interrupt nesting. What Nick is doing is technically breaching two of the API usage restrictions – whether that actually matters or not depends on the the API function being called and the situation in which it is being called. What is being called from the ISR? If it is anything that could potentially result in a yield being attempted then it will be very dangerous on the Microblaze (less so on other ports). Regards.

I remember thinking about this a while back while getting my port running on a Zilog eZ80. I use nested interrupts. I came up with something that sounds similar ~~~~~~ void vPortEnterCritical( void ) { portDISABLE_INTERRUPTS(); uxCriticalNesting++; } void vPortExitCritical( void ) { uxCriticalNesting–; if( uxCriticalNesting == 0 ) { portENABLE_INTERRUPTS(); } } ~~~~~~ I’m interested in hearing the same thoughts. FreeRTOS V8.0.0 Zilog eZ80F91 ZDSII 5.1.1

To be clear, the only functions being called are mine, and the only FreeRTOS API members being referenced are the critical section macros*. It seems that my solution should be safe, but only as a special case where nested interrupts are not possible. :-/ Rather than using uxCriticalNesting as an interrupt detector, I’ve added a dedicated flag that is incremented upon entry to interrupthandler() and decremented upon exit. Testing its value in the trace macro functions, and in portENTERCRITICAL should help protect me from myself.