Datasheet

Appendix B
Appendix B-ii MCF5206e USER’S MANUAL MOTOROLA
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
A
To generate a ColdFire device executable of the target debugger, you should use a
compliant port of the same C compiler originally used to create the M68000 Family debugger
target. This procedure prevents differences in calling convention and parameter passing
from C to handwritten assembly. Another advantage to this approach is that special C flags
are retained. Many C compilers have special extensions as well.
Whichever approach is used, the assembly language lines that are outside the ColdFire
instruction set must be identified. Any ColdFire assembler that properly flags nonColdFire
instructions can be used. During the process of conversion, you can ignore instruction set
issues temporarily because the target is still an M68000 Family member.
Once the instruction set differences have been resolved, the architectural differences
between ColdFire devices and M68000 Family devices need to be addressed.
B.3 INITIALIZATION CODE
The target software and firmware often execute code that identifies the type of processor.
Such a process provides one port that works with various M68000 Family members and
implementations. The easiest way to identify the ColdFire architecture from other M68000
Family processors is to execute an ILLEGAL opcode ($4AFC). This execution generates an
exception stack frame while ensuring that the tracing is disabled. The first two bits of the
exception stack frame would immediately determine whether the processor is a ColdFire
processor.
Motorola suggests that ColdFire architecture testing be performed immediately to avoid
executing potentially undefined opcodes. Unused opcodes in the Version 2 ColdFire
architecture are not guaranteed to result in an illegal instruction exception.
Another item to consider is that the ColdFire architecture will have integrated versions with
modules yet to be defined. It may be a good idea to ensure that there are enough hooks to
allow for initialization of routines.
B.4 EXCEPTION HANDLERS
When dealing with exceptions in debug-oriented software, it is often necessary to extract
exception stack information to obtain the SR and PC. The format word (MC68010 and
higher) is typically used by generalized exception routines. Their sole purpose is to catch
unexpected exceptions and to easily use vector information to identify the cause of the
exception. The MC68000 exception frame is different from that of other members of the
M68000 Family processors in that there is no notion of a format word. This difference would
have forced target software to deal with exception stack frame differences already. The
approach now in use provides guidance on handling exception stack frame differences. In
many low-level exception handlers, the extraction of the stacked SR, PC, or format word is
performed in a common source file or the offsets are handled in some type of header file.
Interrupt handlers probably require no modification because in most cases, an interrupt
occurs asynchronously with respect to normal program flow. Therefore, interrupt handlers
cannot rely on items on the stack as it is often unnecessary to know exactly what was
happening at the time of the interrupt.
Fr
eescale S
emiconduct
or
, I
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com
nc...