Difference between revisions of "Adjusting trace timings and general troubleshooting"

From SEGGER Wiki
Jump to: navigation, search
(Configuration with Ozone)
(Troubleshooting)
 
(21 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
== Trace Timing Configuration ==
 
== Trace Timing Configuration ==
 
In some cases a target device or board design will output trace signals that do not follow the [[Arm_trace_technical_specification#Arm_trace_timing_requirements | Arm trace timing requirements]]. If the issue is due to an incorrect sampling point in the time domain this can be fixed with J-Trace Pro's "Trace Timing Configuration" feature.
 
In some cases a target device or board design will output trace signals that do not follow the [[Arm_trace_technical_specification#Arm_trace_timing_requirements | Arm trace timing requirements]]. If the issue is due to an incorrect sampling point in the time domain this can be fixed with J-Trace Pro's "Trace Timing Configuration" feature.
  +
  +
Per default the sampling point of the trace data signals are shifted by +2 ns relative to the trace clock.
   
 
=== Configuration with Ozone ===
 
=== Configuration with Ozone ===
Line 18: Line 20:
   
 
=== General configuration ===
 
=== General configuration ===
  +
==== Via exec command ====
  +
One more general way to set the delay that is Ozone independent is via an [[J-Link_Command_Strings#TraceSampleAdjust | Exec Command]]. Such command can be used e.g. in a [[J-Link_Command_Strings#Using_J-Link_Command_Strings | J-Link Script file]].
  +
  +
==== Via webserver ====
  +
The J-Trace Pro runs a webserver application and one of its features is to adjust the trace sampling timing.
  +
  +
This can be done as follows:
  +
* Connect the J-Trace Pro via Ethernet cable to a local area network.
  +
* Connect to the J-Trace Pro via [[J-Link_Commander | J-Link Commander]] to find out the assigned IP address (default is DHCP mode).
  +
[[File:trace-ip-commander.png | thumb | none | 600px | J-Link commander output with assigned IP address]]
  +
* Type the assigned IP-address into your browsers address bar and press enter. The webserver should open now.
  +
* In the webserver main menu click on "Trace timing configuration".
  +
[[File:trace-webserver-menu.png | thumb | none | 600px | J-Trace Pro webserver menu]]
  +
* Here you can now shift the sample timing to an earlier or later moment by either adjusting all or individual trace data pins.
  +
[[File:trace-timing-configuration.png | thumb | none | 600px | Trace timing configuration page]]
  +
* Changes to the sampling delay will be take over immediately.
  +
* For verification we recommend to start the trace session with your debugger and let it halt at main.
  +
* If you see trace data by then without error messages from the J-Trace Pro you have a working setup.
  +
  +
{{Note|1=The settings via webserver are not permanent. If you want to set the values permanently try the approach explained above. The Half-Sync detection on the webserver can be ignored and is only used for internal testing at SEGGER.}}
   
 
== Common trace timings ==
 
== Common trace timings ==
  +
The following list shows common timing types that get output by some devices. You can use this charts to determine to which Type the microcontroller you are using belongs to by measuring with an oscilloscope. In most cases there are no additional actions required by the user to fix trace timing errors output by the microcontroller. Should trace not work out-of-the-box with the J-Trace PRO after initializing all pins and clocks correctly please refer to section [[#Troubleshooting|Troubleshooting]].
  +
  +
Most Arm microcontrollers follow the rule that their trace clock speed is the current CPU frequency divided by two. In some other rare cases the microcontroller divides the trace clock even further or has a fixed clock value.
  +
  +
=== Type 1: 50% duty cycle ===
  +
All data signals have a fixed delay e.g. t<sub>1/2</sub> that is directly dependent on the CPU clock speed. This is the preferred timing type as it assures that the trace signals will keep their timing requirements at all CPU clock speeds as they are directly dependent of the CPU clock.
  +
[[File:trace_clock_type_1.png | thumb | none | 600px]]
  +
=== Type 2: Trace data delayed ===
  +
All data signals have a fixed delay t<sub>ad</sub> which is independent of the CPU clock speed. This timing type can be problematic at higher CPU clock speeds as the fixed independent delay might not be sufficient which could lead to incorrect sampling of trace data.
  +
[[File:trace_clock_type_2.png | thumb | none | 600px]]
  +
  +
=== Type 3: Trace clock delayed ===
  +
The trace clock has a fixed delay t<sub>ad</sub> which is independent of the CPU clock speed. This timing type can be problematic at higher CPU clock speeds as the fixed independent delay might not be sufficient which could lead to incorrect sampling of trace data.
  +
[[File:trace_clock_type_3.png | thumb | none | 600px]]
  +
  +
=== Type 4: No delay ===
  +
All data signals toggle at the same time as TRACECLK. Without compensation this timing type can lead to incorrectly sampled trace data. Luckily the J-Trace PRO offers a built in feature that compensates this incorrect timing types. See section "Trace timing configuration" for more information. Also the default offset of +2 ns of the trace data signals relative to the trace clock signal is usually sufficient.
  +
[[File:trace_clock_type_4.png | thumb | none | 600px]]
   
 
== Trace signal quality ==
 
== Trace signal quality ==
  +
When tracing, typically high frequency signals are used to transfer the mass of trace data that is generated by modern, fast MCUs. Otherwise it would be impossible to keep up with the incoming data stream and the trace data generators on target side would overflow constantly.
  +
  +
But with high frequency signals there are additional considerations that need to be made regarding board designs to make sure the signals are as noise free as possible, even at higher speeds.
  +
  +
The [[Arm trace technical specification | interface specification]] shows which min. and max. values the signals must comply to. But they do not show how such signals look in reality.
  +
  +
This section will show some measured signals from various boards and MCUs to give an idea which signals are considered good, good enough or bad.
  +
  +
In the following, examples of the trace signals are shown which have been measured with an active probe.
  +
 
=== The good ===
 
=== The good ===
  +
Signals which look as follows are considered good and should provide a stable trace experience.
  +
[[File:TCLK_Risetime.png|none|thumb]]
   
 
=== The bad ===
 
=== The bad ===
  +
Signals which look as follows are considered bad and usually a board redesign is recommended.
  +
[[File:Arduino_TD1.png|none|thumb]]
   
 
=== The ugly ===
 
=== The ugly ===
  +
Signals which look as follows are considered good enough. So it might be possible to get a stable setup running but it might be worth it to consider redesigning the board.
  +
[[File:STM32H747_Risetime_TCLK.png|none|thumb]]
  +
  +
== Troubleshooting ==
   
  +
* Incorrect trace data - or none at all?
== FAQ ==
 
  +
** Try adjusting the trace sampling delay as described in section [[#Trace Timing Configuration | Trace Timing Configuration]].
  +
** It is recommended to set the trace port width to 1-bit trace. In Ozone via Tools->Trace Settings->Trace Port Width->1-Bit Trace. Or outside of Ozone via [[J-Link_script_files | J-Link Script]] and global variable ''JLINK_TRACE_Portwidth''.
  +
*** Now try to find the correct timing for 1-bit trace. An oscilloscope can be used to determine which direction to shift the sampling delay.
  +
*** Repeat the same for 2-bit trace. Then 4-bit trace.
  +
** Still not working?
  +
*** Check your signal quality with an oscilloscope. For reference see section [[#Trace signal quality | Trace signal quality]].
  +
*** Check the set pin drive strength in your pin initialization and set it to highest/fastest possible and check if a lower trace clock (slow down the CPU clock speed in your PLL init) solves the issue.
  +
*** Check if your signals meet the [[Arm_trace_technical_specification#Arm_trace_timing_requirements | Arm trace timing requirements]]. If not check the [[Trace_board_design_recommendations | Trace board design recommendations]].
  +
* Web server approach not working or not available?
  +
** Try the alternative approach via [[#Configuration with Ozone | Ozone]].

Latest revision as of 10:16, 23 September 2022

This article will explain how the trace sample timing of the J-Trace Pro can be adjusted and some general troubleshooting steps if a setup does not work out-of-the-box as it would be typically expected.

Trace Timing Configuration

In some cases a target device or board design will output trace signals that do not follow the Arm trace timing requirements. If the issue is due to an incorrect sampling point in the time domain this can be fixed with J-Trace Pro's "Trace Timing Configuration" feature.

Per default the sampling point of the trace data signals are shifted by +2 ns relative to the trace clock.

Configuration with Ozone

The recommended way is to use Ozone. It can be used directly to set the number of used trace pins and the trace sampling delay. To access this option simply open the trace project in Ozone and go to Tools->Trace Settings.

Here you can switch between different trace sources and the number of trace pins used. Default for ETM/PTM trace is Trace Source = Trace Pins and Trace Port Width = 4-bit.

To modify the trace sampling delays open the options under Trace Timing and set the the "Override Timings" checkbox. Now either one delay for all data lines can be selected or for each individually.

If you see trace data in the instruction trace window when the target device is halted and no trace related error message is printed in Ozone console the trace setup is currently stable.

Just make sure to restart the debug session each time you adjust the timing delays so they take effect.

General configuration

Via exec command

One more general way to set the delay that is Ozone independent is via an Exec Command. Such command can be used e.g. in a J-Link Script file.

Via webserver

The J-Trace Pro runs a webserver application and one of its features is to adjust the trace sampling timing.

This can be done as follows:

  • Connect the J-Trace Pro via Ethernet cable to a local area network.
  • Connect to the J-Trace Pro via J-Link Commander to find out the assigned IP address (default is DHCP mode).
J-Link commander output with assigned IP address
  • Type the assigned IP-address into your browsers address bar and press enter. The webserver should open now.
  • In the webserver main menu click on "Trace timing configuration".
J-Trace Pro webserver menu
  • Here you can now shift the sample timing to an earlier or later moment by either adjusting all or individual trace data pins.
Trace timing configuration page
  • Changes to the sampling delay will be take over immediately.
  • For verification we recommend to start the trace session with your debugger and let it halt at main.
  • If you see trace data by then without error messages from the J-Trace Pro you have a working setup.
Note:
The settings via webserver are not permanent. If you want to set the values permanently try the approach explained above. The Half-Sync detection on the webserver can be ignored and is only used for internal testing at SEGGER.

Common trace timings

The following list shows common timing types that get output by some devices. You can use this charts to determine to which Type the microcontroller you are using belongs to by measuring with an oscilloscope. In most cases there are no additional actions required by the user to fix trace timing errors output by the microcontroller. Should trace not work out-of-the-box with the J-Trace PRO after initializing all pins and clocks correctly please refer to section Troubleshooting.

Most Arm microcontrollers follow the rule that their trace clock speed is the current CPU frequency divided by two. In some other rare cases the microcontroller divides the trace clock even further or has a fixed clock value.

Type 1: 50% duty cycle

All data signals have a fixed delay e.g. t1/2 that is directly dependent on the CPU clock speed. This is the preferred timing type as it assures that the trace signals will keep their timing requirements at all CPU clock speeds as they are directly dependent of the CPU clock.

trace clock type 1.png

Type 2: Trace data delayed

All data signals have a fixed delay tad which is independent of the CPU clock speed. This timing type can be problematic at higher CPU clock speeds as the fixed independent delay might not be sufficient which could lead to incorrect sampling of trace data.

trace clock type 2.png

Type 3: Trace clock delayed

The trace clock has a fixed delay tad which is independent of the CPU clock speed. This timing type can be problematic at higher CPU clock speeds as the fixed independent delay might not be sufficient which could lead to incorrect sampling of trace data.

trace clock type 3.png

Type 4: No delay

All data signals toggle at the same time as TRACECLK. Without compensation this timing type can lead to incorrectly sampled trace data. Luckily the J-Trace PRO offers a built in feature that compensates this incorrect timing types. See section "Trace timing configuration" for more information. Also the default offset of +2 ns of the trace data signals relative to the trace clock signal is usually sufficient.

trace clock type 4.png

Trace signal quality

When tracing, typically high frequency signals are used to transfer the mass of trace data that is generated by modern, fast MCUs. Otherwise it would be impossible to keep up with the incoming data stream and the trace data generators on target side would overflow constantly.

But with high frequency signals there are additional considerations that need to be made regarding board designs to make sure the signals are as noise free as possible, even at higher speeds.

The interface specification shows which min. and max. values the signals must comply to. But they do not show how such signals look in reality.

This section will show some measured signals from various boards and MCUs to give an idea which signals are considered good, good enough or bad.

In the following, examples of the trace signals are shown which have been measured with an active probe.

The good

Signals which look as follows are considered good and should provide a stable trace experience.

TCLK Risetime.png

The bad

Signals which look as follows are considered bad and usually a board redesign is recommended.

Arduino TD1.png

The ugly

Signals which look as follows are considered good enough. So it might be possible to get a stable setup running but it might be worth it to consider redesigning the board.

STM32H747 Risetime TCLK.png

Troubleshooting

  • Incorrect trace data - or none at all?
    • Try adjusting the trace sampling delay as described in section Trace Timing Configuration.
    • It is recommended to set the trace port width to 1-bit trace. In Ozone via Tools->Trace Settings->Trace Port Width->1-Bit Trace. Or outside of Ozone via J-Link Script and global variable JLINK_TRACE_Portwidth.
      • Now try to find the correct timing for 1-bit trace. An oscilloscope can be used to determine which direction to shift the sampling delay.
      • Repeat the same for 2-bit trace. Then 4-bit trace.
    • Still not working?
  • Web server approach not working or not available?
    • Try the alternative approach via Ozone.