
MC68HC16Z1TUT/D
5.2.5 Problem: Debug System Cannot Enter BDM
1. BKPT is not held low at the release of RESET. Holding BKPT low at the release of RESET en-
ables BDM, and driving it low after reset causes the processor to enter BDM. The debugger
should take care of this.
2. The memory is uninitialized, and the processor is trying to access bad addresses. In this case,
most debuggers should drive BERR to terminate the bus cycle. If the debugger does not do this,
either write valid addresses to the reset vectors or, if this is not possible, manually pulse BERR
low to terminate a hung bus cycle.
5.2.6 Problem: The Processor Takes a Spurious Interrupt Exception
1. The interrupt arbitration (IARB) field for the module requesting interrupt service is not a unique,
non-zero value. Each internal module has its own IARB field. External interrupts use the IARB
field in the SIMCR interrupts.
2. There are noise spikes on an IRQ line. Use pull-up resistors on the IRQ lines.
3. A square wave is used to generate external interrupts, and the source of the interrupt is going
away before the interrupt is acknowledged.
4. The program code is disabling an internal module or is arbitrarily clearing interrupt enable bits for
an internal module before the interrupt is acknowledged. Instead of arbitrarily clearing the enable
bits, first mask out the interrupt level by writing to the IPL field in the CPU status register. For
example, if a level 3 interrupt is to be masked, set the IPL field to three or higher. Then, disable
the enable bit for the specific interrupt.
5. An internal module is initialized improperly in such a way that the module cannot respond with
an internal DSACK even when that module is the one asserting the interrupt.
6. The IACK cycle is terminated by BERR instead of DSACK or AVEC. The assertion of BERR
causes the spurious interrupt vector (vector number 24) to be taken. A spurious interrupt will be
taken in the following three situations:
A. The CPU recognizes the occurrence of a valid interrupt request and begins the IACK cycle. If
none of the modules enter arbitration by asserting an IARB field value, the spurious interrupt
monitor asserts BERR internally.
B. After arbitration, the interrupt source that wins arbitration does not terminate the IACK cycle
with DSACK or AVEC. In this case, the bus monitor asserts the internal BERR signal.
C. An external device terminates the IACK cycle by asserting BERR.
An interrupt request signal
must remain asserted from the time it first occurs until the end of the IACK
cycle. The most common cause of spurious interrupts is a periodic signal, such as a square wave, con-
nected to an external interrupt request line. Other signals, such as the output of a shaft decoder, will
also cause spurious interrupts. Latch periodic or intermittent signals by means of an external circuit, and
clear the latch in the interrupt service routine.
5.2.7 Problem: The Processor Asserts HALT and Halts
A double bus fault has occurred, and the halt monitor (previously called the double bus fault monitor) is
not enabled. A double bus fault can occur under the following conditions.
1. When bus error exception processing begins, and a second bus error is detected before the first
instruction of the first exception handler is executed.
2. When one or more bus errors occur before the first instruction after a reset is executed.
3. When a bus error occurs while the CPU is loading information from a bus error stack frame during
execution of a return from exception (RTE) instruction.
F
re
e
sc
a
le
S
e
m
ic
o
n
d
u
c
to
r,
I
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com
n
c
..
.