The Issue
It is important the 68HC12 device under development is brought out of
reset in ‘special single chip’ mode. If ‘special single
chip’ mode is not entered after reset, the microcontroller begins
normal execution and continues to execute until brought under control
by entering BDM mode. Since the target is under development it is very
likely that the code space will be uninitialised and the processor will
therefore not survive real-time execution. Controlling the processor’s
start-up mode allows code to be downloaded to target memory before the
68HC12 starts execution.
A Solution
A solution is to provide the BDM hardware with a means of controlling
the initial operating mode of the target system. This can be done using
the target’s MODA and MODB signals. Making these signals available
to the BDM hardware allows the debugger to control the 68HC12’s
operating mode following reset. Having gained control of the processor,
the debugger can configure the desired operating mode and download program
code into target memory. All this is achieved before the processor starts
execution.
The Issue
Asynchronous communications create problems for the developer when the
target system changes its CPU clock speed. This is because each time
the target clock speed changes, a new BDM baud rate must be configured.
Without this reconfiguration, the supply of debug information to the
debugger collapses.
A Solution
A solution is to provide synchronous communication support for the BDM
hardware. This requires a suitable signal from the target, fortunately
there is such a signal, ECLK. ECLK can be used to synchronise communications
in any target where ECLK represents the CPU clock. By simply making
the ECLK signal available on the target it is possible to attach a flying
lead from the BDM hardware and communications can then become synchronous.
Adding support for synchronous
communications significantly improves the debug environment because
changes in target clock speed can be detected and communication baud
rates automatically adjusted by the debugger. This is very important
if your target dynamically changes the clock speed, for example it slows
the clock for power saving.
Unfortunately there are conditions
under which the ECLK signal may not be representative of the CPU clock:
- When ECLK
is used an an I/O signal
- During accesses
to external devices with wait states
- During misaligned
word accesses at external locations
Under these conditions ECLK cannot be considered to be a true representation
of the CPU clock and synchronous
communications cannot be supported. This means dynamic CPU clock switching
must be disabled during debug.
Note! Synchronous communications simplify ‘hot insertion’
(i.e. connection of BDM hardware during target execution) because the
hardware automatically senses the BDM baud rate.
