• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 623 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.

Regarding Trace Analysis

krithika sundaramoorthy
Prodigy 50 points


hi,

i am working on TM4C1294XL Lauchpad , is it possible to do trace and system analysis on this board in ccsv6. If it is possible, can you please refer any link or references.

Thanks in advance.

Regards,

Krithika.S

  • 0
    TI__Mastermind 22715 points
    Krithika,

    There is no trace capability on TM4C129x. You can add GPIO pin toggling in your application to check if the application is executing correctly.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Guru 27665 points

    From the TM4C1294 data sheet

    "2.2.3 Trace Port Interface Unit (TPIU)
    The TPIU acts as a bridge between the Cortex-M4F trace data from the ITM, and an off-chip Trace
    Port Analyzer, as shown in Figure 2-2 on page 83."

    [edit] From the signal table

    "

    TRCLK 45 PF3 (15) O TTL Trace clock.

    TRD0 44 PF2 (15) O TTL Trace data 0.

    TRD1 43 PF1 (15) O TTL Trace data 1.

    TRD2 42 PF0 (15) O TTL Trace data 2.

    TRD3 46 PF4 (15) O TTL Trace data 3.

    "



    Is this somehow different from trace? Is the data sheet in error?

    Robert

  • 0 in reply to Robert Adsett
    TI__Mastermind 22715 points
    Robert,

    The following thread should provide additional information.

    e2e.ti.com/.../1462253;tisearch=Search-EN-Everything

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Guru 47900 points
    Information there "not" especially satisfying.

    May I note that w/in IAR - and J-Link - we've been able to employ SWD's SWO as trace output on vendor's (past) LX4F devices.

    This "runs essentially in the background" while providing much (yet not all) of formal trace output.

    Single vendor IDE remains (unable/unwilling) to adapt SWD - while confining ARM MCU choice to "one."
  • 0 in reply to cb1
    Guru 27665 points
    That fits with what I understood cb1. The chip does support trace, at least in a limited form.

    CCS may not but that's a separate issue.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Hi Robert,

    Two outsiders agree - the "defining" thread seemed not impressive.

    Suicide is a "self-inflicted" condition - an IDE - long "depriving" its users of "normal/customary" SWD usage - may prove an equally (poor) and clearly, "self-inflicted" choice...     Locking oneself into a "single source" - when a wealth of M0, M3 (soon M7) beckon - (somehow) seems misguided - does it not?
     
    A proper IDE may well enable the achievement of poster's goals - so any "separation of issues" appears (slight.)