Interrupt priority level and software interrupt
Hello,
We’re using an interrupt with no kernel call with a priority above configMAXSYSCALLINTERRUPTPRIORITY.
This interrupt need a high priority.
My problem is that at the end of this interrupt we call a software interrupt with priority below configMAXSYSCALLINTERRUPTPRIORITY and with kernel call API (From_ISR).
It seems that the software run better if we decrease the first interrupt priority.
I’m not sure to understand what is wrong
Interrupt priority level and software interrupt
I’m not sure to understand what is wrongNor am I as you didn’t mention in your post what the problem you were having was. If you want to ‘call’ another lower priority interrupt then don’t call the function, but just pend the interrupt (M3 interrupts can be pended in software). Then when the high priority interrupt completes the lower priority interrupt will execute automatically.
Interrupt priority level and software interrupt
The problem is that we have some freeze for instance inside vListInsert or in other cases bad behaviour with other drivers just after several hours in load.
The configMAXSYSCALLINTERRUPT_PRIORITY is defined at 6, other driver have interrupt priorities between 1 and 4.
The problem is with our ARINC driver timer TPU which has interrupt priority of 10 but call a software interrupt of priority 4.
We use RX631 with FreeRTOS, the software interrupt is called with
__intrinsic void __software_interrupt(unsigned char);
which is in IAR/include/intrinsics.h in our project
The IPL is forced at 4 inside software interrupt with
__set_interrupt_level(4);
Without the “call” of software interrupt there is no more problem.
We don’t understand why the software interrupt is not pending until the CPU IPL allow execution. Maybe it is something with freertos, like bad use.
What do you mean with M3 interrupts?
Interrupt priority level and software interrupt
We use RX631 with FreeRTOS … What do you mean with M3 interrupts?So you are not using a Cortex-M, which means you can discount my previous reply. I was guessing what your platform was and guessing what your problem was. http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html
The problem is that we have some freeze for instance inside vListInsert or in other cases bad behaviour with other drivers just after several hours in load.So that is normally a symptom of an incorrect priority assignment, as you mention, but can also be caused by just a simple RAM corruption.
The configMAXSYSCALLINTERRUPT_PRIORITY is defined at 6, other driver have interrupt priorities between 1 and 4. The problem is with our ARINC driver timer TPU which has interrupt priority of 10 but call a software interrupt of priority 4.How are you ‘calling’ this interrupt?
Interrupt priority level and software interrupt
The code for the high priority interrupt was
~~~
//——————————————————————————
// Interrupt routine for detecting idle in reception
static void ArItIdleRxiHandler(UINT8 nSci) {
if ( nSci < K_NbArincChannels ) {
//Stop timer
ArStopIdleDetection(nSci);
//check interrupt request flag of reception
if ( M_ArReadRxItFlag(nSci) ){
}
else {
switch ( nSci) {
#if ( K_NbArincChannels >= 1)
case 0:
__software_interrupt(K_ArSoftItVectNbr0);
break;
...
~~~
It’s a TPU interrupt with only HW macros and the call of SW interrupt
The Software interrupt code was
~~~
//——————————————————————————
// Interrupt routine for loading received message after detecting idle
static void ArItLoadRxiMessageHandler(UINT8 nSci) {
portBASE_TYPE xTaskWoken = pdFALSE;
//Complete ARINC message reception
if ( nSci < K_NbArincChannels ) {
// Software interrupt used so set the IPL to under OS IPL
__set_interrupt_level(K_ArRxiLoadMessageItPriority);
// Reactivate interruption
__enable_interrupt();
if ( (t_ReceptionState[nSci] == K_ArFrameReception_OK )) {
// Write reception time
g_ArRxBuffer.recTime = xTaskGetTickCountFromISR();
//Allow ARINC Transmission
xSemaphoreGiveFromISR(g_ArTxSemaphore, &xTaskWoken);
// Context Switch
portYIELD_FROM_ISR(xTaskWoken);
…
~~~
The call of __set_interrupt_level(K_ArRxiLoadMessageItPriority);
was maybe a bad idea since it only set the CPU IPL
But it was working if we only change the ArItIdleRxiHandler priority below configMAXSYSCALLINTERRUPT_PRIORITY so it seems to be a freeRTOS bad use.
As the ARINC idle detection is important. It is important for us to set a high priority. But it seems to work without SW interrupt mechanism. We have changed this way.