|
|
|
 |
Can the Nexus port totally be disabled? (NEXUS-MPC5500)
|
| |
| Ref: 0386 |
|
For the case the NEXUS port is not needed for any reason or if the Nexus probe
is just used as a replacement for a JTAG dongle, the Nexus client can be disabled.
Any NEXUS activity at the NEXUS related pins are then turned off.
To establish that behavior
NEXUS.OFF
must be used.
However, take care if this command is used after system startup. If one disables
the Nexus client before the correct CPU is detected or setup (SYStem.Up), the NEXUS
client will be re-enabled automatically after the particular CPU has been recognized.
To avoid this behavior, use the command
SYStem.DETECT.CPU
as one of the first commands before any SYStem.Up instruction in your start-up script.
If
NEXUS.OFF
is an unknown command, ask for a SW update.
|
|
|
|
|
Does TRACE32 NEXUS MPC5XXX support 16 bit MDO operation? (NEXUS-MPC5500)
|
| |
| Ref: 0310 |
|
TRACE32 PowerTools support MDO16 operation with the NEXUS adapter LA-7630 (NEXUS AutoFocus). LA-7610 and LA-7612 do not support MDO16.
- Note for Mictor38 connection (LA-7631): The standardized Mictor38 connector for NEXUS only defines 12 MDO signals (MDO0..11). The signals MDO12..15 were added later and assigned to reserved pins. To avoid any risc of damage, LA-7631 (converter LA-7630/Mictor76 to Mictor38) does es not connect these signals by default. In order to enable MDO16 operation, J100..J103 on top of the LA-7631 have to be closed using 0 Ohm resistors. If the 0 Ohm resistors are mounted on the adapter, take care that no voltage level more than 5V is connected on targets which do not support MDO16.
- The Glenair51 connector (Adapter LA-7632) does NOT support MDO16.
|
|
|
|
|
How to manage external watch dog timer (WDT) control? (NEXUS-MPC5500)
|
| |
| Ref: 0326 |
|
Please see section "Watchdog Timer Support" in debugger_mpc5500.pdf
|
|
|
|
|
Is there any impact on processing power when using Nexus trace and JTAG debugger? (NEXUS-MPC5500)
|
| |
| Ref: 0150 |
|
Using the default settings of the debugger, there is no impact on the target system performance.
Under certain conditions using the debugger can have an impact on the perfoemance of the target system:
- Enabling SYStem.Option.STALL will cause the core to stop if the NEXUS message FIFO on the processor is full.
- If run-time memory access is enabled, the debugger can genreate memory transactions while the processor is running. The debugger's memory transcations can occur concurrently to the processor's transactions and cause little delay.
|
|
|
|
|
Some variables show wrong values or can not be modified during run-time. (MPC55XX/56XX)
|
| |
| Ref: 0346 |
|
See chapter "Memory Coherency During run-time Memory Access" in debugger_mpc5500.pdf:
|
|
|
|
|
SYStem.Option.FREEZE seems not to have any influence on the timers/counters. Is it possible to let the timers/counters run even when a breakpoint is hit or the cores are halted?
|
| |
| Ref: 0416 |
|
The SYStem.Option.FREEZE setting just uses the debug related registers to influence the timer / counter behavior when the target enters the debug halted state.
QorIQ CPUs typically offer an additional register in the RCPM, called CTBHLTCR or TTBHLTCR.
If the corresponding bit for a specific core in this register
- is set to 1, the SYStem.Option.FREEZE setting can handle both: To let the timers run or to freeze them during the core is in the debug halted state.
- is set to 0, the timers will always be frozen in the debug halted state, regardless of the SYStem.Option.FREEZE setting.
|
|
|
|
|
The disassembly shows invalid code with many undef/align "instructions". Trace list shows FLOWERRORS. How can I fix this? (MPC55XX)
|
| |
| Ref: 0285 |
|
Please see section "Tracing VLE or mixed FLE/VLE applications" in debugger_mpc5500.pdf:
|
|
|
|
|
The external bus interface (EBI) fails when the debugger (JTAG or NEXUS) is connected. (MPC55XX)
|
| |
| Ref: 0325 |
|
The cause of this problem is that there are two signals which are multiplexed between debugger and EBI usage: EVTI and EVTO.
For the MPC5510 series, the function of these signals is controlled by the EVT_EN bit in the NPC_PCR register, which again is controlled by the debugger. The debugger will per default set the pin function to EVTI/EVTO. In order to use the signals for EBI (R/!W and !TA), use the EVTEN setting in the TrOnchip window:
TrOnchip.EVTEN ON ; signals have EVTI/EVTO function. EBI functions disabled (default)
TrOnchip.EVTEN OFF ; signals free for use by EBI or GPIO
IMPORTANT NOTES:
- If the NEXUS adapter LA-7610 is used, EVTI must be physically disconnected from the debug/trace connector, because the LA-7610 will permanently drive EVTI.
- If the NEXUS adapter LA-7630 is used, the EVTI pin will be tristated if TrOnchip.EVTEN is set to OFF. It is recommended to disconnect EVTI/EVTO from the debug connector anyway (see below).
- If the signals are used for EBI, it is strongly recommended to disconnect EVTI/EVTO from the debug connector. Unterminated signals can cause EBI problems, especially if the debugger is not connected.
|
|
|
|
|
There is no debugger access due to a censored device. What can I do? (MPC55XX)
|
| |
| Ref: 0313 |
|
The MPC5XXX processors implement a censorship feature. When enabled, the JTAG debugger is locked out and debugging or tracing is impossible.
The debug implementation on the MPC5XXX does not allow to detect if a processor is censored or not. The indication of active censorship is that reading the JTAGID works, but any further accesses fail. The debugger will report a
Emulation Debug Port Fail
error and the additional error description in the message AREA will look like follows:
JTAGID=0x______1D
Error: received invalid OSR (0x000)
is the device censored?
If the processor was censored on intention, it is possible to regain access using this command sequence:
SYStem.DETECT CPU
SYStem.Option.KEYCODE 0xFEEDFACECAFEBEEF
SYStem.Up
Note:
- If the password (keycode) is unknown or illegal (e.g. after accidentally erasing the shadow row), the processor is locked forever and can not be recovered, unless the application in flash provides a feature to unlock the processor (e.g. via CAN).
- Some processors require the upper and lower 32-bit parts to be exchanged for SYStem.Option.KEYCODE (e.g. 0xCAFEBEEFFEEDFACE instead of 0xFEEDFACECAFEBEEF)
|
|
|
|
|
What are the impacts of the Nexus probe during energy measurement? (NEXUS-MPC5500)
|
| |
| Ref: 0357 |
|
Some recommendation for Energy measurements using the Nexus probe:
In case of Nexus AutoFocus probe LA-7630 , it is recommended to turn the active termination off.
There is not much difference between disable Nexus trace probe hardware (Analyzer.disable) and turn
off the Nexus cell (NEXUS.OFF).
|
|
|
|
|
What causes "emulation pod configuration error" when trying to start the debug session?
|
| |
| Ref: 0105 |
|
This error can have several sources:
- The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use automatic detection (SYStem.DETECT CPU).
- The CPU on the target is not supported by the used debugger software version. Please check if a new version is available in the Downloads section.
In any case please check the AREA window (Menu: View - Message Area) for further information.
|
|
|
|
|
What problems can cause that the debugger fails to connect to an XPC56XX EVB motherboard? (MPC56XX)
|
| |
| Ref: 0361 |
|
When working with the XPC56XX EVB motherboard + a processor minimodule, the debug and trace signals have more than one end point: The JTAG connector, the trace connector and the pin array on the motherboard. The end points are unterminated and can cause signal reflections which disturb debugging. Especially the branch line of TCK to the EVB motherboard can cause problems.
If the debugger fails to connect (configuration error or debug port fail), we recommend to disconnect the signal path to the motherboard, or at least terminate TCK at the XPC56XX EVB motherboard's pin array with a 220~470 Ohm resistor to GND.
|
|
|
|
|
Why are sometimes certain messages not visible in the trace? (NEXUS-MPC5500)
|
| |
| Ref: 0145 |
|
The collision priority management of the MPC5500 family causes, that lower priority messages are canceled by higher priority messages if they occur at the same time. Refer to Freescale's documentation.
All messages have the following priorit: WPM - OTM - BTM - DTM. A BTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message will be lost. An error message will be sent indicating the BTM was lost. The following direct/indirect branch will queue a direct/indirect branch w/ sync. message.
The count value within this message will reflect the number of sequential instructions executed after the last successful BTM Message was generated. This count will include the branch which did not generate a message due to the collision.
A DTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message or branch trace message will be lost. A subsequent read/write will queue a data trace read/write w/ sync. message.
|
|
|
|
|
Why do I get power fail messages, despite target power is correct at the reference pin? (NEXUS-MPC5500)
|
| |
| Ref: 0323 |
|
If one cannot execute SYStem.Up for the debugger and power fail is detected instead, it should be checked if two debugger (e.g. JTAG dongle and NEXUS probe) are connected at the same time.
This is a not allowed configuration which causes that neither the JTAG dongle nor the NEXUS probe can be used for debugging.
|
|
|
|
|
Why does the debugger display bus errors (question marks) for the internal SRAM or local memories? (MPC5XXX)
|
| |
| Ref: 0144 |
|
The SRAM and local memories have an ECC protection. After power-on, SRAM and the corresponding ECC bits hold random values. Therefore, depending on the combination of values, an ECC block (usually 64 or 32 bits) might or might not be displayed as a bus error.
When an application is programmed to FLASH, it is the responsibility of the boot code to initialize the SRAM. Only if it is intended to run an application from SRAM (e.g. as early test or for flash programming), the SRAM must be initialized through the debugger using the command:
Data.Set EA:0x40000000--0x4000BFFF %Quad 0x0000000000000000
|
