AnsweredAssumed Answered

MPC8536 couldn't start

Question asked by Alex Abakin on Nov 30, 2018
Latest reply on Dec 13, 2018 by Alex Abakin

We kindly ask you to help us solve our complicated problem! We are trying to find a solution for many months. We have made many attempts to look at the problem from different points of view and made a lot of trial improvements.


Trying to connect MPC8536 on our custom board with CodeWarrior Development Studio and CWTap causes the error message:

"Error launching <...>

CCSProtocolPlugin : Failed to reset the target

[CCS last error: Draco/m HIP8: ELF is not in expected HALT mode ]"


(The log is in the attached file).


JTAG test is passed. IDCODE 0x0003F01D is detected.

However, CW has no access to the registers of the CPU.


First of all, we have studied Reference Manual, Hardware Specification and special PowerPoint file with the JTAG and reset requirements. Our board was designed in accordance to them.


So we checked TRST and HRESET signals with the oscilloscope. The picture is correct: assertion of HRESET*; then, after delay, assertion and negation of TRST*; finally, a very large “COP halt” interval before negation of HRESET*.

 It seems that it is sufficiently large for “USB TAP to send several COP commands to the processor before HRESET* is negated” (according to the notes in the file). But the processor doesn’t switch to the STOP mode…



Moreover, we tried to connect MPC8536 with TRACE32 (Lauterbach) and PowerDebug USB 3.0 Module.


Processor is detected, but SYStem.Up does not work.

AREA window shows:


“MPC8536 detected

debug port fail

Error reading BPTR. (CCSRBAR=0:FF700000)

Is processor permanently held in reset?

 Please check:

- reset and chkstp signals

- power supply of processor

- bootstrap configuration pins

- system clocks and PLL”.


We can put the system in “Attach” and “Go” mode, but the register values are unavailable (“target reset” is written in the register window in the system.down state, “access timeout, target running” - in the running state).

And we can’t stop it for debugging (BREAK.DIRECT command) – an error message is appeared:


“debug port problem

CPU did not return into debug mode for BREAK”


As I said, we have found no errors in the reset and chkstp signals...

We tested all the power supplies and PLL filters – they have correct voltages...

Bootstrap configuration pins are checked many times. Beside the oscilloscope we used TRACE32 boundary scan with the MPC8536 BSDL file. The values are correct...


It seems that all configuration pins are set up correctly, all necessary signals (clocks, resets, JTAG) and power present on board. And still we cannot debug it!


Finally we came to the opinion that the main cause of the trouble is the device PLL or core PLL which isn't locked despite of correct (as we suppose) SYSCLK and bootstrap configuration.

We have tried several sets of settings: changing of the clock generator and bootstrap configuration pins.

For example:

SG8003  66.70 MHz, LA[28..31] = 0101 (5:1), LBCTL, LALE, LGPL2/LOE/LFRE = 110 (3:1)

SiT8008  100.00 MHz, LA[28..31] = 0100 (4:1), LBCTL, LALE, LGPL2/LOE/LFRE = 101 (2.5:1)

SG8003  125.00 MHz, LA[28..31] = 0100 (4:1), LBCTL, LALE, LGPL2/LOE/LFRE = 101 (2.5:1)


Finally, we payed attention to power-on reset sequence , trying to make it more clear (according to paragraph 4.4.2 of Reference manual):

  • core, platform and I/O power is applied
  • HRESET* and TRST* are asserted
  • POR configuration inputs (including PLL config) are set
  • The system applies a stable SYSCLK signal !
  • The system set POWER_OK signal to the CPU to PLL lock.
  • HRESET* and TRST* are negated after several ms.


Please help us! We hope that the technical experts of NXP Semiconductor will find the solution of the problem, and we won't have to abandon the use of these processors.

Thank you very much.


With respect for you,