Calling taskENTER_CRITICAL(); inside interrupt handler

Kernel
1

cio74 wrote on Tuesday, October 06, 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 pin_edge_handler_INPUT(const uint32_t sourceid, const uint32_t mask){
taskENTER_CRITICAL();
ProcessInterrupt(sourceid, mask);
taskEXIT_CRITICAL();
}

Thanks.

2

rtel wrote on Tuesday, October 06, 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 configMAX_SYSCALL_INTERRUPT_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.

3

cio74 wrote on Tuesday, October 06, 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.

4

rtel wrote on Tuesday, October 06, 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?

Regards.