Phantom Interrupt generation method according to spna063.pdf

Hello Support,

I am still waiting for some answer related to Phantom Interrupt generation mechanism. Also attached below a snippet from another e2e post :

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/63309.aspx

Thank you.
Regards
Pashan

Pashan,

A phantom interrupt is said to have occurred when the CPU takes the interrupt (switches mode to IRQ or FIQ) and then has no way of telling the source of the interrupt request. This can happen when the interrupt flag inside the VIM gets cleared outside of the ISR that is assigned to clear the flag.

Enabling or disabling interrupts while the interrupt flag is set is not recommended. The software must clear flags before enabling interrupts and also check for pending interrupt flags in the module registers and in VIM before disabling interrupts.

Regards, Sunil

Hello Sunil,

Assume everything have been initialized according to the order as mentioned by you [for VIM as well as CPU and DCAN]. Assume in the system we are using DCAN1 for DATA Transfer using DCAN1 Interrupt mechanism through VIM.

Now at the TASK Function Level, we are trying to perform DCAN CTL Register IE0/IE1 set to ZERO, then copy DATA to/from DCAN Peripheral, then again enable DCAN CTL IE0/IE1 bits.

We are not changing any other bits wiithin VIM or CPU Level when we are toggling IE0/IE1 bits other than Read/Write DCAN IFx registers for DATA Transfer.

Question:

Because we are toggling DCAN IE0/IE1 bits continuously, is there any possibility of Phantom Interrupt and if so, then why?

Thank you.
Regards
Pashan 

Pashan,

what is your VCLK ratio to HCLK?

Hello Henry,

My question is not regarding ERRATA VIM#27.

My GCLK:VCLK ratio is 2:1.

My question is whether just by toggling IE0/IE1 bits of DCAN CTL Register continuously during TASK function level [not at ISR Level], is there any possibility of Phantom Interrupts, even though all the necessary INT ACK flags are cleared within respective ISR routines only.

Thank you.
Regards
Pashan

Hello Pashan,

Can i ask why you toggle IE0/IE1 at task level?   what are you trying to achieve by doing this?

These IE0/IE1 are the interrupt enable bits, but clearing them will also clear the interrupt to the VIM.

Now, i can not imagine how toggling these IE0/IE1 will make phantom interrupt because the VIM support pulse interrupt (active high a single cycle).

so, as long as VIM recognize that there is an interrupt trigger and register it inside control logic, it is ok to de-assert interrupt line.

can you try one thing by trying to clear the corresponding INTREG[x] corresponding to line 0 and line 1 that DCAN interrupt got map too every time you clear IE0/IE1 in your task?

Hello Henry,

I never said that I am getting Phantom Interrupt because of IE0/IE1 toggling.

My question is whether there is a possibility of getting Phantom Interrupt at all if I toggle IE0/IE1 at the TASK level.

Now, why I do that?

Because we have multiple aperiodic TASKS performing CAN Tx/Rx action. So, instead of DISABLE I-Bit within CPSR register for Data Coherency, I am using CAN IE0/IE1 to disable CAN Tx/Rx during CAN Data Copy at the TASK level in order to avoid RACE condition of DATA Inconsistency.

Hope my question is clear now.
Thank you.
Regards
Pashan

Hi Pashan,

OK, sorry i misunderstood your question.  I took it from the assumption that you already had it and try to understand if it could happen.

So, to answer the possibility question, i don't see how it can happen.

as i said, the VIM support edge trigger interrupt as well as level trigger interrupt.

so as long as there is an interrupt captured inside VIM, then, it will not be phantom.

Now, you have to be careful that when toggling IE0/IE1, you may accidentally clear interrupt before it is being registered inside VIM.

in that case, you will not get a phantom, but will not get notified if this is acceptable to you.

why don't you implement a semaphore or something like similar that will ensure that only one task at a time to do copy?

are these tasks sharing the same mailbox in CAN RAM?  

Hello Henry,

Thank you for the answer.

1>  Now regarding the statement :

"Now, you have to be careful that when toggling IE0/IE1, you may accidentally clear interrupt before it is being registered inside VIM."

Once I reenable the IE0/IE1, DCAN will trigger an interrupt for the condition which was existing before IE0/IE1 was toggled to ZERO.

Because the only thing being performed in the Crtitical Section [IE0/IE1 = 0] is changing data IF1_DATA fields for CAN Mailboxes which are not Interrupt Active at that instant.

2> Now regarding the semaphore :

We are using the complete CAN Software from third party. They provided CALLBACK for critical section within their code. In those CALLBACK they have asked us to DISABLE CAN Interrupts using VIM MASK bits instead of DCAN IE0/IE1 bits.

But I don't like accessing VIM dynamically because VIM is for all Interrupts within our System. DCAN is only one part of the whole system.

So, I thought of changing IE0/IE1 instead of VIM DCAN Channel Mask. Hence the question about Phantom Interrupt.

3> Now regarding only one TASK for DATA Copy:

That's not the problem, because as I said before, the CALLBACK functions are required by the CAN Stack software from third party.

4> Now regarding shared CAN Mailbox :

That is handled by third party software and invisible to us. We just need to fill up the CALLBACK function for Critical Section within their code.

Please answer to QUESTION 1  in this mail regarding missing INTERRUPT condition.

Thank you.
Regards
Pashan