RTOS/EK-TM4C1294XL: LoggerStreamer2 program commands not recognized

Hi,

Why did you select LoggerStreamer2? While supported, it was specifically designed for a team that wanted to have some pretty creative logging framework.

Here's a write-up on logging that you might find interesting: processors.wiki.ti.com/.../Debugging_Exceptions_With_TI-RTOS

Todd

The idea behind LS2 was to remove the buffer handling from RTOS and let the application manage it. I have not read anything about LS2 team support in the RTSC documentation as you mention. The only other UART transport logger example uses the idle module as it seems to write events to the instrumentation host (RTOS Analyzer) and drops thousands of packets sent to the host. LS2 is not limited to idle CPU time writes and streams data to the instrumentation host, hence it is Lossless.

That was the main reason for wanting to configure the application to manage the buffers with UIA transport transfer to the host. The RTOS Wiki does not even list LS2 as a Logging method, I found little help there.

ToddMullanix said:

I've attached an example of LoggerStreamer2

That LS2 example project does not use any of the RTSC directives as I outlined above post and can not set the context for the specific log buffer to R/W to the UART transport selected by the engineer for the instrumentation host. None of the commands are recognized per the current RTSC documentation relative the LS2 subject matter.

The logging buffer example zip per UIA text is not being followed setting the instance context value to the specific logging buffer. That is why the Exchange function issues the directive to read a specific buffer pointed to by the context returned.

loggerStreamer20Params.context = 0;
loggerStreamer21Params.context = 1;
loggerStreamer22Params.context = 2;

Those two includes make CCS7.3 code analysis indexing break down and hang CCS with the latest JAVA code updates.

Restored project Work Space  (.metadata) prior to import of (empty_rtos) project seemed to fix legacy/indexing hang up etc.. Odd thing is I never past imported a legacy project only the example above, twice. Example LS2 project imported into CCS7.3 posts a console warning message, "Newer project need to update CCS7.4".

Seemingly that project import may have been what trigged the metadata crashes both times after restoring WS .metadata. Afraid to import LS2 example again as things in CCS7.3 get crazy!

I forgot about the LoggerStreamer2_initBuffer API. It does simplify the application code. I added the context setting in the .cfg and show an example of getting it in the new example.

I'm using CCS7.4. You could just grab the contents of the .cfg and empty.c file. I did not change any project settings.

loggerstreamer2_exampleB.zip

Todd

Thanks as I was getting into a type mismatch bind it seems.

The instance name was a bit unique entry " ". Oddly the initBuffer call complains of Char type assigned to the buffers sent to UART0 as (Char *a) is incompatible with UIA LS2 InitBuffer handle below. It still sends garbage data to COM4, rather it floods Hwi execution data. I don't think the initBuffer is compatible with any 8bit call but I've seen similar issue with UARTprintf() conversion to USB0 output (uint32_t) data type. The logging buffers data type may need to be the same data type as UART0 and it seems to have an 8bit FIFO judging by the way UARTutils.c was written.  I'll add the your LS2 example files into an empty project.

 /* Ping-pong filling the two buffers */
 if (id == 0) {
  LoggerStreamer2_initBuffer("loggerStreamer20", buffer_0[0], 0);
  LoggerStreamer2_initBuffer("loggerStreamer20", buffer_0[1], 0);
  return ((Ptr)buffer_0[0]);

ti_uia_sysbios_LoggerStreamer2_initBuffer__E( ti_uia_sysbios_LoggerStreamer2_Handle __inst, xdc_Ptr buffer, xdc_UInt16 src );

You need to use the handle to initBuffer, not a string. Look in my example.

ToddMullanix said:

You need to use the handle to initBuffer, not a string. Look in my example.

That is the handle for the instance and both ways of describing the instance produce the same results.

Neither example actually sends any UIA buffered logger data to RTOS analyzer therefore never has to convert aligned uint32_t buffer data to UART0 char uint8_t data type. The System_print() in the heartbeat will not print UIA buffer data and is missing a System_flush() directive required for it to actually pint each cycle to debug console. I added the System_flush() but debug console still didn't print any data from my initialized buffers by either string or handle name. Oddly the CCS indexer keeps getting hung trying to import legacy data from UIA directives and blocks the CCS workspace .metadata from properly executing anytime the index is being rebuilt. I have restored project .metadata several times as this issue keeps randomly repeating making things difficult having to kill CCS background process tree many times. 

What ever was done to LS2 code is not following the RTSC (documentation) for proper Exchange Fxn (uint32_t) buffer hand off to the UIA instrumentation host via UART0. Text states application must trigger the  buffer in exchange Fxn to flush contents (read buffer) as I show below. The buffer data is actually being written UART0 FIFO on COM4 but the UIA_hdr is likely mangled do to the data type mismatch and will not print any data in RTOS live session window.

/* LoggerStreamer2 buffers */
#define BUFSIZE_0  1024
#define BUFSIZE_1  1024
#define BUFSIZE_2  1024

/* Logging buffers */
char buffer_0[2][BUFSIZE_0];
char buffer_1[2][BUFSIZE_1];
char buffer_2[2][BUFSIZE_2];

/* The prime pointer to RTOS analyzer buffer loading */
Ptr PrimeLS2(LoggerStreamer2_Object *log, Ptr *Pbuf)
{
    /* Determine logger instance context */
    UInt32 id = (UInt32)LoggerStreamer2_getContext(log);

    /* Ping-pong filling the two buffers */
    if (id == 0) {
        LoggerStreamer2_initBuffer(log, buffer_0[0], 0);//"loggerStreamer20"
        LoggerStreamer2_initBuffer(log, buffer_0[1], 0);//"loggerStreamer20"
        return ((Ptr)buffer_0[0]);
    }
    /* Ping-pong filling the two buffers */
    if (id == 1) {
        LoggerStreamer2_initBuffer(log, buffer_1[0], 1);//"loggerStreamer21"
        LoggerStreamer2_initBuffer(log, buffer_1[1], 1);//"loggerStreamer21"
        return ((Ptr)(buffer_1[0]));
    }
    /* Ping-pong filling the two buffers */
    if (id == 2) {
        LoggerStreamer2_initBuffer(log, buffer_2[0], 2);//"loggerStreamer22"
        LoggerStreamer2_initBuffer(log, buffer_2[1], 2);//"loggerStreamer22"
        return ((Ptr)(buffer_2[0]));
    }

    return (NULL); // Error
}

/* The Exchange pointer of RTOS analyzer buffer logging */
Ptr ExchangeLS2(LoggerStreamer2_Object *log, Ptr *full)
{
    static uint32_t count_0;
    static uint32_t count_1;
    static uint32_t count_2;

    UInt32 id = (UInt32)LoggerStreamer2_getContext(log);

    //LoggerStreamer2_getContents();

    if (id == 0) {
        count_0++;
        while(1){
        LoggerStreamer2_getContents(log, (Ptr*)buffer_0, 256, *full);
        /* Ping-pong between the 2 buffers of each logger */
        UARTUtils_loggerSend((Ptr*)buffer_0, count_0);
        return((Ptr*)buffer_0[count_0 & 1]);
        }
    }
    if (id == 1) {
        count_1++;
        while(1){
        LoggerStreamer2_getContents(log, (Ptr*)buffer_1, 256, *full);
        /* Ping-pong between the 2 buffers of each logger */
        UARTUtils_loggerSend((Ptr*)buffer_1, count_1);
        return ((Ptr*)buffer_1[count_1 & 1]);
        }
    }
    if (id == 2) {
        count_2++;
        while(1){
        LoggerStreamer2_getContents(log, (Ptr*)buffer_2, 256, *full);
        /* Ping-pong between the 2 buffers of each logger */
        UARTUtils_loggerSend((Ptr*)buffer_2, count_2);
        return ((Ptr*)buffer_2[count_2 & 1]);
        }
    } 
     return (NULL);  // Error
}

/*
 *  ======== UARTUtils_loggerStreamer2 Send ========
 *  Plugged into LoggerStreamer2 to send lossless log data.
 */
Int UARTUtils_loggerSend(Ptr *Pbuf, Int size)
{
    /* Make sure UART is initialized */
    if (loggerHandle) {
        /*
         * Write up to 16 bytes at a time.  This function runs during idle and
         * should not tie up other idle functions from running.  The idle loop
         * is generally short enough that this function will run again before all
         * 16 bytes have been transmitted from the FIFO.
         */
        if (size < 256) {
            return (UART_writePolling(loggerHandle, (void *)Pbuf, size));
        }
        else {
            return (UART_writePolling(loggerHandle, (void *)Pbuf, 256));
        }
    }
    else {
        return (0);
    }
}

The Exchange Fxn pointer to LS2 exchange buffer data type has issues even when the Instance name is the Handle name or string name. Somehow the 8bit (char) data type works UART0 idle logger example with RTOS handling buffer transfer up to UART0. So the 8bit (char) buffer data type seems a proven UIA_hdr convention in that example.

 Again UART0 is sending binary data to COM4 but the UIA_hdr must be mangled or even missing since debug RTOS Live session window remains data less, void. Not sure of a WA, at this point tried xdc_Char, Char, and (uint32_t) Exchange Fxn log buffer type won't compile without errors. Seemingly the idea is application unloads each buffer into the selected transport chosen via (Logging Setup) and not mangle the merged (uint32_t) UIA_hdr information the instrumentation host requires.

FWI: Indirect memory addressing via header pointers R/W logging buffers using (typedef XDC_ptr) was a WA for skirting over UARTutils.c (char) data type into UART0 FIFO.

BP101 said:

LoggerStreamer2_initBuffer("loggerStreamer20", buffer_0[0], 0);

is not valid. The string is a .const, not a handle. Look at the address it. For example I have this in the .cfg

var LoggerStreamer2 = xdc.useModule('ti.uia.sysbios.LoggerStreamer2');
LoggerStreamer2.transportType = LoggerStreamer2.TransportType_CUSTOM;
LoggerStreamer2.isTimestampEnabled = true;
var loggerStreamer2Params = new LoggerStreamer2.Params();
loggerStreamer2Params.instance.name = "loggerStreamer20";
loggerStreamer2Params.primeFxn = "&logPrime";
loggerStreamer2Params.exchangeFxn = "&logExchange";
loggerStreamer2Params.bufSize = 1024;
loggerStreamer2Params.context = 1;
Defaults.common$.logger = LoggerStreamer2.create(loggerStreamer2Params);
Program.global.loggerStreamer20 =Defaults.common$.logger ;

And in exchange function I print this out (obj is the passed in logger object)

System_printf("0x%x  0x%x 0x%x\n", obj, loggerStreamer20,"loggerStreamer20");

Here is the output 

0x200024c4  0x200024c4 0x3694

Please attach an example project where you think the string is the same as the handle.

Todd

Hi Todd,

ToddMullanix said:

LoggerStreamer2_initBuffer("loggerStreamer20", buffer_0[0], 0);


is not valid. The string is a .const, not a handle. Look at the address it. For example I have this in the .cfg

Oddly that name is called the (Handle) in the LS2 module GUI, suspect the compiler links the symbol to the handle name in the index. Oddly CCS7.4 C example (empty.c) the indexer tries to import and migrate legacy symbols and hangs the CCS7.3 indexer every time it is opened.    

Did you notice I changed the LoggerStreamer2_initBuffer_InitBuffer() handle ("loggerStreamer20")to (Log) in the code posted above, made no difference. The Sytem_printf() statement  (example) seemingly uses uint32_t data type to print console text. UART0 (char uint_8t) does not accept (uint32_t) logger UIA packet header data. The other problem System_printf() only prints the logger buffer contents one time since the Exchange Fxn call to log print is not being triggered by a task to get or flush the buffer contents into UART0.

The flushing task loop still uses the instance handle ("loggerStreamer20") and I will attempt to modify the header to pass Log instance context. 

The UIA_Packet header is four 32 bit Dwords. That seems to infer LoggerStreamer2_InitBuffer() can not have a buffer array built with data type (char) as the LS2 example uses. Warning: The (LoggerStreamer2_Object *log) is incompatible with data type (char).

Initializes the UIA packet header:
C synopsis:
Void LoggerStreamer2_initBuffer(LoggerStreamer2_Handle handle, Ptr buffer, UInt16 src);

ARGUMENTS
handle — handle of a previously-created LoggerStreamer2 instance object
buffer — Pointer to the buffer that LoggerStreamer2 will fill with Log events. The first four 32-bit words will contain the UIAPacket_Hdr structure.
src — Used to initialize the UIA source address. For a single core device, this will generally be 0. For multi-core devices, it generally corresponds to the DNUM (on C6xxxx deviecs) or the Ipc MultiProc id. It must be unique for all cores and match the configuration in the System Analyzer endpoint configuration.

DETAILS

This API is used to initialize a buffer before it is given to LoggerStreamer2 (via priming or exchange). The function initializes the UIAPacket_Hdr portion of the buffer.

I rewrote the exchange part above post and changed the (UARTutils.c) UART0 to accept a pointer into the logging buffers context. Also had left off the LS2prime (Ptr) in the header but it made no difference.

Instead of loggingBufferFlush(log) task forcing the packet exchange, the LS2 Exchange Fxn still seems to auto query the buffers exchange to UART0.
[LoggerStreamer2_getContents(log, (Ptr*)buffer_1, 256, *full) ]

The LoggerStreamer2 module must be using Clock_tick to Exchange the buffers since UART0 output data produces characters. The UART0 data is still not updating RTOS analyzer yet prints characters to debug monitor COM4 and compiles with 0 errors, no warnings.