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.

CCS/SM320F28335-HT: Invalid UIA Configuration, EventTransport Undefined

Part Number: SM320F28335-HT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

CCS 6.1.1.00022
SYS/BIOS 6.35.6.56
XDC Tools 3.25.4.88
CG Tools 6.2.11
UIA 1.4.0.06
OS: Windows 10 64-bit

I'm trying to set up UIA to use the 28335's external memory as a buffer for log data.  I've got the following in the config file.

/* System Analyzer (UIA) Setup */
var loggerCircBufParams = new LoggerCircBuf.Params();
loggerCircBufParams.transferBufSize = 20480;
loggerCircBufParams.bufSection = 'loggerBuf';
var loggerCirc = LoggerCircBuf.create(loggerCircBufParams);
LoggingSetup.sysbiosLogger = loggerCirc;

The project builds and executes, but when I try to boot up the System Analyzer, I get the following error message.

The XDC tools GUI shows my event upload mode as JTAG Stop Mode.  Is this simply unsupported with this version of UIA?

  • Hi Luke,

    A few questions:
    1. What device are you using?
    2. Do you see any Log records in Tools->ROV Classic?
    3. Can you re-post the picture. It did not saw up.
    4. If it is a warning message, what happens if you ignore it and try to open it anyway.

    Todd
  • 5. Why use LoggerCircBuf? I'm asking this because it is not a commonly used logger and I want to understand why you picked it.
  • 1.) Device is the SM320F28335-HT.  

    2.) No, I cannot see log records in ROV, but I do see 6885 dropped events for the custom logger.

    3.)  Notice the Transport column is empty, I'm reasonably confident this is the problem.

    This message occurs after I click past the "Unable to determine instrumentation" popup.

    4.) If I close the message, UIA does not launch.

    5.) I used LoggerCircBuf because the closest User's Guide I can find to the UIA version I'm using is 1.1 (spruh43d), which mentions the only Loggers that can be used are those "that inherit from ti.uia.runtime.IUIATransfer", which are LoggerCircBuf and LoggerSM.    It also mentions that CircBuf is the default implementation of a logger so it made sense to use that one.

    It may be quicker to clarify my understanding of UIA than to try and diagnose this issue from the ground up.  More current User's Guides mention multiple ways to configure a custom logger with a custom memory section, but it appears that most of these are unsupported in UIA 1.4.

    Thanks, please let me know what else I can do to help.

  • Thanks. I recommend just getting LoggerStopMode working first and then if desired, more complicated loggers can be used. LoggerStopMode requires that the target be stopped to allow CCS to read it.

    1. Remove all the Logger code in the .cfg file. It's easiest to just edit the .cfg as a text file.
    2. Make sure BIOS.logsEnabled is true in the .cfg
    3. Add the following line into the .cfg. This will setup most things that people use.
    var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
    4. Rebuild/reload/run/halt and open Execution graph now.

    LoggerStopMode uses internal buffers to store the Log records. If desired (and you have the memory) you can increase the size of those log buffers to get more records. For example:

    LoggingSetup.loadLoggerSize = 256;
    LoggingSetup.mainLoggerSize = 512;
    LoggingSetup.sysbiosLoggerSize = 4096;

    Note the "main" logger holds log records called by the application. The "sysbios" logger holds the kernel log records. The "load" logger holds the CPU Load records. You should be able to see the log records in ROV also under LoggerStopMode->Records.

    If you get this to work, let me know. Also, let me know if this does not meet your needs. If so, I can go into more detail on other options of getting the data off the target.

    Todd
  • Thanks for the explanation Todd.  I've previously gotten a UIA configuration working and I've used the Execution Graph, Load Analysis, etc.  I can do so with my application currently, but I need more memory than I have available for this application, so I'm trying to set up a logger to use some external memory (1MB SRAM) connected to my device.

     I've used the most recent System Analyzer User's Guide (spruh43f) and have the following to try and configure a LoggerStopMode to do what I'm looking for using the following in the .cfg.

    /* System Analyzer (UIA) Setup */
    var loggerParams = new LoggerStopMode.Params();
    loggerParams.bufSection = "loggerBuf";
    loggerParams.bufSize = 20480;
    
    var logger = LoggerStopMode.create(loggerParams);
    logger.instance.name = "BIOS Logger";
    loggingSetup.sysbiosLogger = logger;

    loggerBuf is allocated to the external SRAM I mentioned earlier.  After entering the code above I get an error (getting back to my mention of suspected compatibility issues) saying "XDC runtime error: ti.uia.runtime.LoggerStopMode.Params#1: no element named 'bufSize'    app.cfg"

    The System Analyzer UG shows an example of doing this exact setup aside from using the above logger as the loadLogger instead of the sysbiosLogger.  Unfortunately, none of the other loggers look suitable for what I'm trying to do.

  • Hi Luke,

    The field name is "transferBufSize" not "bufSize". The version you are using is rather old. You might have seen some documentation on a more current UIA (where the name is "bufSize").

    You can see the API reference in the "cdoc" link here for your version (and it's included in the installed product also): software-dl.ti.com/.../index_FDS.html

    Note: newer UIA releases still have "transferBufSize" for backward compatibility, but we don't document that field.

    The bufSection field is correct. Can you try changing the bufSize name and see if that works.

    Todd
  • Thanks Todd.  I can now launch UIA.  I'm getting Load records, but nothing for SYS/BIOS logging aside from 1 dropped event.  Attached is a screenshot.

    Several questions:

    I took a look at this thread and found that I'm pulling in LoggerStopMode as mentioned, but I can't remove it without breaking UIA in this version.

    I have the external memory allocated as a Data Section.  Does this have any sway on a UIA logger?

    Also attached a screenshot of my current LoggingSetup configuration.  Does transferBufSize override the listed sysbiosLogger size?

    Thanks.

  • Hi Ed,

    Thinking.... Based on what you said, this would work if you did not have the SYSBIOS Logger buffer in the external memory (and a smaller size)...correct? Can you confirm that?

    Can you look at the mapfile and determine where the SYSBIOS Logger buffer is in external memory. Then look at it with a CCS Memory Browser. I want to make sure CCS can see it. Can you dump the buffer's contents into a binary file and attach it? I want to look to make sure all the header information at the beginning of the buffer looks ok.

    Also, just to confirm, the Load Logger buffer is not in the external memory...correct? I'm assuming that since it appears to be working properly.

    Todd
  • You are correct.  The sysbios buffer works when placed in local memory.  The Load Logger buffer is also in local memory. 

    Here is the mapfile entry for my buffer:

    loggerBuf 
    *          1    00208000    00005080     UNINITIALIZED
                      00208000    00005080     app_p28FP.o28FP (loggerBuf)

    I can certainly see data at that location in the Memory Browser, and the binary file for the memory section from 0x208000 to 0x210000 is attached.  loggerBuf in xintf.zip

  • Hi Luke,

    The header information (first 4 32-bit words) in the zip does not look correct. Can you compare it against when you have the log buffer in internal memory. I don't have access to a C28 right now (working remote today), but here is one for a 32-bit CortexM3. The first 4 words have information that CCS (and ROV) uses to figure out whether it is big or little endian, core id, length of buffer, etc. After those words, the Log records are encoded (e..g 0x50200300 -> a specific Log id and the length is 0x20 bytes. When you look at 0x20 bytes latter, there is another log record of 0x20 bytes. I cannot remember how much different this looks on the C28 with the 16 bit bytes. I'm hoping when you compare the internal verses external RAM, something pops up. Quick sanity check...do you do any type of memory tests on the external RAM?

    Todd

  • Todd,

    Yes, I run a quick bus test then a short pseudorandom test, all of which pass.  I'm observing data being written to external memory in the memory browser as well. 

    I've moved the loggerBuf to on-chip memory and it works, screenshots attached.  First is evidence of the records.  I also included what appears to be two logger instances.  I've only set one up, and the second is unselectable in the XGConfig script.  Unsure if this is relevant or expected.

    Next is the buffer in the Memory Browser.  (I'm using the entry in ROV for the BIOS Logger's "queueStartAdrs")  The headers don't look quite the same but the records work and fill out the execution graph beautifully so I assume they're as expected.

    loggerBuf_onchip_mem.zip

    Also attached a bin file of the capture. 

    Hope this helps, I'll continue comparing internal vs external memory captures in the meantime.

  • The two logger instances (and one locked) has me a little worried...can you attach your .cfg?
  • 17316.app.cfgSure thing.  Attached is a doctored .cfg

  • I sent you a friend request. Let's work this offline and then update the thread when we have it figured out.

    Todd
  • Still working offline...
  • We found the issue. The external RAM was being initialized in main() before BIOS_start. LoggerStopMode does initialization before main though:( Namely it initializes the buffer header so CCS can read the buffer (e.g. what is the endianess, size of the buffer, etc.). That header was garbage since the memory had not been initialized yet.

    The fix was to add a Startup.firstFxn (3a below) which is called before the kernel's startup functions (3b below). We could have done a resetFxn (1a) instead, but that's a little trickier since there is no C runtime stack at that point (so no function calls, no local variables, etc.).

    Here's the syntax to add the startup functions

          var Startup = xdc.useModule('xdc.runtime.Startup');
          Startup.resetFxn = "&myResetFxn";
          Startup.firstFxns[Startup.firstFxns.length++] = "&myFirst";
          Startup.lastFxns[Startup.lastFxns.length++] = "&myLast";

    You can look at ROV->Startup->Module->firstFxns to see the firstFxns (you need to hit click in the box and select the drop-down).

    Luke added a firstFxn that initialized the external memory and the execution graph is working now...yea!!

    Todd