You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

69 lines
3.0 KiB

  1. +OpenOCD and CoreSight Tracing
  2. +
  3. Many recent ARM chips (Using e..g. Cortex-M3 and
  4. Cortex-M4 cores) support CoreSight debug/trace.
  5. This note sketches an approach currently planned for those cores
  6. with OpenOCD.
  7. This tracing data can help debug and tune ARM software, but not
  8. all cores support tracing. Some support more extensive tracing
  9. other cores with trace support +should be able to use the same
  10. approach and maybe some of the same analysis code.
  11. +the Cortex-M3 is assumed here to be the
  12. +core in use, for simplicity and to reflect current OpenOCD users.
  13. This note summarizes a software model to generate, collect, and
  14. analyze such trace data . That is not fully implemented as of early
  15. January 2011, +and thus is not *yet* usable.
  16. +
  17. +
  18. +Some microcontroller cores support a low pin-count Single-wire trace,
  19. with a mode where +trace data is emitted (usually to a UART. To use
  20. this mode, +SWD must be in use.
  21. +At this writing, OpenOCD SWD support is not yet complete either.
  22. (There are also multi-wire trace ports requiring more complex debug
  23. adapters than OpenOCD currently supports, and offering richer data.
  24. +
  25. +
  26. +* ENABLING involves activating SWD and (single wire) trace.
  27. +
  28. +current expectations are that OpenOCD itself will handle enabling;
  29. activating single wire trace involves a debug adapter interaction, and
  30. collecting that trace data requires particular (re)wiring.
  31. +
  32. +* CONFIGURATION involves setting up ITM and/or ETM modules to emit the
  33. +desired data from the Cortex core. (This might include dumping
  34. +event counters printf-style messages; code profiling; and more. Not all
  35. +cores offer the same trace capabilities.
  36. +
  37. +current expectations are that Tcl scripts will be used to configure these
  38. +modules for the desired tracing, by direct writes to registers. In some
  39. +cases (as with RTOS event tracking and similar messaging, this might
  40. +be augmented or replaced by user code running on the ARM core.
  41. +
  42. +COLLECTION involves reading that trace data, probably through UART, and
  43. +saving it in a useful format to analyse For now, deferred analysis modes
  44. are assumed, not than real-time or interactive ones.
  45. +
  46. +
  47. +current expectations are to to dump data in text using contrib/itmdump.c
  48. +or derived tools, and to post-process it into reports. Such reports might
  49. +include program messaging (such as application data streams via ITM, maybe
  50. +using printf type messaging; code coverage analysis or so forth. Recent
  51. +versions of CMSIS software reserve some ITM codespace for RTOS event
  52. tracing and include ITM messaging support.
  53. Clearly some of that data would be valuable for interactive debugging.
  54. +
  55. +Should someone get ambitious, GUI reports should be possible. GNU tools
  56. +for simpler reports like gprof may be simpler to support at first.
  57. +In any case, OpenOCD is not currently GUI-oriented. Accordingly, we now
  58. +expect any such graphics to come from postprocessing.
  59. measurments for RTOS event timings should also be easy to collect.
  60. +Examples include context and message switch times, as well as times
  61. for application interactions.
  62. +