
Enhanced Time Processing Unit (eTPU2)
MPC5644A Microcontroller Reference Manual, Rev. 6
Freescale Semiconductor
965
(MDIS = 1 or device debug request = 1) requests, hardware breakpoint prevails and the engine enters
Debug mode (Halt_idle state).
If the engine entered Debug mode after a thread finished (Halt_idle state) and a “go” command comes from
the debug interface, the engine state machine goes to Idle and the rules above apply. It means that if a “go”
is issued in Halt_idle state with MDIS = 1, the engine goes to Idle for one microcycle and then stops (if
MDIS or device debug request keeps asserted and there is no other breakpoint request).
NOTE
Hardware breakpoint requests are ignored for the first microinstruction
executed when microengine leaves halt.
24.5.10.2.4
Hardware watchpoints
Debug Interface allows watchpoints on the same conditions available for hardware breakpoints (see
Section 24.5.10.2.3, Hardware breakpoints
24.5.10.2.5
Software breakpoints
A software breakpoint occurs when microengine executes a HALT microinstruction. Any number of
software breakpoints can be set in code, usually replacing an active microinstruction.
Like any other microinstruction, HALT increments the PC and pre-fetches the next instruction. So, before
the halt state is suspended, if the original program flow must be followed, the original instruction at the
HALT address must be executed, regardless if the software breakpoint is removed (replacing HALT by the
original microinstruction) or not. The following is the procedure to resume execution from a software
breakpoint:
1. Restore the original instruction in SCM (replace HALT).
2. Force a jump with flush to the original instruction (see
).
3. If the software breakpoint must be kept: single-step and replace the original instruction with a
HALT.
4. Let the flow continue, issuing a GO command (leaving halt state).
Special care must be taken if HALT is followed by another HALT, and the second HALT is removed when
microengine was halted by the first one. In this case, replacing the second HALT with the original
microinstruction is not enough to remove the second breakpoint, because the second HALT was already
prefetched and would be executed anyway when halt was suspended. The debugger must also do a forced
execution of unconditional branch with flush to the original microinstruction address. That will clear the
pipeline, replacing the prefetched instruction with a NOP, and load PC with the address of the removed
breakpoint. So, when halt state is suspended, the original microinstruction will be fetched while NOP is
executed, and program flow continues normally from then on.
Summary of Contents for MPC5644A
Page 2: ...MPC5644A Microcontroller Reference Manual Rev 6 2 Freescale Semiconductor...
Page 24: ...MPC5644A Microcontroller Reference Manual Rev 6 24 Freescale Semiconductor...
Page 26: ...MPC5644A Microcontroller Reference Manual Rev 6 26 Freescale Semiconductor...
Page 52: ...Introduction MPC5644A Microcontroller Reference Manual Rev 6 52 Freescale Semiconductor...
Page 56: ...Memory Map MPC5644A Microcontroller Reference Manual Rev 6 56 Freescale Semiconductor...
Page 1228: ...Decimation Filter MPC5644A Microcontroller Reference Manual Rev 6 1228 Freescale Semiconductor...
Page 1440: ...FlexCAN Module MPC5644A Microcontroller Reference Manual Rev 6 1440 Freescale Semiconductor...