Trace Troubleshooting

From SEGGER Knowledge Base
Jump to navigation Jump to search

This page provides troubleshooting steps for common problems when using J-Trace or J-Link-based trace features.

Start with the supplied trace example whenever possible. A known-good example helps separate target-specific problems from hardware, configuration, and software issues.

Before troubleshooting

Before investigating a specific error, verify the following:

  • The target device is supported by J-Link. Check J-Link supported devices list.
  • The J-Trace/J-Link model supports the required trace feature.
  • The latest compatible J-Link Software and Documentation Package is installed.
  • The target is powered and the target voltage is detected correctly.
  • The debug connection works without trace enabled.
  • The supplied trace example is being used with the hardware for which it was provided.
  • The application has been downloaded to the target before starting a trace session.
  • The correct target device and CPU core have been selected.

If the supplied example does not work, avoid changing several configuration parameters at once. Establish a known-good baseline first and then change one item at a time.

J-Trace is not recognized by Windows

If Windows recognizes the J-Trace/J-Trace PRO USB device but the WinUSB driver cannot be started, the device may appear as unrecognized or with Code 10 in Device Manager.

This can occur when Windows has cached outdated USB/MS OS Descriptor information for the device.

For the detailed cause and solution, including the required registry cleanup, see J-Trace driver (WinUSB) is installed but the driver could not be started.

No trace data is received

If the trace session starts but no trace data is displayed (as shown in picture below), check the following.

Check the trace connection

Verify that all required trace signals are connected between the target and J-Trace.

Depending on the target and trace architecture, this can include:

  • Trace clock.
  • Trace data pins.
  • Debug signals such as SWD or JTAG.
  • Target reference voltage.

Check the connector pinout on both the target board and J-Trace. Do not assume that similarly named connectors use the same pin assignment. See 19-pin JTAG/SWD and Trace Connector

Check trace pin multiplexing

Many MCUs share trace pins with other peripherals. The trace pins may therefore need to be explicitly configured for their trace alternate function.

Check the device reference manual for:

  • Pin multiplexing.
  • Trace-port configuration.
  • Debug configuration registers.
  • Security or protection settings.
  • Required peripheral clocks.

If the trace pins are configured by software, verify that this configuration actually executes before tracing starts.

For a device without a supplied trace example, a J-Link Script can be used to perform device-specific initialization.

Check the target voltage

J-Trace needs to know the target I/O voltage in order to communicate correctly with the target.

Check that:

Trace contains unknown addresses

If the trace contains instructions that are displayed as unknown addresses, the trace data may have been captured correctly but cannot be mapped to the application image.

Check that:

  • The application was downloaded before tracing started.
  • The correct application image is loaded.
  • The application was not modified after it was downloaded.
  • The debugger has access to the symbols and executable image.
  • The trace session uses the same memory layout as the running application.

See Getting unknown addresses in instruction trace for additional information.

Trace data is corrupted or cannot be decoded

Corrupted trace data can result from signal-integrity problems, an incorrect trace configuration, or a trace data rate that the setup cannot reliably handle.

Check the following.

Reduce the trace clock

If the target allows the trace clock to be configured, try a lower trace frequency.

If trace becomes reliable at a lower frequency, investigate the PCB and signal integrity before increasing the frequency again.

Check trace signal integrity

Inspect:

  • Trace routing.
  • Signal length.
  • Ground connections.
  • Connector quality.
  • Impedance.
  • Crosstalk.
  • Reflections.
  • Level shifting.
  • Pull-up or pull-down resistors.

A trace interface can operate correctly at a low frequency and still fail when the trace bandwidth is increased.

See Trace board design recommendations for recommendations when designing custom hardware.

Check the trace width

Make sure the number of trace data pins configured in the debugger matches the number physically connected to J-Trace.

For example, configuring a wider trace port than the PCB provides can result in missing or invalid data.

Adjust trace signal timing

For correctly sampling trace signals, the sampling point of each data signal relative to the trace clock needs to be correct. This becomes especially important for high trace clock frequencies.

For a detailed guide on how to adjust the trace signal sampling point, see Adjusting trace timings and general troubleshooting

J-Trace reports a trace overflow

A trace overflow means that trace data is being generated faster than it can be transferred or processed by the current setup.

For streaming trace, check:

  • Trace clock and trace bandwidth.
  • Number of active trace pins.
  • Host PC performance.
  • USB connection.
  • J-Trace configuration.
  • Whether the selected trace mode is appropriate for the application.

See J-Trace overflow error for details. If USB is used, ensure that a USB 3 port is used together with the supplied USB 3 cable. See J-Trace USB recommendations for more details.

An overflow does not necessarily indicate a problem with the target application. It can indicate that the trace infrastructure cannot keep up with the amount of generated data.

Trace starts but stops unexpectedly

If tracing starts successfully and then stops, determine whether the target itself stopped or whether the trace connection was interrupted.

Check:

  • Whether the CPU entered a fault handler.
  • Whether the application has reset.
  • Whether a watchdog reset occurred.
  • Whether the debugger halted the CPU.
  • Whether the target lost power.
  • Whether the trace connection was physically interrupted.
  • Whether a trace buffer overflow occurred.

If possible, reproduce the problem with the supplied trace example before investigating the application. This step is meant as a sanity check, to rule out any generic setup issues.

Tracing does not work after a system reset

If tracing works while the application is running but stops working after a system reset, check whether the reset also resets or disables the hardware required for trace.

Depending on the target device, a reset can affect:

  • Trace-port configuration.
  • Trace pin multiplexing.
  • Trace clocks.
  • CoreSight or other trace components.
  • Debug configuration registers.
  • Trace funnels or routing components.
  • Device-specific trace initialization.

A common cause is that trace initialization is performed by the application and is therefore lost when the device resets. In this case, the trace configuration must be restored after the reset.

Check the device documentation for the behavior of the relevant trace and debug registers during the specific type of reset.

Also distinguish between different reset sources, such as:

  • Software reset.
  • Watchdog reset.
  • System reset.
  • External reset.
  • Power-on reset.
  • CPU/core reset.

Different reset types may affect different parts of the debug and trace infrastructure.

If a J-Link Script is used to configure device-specific trace functionality, verify whether the required initialization is performed again after a reset.

For devices without a supplied trace example, see How to configure JLinkScript files to enable tracing.

If the reset happens as a result of an unexpected fault, which needs to be analyzed, Ozone's post-mortem mode can be used to find the cause of the fault. See Post-mortem trace analysis.

Tracing does not work over Ethernet

If J-Trace or J-Link is connected through Ethernet, distinguish between a problem with the debug connection and a problem with the trace data path.

First verify that normal debugging works over the same Ethernet connection. For example, confirm that you can connect to the target, halt the CPU, read registers, and download the application.

If debugging works but trace does not, check:

  • The J-Trace/J-Link model and its supported Ethernet functionality.
  • The J-Link software and DLL version.
  • The network connection between the host and debug probe.
  • Network latency and stability.
  • Whether the trace configuration is supported with the selected connection.
  • Whether the amount of trace data exceeds the available transfer bandwidth.
  • Whether trace data is being lost during high-bandwidth streaming.
  • Whether a firewall or network configuration interferes with the connection.

See Setting up IP network interface

Trace works on the evaluation board but not on custom hardware

This is one of the most common situations when moving from a supplied trace example to a custom PCB.

Compare the two hardware designs.

Check:

  • Trace connector pinout.
  • Trace pin routing.
  • MCU pin multiplexing.
  • Target I/O voltage.
  • Trace clock routing.
  • Ground connections.
  • Pull resistors.
  • Level shifters.
  • Other devices connected to trace pins.
  • Reset circuitry.
  • Power-supply stability.

Also compare the software initialization. An evaluation board may configure clocks, pins, or peripherals differently from the custom hardware.

See Trace board design recommendations

The supplied trace example does not work

If a SEGGER-supplied example does not work on the hardware it was intended for, first restore the example to its original state.

Check:

  1. The exact target device is selected.
  2. The correct project configuration is selected.
  3. The correct J-Trace model is connected.
  4. The target board is powered.
  5. The J-Link software package is compatible with the example.
  6. The trace cable is connected correctly.
  7. The application can be downloaded and debugged without trace.
  8. No additional initialization code has been added.
  9. The example's expected clock configuration is being used.

If the debug connection itself fails, resolve that problem before troubleshooting trace.

Trace works with a lower CPU speed but not the normal clock

A higher CPU or trace clock can increase the amount of generated trace data and can make marginal signal-integrity problems visible.

Test systematically:

  1. Run the example with its default clock configuration.
  2. Reduce the trace clock if supported.
  3. Verify the trace data at the lower rate.
  4. Increase the trace rate incrementally.
  5. Check the PCB and cabling if failures correlate with trace frequency.

If the problem is specific to custom hardware, inspect the trace clock and data routing.

SWO does not work

SWO is different from full instruction trace and uses a dedicated SWO output pin.

Check:

  • The MCU supports SWO.
  • The SWO pin is correctly configured.
  • The SWO pin is connected to the debug connector.
  • The selected SWO frequency is supported.
  • The CPU clock configuration is correct.
  • ITM is enabled if ITM output is being used.
  • The debugger is configured for the correct CPU/core.

If SWO output is generated by software, verify that the application actually writes to the expected ITM stimulus port.

RTT does not work

For issues with RTT, check the dedicated page for RTT.

Semihosting does not work

For issues with RTT, check the dedicated page for Semihosting.

printf does not produce output

First determine which output mechanism the application uses.

printf may be routed through:

  • Semihosting.
  • RTT.
  • SWO/ITM.
  • STM
  • A UART.
  • A custom implementation.

The troubleshooting steps depend on the selected backend.

Check the application's printf implementation and linker configuration rather than assuming that printf automatically uses J-Trace.

Buffer trace works, but streaming trace does not

Buffer trace and streaming trace have different requirements.

Buffer trace stores trace information in an on-chip buffer and is read after or during a debug session. Streaming trace continuously transfers trace data from the target through the trace interface.

If buffer trace works but streaming trace does not, check:

  • Trace pin connections.
  • Trace clock.
  • Trace bandwidth.
  • J-Trace model.
  • Trace configuration.
  • Signal integrity.
  • Host-side data transfer.

This distinction can be useful when diagnosing a hardware problem, as successful buffer tracing demonstrates that the target's trace generation is functioning, but does not by itself prove that the external trace connection is suitable for continuous streaming.

Device has no supplied trace example

A supplied trace example is not always available for every device.

If the device supports the required trace architecture, investigate whether device-specific initialization is needed.

Typical initialization can include:

  • Enabling clocks for trace-related peripherals.
  • Configuring trace pins.
  • Selecting the appropriate pin multiplexing.
  • Enabling device-specific trace components.
  • Configuring trace funnel or routing components.

This initialization can be implemented in a J-Link Script.

See How to configure JLinkScript files to enable tracing for an example.

If no suitable example is available and you are interested in having SEGGER implement one for you, please open a support ticket at [segger.com/ticket].

Tracing functions executing from RAM

If tracing works for code executing from Flash but functions executing from RAM appear as unknown or cannot be resolved correctly, Ozone may not yet have the runtime contents of the RAM functions.

RAM functions are typically copied or decompressed from Flash into RAM during startup. Ozone needs to read the initialized RAM contents before it can generate the correct disassembly and use the functions for instruction trace analysis.

Check that:

  • The RAM functions have been initialized before tracing is analyzed.
  • `ReadIntoTraceCache` is called after RAM initialization.
  • The address range passed to `ReadIntoTraceCache` covers all RAM containing executable code.

For detailed information and an example project, see Ozone Debug and Trace with RAM Functions.

Ozone-Specific issues

Ozone only shows trace data for a limited timeframe

When doing instruction tracing via pins the recorded trace data is stored temporarily in system RAM. Per default the number of trace items stored in the backtrace buffer is ~64 million items. This limits the amount of time that can be recorded and can be displayed once the target device is halted. To lift the limit and increase the number of items that can be stored the following exec command can be used.

See J-Link Command Strings: TRACE_SetBackTraceNumItems.

To automatically execute this command before connecting to the target, it can be added to the BeforeTargetConnect() function of the Ozone project (*.jdebug).

Target.ExecCommand("TRACE_SetBackTraceMaxNumItems = <NumItems>")

In addition, the maximum instruction count in Ozone needs to be adjusted. This can be done in Debug → Trace Settings → Maximum Instruction Count.

Seek out SEGGER support

If the troubleshooting steps above do not resolve the issue, and you are eligible for SEGGER support, please open a support ticket with SEGGER.

Before opening a ticket, make sure that your SEGGER product or support agreement qualifies for technical support. The applicable support options and conditions depend on the product and purchase/support agreement. Check the KB page Technical Support to check whether you are eligible for technical support.

To help SEGGER reproduce and investigate the issue as quickly as possible, provide all information required to reproduce the problem. In particular, include:

  • Evaluation board or target hardware: Provide the exact evaluation board or target hardware used, including the board revision if applicable. If you are using custom hardware, provide the relevant hardware details and, if possible, the schematic of the debug/trace interface.
  • Target device: Provide the exact device part number and CPU/core for which tracing is being used.
  • J-Link software / DLL version: Provide the exact version of the J-Link Software and Documentation Package, including the J-Link DLL version if available.
  • J-Trace/J-Link hardware version: Provide the exact J-Trace or J-Link model and hardware version/revision.
  • Trace configuration: Provide the trace method, trace width, trace clock, and any other relevant trace configuration.
  • Reproduction steps: Describe the exact sequence of steps required to reproduce the issue. Start with connecting the hardware and include the software/project configuration, target initialization, and the action that causes the problem.
  • Expected behavior: Describe what you expected to happen.
  • Actual behavior: Describe what happens instead, including the complete error message if one is displayed.
  • Example project: If possible, provide the smallest project or trace example that reproduces the issue.
  • Logs and screenshots: Include relevant J-Link, debugger, and trace output as well as screenshots of the configuration where useful.

Providing this information up front can significantly reduce the time required to identify whether the problem is related to the target device, hardware setup, trace configuration, J-Link software, or the J-Trace/J-Link hardware.

Further information

Retrieved from "https://kb.segger.com/index.php?title=Trace_Troubleshooting&oldid=32624"