FAQs Archive for MPC56x NEXUS Debugger and Trace

The embedded tools company

Search FAQs

PDF document ( 143KB / 27-Mar-2022 )

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

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.

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? (NEXUS-MPC56X)
Ref: 0116

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.

Do MDI/MDO lines have to be disconnected from Nexus port in MDO2 mode? (NEXUS-MPC56X)
Ref: 0127

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.

How is the terminal supposed to be used on nexus? (NEXUS-MPC56X)
Ref: 0122

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).

Is the port replacement feature supported? (NEXUS-MPC56X)
Ref: 0125

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.

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? (NEXUS-MPC56X)
Ref: 0130

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.

What do I have to consider if I want to debug the TPU? (NEXUS-MPC56X)
Ref: 0118

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

What is the difference between a Nexus Debugger and a BDM/RISC Trace configuration? (NEXUS-MPC56X)
Ref: 0121

Basically there is no difference in debug features (Nexus compliance class 1 and BDM/JTAG-Debugger), except only Nexus can access memory and SPRs in real time without touchingreal time execution.
The main differences can be found in Trace features.
Nexus + Trace BDM + Trace
Program Flow-Trace enable | on /off | on /off, showcycles
Data Trace enable | on/ off | on /off, showcycles
Additional Bus cycles | no | yes
Selective Program Trace | only ranges via watch-points | only ranges , limitted
Ownership Trace | possible | not possible
Selective Data Trace | possible, 2 address ranges | not possible
Risk of Queue overflow | high, in case of data trace | not possible
Show-cycle setup | ISTCL = 0b101 | ISTCL <> 0b000

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

 GND  1    2  GND
 GND  3    4  OUT1
 GND  5    6  OUT0
 GND  7    8  GND
 GND  9   10  GND
 GND 11   12  IN1
 GND 13   14  IN0
 GND 15   16  GND
 GND 17   18  MDI1J
 GND 19   20  MDI1
  • OUT1 : Complex TriggerUnit Output 1
  • OUT0 : Complex TriggerUnit Output 0
  • IN1 : Complex TriggerUnit Input 1
  • IN0 : Complex TriggerUnit Input 0
  • MDI1J : MDI1J and MDI1 must be connected for 8 bit MDO mode (same meaning as jumper J105 of previous board revisions)
  • MDI1 : Leave it open for 2 bit MDO mode

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

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

Which slot on the PowerTrace is used for the NEXUS adapter? (NEXUS-MPC56X)
Ref: 0119

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

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

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.

Why do I get the error message "Emulator debug port fail"? (NEXUS-MPC56X)
Ref: 0120

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

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

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.

Copyright © 2023 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: 02-Jan-2023