How to Interpret time unit in Execution Graph

Hi Louis,

As far as I know, that time should be in microseconds.

Can you please attach your app's *.cfg file?

Steve

Edit: I meant to say "microseconds"

var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var Error = xdc.useModule('xdc.runtime.Error');
var Log = xdc.useModule('xdc.runtime.Log');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main');
var SysMin = xdc.useModule('xdc.runtime.SysMin');
var System = xdc.useModule('xdc.runtime.System');
var Text = xdc.useModule('xdc.runtime.Text');

var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Task = xdc.useModule('ti.sysbios.knl.Task');

var Hwi = xdc.useModule('ti.sysbios.family.c28.Hwi');
var Boot = xdc.useModule('ti.catalog.c2800.init.Boot');
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
var Timer = xdc.useModule('ti.sysbios.hal.Timer');
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');

/*
 * Uncomment this line to globally disable Asserts.
 * All modules inherit the default from the 'Defaults' module.  You
 * can override these defaults on a per-module basis using Module.common$.
 * Disabling Asserts will save code space and improve runtime performance.
Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
 */

/*
 * Uncomment this line to keep module names from being loaded on the target.
 * The module name strings are placed in the .const section. Setting this
 * parameter to false will save space in the .const section.  Error and
 * Assert messages will contain an "unknown module" prefix instead
 * of the actual module name.
 */
Defaults.common$.namedModule = false;

/*
 * Minimize exit handler array in System.  The System module includes
 * an array of functions that are registered with System_atexit() to be
 * called by System_exit().
 */
System.maxAtexitHandlers = 4;      

/*
 * Uncomment this line to disable the Error print function. 
 * We lose error information when this is disabled since the errors are
 * not printed.  Disabling the raiseHook will save some code space if
 * your app is not using System_printf() since the Error_print() function
 * calls System_printf().
Error.raiseHook = null;
 */

/*
 * Uncomment this line to keep Error, Assert, and Log strings from being
 * loaded on the target.  These strings are placed in the .const section.
 * Setting this parameter to false will save space in the .const section.
 * Error, Assert and Log message will print raw ids and args instead of
 * a formatted message.
 */
Text.isLoaded = false;

/*
 * Uncomment this line to disable the output of characters by SysMin
 * when the program exits.  SysMin writes characters to a circular buffer.
 * This buffer can be viewed using the SysMin Output view in ROV.
 */
SysMin.flushAtExit = false;

/*
 * The BIOS module will create the default heap for the system.
 * Specify the size of this default heap.
 */
BIOS.heapSize = 0x0;

/* System stack size (used by ISRs and Swis) */
Program.stack = 1024;

/* Circular buffer size for System_printf() */
SysMin.bufSize = 128;

/*
 * Create and install logger for the whole system
 */
var loggerBufParams = new LoggerBuf.Params();
loggerBufParams.numEntries = 4;
var logger0 = LoggerBuf.create(loggerBufParams);
Defaults.common$.logger = logger0;
Main.common$.diags_INFO = Diags.ALWAYS_ON;

System.SupportProxy = SysMin;

/*
 * Build a custom BIOS library.  The custom library will be smaller than the
 * pre-built "instrumented" (default) and "non-instrumented" libraries.
 *
 * The BIOS.logsEnabled parameter specifies whether the Logging is enabled
 * within BIOS for this custom build.  These logs are used by the RTA and
 * UIA analysis tools.
 *
 * The BIOS.assertsEnabled parameter specifies whether BIOS code will
 * include Assert() checks.  Setting this parameter to 'false' will generate
 * smaller and faster code, but having asserts enabled is recommended for
 * early development as the Assert() checks will catch lots of programming
 * errors (invalid parameters, etc.)
 */
BIOS.libType = BIOS.LibType_Debug;
BIOS.logsEnabled = true;
BIOS.assertsEnabled = true;

Boot.pllcrDIV = 16;
BIOS.cpuFreq.lo = 80000000;
var hwi0Params = new Hwi.Params();
hwi0Params.instance.name = "adcHandle";
Program.global.adcHandle = Hwi.create(32, "&ADCINT1_ISR", hwi0Params);
Idle.idleFxns[0] = "&ToggleLED";
Idle.idleFxns[1] = "&ConvertTemp";
var timer0Params = new Timer.Params();
timer0Params.instance.name = "timer0";
timer0Params.period = 100000;
Program.global.timer0 = Timer.create(null, "&StartTempSampling", timer0Params);
BIOS.customCCOpts = "-v28 -DLARGE_MODEL=1 -ml --float_support=fpu32 -q -mo  --program_level_compile -g";
LoggingSetup.sysbiosHwiLogging = true;

1. You seem to be looking at the clock tick, which occurs every 1ms by default.

2. Afaik, timer periods are given in clock ticks, so 100000 seems to be excessively long

3. The unit is given below the scale, where it says "Time (us)". It may change when you zoom in or out, but in the given screenshot it's a microsecond.

Yes, as Markus mentioned, the default clock tick is every 1 millisecond.

As your view is showing microseconds, the difference of 1000us == 1 ms makes sense. It seems you're looking at the BIOS clock tick.

Your period of 100,000 ticks == 100,000 ms == 100 seconds ... again as Markus mentioned, you might want to make sure that you want a period that's that long.

Steve

Thank you for your support, but I'm still unclear what was wrong. I configured timer 0 with 100 ms (100000 us) period to call a function StartTempSampling() that triggers ADC. The ADC interrupt generates HWI, and I want to view its occurrences in the execution graph, but the HWI interval shows 1000. If its unit was microsecond as the X scale shows in the graph, I couldn't understand the correlation. Please explain.

Hi Louis,

Ok, I didn't realize that your period was in microseconds.

I think the issue you are having is that the execution graph view is zoomed in too far.

Note that the units of the graph, as well as the X values displayed at the top, change to match whatever the graph units are.

I ran an app on my side which has a 100ms timer.  It also has, by default, the 1ms clock tick:

As you can see, the units on the graph are in us.  Note that I had to zoom in a number of times to reach that granularity (the graph initially was zoomed out and showed milliseconds).

Here's some details on the highlights I made in the screen shot:

1. Blue rectangle:
   1. These time values are in micro seconds
2. Pink circles:
   
   1. This highlights the 1millisecond BIOS Clock tick.
   2. You can see that it's a 1 ms tick by looking at the value of "X3 - X2 = 1,000 (us)" that's displayed in the blue rectangle
3. Red rectangle
   
   1. This corresponds to my network scheduler, which runs every 100 milliseconds.
   2. The scheduler (ti_ndk_config_Global_stackThread()) is driven by a 100 ms Clock instance.  You can see this happen at time X2, and the NDK scheduler actually running just after (the dark blue time slot on the graph)
   3. There is another time that I marked on the graph that you can't see - time X1.
   4. X1 was marked at the previous time the NDK scheduler ran.  So it would look just like the graph that's inside the red rectangle
   5. Notice that X2 - X1 = 100,000 us == 100 ms which is the correct period.

Now, if I zoom out a bit more, the units of the graph will again change back to milliseconds.  Note that the "blue rectangle" times also display in milliseconds now (e.g. X2 - X1 now = 100 (ms))

So, I'm guessing that you would see your 100ms clock if you zoomed out far enough.

Steve

Also, if you notice that my execution graph has more info, you can get this by updating your *.cfg file.

Here's the code from mine. You may need to adjust buffer sizes for your h/w:

/* ================ Logging Configuration ================ */
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.sysbiosSwiLogging = true;
LoggingSetup.sysbiosHwiLogging = true;
LoggingSetup.sysbiosSemaphoreLogging = true;
LoggingSetup.loadLogging = false;
LoggingSetup.benchmarkLogging = false;
LoggingSetup.mainLoggingRuntimeControl = false;
LoggingSetup.loadTaskLogging = false;
LoggingSetup.loadSwiLogging = false;
LoggingSetup.loadHwiLogging = false;
LoggingSetup.loadLoggerSize = 0;
LoggingSetup.sysbiosLoggerSize = 24576;
LoggingSetup.mainLoggerSize = 8192;

var UIABenchmark = xdc.useModule('ti.uia.events.UIABenchmark');

var Main = xdc.useModule('xdc.runtime.Main');
Main.common$.diags_INFO = Diags.ALWAYS_ON;

Hi Steven,

Thank you for your great help, but I was unable to generate the similar waveforms on F28069 Launchpad. With F28069, there was no option to use UIABenchmark in the configuration tool, even though I added the script manually, it does not make a difference. All I saw was the 1 ms HWI ticks, not my application HWI events (100 ms).
Can you test on an F28069 Launchpad to see if you are able to generate the app events waveform? Thanks!

Even though I added two HWIs and two SWIs, and had the checkbox of HWI and SWI in LoggingSetup checked, the execution graph dose not show any of them except the 1 ms HWI ticks, albeit my application works well. Do you have an idea what could be wrong?

Thanks!

Louis

Thanks, Steve, you are the best.