Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Yet another portENTER_CRITICAL() question

Posted by nburkitt on January 30, 2015

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


Yet another portENTER_CRITICAL() question

Posted by richard_damon on 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.


Yet another portENTER_CRITICAL() question

Posted by rtel on 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).

Regards.


Yet another portENTER_CRITICAL() question

Posted by markwrichardson on 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 ) { 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


Yet another portENTER_CRITICAL() question

Posted by nburkitt on 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 interrupthandler() and decremented upon exit. Testing its value in the trace macro functions, and in portENTERCRITICAL should help protect me from myself.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS