68HC11 XIRQ masking.

   The MC68HC11 has an XIRQ input which generates a high-priority interrupt.   Before this is operable, the stack pointer must be loaded and the XIRQ must be enabled by clearing its mask bit (X-flag) in the CCR.   Once cleared, this cannot be set (at least in any "normal" manner) so that the XIRQ cannot be masked.   But there is in fact a way to disable the XIRQ other than by RESET.

   The following is quoted from one of my discussions on the MC68HC11 mailing list:

   "My gray book describes in section 5.4.1, the hardware implementation of the X bit as a set-reset latch rather than a D flip flop. ... with the SET input connected to the OR of reset and XIRQ* acknowledge."

   If indeed this is the case, then

1. this means that the XIRQ service routine has the option (by fiddling the stacked CCR) to re-enable itself or not.
2. Clearing the I-bit and thereby enabling other interrupts to nest within an XIRQ call would function perfectly satisfactorily.
3. Re-entrant XIRQ code would, by the same token, work if written correctly and
4. it would be far simpler than what I had previously suggested might be the case.

   "Okay, I believe we all agree that once the X bit is cleared to 0 by a TAP instruction, XIRQ becomes a non-maskable interrupt which cannot be re-masked by writing a 1 to the stacked CCR during an xirq_ISR.   My gray book tells me so."

   Err, no!Your description above says it CAN be "re-masked" by writing a 1 to the stacked CCR, because it has ALREADY been re-masked and setting the bit in the stacked CCR merely prevents it from being "un-re-masked" on completion of the ISR.

   "Vector to xirq_ISR"

   This can be used ... only if you do it by activating the XIRQ line.

   "Paul alluded to the existence of a secret stack for holding the CCR during XIRQ service."

   I tke it back entirely as I now understand the simpler description.

   "Section 5.4.1 of the gray book explains their reasoning.    I won't repeat it here, but only add that if XIRQ could be re-masked by a TAP or RTI instruction, then an insane program, or any ISR with a stack error could accidentally re-mask it."

   It would seem that an XIRQ ISR with a stack error, could.

   "Have they gone to great lengths?   Probably.   Was it necessary?   Yes."

   Beyond a certain point it becomes ridiculous.   I should find this latest understanding of the implementation, more than adequate.   If you can get execution errors within an XIRQ routine, you really are cooked!