 |
|
Connect a Nexus Probe to a PowerTrace Unit
|
|
 |
How do I correctly connect a Nexus Probe to a PowerTrace unit?
|
| |
|
A Nexus probe has one, two or three ribbon cables for the connection to the PowerTrace unit.
The PowerTrace has three connectors which are marked with A, B and C. (C is close to the black heatsink)
Nexus probe connectors of newer probes are also marked with A, B and C. Place the appropriate cable into the corresponding connector.
For older probes note the following:
Probes with a single cable: connect the ribbon cable to connector C.
Probes with two cables: connect the upper cable to connecter C, the second cable underneath to B.
Probes with three cables: connect the upper cable to connecter C, the second cable underneath to B and
the third cable below to connector A.
One does not require an additional JTAG dongle!
|
|
|
Incorrect Nexus-POD CPLD Revision
|
|
|
What is the reason for "Incorrect Nexus-POD CPLD revision" message?
|
| |
|
There are several reasons for the following message:
Incorrect Nexus-POD CPLD revision - Please call technical support (refer to AREA)
A wrong T32xxx.EXE has been executed (e.g. Super10.exe for a Copperhead probe)
The current SW contains a new image for the CPLD on the probe.
This reason is very seldom, but it may happen. One have to consider, that it is just a warning and normally one can continue using the debugger. However only for the case, the Area window shows a similar "expected CPLD revision number". It is recommended to contact your next support office. One will get a SW-Tool and some instructions how to fix it.
The probe is defective.
This reason can be recognized if the expected CPLD revision number is totally different from the current CPLD revision number, or even 0x00000 or 0xFFFFF. It is a serious reason and requires to send the probe back for repair. Also contact your local support office first.
|
|
|
Missing Address Information on Top of the Trace
|
|
|
Is there any reason why symbol addresses and names are not displayed from the beginning of the trace?
|
| |
|
The Nexus protocol defines that a full address is transferred only occasionally, just in a Branch-Trace-Sync-Message and Data-Trace-Sync-Message. Most of the time only the significant portion of the current address is generated in the device and transferred in a Nexus message. Therefore the address can only be reconstructed and displayed after occurrence of a Sync-Message in the trace memory. A Sync messages is generated automatically after 255 messages latest.
A single Nexus message without knowing what had happened before is useless!
Look at the T.L /NEXUS , then one will see the location of the DTSM . After that location the address information is visible.
A Sync message could be missing on top of the trace in the following cases:
- Any time Program is running before trace is in ARM state!
Normally if analyzer is armed manually!
- In FIFO mode if trace memory overflows.
- Selective trace using Watchpoints
- Selective trace using CTU
- Some other cases.
|
|
|
Nexus Connector Pinout on Target
|
|
|
I don′t know exactly which signals from MCU must be connected to which
signal on the AUX-port connector.
Must certain signals be crossed ?
|
| |
|
Not at all. The pin out one can find in the manual and at our home page,
fits the description of Nexus standard from the target point of view.
With other words, you have to connect the signals from the device to the
appropriate signals with the same name on the connector. You
must not take care about signal crossing.
|
|
|
No or wrong Data in Nexus Trace
|
|
|
There are no or wrong Nexus Trace entries. What can be wrong ?
|
| |
|
There are different reasons for the case the Nexus trace remains empty or the contents of the trace memory is not correct. Often this happens, if new prototype targets are used. Provided the Nexus probe is not defective, the Nexus probe - target connection should be
investigated.
To prevent wrong trace analyzer settings by scripts, enter the command
Analyzer.Reset
and disable Performance Analysis , before checking the steps below.
- First check if the Nexus probe or the extension cable is properly connected to the target.
To be able to trace Nexus messages, the appropriate trace signals must be activated, available at the connector
and they must fit timing and electrical demands.
- Activation of trace signals is the job of the Trace32 SW. The user must not take care about.
- The designer of the target is responsible for the availability of all relevant Nexus signals, according
to the Nexus standard specifications and the information one can find at the Lauterbach home page
(Adaptions/Connectors).
It is recommended to check the scheme of the target in case of problems.
- The following trace signals (trace clock and status signals) are essential for trace capture:
MCKO, MSEO0 (and MSEO1 in case it is provided by the CPU). It is recommended
to observe these
signals during real time program execution if the trace record counter does not change, despite the Analyzer
state is in ARM state. All two (three) signals must change their levels.
Trace data signals (MDO0 ... MDO15 , number depending on the aux port width) have to follow the same requirements
as the trace clock and control signals, but they can not prevent trace entries. They just can cause wrong trace entries.
- Electrical characteristics are normally given by the device on the target. Just for the case there are buffer or other circuitry
between the CPU and the trace connector, it is recommended to check signal integrity regarding signal level and timing
constrains.
A further reason for wrong or no trace data can be, the selected AUX-port width in the SYSTEM window does not fit to the
aux port width really available at the Nexus connector. That means, if just 4 MDO bits are routed, one can not get proper trace
if 8 bit MDO mode is selected in the System window. The debugger and trace does not know which port width the user intends
to use. It must be selected manually.
The following hints may help to find connection and signal level dependent issues.
- Run the Lauterbach SIEVE demo example instead of any of your own programs. One will find it in the pull down menu
( example: MPC55xx --} Tools --} start demo).
- Do not use any of your own setup scripts before. Run the demo just after powering the debugger and the target.
- Then try to take trace data . If they still corrupted or if there are still no trace data, continue with the next steps.
- Execute TESTFOCUS (in the T.STATE window or enter T.TESTFOCUS) and check the AREA window for information about possible problems.
- Check if MCKO is available. Use the system counter and select MCKO. Check if the frequency fits to the expected frequency. Consider MCKO divider.
- If you own a Nexus Autofocus probe, use the MNZXINFO tool to find trace signals which stuck. Refer to the stuck register area.
The HELP button gives information about the meanings of the areas in the MNZXINFO tool.
- Check if the target CPU delivers MCKO, MSEO0, MSEO1 and the appropriate number of MDO signals. It is very helpful to use an oscilloscope. Check also if the signal levels are correct and if the mentioned trace signals are really routed to the Nexus connector at the target.
If the signals and the connection are ok, an other reason for destroied trace entries can be the use of VLE or mixed FLE and VLE instruction.
Look at the FAQs for further help about that.
The trace list command needs access to the memory area where the code was executed during real time program execution.
If this is not the case due to changed mapping etc., Flowerrors can also be the result. Try to use the virtual memory as the source for the code for trace list commands in this case. This is also often helpful in case a trace list window is opened while the user program remains running.
|
