• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1272 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/MSP432P401R: Using and understanding Execution Graph

Julian Kolodko
Expert 2265 points

Part Number: MSP432P401R

Tool/software: TI-RTOS

Hi all,

Can anyone give me some pointers for using Execution graph more effectively?  I'm running into a few difficulties I hope you can help me work around.

Before I ask my questions, here is a typical Execution Graph  I am seeing.

1. I create all RTOS object instances (HWIs, SWIs, Tasks, Clock Functions, Semaphores, Timers)   dynamically.  For each one I set the .instance->name field.  Is there any way to get Execution Graph to use those names instead of the more cryptic names it uses  [#Swi.2000348???  Hwi.ti_sysbios_family_arm_msp432_Timer_oneShotStub_E()?????]

Sure, these things can be decoded with enough digging through ROV etc.  But why should I have to??

I have gone to the effort of giving these things names, and it would be great if Execution Graph could use them.

  (BTW, What IS the .instance->name field for, if not for identifying objects in the RTOS tools???)

2. What does {unknown} correspond to?  It appears the CPU is spending most of it's time there!  How can I find out what the micro is really doing during these periods???

3.  It seems that the units used by measurement markers (displayed top left oft he execution graph window) somehow track the units being used on the horizontal axis.  And the units on the horizontal axis change as you zoom in and out.  This can get annoying.  At a high zoom level you might have 1645uSec between your markers, then as you zoom out you have 2mSec betweeny your markers and if you zoom out far enough you can have 0mSec between your markers, even though you didn't move your markers.  Is there any way to make the units used by the markers independent of the horizontal axis.  Or can I set up the markers to display as floats rather than ints?  I've tried changing the properties of the horizontal axis, but that doesn't really help.....

3a.  Can measurement markers be moved after being placed?  Or is the only option to delete and reset?

4.Why does Execution Graph forget the position of the red cursor (placed when you click on the graph) as you zoom.  If I place that cursor, I want to be able to zoom in/out around that location as far as I like.  But the current behaviour is that the red cursor disappears each time you zoom in and if you click zoom again you zoom around center.  When you have a long period of data, this gets you lost really quickly.

5. Is there a way to compress periods of data loss so that periods of real data appear close together.  During debug I find I sometime run and pause execution multiple times.  Given the relatively small amount of data that Execution Graph captures you end up with something like the picture below.  Tiny bursts of data with huge gaps between (e.g. the execution graph above is what you get when you zoom into the far left edge of the execution graph below).  Couple this with issue 4 above and you have a hard time nagivating around the data.

6. How do I clear the execution graph so that next time I run the micro I start with a blank slate (rather than something like the above with big gaps?)

7. Is there a way to have CCS remember my use of Execution Graph/CPULoad graph etc between debug sessions.  It can be frustrating to start up all these tools again each time you compile. 

7a. Why does it sometimes take 20sec or more for the Tools->RTOS Analyzer menu to pop out (CCS7)?

Thank you very much for your help!

Cheers

Julian

  • 0
    TI__Genius 12025 points

    Julian,

    Re #1 - names

    I will have to get back to you on this one. Not sure that displaying names in the execution graph is supported at this time.

    Re #2 - unknown

    The execution graph is simply a graphical representation of the log events in the logger buffer. Having said that, the execution graph does its best to create a context based on what it finds in the log events. For example, there is no log event which corresponds to BIOS Scheduler, that is an inferred state. When an interrupt happens, there is a Hwi_begin event near the beginning and a Hwi_end event near the end. The time spent between these events is rendered as a bar for the ISR. If the ISR were to post a Swi, then the Swi will run after ISR finishes. The Swi also has a Swi_begin and a Swi_end event, just like the Hwi and it is rendered as a bar for the Swi function. Now, the time spent between the Hwi_end and the Swi_begin is inferred as BIOS Scheduler because nothing else would be running at that point.

    It is also important to understand that the logger buffer is circular. Once the buffer is full, events are written from the beginning again which will overwrite old events. Finally, when the BIOS scheduler switches from one task to another task, a Task_switch event is generated. This switch event tells us which task is going out and which is coming in. When you halt the processor, chances are that the task switch event for the currently running task is no longer in the buffer. This means that there is no information in the logs which tells the execution graph which task is currently running. It is very typical to see Unknown task running until the first task switch event is encountered. Now, we could use the outgoing task to know which task was running. But unfortunately, the execution graph does not do this.

    In your example, I'm guessing the Idle task is running as Unknown. We finally get a task switch event into Task.ten_msec_task and then another task switch into Task.idle. I hope that answers your question.

    Re #3 - markers

    You are correct, the time units on the markers reflect the current zoom level. There is no way to turn off this behavior or to lock the time units. This is indeed a bummer when you zoom out. However, I've found that for most of the time, this behavior is to my advantage. And when I need to know exact time, I simply zoom in on the marker. You can fence pick (click-hold-drag-release) in the timeline just under the marker to quickly zoom in on a spot.

    You cannot move a measurement marker. Delete and re-create. Sorry.

    Re #4 - current position

    It is a re-draw bug that makes the red current position marker disappear when you zoom. To deal with this, I layout my CCS perspective with the graph on top and the live session below. I group the two views together (icon on toolbar in both views). When I click in the graph, the corresponding event is highlighted in the live session. When I zoom the graph, the current position disappears. I then click on the highlighted event in the live session and the current marker is re-centered.

    Re #5 - data loss

    There is no way to compress or cut out data loss time. I always pause the execution graph before I run the target again. When I halt, I reload the execution graph with the new data. This eliminates the old data and the data loss window. I'm always only looking at the current data window. This is a bummer if you want to compare the current execution graph with the previous one, but I find it works better for analysis of the current window.

    Re #6 - pause

    Before you run the target again, click the Stop icon (red button) in the Live Session toolbar. Run the target. Halt the target. Now click the Start icon (green arrow). This will discard the old data and load the new data.

    Re #7 - layout

    No, there is no way to save you dashboard layout.

    I don't know why the menu post takes so long. I observe this happens only on the first time. My guess is that there is some lazy memory allocation happening.

    I know the execution graph has many glitches. Unfortunately, it is hard to find resources to make this tool better. But with more customers as yourself expressing an interest, we can only hope they will improve the tool with time.

    Thanks for your understanding.
    ~Ramsey

  • 0 in reply to Ramsey
    Expert 2265 points
    G'Day Ramsey,

    Thank you for your clear answers. The tip you gave for #4 is neat!
    As you say, the tool should get better with time.

    Cheers
    Julian