cancel
Showing results for 
Search instead for 
Did you mean: 

[solved] Interrupt priorities

Patriks
Senior
Posted on November 25, 2014 at 13:18

Hello,

Yesterday, I investigated a problem with my software project for an SPC560B. There are several calculations running on the controller and it additionally communicates over UART with a PC. When I tried to increase the UART baud rate, I got the effect that the controllers ''miss'' some bytes sent by the PC.

I found out, that reason for that effekt has something to do with the UART RX interrupt and an interrupt created by the periodical timer PIT. After the PIT causes an interrupt, the UART RX can not trigger an interrupt. I always thought that a higher priority interrupt can break the program even when another lower prior interrupt is currently running?

Best regards,

Patrik
This discussion has been locked for participation. If you have a question, please start a new topic in order to ask your question
16 REPLIES 16
Patriks
Senior
Posted on April 22, 2015 at 16:19

Hello!

Once again, I have problems with interrupt priorities (the issue I started with this topic has never been solved).For my current project, Ihave a very high priority ISR which must preempt all other ISRs. I tried different priorities and settings within the source code, butI wasn´t able to get this behavior.

Therefore, I set up a small demo project for SPC56xL Discovery Board (based on SPC56EL OS-Less Demo Application from SPC5 Studio)

Within this application, I integrated two PIT timer interrupts (channel1 and channel2). One interrupt handler gets a high priority (8) and the other one a low priority (2). I expected, that the high priority preempts the lower priority. But the higher priority interrupt is only executed when the lower priority isn´t running.

For better understanding, I attached a picture. In this picture, signal D6 represents the lower prior interrupt, D4 the higher prior interrupt. The two pins are set at the beginning of the corresponding ISR and cleared at the end of ISR.

To be sure that it isn´t a problem with my interrupt handlers, I also created the ISRs using the SPC5 Application Configuration with activated ''Preemptable ISRs'' option. Nevertheless, I got the same result as with my ''own'' interrupt handlers.

These are the interrupt handlers in osal_cfg.c:

/*===========================================================================*/ 
/* Module ISRs. */ 
/*===========================================================================*/ 
/* 
* ISR_1 ISR function (vector 61). 
*/ 
OSAL_IRQ_HANDLER(vector61) { 
OSAL_IRQ_PROLOGUE(); 
/* ISR code here.*/ 
Task_10us(); 
/* Resets the PIT channel 0 IRQ flag.*/ 
PIT.CHANNEL[2].TFLG.R = 1; 
OSAL_IRQ_EPILOGUE(); 
} 
/* 
* ISR_2 ISR function (vector 60). 
*/ 
OSAL_IRQ_HANDLER(vector60) { 
OSAL_IRQ_PROLOGUE(); 
/* ISR code here.*/ 
Task_100us(); 
/* Resets the PIT channel 0 IRQ flag.*/ 
PIT.CHANNEL[1].TFLG.R = 1; 
OSAL_IRQ_EPILOGUE(); 
} 
/*===========================================================================*/ 
/* Module exported functions. */ 
/*===========================================================================*/ 
/** 
* @brief Generated initialization code. 
* 
* @special 
*/ 
void osal_cfg_init(void) { 
INTC_PSR(OSAL_VECTOR_ISR_1)=INTC_PSR_ENABLE(INTC_PSR_CORE0, 8); 
INTC_PSR(OSAL_VECTOR_ISR_2)=INTC_PSR_ENABLE(INTC_PSR_CORE0, 2); 
} 
/** @} */

Additionally, OSAL_ENABLE_IRQ_PREEMPTION in osal_cfg.h is set TRUE

#if !defined(OSAL_ENABLE_IRQ_PREEMPTION) 
#define OSAL_ENABLE_IRQ_PREEMPTION TRUE 
#endif

What is the reason for the described behavior? And how I have to configure my system toactivate preemption of lower priorities by higher priority ISRs?

Best regards,

Patrik

________________

Attachments :

scope_72.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Vk&d=%2Fa%2F0X0000000bZo%2FrJoqsMF2nqhS.6_N.508vRWfiqkn9aZhUOcTRN0gUM4&asPdf=false
Erwan YVIN
ST Employee
Posted on April 22, 2015 at 18:12

Hello Patrik ,

Very strange, on SPC56xL , the preemption and nesting IRQ are activated by default. I will check this issue this thursday. could you check your CPR by debugger when the interruption is generated ?

#define INTC_CPR(n) (*((volatile uint32_t *)(INTC_BASE + 8 + ((n) * sizeof (uint32_t)))))

could you try INTC_EOIR(

INTC_PSR_CORE0

) = 0 before the end of the interruption handler the two) ? Could you send me your application ? Best regards Erwan
Patriks
Senior
Posted on April 23, 2015 at 07:52

Hello Erwan,

I checked INTC_CPR_PCR0 register value. When interrupt is generated, the register shows the priority level of corresponding interrupt (8 or 2).

Including

INTC_EOIR(INTC_PSR_CORE0) = 0;

at the end of interrupt handler has no effect onbehavior.

You can find the project within the zip file attached to this post.

Best regards,

Patrik

________________

Attachments :

SPC56ELxx_OS-Less_Test_Application.7z : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Va&d=%2Fa%2F0X0000000bZn%2FqIArxY6dwHNPq0HRmyxV_4dS5_rQZbCuX9Dtc.yqw3E&asPdf=false
Erwan YVIN
ST Employee
Posted on April 23, 2015 at 10:46

Thanks ;)

We will check today

Erwan YVIN
ST Employee
Posted on April 23, 2015 at 18:28

Hello Patrik ,

The problem has been reproduced .

in forcing in ivor.s, it is working.

/* Allows preemption while executing the software handler.*/
wrteei 1
/* Executes the software handler.*/
bctrl
/* Prevents preemption again.*/
wrteei 0

Could you try this piece of code ''ivor.s'' ?

The compilation switch was not taken in account.

i am checking the platform configuration in SPC5studio

Best Regards

Erwan

________________

Attachments :

photo.JPG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0VV&d=%2Fa%2F0X0000000bZm%2FItO27sKjPGzL3Ya3K0cSNAw_8by8ZlvVr186uAmJKRE&asPdf=false
Patriks
Senior
Posted on April 24, 2015 at 08:38

Hello Erwan,

That was the reason. After changing ivor.s it works. Thanks for your fast help!

Best regards,

Patrik
Erwan YVIN
ST Employee
Posted on April 24, 2015 at 09:19

Hello Patrik ,

we have submitted an Error Report to have this correction.

sorry again for the issue

   Best regards

              Erwan