Target Aux Port Connector Location and Extension Cables |
||
 |
 |
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) |
||
|
|
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) |
||
|
|
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. 
Nexus Connectors (208K)
|
|
|
AXIOM EVA-Board for 561/3 (NEXUS-MPC56X) |
||
|
|
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) |
||
|
|
Why do I get a "emulator debug port problem" when I try to change the system clock via the System Clock SFRs? |
| |
(Taken from CUSTOMER ERRATA AND INFORMATION SHEET CDR_AR_924) READI: Communication is lost when clock freq. is changed while in BDM mode. ****** DESCRIPTION: 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: ****** WORKAROUND: 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) |
||
|
|
What is the difference between a Nexus Debugger and a BDM/RISC Trace configuration? |
| |
The main differences are listed in the document below.
Differences (6K)
|
|
|
Debugger access during PLL setup (NEXUS-MPC56X) |
||
|
|
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,
|
|
|
Different Address Space for BDM vs. Nexus (NEXUS-MPC56X) |
||
|
|
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) |
||
|
|
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 batch job (Practice) 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) |
||
|
|
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) |
||
|
|
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 Probe (MNAD_x) Front Connector (NEXUS-MPC56X) |
||
|
|
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) |
||
|
|
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) |
||
|
|
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. 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. 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. 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. 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) |
||
|
|
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) |
||
|
|
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.cmm on the TRACE32 software CD.
Demo (2K)
|
|
|
Trace Impacts , Full trace settings (NEXUS-MPC56X) |
||
|
|
Are there impacts using Nexus trace ? What are the right settings to get full trace? |
| |
Refer to the Motorola's AN
AN by Motorola (105K)
|
|
|
Usage of Nexus-pins or IO-pins (NEXUS-MPC56X) |
||
|
|
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) |
||
|
|
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 © 2008 Lauterbach Datentechnik GmbH, Fichtenstr. 27, D-85649 Hofolding, Germany Impressum The information presented is intended to give overview information only. Changes and technical enhancements or modifications can be made without notice. Last generated/modified: Nov-4-2008 |
Target Aux Port Connector Location and Extension Cables
FAQ for NEXUS-PPC
