Please enable JavaScript to view this site.

winIDEA Help

Version: 9.21.233

NXP/ST Power Architecture Nexus L2+

This document covers NXP MPC5xxx and ST SPC56 microcontrollers featuring Nexus Class 2+ interface. Refer to microcontroller reference manual to identify Nexus Class level of a particular or contact Technical support for this information.

 

 

According to the Nexus standard, these devices contain multiple Nexus clients that communicate over a single IEEEE-ISTO 5001-2003 Nexus class 2(+) combined JTAG IEEEE 1149.1 auxiliary out interface. Combined, all of the Nexus clients are referred to as the Nexus development interface (NDI). Class 2+ Nexus allows for program and ownership trace of the microcontroller execution without access to the external data and address buses.

OCTMPC5xxxNexusL2p-NDIBlockDiagram

 

The Nexus trace is based on messages and has its restrictions comparing to the debugger where the complete CPU address, data and control bus is available to the debugger in order to implement exact and advanced trace features.

Nexus trace supports Program and ownership trace for the e200 core.

 

 

Program Trace

Using a branch-trace mechanism, the program trace feature collects the information to trace program execution. For example, the branch-trace mechanism takes into account how many sequential instructions the processor has executed since the last taken branch or exception. Then the debugging tool can interpolate the instruction trace for sequential instructions from a local image of program memory contents. In this way, the debugging tool can reconstruct the full program flow. Self-modifying code cannot be traced due to this concept.

Nexus trace implements internal FIFO buffer, which keeps the data in the pipe when the Nexus port bandwidth requirements are greater than capabilities. FIFO is heavily used when the application sequentially accesses data, which yields heavy trace port traffic through a narrow Nexus port.

Note that only transmitted addresses (messages) contain relatively (time of message, not of execution) valid time stamp information. All CPU cycles being reconstructed by the debugger relying on code image and inserted between the recorded addresses, do not contain valid time information. Any interpolation with the recorded addresses containing valid time stamp would be misleading for the user. Thereby, more frames displayed in the trace window contain the same time stamp value.

 

 

Ownership Trace

Ownership trace is based on ownership trace messaging (OTM). OTM facilitates ownership trace by providing visibility of which process ID or operating system task is activated. In practice, an operating system writes to the process ID register (PID0), which yields an ownership trace message for every write. Then it’s up to the data profiler to record these messages and display the task activities (task profiler).

 

Nexus Class 2+ Trace Features (iC5000, iC5500, iC5700):

External trace buffer

Program and OTM Trace for e200 core

AUX inputs

Profiler

Execution Coverage

 

Default winIDEA instance allows debugging and tracing the primary e200 core. In case of the second core, another winIDEA instance is open from the Debug / Core in order to debug and trace the 2nd e200 core.

 

Warning_orange

A detailed and exhaustive explanation on how the Nexus trace works and the meaning and purpose of all Nexus options, which are found in the Nexus configuration dialogs within winIDEA, can be found in the individual Core Reference Manual. Identify the core inside of your microcontroller and then refer to the belonging Core Reference Manual, which can be typically found at and downloaded from the semiconductor vendor web site. Some information may also be found in the Microcontroller Reference Manual of a specific

 

 

e200 Nexus Trace Configuration

Record everything

This configuration is used to record the contiguous program flow either from the application start or up to the moment when the application stops.

The trace can start recording on the initial program start from the reset or after resuming the program from the breakpoint location. The trace records and displays program flow from the start until the trace buffer fulfills.

This is the default mode when a new analyzer .trd file is created.

 

Buffer Size - This setting defines a maximum analyzer file size. The analyzer stops collecting Nexus trace information when this limit is exceeded.

 

Note that this setting is not correlated to the physical trace buffer of the HW debug tool by any means. The actual analyzer physical buffer size is limited by the debug tool. For instance, if the debug tool is capable of recording 512KB of the Nexus trace information only, limiting analyzer file size to 1MB poses no restriction at all. However, if the user finds just a small portion of the analyzer record (e.g. 16kB) being of interest and requires a swift analyzer window handling, it makes sense limiting the analyzer files size to 16kB. In this case, just a belonging portion of the complete analyzer physical buffer is required and used.

 

 

Trace Trigger

This trace operation mode is used, when it’s required to trace the application around a particular event or when only some parts of program or data have to be recorded.

Create a new Trace Trigger in the Analyzer window.

 

Trigger

Warning_orange

There is a single Trigger dialog which covers all different devices, which also feature different set of on-chip debug resources. Based on the selected CPU, only supported settings in the dialog are enabled and others are disabled.

 

The same On-Chip debug resources are shared among e200 hardware execution breakpoints, e200 access breakpoints and e200 on-chip trace trigger. Consequentially, debug resources used by one debug functionality are not available for the other two debug functionalities. In practice this would mean that no trace trigger can be set for instance on instruction address, when four execution breakpoints are set already.

Trace can trigger immediately after the trace is started or can trigger on one or more watchpoints (debug events), which occur while the target application is running. Trigger watchpoints can be IAC1-IAC3, DAC1-DAC2, CNT1-CNT2 and are described next.

 

Instruction

Four watchpoints (IAC1-IAC4) can be configured to trigger on executed instruction address (program counter match). Four address matches, two address in/out range matches or two address matches where address can be additionally masked, can be configured.

 

OCTMPC5xxxNexusL2p

 

 

Data

Two watchpoints (DAC1, DAC2) can be configured to trigger on accessed data address. Besides the access type, two address matches, one data address in/out range match or one address match where address can be additionally masked, can be configured.  In case of MPC56xx derivatives, data address can be also combined with the data value while the data value comparison is not available for the MPC551x devices.

 

OCTMPC5xxxNexusL2p-DAC

 

When Link to option is checked, configured data access is further conditional on instruction defined by IAC1/IAC3 watchpoint. In practice, the user can restrict trigger on data access caused by an explicit instruction.

 

 

Warning_orange

Data accesses are not visible since Nexus class L2+ doesn’t implement data trace.

 

Program Trace

Program trace is enabled by default.  Most often setting for the Start is ‘immediately’ and for the ‘End’ is ‘never’. However, user can select any of the previously described watchpoints to act as Start or End condition on match.

There are two types of messages, which can be used for the Nexus program trace protocol. ‘Individual Branch Messages’ yield more information about program execution than the ‘Branch History Messages’ setting. Major advantage of the ‘Individual Branch Messages’ setting is more accurate time information but it requires more Nexus port bandwidth, which means that the Nexus trace is more subject to the overflows, which are depicted in the trace window when they occur. In case of overflows, program reconstruction in the trace window resumes with next valid Nexus trace message.

 

OTM Trace

Enable OTM check box in the Record section, when 8-bit writes to the process ID register should be recorded.

Generate periodic OTM - Periodically, once every 256 messages, the most recent state of the PID0 register is messaged out when this option is checked.

Watchpoints - Per default all watchpoints are generated and recorded. If there are custom requirements, the user can configure either ‘no watchpoints are generated’ or selects specific watchpoints to be generated and recorded.

OCTMPC5xxxNexusL2p-Watchpoints

 

DQM Trace

Data acquisition trace provides a convenient and flexible mechanism for the debugger to observe the architectural state of the core through software instrumentation.

For DQM, a dedicated 32-bit SPR has been allocated (DDAM). It is expected that the general case is to instrument the software and use mtspr operations to generate Data Acquisition Messages.

 

Nexus FIFO Control

Stall CPU - When this option is checked, the program execution is stalled before Nexus overruns.

 

 

Trace Trigger Configuration via Wizard

To configure Trigger on Nexus devices follow the steps described below.

 

number1

Configure Operation mode.

Go to Hardware / CPU Options / Analyzer and set Operation mode to Nexus.

Nexus

 

number2

Open Analyzer.

To access available Analyzer options go to View / Analyzer / Analyzer Configuration.

 

hmtoggle_arrow0 Refer to Trace Configuration for more information.

 

 

number3

Configure Recorder.

Set the Recorder to start recording depending on your use-case.

 

1. Configure the Start of the recording. You can choose between Continuous Mode, On Trigger and Trigger Immediately.

2. Define reasonable buffer size in the Recording Size Limit drop-down menu depending on the required depth of the trace record. Have in mind that a smaller buffer uploads faster. You can start with e.g. 128kB.

 

hmtoggle_arrow0  Refer to Recorder Configuration for more information.

 

 

Number4

Configure Trigger via Wizard.

1. Check Manual Trigger/Recorder configuration and click Configure.

hmtoggle_arrow0 Refer to Manual Trace Configuration for more information.

 

2. In the bottom left corner of the newly opened window click Wizard and follow the steps. Wizard will guide you trough the process. If there is something you would still like to change, you can do it manually in the Trigger Configuration window.

 

 

Number5

View Results.

Initialize the complete system, start the trace and run the program. View the results in the Trace window.

 

 

Troubleshooting

Missing program code

If a “missing program code” message is displayed in the trace, it means that the program was executed at addresses where no code image is available in the download file. The debugger needs complete code image for the correct trace reconstruction! The code not reported in the download file or a self-modifying code cannot be traced. In order to analyze which code is missing in the trace, click on the last valid trace frame before the “missing program code” message. This will point to the belonging program point in the source or disassembly window. Set a breakpoint there, run the program until the breakpoint is hit and then step the program (F11) from that point on to see where the program goes.

 

Trigger position

With Nexus trace, which is a message based trace, actual trigger point (frame 0) is most likely not to be displayed next to the instruction which generated the trigger event. The Nexus trace port broadcasts only addresses of non-sequential branch jumps. All the sequential code in between is reconstructed by the debugger based on the code image available from the download file. There is no exact information to which of the inserted (reconstructed) sequential instructions the trigger event belongs. Nexus trace port broadcasts a dedicated trace trigger message beside the non-sequential branch messages.

For example, if there are 30 sequential instructions between the two non/sequential jumps and there was a trigger event in between, trace will always depict the trigger at the same position regardless which one of the 30 instructions generated the trigger event. That's why you probably see the misalignment between the trigger event and the belonging code.

 

MPC563xM

There is an errata related to the Nexus port on MPC563xM devices. Slew rate on Nexus pins remains slow when Nexus is enabled. Use below initialization sequence to change the slew rate of Nexus pins. See Initialization Sequence chapter for more details on initialization sequence configuration and use.

 

S 0xC3F901F6 W 0x000C
S 0xC3F901F8 W 0x000C
S 0xC3F901FA W 0x000C
S 0xC3F901FC W 0x000C
S 0xC3F901FE W 0x000C
S 0xC3F90200 W 0x000C
S 0xC3F90202 W 0x000C
S 0xC3F90206 W 0x000C
S 0xC3F90208 W 0x000C

 

Check the errata document for your target device to see if this issue is still applicable.

Copyright © 2024 TASKING Germany GmbH