FAQs Archive for MPC56x NEXUS Debugger and Trace
|Can the multi function pins (Nexus or I/O ) be usesed as I/O during Nexus debugging? (NEXUS-MPC56X)|
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)|
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.
|Do MDI/MDO lines have to be disconnected from Nexus port in MDO2 mode? (NEXUS-MPC56X)|
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)|
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)|
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)|
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)|
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)|
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)|
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
|What's the reason for "emulation debug port fail" during step over PLL setup ? (NEXUS-MPC56X)|
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,
|Which slot on the PowerTrace is used for the NEXUS adapter? (NEXUS-MPC56X)|
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)|
(Taken from CUSTOMER ERRATA AND INFORMATION SHEET CDR_AR_924)
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:
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)|
This is a global nexus protocol error . There are different reasons for this error message:
|Why does the debugger not work on my target with an external watch-dog timer? (NEXUS-MPC56X)|
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 © 2020 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany
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: 13-Jan-2020