NXP Semiconductors MPC5644A, Reference Manual, Page: 967 / 1735

Enhanced Time Processing Unit (eTPU2)
MPC5644A Microcontroller Reference Manual, Rev. 6
Freescale Semiconductor 967
instruction with a NOP. So, to clear the instruction pipeline during halt, all one has to do is an unconditional
branch to the desired address with flush. HALT instructions must not be executed as forced.
Forced operations that depend on the serviced channel are unpredictable when executed in halt_idle.
24.5.10.2.8 Microengine register access
eTPU provides no direct access to microengine and channel registers from the slave bus or any other
interface. However, these registers can be read and written in halt state by executing forced
microinstructions (see
Section 24.5.10.2.7, Forced microinstruction execution ). Immediate data
microinstructions may be used to set register values. Some registers are not selectable for immediate data
destination, so intermediary register(s)—notably P—may have to be used to carry the desired new value
to the target register in two or more microinstructions. Usually the previous values of intermediary
register(s) must be previously saved and restored after the whole operation.
Similar procedures apply for register reads: their contents must be dumped to SPRAM, where they can be
read from the slave bus.
24.5.10.2.9 Microengine flag access
Microengine halt state allows reading the branch conditions flags through forced microinstructions or,
more easily, through the NDEDI register NDEDI_ENGINEx_CFSR. Flag conditions set by the user are
seen by microengine for the next microinstruction execution. The flag set options are limited by the
possibilities of forced microinstruction execution.
If the eTPU runs (not single-stepping) after exiting the halted state, the conditions modified during halt
may remain only for the first microcycle after the halted state. After the first microcycle, branch conditions
are altered only according to their regular update scheme.
24.5.10.2.10 Microengine stall
Microengine can get into a stall state, attending a request from a debug interface signal assertion. The
reason for a Stall request from NDEDI (or from any other debug support block) should be a temporary lack
of resources, for instance queue full. During stall the microengine suspends execution, but all the other
engine logic continues operating: time bases, angle logic, channel logic, input sampling and filters. Stall
differs from Halt, not enabling any of the debug features that Halt enables (see
Section 24.5.10.2.2,
Microengine halt state ). It also does not break an atomic microengine access, unlike halt.
The Microengine can be stalled when idle and from the moment TST ends, before executing the first thread
microinstruction, until just before the last thread microinstruction is executed. Stall requests are ignored in
any other occasions. Microengines in a dual-engine system can be independently stalled. If a forced end
is issued when microengine is in stall coming from execution, the END is executed only when the
microengine resumes execution from stall.
24.5.10.2.11 SCM emulation
If SCM is implemented as ROM, an external RAM may be used to replace it, allowing code patching and
software breakpoint setting for debugging purposes. SCM ROM replacement by Emulation RAM is
MCU-dependent. The SCM may even be divided into a ROM part and a RAM part. In this case, both