鈩?/div>
Family
Technical
Bulletin
EPD Systems Engineering
Using Slow Peripherals with
29K Family Processors
August 1, 1994
Purpose
Usually, when a peripheral requests an interrupt from
a 29K Family processor, the interrupt handling
software clears the interrupt source and the peripheral
de-asserts the interrupt line. However, some
peripheral devices are so slow that the 29K Family
processor is able to begin processing the interrupt
again (as if it were a new interrupt) before the
peripheral removes the original interrupt.
This technical bulletin describes how to work around
the disparity in speeds between a slow peripheral and
a 29K Family processor.
interrupt is active, the slow peripheral device finally
clears the interrupt condition. Now the processor is
not able to determine which peripheral called for an
interrupt, so it defaults to trap 0 (the invalid op code
trap).
This situation is aggravated because the 29K Family
pipeline allows load and store bypassing until there is
a direct dependency situation. Therefore, simply
moving the interrupt-clearing LOAD or STORE
earlier in the handler may not help, as the LOAD or
STORE is not guaranteed to actually execute any
earlier.
Affected Parts
The information in this bulletin affects the following
parts:
Device
All 29K Family microprocessors and
microcontrollers
Work-Around
Revision
All
Slow Peripherals
If an external peripheral device requests an interrupt
from a 29K Family processor, the 29K Family-based
part clears the interrupt by reading or writing the
appropriate external bits from the interrupt handler.
Then the interrupt handler performs an interrupt
return sequence (IRET).
As part of the interrupt return, the processor looks for
active interrupt sources. In the case of a peripheral
device that is much slower than the 29K Family
processor, the peripheral device still has not
processed the interrupt-clearing LOAD or STORE, so
the interrupt is still asserted. Consequently, the
processor sees an active interrupt and begins to
process it (for the second time).
After the processor determines that an interrupt is
pending, and before the processor determines which
The way to work around this situation is to force the
LOAD/STORE to complete and guarantee the
peripheral has de-asserted the interrupt before the
processor executes the IRET. Adding a serializing
instruction between a LOAD/STORE and an IRET
forces a LOAD/STORE to complete before the IRET,
allowing more time for the peripheral to de-assert the
interrupt line before the processor executes the
interrupt return sequence.
If the peripheral and processor are somewhat closely
matched or if the interrupt handler is long, using a
serializing instruction alone will often resolve the
situation. However, if the speed disparity between the
peripheral and the processor is significant, it may be
necessary to guarantee that the peripheral has the time
it needs to de-assert the interrupt line. This can be
accomplished by using a busy loop or delay loop.
Using a busy loop is guaranteed to work even if the
software is ported to a different-speed platform.
However, for some applications the addition of a busy
loop will degrade performance. Using a delay loop
does not involve the bus overhead of the busy loop,
but a delay loop needs to be tuned for each system
configuration.
PID No. 18414B
1 of 3
1
2
3
