The embedded tools company

Search FAQs

PDF document ( 89KB / 17-May-2017 )


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.


Cannot write to SYPCR (MPC5XX/8XX)

Ref: 0045
Writing SYPCR has no effect.

The SYPCR register can only be written one time.
If the SYSTEM.OPTION.WATCHDOG is set to OFF then the CPU WATCHDOG function will be disabled by the debugger during a SYSTEM.UP. To disable the WATCHDOG on the CPU the debugger writes to SYPCR and uses the one-time write access to the SYPCR register.


Available Nexus Adaptions (NEXUS-MPC56X)

Ref: 0124
Which kind of Nexus adaptions are available for PowerPC debugging? Are converters also available?

Current Connections and Converters:
Preprocessor             Target         Order Nummer

AMP40 (LA-7781)     to   AMP50            (LA-7786)
                    to   Glenair51         follows

AMP50 (LA-7783)     to   AMP40            (LA-7784)
                    to   Glenair51         follows

Glenair51 (LA-7782) to   AMP40            (LA-7784)
                    to   AMP50             follows

AMP40 8bit/MDO      to   AMP40 2bit/MDO   (LA-7787)
AMP50 8bit/MDO      to   AMP50 2bit/MDO   (LA-7785)
If you need a different adaption it will take a few weeks to develop it.
Some NEXUS connectors are shown in the file below.


AXIOM EVA-Board for 561/3 (NEXUS-MPC56X)

Ref: 0129
If I change the CPU to MPC561/3 at the Axiom EVB, I have some problems to start the debugger on certain frequencies. What can I do?

It seems that the MPC561 and MPC563 is very sensitive about spikes, overshots and missing or wrong termination on the MCKI line. Unfortunately the current Axiom EVB has a very long open line at the base board to one of the Mictor connectors. To improve that behavior, cut the line DSCK/MCKI(J4-66) or/and short cut the pins 3 - 4 at the BDM-Port connector by a jumper.
For new target designs take care that the location of the NEXUS/READI connector is very close to the MCP561/3, the aux. port lines are as short as possible and terminate the lines correctly.


BDM-Debugport Fails after Changing Clock Frequency (NEXUS-MPC56X)

Ref: 0117
Why do I get a "emulator debug port problem" when I try to change the system clock via the System Clock SFRs?

READI: Communication is lost when clock freq. is changed while in BDM mode.
When the READI is being used for BDM, a deadlock occurs when the development tool tries to enter a low-power mode or change the clock frequency (via the debug port). The internal clock will still run at the previous frequency. If code running on the target is changing the frequency then the following will occur:
  • All READI MDI/MSEItraffic is ignored when this change is recognized.
  • All MDO messages in the transmit FIFO will be sent.
  • Then the MCKO will be stopped until the PLL has relocked at the new frequency.

Do not change the System Clock by the NEXUS debugger. Use the code running on the target to change the clock speed.
Reset the READI module by asserting sreset_b or hreset_b to continue debugging after unsuccessfully changing the system frequency.
****** NOTE: In newer silicons this problem is fixed.


Comparision PowerTrace-NEXUS to RISC Trace (NEXUS-MPC56X)

Ref: 0121
What is the difference between a Nexus Debugger and a BDM/RISC Trace configuration?

The main differences are listed in the document below.

Differences ( 5.49k)


Debugger access during PLL setup (NEXUS-MPC56X)

Ref: 0305
What's the reason for "emulation debug port fail" during step over PLL setup ?

During PLL setup instructions it may happen that MCKO and MCKI are turned off
for a certain time by the device. It depends on the PLL filter how long it lasts.
Both clocks are important for the communication between the debugger and the device.

If there is a communication request or a data transfer in progress during the missing
clocks, it may happen that communication fails. A "Debug port fail" is the result.

To prevent that issue,

  • do not Step over PLL setup instructions
  • do not set breakpoints right after PLL setup instructions
  • make sure that any dual-port access is disabled during PLL setup
  • disable terminal functionality during PLL setup


Different Address Space for BDM vs. Nexus (NEXUS-MPC56X)

Ref: 0130
My Chip Select Setup works with a BDM debugger, but with a Nexus debugger the CS Setup does not work properly. What is the reason for?

If the upper addresses of the available address space are used to distinguish between the different chip select lines of the MPC56x, one must be aware that Nexus trace messages and dual ported memory access uses 25 address lines only (restricted by the Nexus aux. port protocol). A BDM-Debugger however, uses the full address space of 32 address lines. The only way to access full address space is to use the option "SYStem.Option HighMemory ON". Than all debugger accesses will be handled by BDM instructions in a Nexus message frame. In this case the CPU must be stopped in any case to access the memory. Bear in mind, that the trace reconstruction can not work properly in this case, due to the fact, that the address space in the trace messages can not be extended.


External Watchdog timer (NEXUS-MPC56X)

Ref: 0143
Why does the debugger not work on my target with an external watch-dog timer?

In general, all watch dog timers (WDT) in the system must be disabled anyhow. The debugger SW needs to initialize the Nexus interface of the device and must do other settings. Also it takes some time to start a user program. If a WDT pulls Reset before it can be disabled, the debugger SW has no chance to finish initialization.
The device internal WDT will be disabled by the debugger SW during startup automatically.
An external WDT must be turned off by HW. This is very important, because normally a PRACTICE script sequence is too slow to do it in time by SW.
The only chance to disable an external WDT by SW is to use an appropriate user program on the target which will be started by SYSTEM.STANDBY. This is the fastest method to start a user program out of Reset.


MDI/MDO Lines Disconnected in MDO2 Mode (NEXUS-MPC56X)

Ref: 0127
Do MDI/MDO lines have to be disconnected from Nexus port in MDO2 mode?

Normally the only line which must be disconnected is MDI1.
MDO 7..2 are input lines anyway and don't need to be disconnected. But it is recommended and usually done by the small PCB.


Nexus Debug Port Fail (NEXUS-MPC56X)

Ref: 0120
Why do I get the error message "Emulator debug port fail"?

This is a global nexus protocol error . There are different reasons for this error message:
  • Nexus message access timeout
  • MCKO clock is missing
  • general connector problems


Nexus Probe (MNAD_x) Front Connector (NEXUS-MPC56X)

Ref: 0247
What is the pinout and the meaning of the Nexus Probe Front Connector? (MNAD_x)

Please refer to the pdf file.


Port Replacement Feature (NEXUS-MPC56X)

Ref: 0125
Is the port replacement feature supported?

We don't expect to support the port replacement feature. It's made to use the same pins for Nexus and for the application when using an 80 pin connector. But device manufacturers don't seem to have plans to support this feature.


Realtime Recording by NEXUS (NEXUS-MPC56X)

Ref: 0116
Can there be a delay between the time of a message is entered into the NEXUS message queue and the time of this message is sampled in the trace?

Yes, there can be a delay between the time of a message is entered into the NEXUS message queue (max. 8 entries) and the time of this message is sampled into the trace and marked with a time stamp.
  • Delay due to different priorities of messages
NEXUS messages have different priorities. High priority messages are output first. High priority messages are for example Invalid Messages. Data or Program messages have a low priority. The delay is not predictable.
  • Delay due to the filling degree of the NEXUS queue
If the NEXUS queue is nearly full when a message is entered, it take more time until the message is output. The delay is not predictable.
  • Delay due to port width
If a small NEXUS model is used it takes more time to output a message then on a large NEXUS model. The delay is predictable.
  • Delay due to message portion collector in the NEXUS debugger
A message can be 16, 24, 32 ... bit long. The NEXUS port has a width of 2 or 8 bit. So the NEXUS debugger has to wait until the complete message is output. When the NEXUS debugger received the full message, the message is sampled into the trace buffer and marked with a time stamp.


Required Slot for NEXUS Preprocessor (NEXUS-MPC56X)

Ref: 0119
Which slot on the PowerTrace is used for the NEXUS adapter?

For the Motorola MPC56x family slot C has to be used.


TPU Registers are all Reset to Zero (NEXUS-MPC56X)

Ref: 0118
What do I have to consider if I want to debug the TPU?

To debug the TPU the CPU has to enter the test mode.
An example is given in ~~/demo/powerpc/etc/tpu/tpu.cmm on the TRACE32 software DVD.

Demo ( 1.06k)


Trace Impacts , Full trace settings (NEXUS-MPC56X)

Ref: 0269
Are there impacts using Nexus trace ? What are the right settings to get full trace?

Refer to the Motorola's AN

AN by Motorola ( 104k)


Usage of Nexus-pins or IO-pins (NEXUS-MPC56X)

Ref: 0128
Can the multi function pins (Nexus or I/O ) be usesed as I/O during Nexus debugging?

No, they can't. When Nexus port is active the I/O function of the multi function pins will be disabled.
If you prefer to debug and to use these I/O pins at a time you need to connect the additional BDM debug cable (no trace capability; extra charge) to PowerTrace instead of the Nexus preprocessor.


Usage of the Terminal with NEXUS (NEXUS-MPC56X)

Ref: 0122
How is the terminal supposed to be used on nexus?

It works like dual port memory. So SingleE and BufferE are prefered modes. READPIPE and WRITEPIPE can connect the "host side"of the terminal to a named pipe on the host to talk to another application (not nexus specific).

Copyright © 2017 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany  Impressum
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: 24-May-2017