• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 781 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.

AM335X EtherCAT Performance

Mark Ackerson
Genius 10190 points

Other Parts Discussed in Thread: AM3517

Customer is using the AM335x processor in the Beagle Bone implementation. They are in the process of upgrading to the ti-sdk-am3356x-evm-05.03.02.00, but currently running 05.03.00.00.  These are based on the 3.1 Linux kernel.

Customer is running a prototype of their EtherCAT application and are seeing significant time jitter.  Typical response times are on the order of 200 usec but occasionally response time is up to 10 msec.  They are not using real time extensions.  They would like to investigate the source of this jitter.  They have used OProfile, but it doesn't give the level of visibility due to the statistical nature of this tool.

This would be using an XDS560v2 and an enhanced version of CCS.  Can you point me at an App Note or other documentation that shows what information can be gotten using this tool?

Do you have other recommendations for getting this kind of information?

Mark Ackerson
Texas Instruments
Field Applications – MCU Products
(612) 991-1215 (Cell)
mark.ackerson@ti.com

 

  • 0
    TI__Mastermind 44306 points

    Mark,

    the most bvious reason for this jitter is Linux itself. Although more and more of the RT-preemption patches for Linux are arriving in the standard kernel there is still a set of patches required to achieve full real-time capabilities. Once the patches are done there is a set of tools to measure RT performance e.g. latencies and jitter.

    Unfortunately we have no RT patched kernel for our supported kernels at the moment as we are mainly on 3.1. There is an RT-preemption patch for 3.0 and 3.2 work is ongoing.

    For more info also see the OSADL web page (www.osadl.org). There one can see RT performance on a live system e.g. AM3517 however with a 2.6.xx kernel only.

    Regards,

     Frank

  • 0 in reply to Frank Walzer
    TI__Genius 10190 points

    Hi Frank,

    Thanks for the reply.  That confirms our suspicion.  Would you be able to comment on debugging options for tracking down root cause?

    I've been looking at Linux trace toolkit (LTTng), and it looks like it is the tool to use.  The question is what extra information / value would the XDS560v2 provide over using just the LTTng software only solution.

    Regards,
    Mark

     

     

  • 0 in reply to Mark Ackerson
    TI__Guru*** 125430 points

    CCS Trace documentation is available inside CCS at Help -> Help Contents -> Code Composer Help -> Tasks -> Using Trace Analyzer.  I've spent some time looking around in there for details related to interrupt latency profiling but couldn't find anything specific.  There is mention of "interrupt profiling" on this wiki page.  I suspect that's counting how many of each interrupt you're getting rather than the latency in servicing a given interrupt.

    I suggest starting a new thread in the CCS forum for getting more assistance in XDS560v2 capabilities.

  • 0 in reply to Brad Griffis
    TI__Mastermind 44306 points

    I think Brad is right that we do have some real-time trace options in CCS and also CCS is continuously improving in that area. Anyway it s not really sufficient to track real-time latencies in long term yet. The measurements done for RT-Linux have to run for a few hours (or even days in some cases). So the amount of data is difficult to handle with just standard JTAG debug. The RT folks have put many man years into developing the right tools to measure in accordance with the RT-preemption patch. Unfortunately there are very few people really knowing the insides. If needed we can recommend 3Ps who can help.

    regards.