CFV2 vector 125??? (vector or'ing?)

[RichTestardi]

Hi all,

I have a perplexing problem with a 52221 processing receive interrupts from uart0.  I am running CW7.1.1 if that matters.

Basically, it all seems to work, but out of the blue, occasionally, I take vector 125 of the IVT!  Vector 125 is interrupt source 61, which is supposedly "CFM, PVIF, Protection violation".

Now, of course, I don't have the CFM enabled to interrupt (CFMMCR is 0), and it isn't actually requesting one (CFMUSTAT is 0xc0).  However, on the stack, plain as day, is a trap frame indicating vector 125:

    41F42004  -->  0100 00(01 1111 01)00  -->  0x7d  -->  125

And the stack is valid, within bounds, etc.

At the time, of course, IPRH (0x00A00000) does not indicate this interrupt is pending (though the uart0 and USB interrupts are, as well as pit0), though the "Cleared automatically" in the interrupt sources table makes me wonder if I should see it there even if it was...

This only occurs when using uart0 along with USB; both devices are configured to IPL 4, so they should be mutually exclusive.

Now here is where things get crazy!!!

The interrupt source number for usb is 53...  The interrupt source number for uart0 is 13.  IF I "OR" (bitwise) THESE TOGETHER WE GET 61, WHICH WOULD LEAD TO VECTOR 125!!!

CAN THIS BE HAPPENING?  Could the simultaneous uart0 and USB interrupts cause the vector numbers to be or'd???

Or what could I possibly be doing wrong to cause this?

If I just make vector 125 do shadow the uart0 vector, everything works (which is both good and scary).

Thanks!

-- Rich

[RichTestardi · Accepted solution]

Well, I am going to answer my own question for anyone else who stumbles here!

It's in the doc!

Note: It is the responsibility of the software to program the ICRnx registers with unique and non-overlapping level

and priority definitions. Failure to program the ICRnx registers in this manner can result in undefinedbehavior. If a specific interrupt request is completely unused, the ICR

nx value can remain in its reset (and

disabled) state.

[MrBean]

It seems you have reverse engineered the undefined behaviour ;D

[RichTestardi]

Wow, and if I change *either* the interrupt level *or* the interrupt priority of the uart0 interrupt to not be the same as for the USB, the problem goes away!

Now maybe someone will tell me I should have known all along that you can't have two interrupts with the same level and priority?  I thought priority only determined which interrupt was serviced if multiple were pending when the level dropped, not that priority had to be *unique* within a level.

Does anyone know if the former could in fact be the case?  Thanks!