2

I'm debugging a crash where a long-running method is called frequently before death. My primary concern is the difficulty in determining where nested and/or recursive calls are.

The Trace->Chart->Symbols window shows a graph of which function is running at a given time, which looks like this for the following calls:

         display
            |
       drawChildren
       /         \
  drawTitle   drawImage
      |           |
   display     display
      |           |
drawChildren  drawChildren

display      | _     _   _       _   _     _
drawChildren |  |_  | |_| |  _  | |_| |  _|
drawTitle    |    |_|     |_| | |     | |
drawImage    |                |_|     |_|

What I'd like is a something more akin to a flame graph, where the duration of each call is visible at a glance and nested calls are easier to spot:

display______________________________
 drawChildren_______________________
  drawTitle_______ drawImage_______
   display_______   display_______
    drawChildren     drawChildren

I've tried looking at the list view, but I found it cumbersome to navigate for the amount of calls and iterations within our problematic code. I know the chart view can be sorted, but is there any way to get a different view of the data?

codehearts
  • 483
  • 1
  • 9
  • 16

1 Answers1

3

I guess the commands which match best to your needs are

  • Trace.Chart.Nesting
  • Trace.ListNesting

You won't find this commands in the menu. You have to type them in the command line on the bottom of the TRACE32 application window (behind B::) or use the Softkey-Buttons below the command line to find these commands.

Note that you can synchronize the trace windows along each other with the option "/Track".

Holger
  • 3,920
  • 1
  • 13
  • 35
  • `Trace.Chart.Nesting` looks really promising, although I see "STACK OVERFLOW" shortly after it attempts to process. `Trace.Chart` is still working, so I guess I'll have to figure this out before I can use it – codehearts Mar 27 '19 at 23:06
  • 1
    `Trace.Chart.Nesting` uses the so called "Nested Analysis", while Trace.Chart (aka. `Trace.Chart.sYmbol`) is using the so called "Flat Analysis". "Flat Analysis" is basically only analyzing the program counter, while the "Nested Analysis" is actually analyzing function entries and exits, which is much more complex. "STACK OVERFLOW" appears if the number of function entries does not match with the number of function exits. – Holger Mar 28 '19 at 11:06
  • 1
    If you are using an operation system on your target you must load the OS awareness to use "Nested Analysis" with the command`TASK.CONFIG` (or TAKS.ORTI in case of AutoSar). Furthermore you have to trace the active task. This is achieved either via data trace (`Break.Set TASK.CONFIG(magic) /Write /TraceData`) or - on ARM CPUs without data trace - by writing to the Context-ID register on every task switch and enabling the tracing of Context-ID via `ETM.ContextID`. – Holger Mar 28 '19 at 11:12
  • I'm not able to get this working reliably for an ARM Cortex M3 running ChibiOS, but the times I have gotten output it's been incredibly useful. I suspect it may have to do with the function enter/exit counts – codehearts Apr 03 '19 at 20:04
  • For ARM Cortex M3 and ChibiOS load (after your ELF file) the OS awareness with `TASK.CONFIG ~~/demo/arm/chibios/chibios.t32`, enable the data trace via ITM with `ITM.DataTrace CorrelatedData` and finally request data samples for the change of the active task with `Break.Set TASK.CONFIG(magic) /Write /TraceData`. This should give you results in Trace.CHART.TASK for any new trace recording and allows nested timing analysis. – Holger Apr 06 '19 at 22:23