RTI and OVERFLOW

[JYJY]

On my NMIY-0020, I use the interruptions RTI and Overflow. When they are programmed both,
only the rti functioning. And if I puts the overflow priority numbers one, it is only it which goes. It is always one or the other which functions?
Would you have a solution?
Thank you!

Jean-Francois

[RMDumse]

One of the most common mistakes people have with interrupts is they forget to clear the interrupting source. Here is sounds like you might have the opposite problem. Tell us how you clear the interrupt? What do you write to TMSK2 in your interrupt routines?

[JYJY]

Ok!
In the configuration of the interruptions, TMSK2=0xC0. In routine OVERFLOW, TFLG2| = 0x80.
In routine RTI, TFLG2| = 0x40.
Could it be a material problem between the two interruption. If both interruption occur at the same time, both are appellés or only priority.

thanks
Jean-Francois

[RMDumse]

Originally posted by JYJY
In the configuration of the interruptions, TMSK2=0xC0.

Both enabled. That looks right.

In routine OVERFLOW, TFLG2| = 0x80.
In routine RTI, TFLG2| = 0x40.

Yes, the individual bit corresponding to the flag should be written as a one to clear the flag.

I was afraid you might be using a 0xC0 to clear both.

Could it be a material problem between the two interruption. If both interruption occur at the same time, both are appellés or only priority.

Each interrupt should ascert the IRQ line (internally) and the processor should first service the higher priority interrupt. Once inside the first interrupt, the processor's Condition Code Register has the I bit set, which disables further interrupts. However, when finished with the higher priority interrupt, the second interrupt should still be pending. The RTI ( return-from-interrupt software instruction) at the end of the first interrupt routine should pass control back to the foreground. By reinstalling the CC Register from the stack, the I bit in the CC is again cleared, and any pending interrupt can be processed.

Unless something first releases the second interrupt by clearing its bit from the TFLG2 register, or disabling its enable in the TMSK2 register, the second interrupt, still pending, should be processed. So my first suspicion was perhaps you were clearing both flags in each interrupt routine.

My next guess would be you are using a high level language which might be doing a word write as opposed to a byte write to those locations.

At this point, I think I would strart building tools to see what is going on. For instance. Make a variable. In your Real Time Interrupt routine, first thing, read the TFLG1 and store it in that variable. Then, you can tell by post examination if both bits are set or not. (This will work best if RTI is programmed for same rate as OVFL, so both bits should always be present.)

I can't tell you I've used the RTI and OVFL interrupts at the same time, but in all my experience with mutliple interrupts running at the same time, I've never seen one do away with the other pending unless an accidental software effect happened. Most likely, one interrupt routine is clearing both flags, or turning off an enable. There is a very small chance it is a hardware bug in the HC11. This is so unlikely as to be discounted until other testing is completed.

Can you do the test with the variable copy of TFLG2?

[CIM]

Salut J-F
As-tu résolu ton problème?
Si tu as des questions ou si tu demeure dans la région de Sherbrooke, je peux probablement t'aider.
Donne-moi des nouvelles

Mario