FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2015 Threads] Calling taskENTER_CRITICAL(); inside interrupt handlerPosted by cio74 on October 6, 2015 Hello,
I have a board with ARM Cortex-M4 MCU runing FreeRTOS 7.3.0 which has 4 tasks and 1 hardware interrupt. What I would like to happen when the interrupt is fired is to disable interrupts (including the one that generated the event), do the work and then re-enable them all. Basically I don;t want anything to trigger while inside the interrupt.
Is it correct to implement it like that:
void pinedgehandlerINPUT(const uint32t sourceid, const uint32t mask){
taskENTERCRITICAL();
ProcessInterrupt(sourceid, mask);
taskEXIT_CRITICAL();
}
Thanks.
Calling taskENTER_CRITICAL(); inside interrupt handlerPosted by rtel on October 6, 2015 On a Cortex-M you might get away with that - but the correct way (in the old version of FreeRTOS you are using) would be something like this:
UBaseType_t uxSavedInterruptStatus;
uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
ProcessInterrupt();
portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );
Note that will only disable up to configMAXSYSCALLINTERRUPT_PRIORITY - if you want to globally disable then use the interrupt enable/disable bit inside the CPU itself.
....alternatively, you could just make the interrupt the highest priority interrupt in your system, then you are guaranteed that it won't get interrupted by anything else.
Calling taskENTER_CRITICAL(); inside interrupt handlerPosted by cio74 on October 6, 2015 Thanks for your quick response, it all makes sense.
About making the interrupt the highest priority, it won't get interrupted by anything else but it may get triggered again; I don't want this to happen, I'm happy to ignore all other interrupt triggers until I'm done processing the first event.
In the old x86 I used to call CLI first line and STI last one, quite a while since then.
A bit off-topic, what tool will help me trace process and stack usage, I got hardware fault now and then and these are very difficult to debug; any suggestion of something that may help?
Thanks.
Calling taskENTER_CRITICAL(); inside interrupt handlerPosted by rtel on October 6, 2015
About making the interrupt the highest priority, it won't get
interrupted by anything else but it may get triggered again; I don't
want this to happen, I'm happy to ignore all other interrupt
triggers until I'm done processing the first event.
....but on a Cortex-M an interrupt cannot itself be interrupted by
another interrupt of equal priority. Maybe you are worrying about
something that cannot happen.
In the old x86 I used to call CLI first line and STI last one, quite
a while since then.
I'm not suggesting you do it, but the equivalent on a Cortex-M would be
cpsid i
and
cpsie i
A bit off-topic, what tool will help me trace process and stack
usage, I got hardware fault now and then and these are very difficult
to debug; any suggestion of something that may help?
http://www.freertos.org/Stacks-and-stack-overflow-checking.html
http://www.freertos.org/uxTaskGetStackHighWaterMark.html
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|