Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

METHOD TO PREVENT INTERRUPTS WITH UNKNOWN SOURCE

IP.com Disclosure Number: IPCOM000009921D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2002-Sep-27
Document File: 2 page(s) / 87K

Publishing Venue

Motorola

Related People

Russell L. Oertel: AUTHOR

Abstract

The HCll and HCl2 families of microcontrollers have historically allowed customers great flexibility in the handling of interrupts. For instance, an interrupt that is asserted will cause an interrupt request to be sent to the CPU, but the vector address is not calculated immediately; instead, the vector address is calculated only after the CPU requests one, thus allowing time for a higher-priority interrupt to arrive and be serviced first.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 50% of the total text.

MOTOROLA

Technical Developments

METHOD TO PREVENT INTERRUPTS WITH UNKNOWN SOURCE

by Russell L. Oertel

The HCll and HCl2 families of microcontrollers have historically allowed customers great flexibility in the handling of interrupts. For instance, an interrupt that is asserted will cause an interrupt request to be sent to the CPU, but the vector address is not calculated immediately; instead, the vector address is calculated only after the CPU requests one, thus allowing time for a higher-priority interrupt to arrive and be serviced first.

In addition, it is permissible to "take away" an interrupt, if for some reason (e.g. too much time has elapsed) it is no longer needed. This has left these MCUs with a problem throughout the years - what to do if an interrupt source is taken away after the CPU has recognized that it will take the interrupt flow, but before the vector has been calculated.

This problem has been handled by assigning an "unknown interrupt" vector address and leaving it to the customer to figure out what happened. This solution has been accepted for several years, but has never been very popular.

The simplest solution is to calculate the vector as soon as the CPU decides to take the interrupt flow, but this is undesirable since this can increase latency for high-priority interrupts. Even so, this is what was implemented on the HC12/STAR12,

Motorola. Inc. 2000

mostly for reasons unrelated to the problem described here. However, it turned out that the problem was not completely solved this way.

Certain operations, like STOP and WAIT modes, allowed windows in which an interrupt source could be removed and the CPU would be forced to take the "unknown interrupt" vector.

Although it was made to be difficult to set up these situations and their occurrence could be made rare, it was still undesirable to have them to be possible at all. What was needed was a mechanism...