Difference between revisions of "Debug setup considerations when tracing"

From SEGGER Wiki
Jump to: navigation, search
 
Line 1: Line 1:
 
When setting up a debug setup which also should be traced there are some considerations that should be taken into account for the best possible trace experience.
 
When setting up a debug setup which also should be traced there are some considerations that should be taken into account for the best possible trace experience.
   
* Tracing sleep or low-power modes is usually not possible. Make sure that they are disabled. This is generally recommended for debugging.
+
* Tracing sleep or low-power modes is usually not possible. Make sure that they are disabled (check for WFE or WFI instructions on Arm as they usually trigger such modes). This is generally recommended for debugging.
 
* It is recommended to disable any compiler optimization. This is generally recommended for debugging. While you can trace even highly optimized code, the debugger will most likely not be able to reference the traced data to the provided source code anymore. So to be able to use all trace features the J-Trace Pro and Ozone it is recommended to disable optimization.
 
* It is recommended to disable any compiler optimization. This is generally recommended for debugging. While you can trace even highly optimized code, the debugger will most likely not be able to reference the traced data to the provided source code anymore. So to be able to use all trace features the J-Trace Pro and Ozone it is recommended to disable optimization.
 
* Do not do any trace init steps in your target application. Always use a [[J-Link_script_files | J-Link Script]] for that task. The benefits are explained [[J-Trace#Pinout_.2F_Trace_debug_interface | here]].
 
* Do not do any trace init steps in your target application. Always use a [[J-Link_script_files | J-Link Script]] for that task. The benefits are explained [[J-Trace#Pinout_.2F_Trace_debug_interface | here]].

Latest revision as of 08:59, 13 October 2022

When setting up a debug setup which also should be traced there are some considerations that should be taken into account for the best possible trace experience.

  • Tracing sleep or low-power modes is usually not possible. Make sure that they are disabled (check for WFE or WFI instructions on Arm as they usually trigger such modes). This is generally recommended for debugging.
  • It is recommended to disable any compiler optimization. This is generally recommended for debugging. While you can trace even highly optimized code, the debugger will most likely not be able to reference the traced data to the provided source code anymore. So to be able to use all trace features the J-Trace Pro and Ozone it is recommended to disable optimization.
  • Do not do any trace init steps in your target application. Always use a J-Link Script for that task. The benefits are explained here.
  • Make sure that your target application does not alter any settings that might impact the trace pins or the trace clock generation. If you need to alter such registers make sure to do it with read-modify-write steps.
  • When tracing an RTOS the debugger is not automatically aware that there is a RTOS running, so the analyzed trace data may look faulty. So make sure that RTOS awareness is enabled for your particular RTOS in your debugger.
  • Make sure that target device specific features (e.g. watchdog) that might impact the trace data generation are disabled or taken care of.