|
|
|
 |
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.
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 |
|
(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:
- 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.
****** 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.
|
|
|
|
|
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.
|
