FAQs for NEXUS-MPC5500

The embedded tools company

Search FAQs

PDF document ( 68KB / 17-May-2018 )

Target Aux Port Connector Location and Extension Cables

Ref: 0162
Can I use a longer extension cable?

Often customer ignore the warnings regarding the locaction of the aux port connector and regarding additional extension cables between the debugger and the target.
This can cause a lot of trouble, especially for high speed applications. We strongly recommend to place the aux port connector as close as possible nearby the CPU. As closer as better. Take care about the signal trace length.
Do not connect aux port signals to other connectors than the aux port connector and prevent signal stubs. Connect a proper termination to the signals coming from the probe, close to the CPU. Signals from the CPU to the probe should not be terminated.
One can add 0 Ohm resistors in line of each Nexus signal close to the CPU. If necessary 0 Ohm can be replaced by a better value.
The debugger does normally not need any pull-up or pull-down, except for reset. Care must just be taken just for non-Nexus signals. Bear in mind that the target needs possibly a pull-up or pull-down for certain signals if the debugger is not connected.
Pay attention about the recommendations of the device manufacturer regarding the circuitry around the Nexus Aux port.
We also recommend to use no other extension cables than the cables which come with the debugger.
If possible do not use additional cables at all. Longer cables may work, but must not. It is the customers risk to use longer once as recommended. We can not guarantee proper operation.

Device censored (MPC55XX)

Ref: 0313
There is no debugger access due to a censored device. What can I do ?

The MPC5XXX processors implement a censorship feature. When enabled, the JTAG debugger is locked out and debugging or tracing is impossible.
The debug implementation on the MPC5XXX does not allow to detect if a processor is censored or not. The indication of active censorship is that reading the JTAGID works, but any further accesses fail. The debugger will report a Emulation Debug Port Fail error and the additional error description in the message AREA will look like follows:
Error: received invalid OSR (0x000)
is the device censored?
If the processor was censored on intention, it is possible to regain access using this command sequence:
  • If the password (keycode) is unknown or illegal (e.g. after accidentally erasing the shadow row), the processor is locked forever and can not be recovered, unless the application in flash provides a feature to unlock the processor (e.g. via CAN).
  • Some processors require the upper and lower 32-bit parts to be exchanged for SYStem.Option.KEYCODE (e.g. 0xCAFEBEEFFEEDFACE instead of 0xFEEDFACECAFEBEEF)

EBI problems on MPC5510 (MPC55XX)

Ref: 0325
The external bus interface (EBI) fails when the debugger (JTAG or NEXUS) is connected.

The cause of this problem is that there are two signals which are multiplexed between debugger and EBI usage: EVTI and EVTO.

For the MPC5510 series, the function of these signals is controlled by the EVT_EN bit in the NPC_PCR register, which again is controlled by the debugger. The debugger will per default set the pin function to EVTI/EVTO. In order to use the signals for EBI (R/!W and !TA), use the EVTEN setting in the TrOnchip window:

TrOnchip.EVTEN ON ; signals have EVTI/EVTO function. EBI functions disabled (default)
TrOnchip.EVTEN OFF ; signals free for use by EBI or GPIO

  • If the NEXUS adapter LA-7610 is used, EVTI must be physically disconnected from the debug/trace connector, because the LA-7610 will permanently drive EVTI.

  • If the NEXUS adapter LA-7630 is used, the EVTI pin will be tristated if TrOnchip.EVTEN is set to OFF. It is recommended to disconnect EVTI/EVTO from the debug connector anyway (see below).

  • If the signals are used for EBI, it is strongly recommended to disconnect EVTI/EVTO from the debug connector. Unterminated signals can cause EBI problems, especially if the debugger is not connected.

Error Message: "emulation pod configuration error" (MPC55XX)

Ref: 0105
Error message "emulation pod configuration error" after starting the T32 ICD software

This error can have three sources:
  • The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available.
  • The CPU detection failed. Check the JTAG connection to the target.
  • The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window.

Problems with displaying and/or tracing VLE code (MPC55XX)

Ref: 0285
The disassembly shows invalid code with many undef/align "instructions". Trace list shows FLOWERRORS. How can I fix this?

Please see section "Tracing VLE or mixed FLE/VLE applications" in debugger_mpc5500.pdf

Run-Time Memory Access Restrictions (MPC55XX/56XX)

Ref: 0346
Some variables show wrong values or can not be modified during run-time. What causes this problem and how can it be solved?

See chapter "Memory Coherency During run-time Memory Access" in debugger_mpc5500.pdf

MDO12 mode works, but MDO16 mode fails (MPC56XX)

Ref: 0322
16 BIT NEXUS trace does not work, earlier Nexus probe however work. What could be the reason ?

A reason can be that the adapter from mictor38/Glenair51 to Mictor76 is not yet prepared for 16 bit MDO. Refer to FAQ "16 Bit AUX-Port Width "

XPC56XX EVB motherboard issues (MPC56XX)

Ref: 0361
What problems can cause that the debugger fails to connect to an XPC56XX EVB motherboard?

When working with the XPC56XX EVB motherboard + a processor minimodule, the debug and trace signals have more than one end point: The JTAG connector, the trace connector and the pin array on the motherboard. The end points are unterminated and can cause signal reflections which disturb debugging. Especially the branch line of TCK to the EVB motherboard can cause problems.

If the debugger fails to connect (configuration error or debug port fail), we recommend to disconnect the signal path to the motherboard, or at least terminate TCK at the XPC56XX EVB motherboard's pin array with a 220~470 Ohm resistor to GND.

Bus Errors in Internal SRAM (MPC5XXX)

Ref: 0144
Why does the debugger display bus errors (question marks) for the internal SRAM or local memories?

The SRAM and local memories have an ECC protection. After power-on, SRAM and the corresponding ECC bits hold random values. Therefore, depending on the combination of values, an ECC block (usually 64 or 32 bits) might or micht not be displayed as a bus error.
When an application is programmed to FLASH, it is the responsibility of the boot code to initialize the SRAM. Only if it is intended to run an application from SRAM (e.g. as early test or for flash programming), the SRAM must be initialized through the debugger using the command: Data.Set EA:0x40000000--0x4000BFFF %Quad 0x0000000000000000

Debugger Impacts (NEXUS-MPC5500)

Ref: 0150
Is there any impact on processing power when using Nexus trace and JTAG debugger?

Using the default settings of the debugger, there is no impact on the target system performance.
Under certain conditions using the debugger can have an impact on the perfoemance of the target system:
  • Enabling SYStem.Option.STALL will cause the core to stop if the NEXUS message FIFO on the processor is full.
  • If run-time memory access is enabled, the debugger can genreate memory transactions while the processor is running. The debugger's memory transcations can occur concurrently to the processor's transactions and cause little delay.

Energy measurement impacts (NEXUS-MPC5500)

Ref: 0357
What are the impacts of the Nexus probe during energy measurement ?

Some recommendation for Energy measurements using the Nexus probe:

In case of Nexus AutoFocus probe LA-7630 , it is recommended to turn the active termination off.

There is not much difference between disable Nexus trace probe hardware (Analyzer.disable) and turn off the Nexus cell (NEXUS.OFF).

Lost Messages (NEXUS-MPC5500)

Ref: 0145
Why are sometimes certain messages not visible in the trace?

The collision priority management of the MPC5500 family causes, that lower priority messages are canceled by higher priority messages if they occur at the same time. Refer to Freescale's documentation.

All messages have the following priorit: WPM - OTM - BTM - DTM. A BTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message will be lost. An error message will be sent indicating the BTM was lost. The following direct/indirect branch will queue a direct/indirect branch w/ sync. message.
The count value within this message will reflect the number of sequential instructions executed after the last successful BTM Message was generated. This count will include the branch which did not generate a message due to the collision.
A DTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message or branch trace message will be lost. A subsequent read/write will queue a data trace read/write w/ sync. message.

MDO 16 Bit Operation (NEXUS-MPC5500)

Ref: 0310
Does TRACE32 NEXUS MPC5XXX support 16 bit MDO operation?

TRACE32 PowerTools support MDO16 operation with the NEXUS adapter LA-7630 (NEXUS AutoFocus). LA-7610 and LA-7612 do not support MDO16.
  • Note for Mictor38 connection (LA-7631): The standardized Mictor38 connector for NEXUS only defines 12 MDO signals (MDO0..11). The signals MDO12..15 were added later and assigned to reserved pins. To avoid any risc of damage, LA-7631 (converter LA-7630/Mictor76 to Mictor38) does es not connect these signals by default. In order to enable MDO16 operation, J100..J103 on top of the LA-7631 have to be closed using 0 Ohm resistors. If the 0 Ohm resistors are mounted on the adapter, take care that no voltage level more than 5V is connected on targets which do not support MDO16.
  • The Glenair51 connector (Adapter LA-7632) does NOT support MDO16.

Nexus Autofocus Probe + PT-I restriction (NEXUS-MPC5500)

Ref: 0327
I'm getting error messages during debugger startup using the Nexus Autofocus Probe (LA-7630) and Powertrace-I (LA-7705,LA-7707,LA-7690). What can be the reason ?

The error message Nexus Probe : Lost FPGA configuration during T32 startup , may be a hint about an issue with the PT-I.

The Nexus Autofocus Probe (LA-7630) works with PowerTrace-I Units in any case, if the serial number is higher than E0312000xxxx.

If the serial number is below E0201000xxxx , there is no chance to use the new MNZX probe.

For all units with serial numbers between the mentioned numbers , it is recommenden to ask the local representative what is required to do to work with the MNZX probe.
For serial numbers between E0201000xxxx and E03020003999 , a modification of the PT-I board is needed and we recommend to exchange the trace board (MESR_x) to the latest revision.
For serial numbers between E03020004000 and E0312000xxxx , just a modification of the PT-I board is needed.

For modification , the PT-I unit and the MNZX probe must be sent back to Lauterbach.

Nexus probe replaces JTAG dongle (NEXUS-MPC5500)

Ref: 0386
Can the Nexus port totally be disabled ?

For the case the NEXUS port is not needed for any reason or if the Nexus probe is just used as a replacement for a JTAG dongle, the Nexus client can be disabled. Any NEXUS activity at the NEXUS related pins are then turned off.

To establish that behavior NEXUS.OFF must be used.

However, take care if this command is used after system startup. If one disables the Nexus client before the correct CPU is detected or setup (SYStem.Up), the NEXUS client will be re-enabled automatically after the particular CPU has been recognized.

To avoid this behavior, use the command SYStem.DETECT.CPU as one of the first commands before any SYStem.Up instruction in your start-up script.

If NEXUS.OFF is an unknown command, ask for a SW update.

Power fail reasons (NEXUS-MPC5500)

Ref: 0323
Why do I get power fail messages, despite target power is correct at the reference pin ?

If one cannot execute SYStem.Up for the debugger and power fail is detected instead, it should be checked if two debugger (e.g. JTAG dongle and NEXUS probe) are connected at the same time.
This is a not allowed configuration which causes that neither the JTAG dongle nor the NEXUS probe can be used for debugging.

Slow Reset (NEXUS-MPC5500)

Ref: 0282
Why does Reset take longer if a Nexus Class 2/3+ debugger is used in respect to a class 1 Nexus debugger or if no debugger is attached?

The delay is caused by the debugger.

During target reset, all breakpoints, watchpoints and other settings are cleared by the reset logic of the CPU.

The NEXUS class 2/3+ debugger will detect a target reset on the signals RSTIN and (optional) RSTOUT. After reset, the debugger has to program the debug registers, breakpoints and watchpoints again. This causes an extra delay between asserting reset and start of program execution.

Watchdog timer, Tool detect (NEXUS-MPC5500)

Ref: 0326
How to manage external watch dog timer (WDT) control ?

Please see section "Watchdog Timer Support" in debugger_mpc5500.pdf

Which Nexus probe for which PPC device (NEXUS-MPC5500)

Ref: 0329
Is there a list about the different available Nexus probes, that informs about PPC devices which can be supported with?

Please refer to the last part of the document below.

Download probediff-customer.pdf (134k)

Universal JTAG Adapter LA-7640 (NEXUS-PPC5500)

Ref: 0383
Where can I use the Universal JTAG-Adapter LA-7640?

Please refer to the document below.

Copyright © 2019 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany   Impressum     Privacy Policy
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 08-May-2019