TMS570LS - SCI Phantom Interrupt

Hi Zhaohong,

I got the wording from the following code in sciLowLevelInterrupt()

default:

/* phantom interrupt, clear flags and return */

        sciREG->FLR = sciREG->SETINTLVL & 0x07000303U;

break;

So it appears that an interrupt of undetermined cause is not uncommon. 

We disable/reenable SCI_RX_INT in the sci module as follows:

        sciREG->CLRINT = SCI_RX_INT;

    ...

    sciREG->SETINT = SCI_RX_INT;

The VIM registers are not changed.

If we set a breakpoint set at the phantom (default) location, then step through to the ISR return, it returns to the line following the CLRINT.

Do we also have to set/clear RXENA in the SCI Global Control Register 1 (SCIGCR1)?

Thanks, Charlie

Charles,

Phantom interrupt are normally caused by racing conditions. The discussion in the following thread would provide useful information about phantom interrupt.

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

Can you put a breakpoint at vect 0 and check if there are any bits in the flag register when CPU stops there?

Thanks and regards,

Zhaohong

Zhaohong,

When a breakpoint was set at the default case (phantom), the flag register had at least  RXRDY set.  I'll run it again to see if any other interrupts were pending.

Your discussion you linked to looks like it may be helpful.  I'll look through it and get back to you.

Thanks for your time so far,

Charlie

Charles,

Normally, the offset register should point to the RX event when RXRDY is set. Would you please double check if you are reading the correct offset register? There are separate ones for level 0 and level 1 interrupts. You need to check the following.

(1) Which interrupt is enabled level 1 or level 0? You can only enable one. You need to check SCI registers and VIM registers.

(2) Check the VIM register to see if the correct flag is set when SCI interrupt occurs. To do this, you need to put a breakpoint at the very beginnin of the ISR,

(3) Check if the correct offset register is read.

I had personal experience in reading wrong offset register.

Thanks and regards,

Zhaohong

Hi Zhaohong,

We are looking at the correct offset register.  It's showing 0 which is why the ISR falls through to the default case.

"(2) Check the VIM register to see if the correct flag is set when SCI interrupt occurs."  I assume you mean the SCI Flags Register (SCIFLR).  It shows TXRDY, RXRDY, and TXEMPTY.

I have a queston about the discussion you linked to.  It seems to be a similar race condition but on the RTI module instead of the SCI module.  The race condition seems to occur when the Clear RTI Interrupt command is not received by the VIM when the ISR exits.  The suggested solution is to verify the interrupt flag is cleared before exiting the ISR.  This did not help in our case. 

What did resolve the problem was removing the CLRINT and SETINT.  The ISR never reached the default case.  This is similar to the solution found in the linked discussion.    Could you explain how the race condition in the ISR can be affected from outside the ISR?

Thanks, Charlie

Charles,

Can you provide details about what operation you perform on SCI after SCI interrupt is disabled? Can you make sure that SCI interrupt flag is cleared in the VIM module before re-enable SCI interrupt?

Thanks and regards,

Zhaohong

Zhaohong,

We are not performing an operation on the sci while interrupt is disabled.  We are accessing the queue directly and want to make sure the ISR is not updating the queue at the same time.

I don't think we want to clear the SCI interrupt in the VIM.  What we are seeing is the ISR is entered immediately after the interrupt is disabled in the sci.  The phantom interrupt occurs first with the RXRDY bit set.  When the interrupt is re-enabled, the ISR is entered again and the data is correctly processed.  This only happens now because we removed the following line from the ISR default case:

sciREG->FLR = sciREG->SETINTLVL & 0x07000303U;

This line seemed to clear out the real pending interrupt and result in data loss. 

This line is also confusing because the structures of the FLR and the SETINTLVL registers are not the same.  The mask corresponds to the SETINTLVL register. 

Thanks, Charlie

Charlie,

Would you plese share the source code of the ISR and disable/enable SCI ISR. From the information in this post I could not come up with a theory why SCI phantom interrupt occurs when you re-enable SCI interrupt. All I can guess is there are some racing condition when you re-enable SCI interrupt.

I personally do not like the approach of dynamically disable/enable interrupts. It could cause issues if one subtle item is missed in the process. Is is possible to keep the interrupt alive and use a double buffer to save and process data? If the message size is fixed, you can also consider using DMA to move data between SCI and RAM.

Thanks and regards,

Zhaohong

Hi Zhaohong,

The phantom interrupt occurs when the interrupts are disabled, the real interrupt occurs when the interrupts are re-enabled.

We have decided not to disable / enable the SCI receive interrupt.  The phantom interrupt periodically occurs, but since we modified the HALCoGen ISR, we have no loss of data.  We don't clear the interrup flags when a phantom interrupt occurs.

Thanks, Charlie