• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 609 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.

SYSLINK trace sample for DSP + Linux

Andrew Elder
Expert 1680 points


I'm looking in syslink_2_10_00_12 for a sample that uses the trace interface between the host and the slave processor. I want to be able to see stuff "printed" on the DSP display on the ARM linux side. Am I missing something ?

I've found various scatter information about trace interface and SYSLINK_TRACE_ENABLE, but no complete, well documented example. Any pointers ?

- Andrew

  • 0
    TI__Genius 17205 points

    That isn't inherently supported by SysLink, so you won't find it in the examples.  However, depending on your device, there may be other products that can work with SysLink that provide what you're looking for.  What device are you on?

    Chris

  • 0 in reply to Chris Ring
    Expert 1680 points

    814x. It looks like trace.h has much of what I am looking for....

    - Andrew

  • 0 in reply to Andrew Elder
    TI__Genius 17205 points

    Currently, SysLink's Trace.h (on the BIOS side) sits above System_printf().  Where that output goes depends on how you've configured your "System" module (in various .cfg scripts).  Given that, this thread may help:

        http://e2e.ti.com/support/embedded/bios/f/355/t/145079.aspx

    Stop reading here if that gets you going.  :)

    That said, frankly that's not the strategic direction we're going - a better approach is to build on Log_* APIs (rather than System_*), so I wouldn't use SysLink's Trace.h.  (We're actually considering changing SysLink's tracing to use Log in the future, so be a little careful building on Trace.h in its current state - Trace.h is an 'internal detail' only meant for use internally by SysLink.)

    On the BIOS side, I'd probably recommend you directly use the BIOS (really XDC) Log_printf() APIs.  More details than you want are here:

        http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_Logging

    Once you start using Log APIs, you can use the features in the UIA (Unified Instrumentation Architecture) product (like the LoggerSM utility - SM == Shared Memory) to retrieve the Logged statements on remote cores.

    It's not nearly as clean as I'd like, but this article has some details and reflects where we're ultimately going with this:

        http://processors.wiki.ti.com/index.php/OMX_Viewing_Media_Controller_Traces

    I'd love to work up a simple example of this, but we just haven't yet had the time.  IMHO, the Log_* APIs and UIA are strategically the right direction.  However, if System_print() and the thread at the top of my reply makes you happy - run with that.

    Chris

  • 0 in reply to Chris Ring
    Expert 1680 points

    Thanks for the detailed response. I'm going to give the Log_printf() APIs a try. I'd rather not start down a path that is not going to be supported.