To FreeRTOS, is an Interrupt Callback Stlll an ISR?

groger57 wrote on Thursday, May 02, 2019:

Is a callback handler (implemented in STM32L4 using HAL/LL) still considered an ISR, and thus the thread safe calls should only be used? Or is the ISR cleared once the callback is being executed?

richarddamon wrote on Friday, May 03, 2019:

If the function is called from inside an ISR, like most of the HAL/LL interrupt callbacks, then YES, that function is part of an ISR, and should only use the FromISR functions (and can do so only if the interrupt is in the proper priority range). If you need to use some other APIs, then you could use the Pend Function from ISR call to schedule the function to be called from a task context.

The ISR context runs from the entry into the ISR until it return back to the interrupt code.

groger57 wrote on Friday, May 03, 2019:

The setup installs a callback handler and it’s not actually called directly from the ISR, at least for the ADC and USART which use a DMA IRQ. For this case it is different?
The only with the exception I see to this is the timer tick increment, which is called directly from the interrupt.

rtel wrote on Friday, May 03, 2019:

The setup installs a callback handler and it’s not actually called
directly from the ISR

What Richard D said stands in all cases. The processor is either
executing in an interrupt context or it is not. The context is a
hardware thing, not a software thing. If the callback is called from an
interrupt handler then it has an interrupt context. If you say here
that it’s not actually called directly from the ISR, then you have
probably answered your own question, but I have to ask - if it is an
interrupt callback and its not being called from the ISR, what is it
being called from? If you were to set a break point in the callback
function and look at the function call stack, what is at the top?

richarddamon wrote on Friday, May 03, 2019:

The key question is if the callback is called during the execution of the ISR, which my memory is that most of them are, instead of from a ‘task’ level polling loop that check flags set by the ISR.

The question isn’t did the interrupt directly vector to the function, that would affect if the function might need special code at start/end to handle being an ISR (which isn’t generally needed for the Cortex M4). The question is are you executing in an execution context setup by such an interrupt, that context extends from the beginning of the ISR function until it returns. The act of the ISR calling a function doesn’t change that context, you are still inside an ‘ISR’.

There are some callbacks called from a non-interrupt context in the HAL/LL package, but most of those are inside polling loops inside the drivers, and the presense of those polling loops generally says these functions are not well suited for ‘Real Time’ code (maybe usable at idle level tasks at best).

I suppose one quick distinction would be is this execution sequence something determined by the hardware interrupt controller, with possible software decisions after that (ISR), or is this execution sequence initiated by the task scheduler (Task). Once the interrupt controller initiates an execution sequence, you are in the ISR until control is returned to the interrupted task, or possibly initiate the scheduler, which then returns to some other task.

groger57 wrote on Saturday, May 04, 2019:

Thanks guys. All this advice is taken into account, and I will do some diggin with breakpoints and check the stack to see what is going on. Not that there is an issue, but understanding how this functions in the context of FreeRTOS will help avoid issues.

richarddamon wrote on Saturday, May 04, 2019:

Rather than using a debugger, you can use an IDE with a global search, and look for where those functions are called (and then perhaps where the function that calls the callback is called from).

I think you will find that a lot of those callback eventually go back to an ISR.