Motorola M68CPU32BUG User Manual download pdf (Page 48)

MOTOROLA MC68332TUT/D

rupt lines (by writing to the PFPAR register). This problem is likely to be intermittent, as it would only

occur if an IRQ7 interrupt is received in the short time before system initialization. See 2.1 Using

Data Bus Pins to Configure the MCU.

3. An interrupt is received, and the interrupt vectors have not been initialized. Make sure that the inter-

rupt vectors are initialized. See 4.1.3.2 Initializing Exception Vectors other than Reset.

4. The BR or BGACK pin has floated low and the CPU has relinquished control of the bus. Configure

these pins for chip-select operation out of reset by pulling DATA1 high during reset, or put pull-up

resistors on these pins.

5. Some of the pins are being powered up before V

. If the MCU is connected to another system with

a separate power supply, use an LVI device to prevent the system with the faster power supply from

driving logic one levels before the system with the slower power supply has become operational. If

this happens, the driven pins on the device with the slow supply will momentarily have a higher volt-

age than the V

pin. This condition can cause the input protection diodes to become momentarily

forward biased and cause significant current injection into the device substrate, which will probably

improperly charge or discharge some of the internal nodes of the MCU. This action is completely ran-

dom, and it is impossible to predict what will happen when significant injection occurs. Usually, the

MCU will not function at all and will display undefined states. For example, the RESET

, HALT, BERR,

BR and FREEZE signals may be asserted but the device may fail to fetch opcodes. See 2.7 Power

Supply.

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 enables

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 ter-

minate 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 using the BCLR instruction to arbitrarily clear

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

able 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:

1 2 ... 43 44 45 46 47 48 49 50 51 52 53 54 55 56

Comments to this Manuals

No comments

Motorola M68CPU32BUG User Manual Page 48

Comments to this Manuals