System Analyser : LoggerBuf, LoggerCircBuf, overflowLogger

Hi Clement,

It is true that you cannot use LoggingSetup to create an overflow logger for JTAGRUNMODE with uia 1.01.00.04.  It seems that incorrect meta data is generated in the uia.xml file.  In later versions of UIA, LoggingSetup will not create an overflow logger for any upload mode.

However, if you do want an overflow logger, you could configure LoggerCircBuf.overflowLogger in your .cfg file.  For example, if I wanted to use LoggerBuf for my overflow logger, I could do it as follows:

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');

// Set overflowLoggerSize to 0 so that LoggingSetup won't try to create
// the overflow logger.
LoggingSetup.overflowLoggerSize = 0;

LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGRUNMODE;

// LoggerCircBuf is used in JTAGRUNMODE
var LoggerCircBuf = xdc.useModule('ti.uia.runtime.LoggerCircBuf');

var loggerBufParams = new LoggerBuf.Params();
loggerBufParams.numEntries = 1024;
var overflowLogger = LoggerBuf.create(loggerBufParams);
overflowLogger.instance.name = "overflowLogger";

LoggerCircBuf.overflowLogger = overflowLogger;

I tried this out on a newer version of UIA (1.03.01.08).  I'm not sure if it will work with your old version.  If not I can try to find a work-around for you.

The reason LoggerCircBuf does not allow wrapping is to minimize overhead.

Best regards,

    Janet

Hi Janet,

Thank you for your input.

I already tried some of what you described but I got the line LoggingSetup.overflowLoggerSize = 0; wrong and may have missed a thing of two. I was on the right track. I'll try again tomorrow (for my timezone) and let you know if it worked.

Another thing you can help me with, is creating a specific logger for say "semaphores" and another one for "swis".

I tried to create a LoggerCircBuf 'loggerA' and then I set something like Semaphore.logger = loggerA.

But I think I hit a conflict with LoggingSetup which puts everything under the Sysbios logger. Sometimes I get an explicit warning about it (saying that my attempt was not taken into account because it is already defined by LoggingSetup) sometimes not but in all cases I never got it to work as of now.

I can replace the whole Sysbios logger with my own but not break it down into specific loggers for specific events (semaphores, swis, events, ...).

Regards,

Clément 

Hi Clement,

If you try to assign a logger to a module such as Semaphore or Task, and then use LoggingSetup, it will re-assign the module's logger.  I suppose System Analyzer needs these events to all be in one log.  If you are not going to use System Analyzer, you can assign different logs to Semaphore and Task.  For example:

var taskLogger = LoggerBuf.create(loggerParams);
Task.common$.logger = taskLogger;

Best regards,

    Janet

Ok got it Janet,

I tried the overflow logger setup you suggested : it seems to work.
With ROV tool we could see the content of the logger the strange thing was that the logs were from 221 to 1142 (which is 921 logs instead of 1024).
I also tried a size of 2048 and the logger was filled from 1 to 1128, which is confusing.

For the display on the execution graph it's a bit strange sometimes we get the right thing :
first data (from loggerCircBuf) - data loss (overflow overwriting) - last data (from overflowlogger)

but most of the time (with the same compiled code !)
we get data + data loss and the data from the overflow logger (visible in ROV) is NOT displayed on the execution graph.

As of now we aren't able to reproduce the "working" state. Is there any steps that we should follow other than loading .out on all cores, launching Syst Analyser, running the program , stop SA (red dot button), analyse-> execution graph ?

I'm a bit confused about the "serial" terminology, what does it mean exactly ? How is incremented ?.

Thank you for your help,

Clément

Hi Clement,

I don't think you are seeing the contents of the overflow logger in the execution graph (actually, I'm having trouble figuring out the differences in the two graphs above).  You would need to use ROV to see the overflow logger records.

As for the number of entries in the overflow loggers and the serial numbers, some events may be taking up two entries (eg, Log_write8() will take 2 LoggerBuf entries).  The serial number indicates whether a record is new or a continuation.  Here's a comment from LoggerBuf_write8() in LoggerBuf.c:

 *  Odd serial numbers indicate a new record, even serial numbers indicate
 *  an "extension" to the previous record.  0 is a sentinal for no record,
 *  but only if it doesn't follow a -1 (0xffffffff).  If a serial number
 *  of 0 follows a serial number of 0xffffffff, it's an extension, otherwise
 *  it's a "no record".

So that's why you may not be seeing the same number of records as the size you configured the Log.

Best regards,

    Janet

Janet,

The difference on the execution graph is that on the first one it looks like the overflow logger data is displayed on the far right (I agree we can't see it very well) whereas on the second one there is no data after the data loss part.

Ok for the serial numbers explanation.

Clément

I think the graphs are more or less the same.  Maybe if you expand the lower graph near the right hand side, you will find that it is similar (in the graph, hold down the "Alt" key while using the mouse to select the region).  I think the big gap is where you have lost data.

Best regards,

    Janet

Janet,

Here's new screenshots, detailling the part on the right :

a) Right behaviour (data then data loss then data from overflow logger)

b) Wrong behaviour

As you can see it's quite different.

Anyway I'll keep investigating and let you know if -a- was resulting from a bug in the execution or if I can reproduce it.

Regards,

Clément

Janet,

Sorry for the delay, I was away from the office for a few days.

I think your explanation makes sense.

Here's what I want to achieve :

I have an example application that do a bit of data processing across 8 cores (the work is split in 8). I'd like to make it run in a loop all night long with events logged via the System Analyser. I want to have an execution graph of the execution of a couple of iterations of the loop (the first ones) and also the last 2 or 3.

Right now I can increase the size of the buffers to get around 150 iterations of the loop. All night long doesn't seem achievable with this configuration.

Again I don't need all the iterations, let's say the first 5 and the last 5. But for these iterations I would like to see the execution graph.

Clément

Hi Clement,

Can you try starting your program running without System Analyzer?  Then the LoggerCircBuf buffer will fill up and data will no longer be logged to it because the buffer is full.  Let your program run overnight, and then bring up System Analyzer.  Make sure to leave the configuration as JTAG RunMode.  Then you should get the first and the last records.

Best regards,

    Janet

Hi Janet,

I'll try your suggestion.

In the case where the application crashes I also would like to see the last few iterations that lead to the crash.
Your workaround won't work in this scenario right ?

Thank you for your help and the follow-up on this thread. Is it possible for you to ping BrianC (in the forum) about this ? He seems quite involved with the System Analyser (he wrote some of the wiki tutorials).

Clément