Yet another portENTER_CRITICAL() question

nburkitt wrote on Friday, January 30, 2015:

I’ve run into a problem caused by my calling from an ISR a function that, ultimately, calls portENTER_CRITICAL(), or more to the point, portEXIT_CRITICAL(), 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 interrupt_handler, after its original value has been saved. When interrupt_handler 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.


FreeRTOS V8.1.2
Xilinx Spartan 6
MicroBlaze 8.50a
Xilinx EDK 14.5

richard_damon wrote on Friday, January 30, 2015:

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.

rtel wrote on Friday, January 30, 2015:

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).


markwrichardson wrote on Friday, January 30, 2015:

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 )

void vPortExitCritical( void )
	if( uxCriticalNesting == 0 )

I’m interested in hearing the same thoughts.

FreeRTOS V8.0.0
Zilog eZ80F91
ZDSII 5.1.1

nburkitt wrote on Saturday, January 31, 2015:

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 interrupt_handler() and decremented upon exit. Testing its value in the trace macro functions, and in portENTER_CRITICAL should help protect me from myself.