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.

Custom Transport for System Analyzer

Other Parts Discussed in Thread: SYSBIOS, CCSTUDIO

Hello,

It appears from the UIA (target) side implementing a custom transport for different interfaces is rather straight forward. Is the same true for System Analyzer in Code Composer?

If it is, are there some docs I can be pointed towards? If not, are there docs on the binary file format System Analyzer uses so I could have another app receive the data and put it into something System Analyzer can display?

Thanks!

  • Hello,

    Unfortunately the System Analyzer docs is a bit light here. But there may be a few things I can point you to. Before I do that, one question I have is if you are using SYS/BIOS? If so, it will make things a bit easier.

    Thanks

    ki

  • I am using SYS/BIOS. But it is not the target side I am worried about. I read through the UIA code, and adding a new transport doesn't look too difficult. The NDK transport code is quite straight forward, and is a good example. It is more the Code Composer side I am worried about. With where my part is in the whole system, getting a JTAG pod on it is difficult, and I really only have a UART which is passed through an FPGA before it makes it out of the box.

  • Hi, sorry for the delay. This topic is a bit out of my expertise so I had to do my own digging and talk to some more knowledgeable people before I could get back to you.

    Some material that was recommend to me (which i am passing to you):

    It is recommend to start with the System Analyzer tutorial 5A that is in the wiki:

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

    it walks through how to write captured events to a file and upload them to System Analyzer.

    The exact same packet structure that is used in the file (i.e. a packet header followed by event data) can be used when streaming over UDP, except that the max packet size should be less than 1500.  

    The zip attachment posted here provides a lot more info on the packet header and event header data structures, UIA architecture, etc.

    3326.uia_packet_info.zip

    NOTE that the included architecture document in the zip is an early preliminary version that has not yet been publicly released

    Now the example in the wiki uses JTAG to get the data off the target and you will not have that available and wish to use UART.  We do support UART as a transport – the following pages from the System Analyzer user guide (http://www.ti.com/lit/ug/spruh43f/spruh43f.pdf) should help:

    Section 5.3.6 covers how to use LoggerIdle for logging events and uploading via UART.

    Pg 45: Section 4.2 Starting an RTOS Analyzer or System Analyzer session: talks about setting up the COM Port to receive data on

    Pg 95: Talks about LoggerIdle - Events uploaded over UART, USB, or Ethernet in the SYS/BIOS Idle Task.
    User must provide the transport
    function for uploading the events.

    Pg 97: shows LoggingSetup configuration for LoggerIdle.

    Hope this helps! As I get more information, I'll pass it along.

    ki

  • It seems that I was able to get the data out of the part and written to a file. I did some quick manual parsing of the file and it appears correct (event types, lengths and sequence numbers line up). But when I load it into CCS (v5.3, using UIA 1.01.04.27) the log tab doesn't show any entries. Any ideas why this would be the case?

    I placed the file in workspace/dvt and named it systemAnalyzerData.bin.

    Unfortunately I cannot run the UART straight into CCS because there is more than one data stream coming out of the UART. In my transport function I give to LoggerIdle, I wrap all of the UIA data into another message, and then wrote a tool to dump the data in those messages into a file.

    Would having an incomplete UIA packet at the end cause CCS trouble? I was hoping my dump script wouldn't have to parse the data too.

    Any pointers on what may be going on would be helpful.

    Thanks
  • It seems that having incomplete UIA packets is not the problem:

    I took one of my dumps, and used xxd to dump only the first 4 packets into a new file. System analyzer still does not show the four packets in the file.

    Is there some metadata which is missing at the beginning of the file? My issue is not just a pure UIA Packet format problem.
  • Hello, Sorry for dropping the ball here with the tardiness of my replies. I'm a bit over my head here and have recruited the experts and notified them of this thread. Hope to get some answers for you soon.
  • I appreciate the status update, and thanks for the help
  • Hi,
    Could you post the bin file with your events and your .usmxml, uia.xml and rta.xml files? (see section 4.5 of spruh43d.pdf - the System Analyzer User Guide that is in the UIA package's "docs" folder - for more info on these files. The uia.xml and rta.xml files are typically in e.g. Debug\configPkg\package\cfg in your CCS project's folder in your workspace folder.) One possible problem is that the logger ID you are providing in your packet header is not present in your rta.xml file.

    Regards,
    Brian

  • Hi Nick,

       A bit of background info:

       The packet header that is needed at the start of the .bin file is defined by the  ti/uia/runtime/UIAPacket module.   It's always big-endian, and typically contains 4 bytes.  Here's the relevant info:

        

    The HdrType that is used (from UIAPacket.xdc) is HdrType_EventPkt = 10, /*! Event rec. containing multiple events: (4 word hdr, 1 word footer) */

    The following macro is provided by UIAPacket (in UIAPacket_epilogue.h) to handle initialization of the fields in the header: 

    ti_uia_runtime_UIAPacket_initEventRecHdr(pPktHdr, endianness, eventLength, seqCount, priority, moduleId, instanceId, destAdrs, senderAdrs)

    Instead of using this directly in your code, I think the best approach would be to use the ti/uia/sysbios/LoggerStreamer logger to log your events.  To use LoggerStreamer, you set up an array of packet buffers.  Each packet buffer needs to be initialized (i.e. configured with valid UIAPacket headers) by calling the following macro, defined in LoggerStreamer_epilogue.h:

    ti_uia_sysbios_LoggerStreamer_initBuffer(buffer, src)

    LoggerStreamer then writes events into the current packet buffer in the array, and when the packet is full, it calls a user-provided exchangeBuffer method.  In this method, you pass it back the next buffer in the array and can queue up the last filled packet for transmission over whatever transport you'd like.  e.g. you can have an idle loop task that looks for full packet buffers and does whatever is needed to get the packet buffers to the host.

    The nice thing about this approach is that it is quite flexible and quite efficient.   It also handles all of the packet header stuff for you, so at the host side you can take the captured packets, store them to a binary file and have System Analyzer read this file.  (See section 4.6.2 of the System Analyzer User Guide spruh43d.pdf for info on how to open a binary file in System Analyzer, and section 4.5 for how to create a UIA configuration file (e.g. DefaultSession.usmxml) - set the Event Transport type to None for binary files.) 

    UIA Tutorial 5A (http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorial_5A ) shows how to use LoggerStreamer.  It's written for the C66x, but the logger is supported on other device families as well.  

    System Analyzer should only be given complete, valid UIA packets to work with in the binary file.  Normally, when System Analyzer receives a bad packet (i.e. one with data corruption that causes event decoding to fail) it does not display the events, since some of the events may contain 'bad data' that can be misleading. To prevent System Analyzer from flushing the data, you can add the following line to the end of your <CCStudio install dir>/ccsv5/eclipse/eclipse.ini and ccstudio.ini files to get System Analyzer to display event data when a corrupted packet is received:

    -Ddvt.uia.KeepDataOnError=true

    On the target, you can configure LoggerStreamer to validate that the data in a packet is ok by setting LoggerStreamer's isBadPacketDetectionEnabled property to true in your .cfg file.   The LoggerStreamer_validatePacket function that is provided in ti/uia/sysbios/LoggerStreamer.c can be used to give you some ideas on how to check whether the data received by the host is 'clean' before committing it to the .bin file to be used by System Analyzer.

    Hopefully this will be enough to get you started.  Please post here if you have any questions.

    Regards,

      Brian

     

  • Hi Nick,

       The template project that was used to demonstrate how to use LoggerStreamer in Tutorial 5A was removed in CCSv5.3, so I've updated Tutorial 5A  by adding a zip file containing the project files.  

    Hopefully this helps make it a bit easier to get familiar with how to use LoggerStreamer.

    Regards,

      Brian

  • Hi Brian,

    Thanks for keeping up on this. New fires have erupted and drawn my attention away form this particular issue.

    You suggest using logger streamer. My first attempt was with LoggerIdle and my own custom transport function. What makes Streamer more likely to work than Idle?

    Nick
  • Here is the UIA portion of my config file:

    var logSize = 0x100;
    Load = xdc.useModule('ti.sysbios.utils.Load');
    Load.hwiEnabled = false;
    Load.swiEnabled = false;
    Load.taskEnabled = false;
    var Log = xdc.useModule('xdc.runtime.Log');
    var LoggerIdle = xdc.useModule('ti.uia.sysbios.LoggerIdle');
    LoggerIdle.bufferSize = logSize;
    LoggerIdle.transportType = LoggerIdle.TransportType_CUSTOM;
    LoggerIdle.customTransportType = "CustomUart";
    LoggerIdle.isTimestampEnabled = true;
    LoggerIdle.transportFxn = UartUIATransportV1.IdleTransport;
    var LoggerIdleParams = new LoggerIdle.Params;
    logger = LoggerIdle.create(LoggerIdleParams);
    var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
    LoggingSetup.disableMulticoreEventCorrelation = true;
    LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_IDLE;
    LoggingSetup.loadLogger = logger;
    LoggingSetup.loadLoggerSize = logSize;
    LoggingSetup.loadLogging = false;
    LoggingSetup.loadLoggingRuntimeControl = false;
    LoggingSetup.mainLogger = logger;
    LoggingSetup.mainLoggerSize = logSize;
    LoggingSetup.mainLogging = true;
    LoggingSetup.mainLoggingRuntimeControl = false;
    LoggingSetup.overflowLoggerSize = 0;
    LoggingSetup.sysbiosHwiLogging = true;
    LoggingSetup.sysbiosHwiLoggingRuntimeControl = false;
    LoggingSetup.sysbiosLogger = logger;
    LoggingSetup.sysbiosLoggerSize = logSize;
    LoggingSetup.sysbiosSwiLogging = true;
    LoggingSetup.sysbiosSwiLoggingRuntimeControl = false;
    LoggingSetup.sysbiosTaskLogging = true;
    LoggingSetup.sysbiosTaskLoggingRuntimeControl = false;


    var UIABenchmark = xdc.useModule('ti.uia.events.UIABenchmark');
    var UIARoundtrip = xdc.useModule('ti.uia.events.UIARoundtrip');
    var UIAEvt = xdc.useModule('ti.uia.events.UIAEvt');
    var Main = xdc.useModule("xdc.runtime.Main");
    var Diags = xdc.useModule("xdc.runtime.Diags");
  • After more than a year I have finally gotten an opportunity to implement an interface for the streamer to get data out. Unfortunately it still seems to cause an error when I try to load the binary file into System Analyzer. I have verified that the data going into the data matches the data getting dumped to the binary file.
  • Attached is a zip file with a screen capture of the error, the required xml files, and the bin file I dumped.uia_test_20160318_0921.zip

  • It turned out that I needed code composer 5.1 for it to properly display the data
  • I still have an issue with system analyzer reading the binary file. It appears to only read in the first buffer which was "exchanged." So depending on the run I only see 10 or 11 items in system analyzer.

    The buffer size I'm using is 512 bytes, and the initial zip file in a previous post has the whole buffer written to the file.

    I have since tried reading the event length field in the header, and only writing that amount, which produced a corrupted file.

    I also tried adding 16 bytes (header) and 20 bytes (header + footer) and still only get 10 records.

    What else am I missing?