SYSBIOS - SWI and EDMA callback fct not appearing in exec graph when running Audio example on OMAP-L138?

AnBer

Other Parts Discussed in Thread: SYSBIOS

Team,

I am trying to debug a problem on the C674x side Audio example (from SYSBIOS 6.3x - PSP 3.01) on the OMAP-138 EVM.

I recompiled (with CGTools 7.4.1 for elf) the EDMA and McASP BIOS driver for debug. The execution graph does show the TSK (Audio_echo_task) and SWI (Mcasp_localIsrSwiFxn() posted from the McASP HWI).
However the below thread are not shown on the exec graph/exec graph data (see enclosed picture):
        -SWI posted from Mcasp_localIsrSwiFxn():
                 mcaspIsrInput(), mcaspIsrOutput()
        - Edma callback:
                 Mcasp_localEdmaCallback()
       - SWI posted from Edma callback
              Mcasp_swiTxFifo()
even if they do run as the SW BP in those fct is hit.

- All the SWI src code and callback src code (McASP SWI, EdMA callback, SWI posted by EDMA callback) are located in the McASP driver so I don't think the problem is linked with building with debug enabled.
- In the BIOS cfg the HWI and SWI logging are enabled in RTA agent.

a) Is there something specific to setup in order to view all threads in the exec graph?
The EDMA callback code is located in the McASP driver but it is called by the EDMA driver. Does it make a difference for the exec graph point of view from which context a thread is called?

b) Exec graph shows SEM and Hwi. Is there a way to get info on which Sem and Hwi are called?

I have looked at the below wiki pages already:
http://processors.wiki.ti.com/index.php/Adding_RTA_to_Your_BIOS_6_Application
http://processors.wiki.ti.com/index.php/BIOS_6_Real-Time_Analysis_%28RTA%29_in_CCSv4
I played with the stairstep project and it is working as expected.

Thanks and best regards,

Anthony

over 12 years ago

0 Steven Connell over 12 years ago

TI__Mastermind 45025 points

Hi Anthony,

For Hwi and Swi logging, you need to build with BIOS.LibType_Custom or LibType_Debug.

AnBer said:
I recompiled (with CGTools 7.4.1 for elf) the EDMA and McASP BIOS driver for debug.

Just wondering if this had any effect on the problem you are seeing?

AnBer said:
However the below thread are not shown on the exec graph/exec graph data (see enclosed picture):

The execution graph is plotted based on the log data that's seen in the "Exec Graph Data" log. If the PSP

AnBer said:
b) Exec graph shows SEM and Hwi. Is there a way to get info on which Sem and Hwi are called?

From the BIOS User's Guide (section 8.6.3 Exec Graph):

"In this graph, square brackets “[]” indicate the beginning and end of Hwi and Swi threads. ...

These icons do not indicate which Hwi, Swi, Semaphore, or Event instance the brackets and flags refer
to. For this information, group the Exec Graph with the Raw Logs view (they are grouped by default).
Then you can click anywhere on the Exec Graph to jump to the corresponding Raw Log record."

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

Steve

0 AnBer over 12 years ago in reply to Steven Connell

TI__Mastermind 30110 points

Thanks Steven.

Steven Connell said:
For Hwi and Swi logging, you need to build with BIOS.LibType_Custom or LibType_Debug.

Steven Connell said:
Can you please attach your application's *.cfg file?

Enclosed is my latest .cfg file (renamed as .txt).
I added/changed manually the following:
BIOS.libType = BIOS.LibType_Debug;
GIO.common$.diags_INTERNAL = Diags.RUNTIME_ON;
It seems that this last line does make some changes as the .out file is bigger and the .map file does show a different mapping (see map.txt and mapv1.txt).
But I still no changes from before, I still do not get all the SWI/Thread in the exec graph.

Steven Connell said:

From the BIOS User's Guide (section 8.6.3 Exec Graph):

"In this graph, square brackets “[]” indicate the beginning and end of Hwi and Swi threads. ...

These icons do not indicate which Hwi, Swi, Semaphore, or Event instance the brackets and flags refer
to. For this information, group the Exec Graph with the Raw Logs view (they are grouped by default).
Then you can click anywhere on the Exec Graph to jump to the corresponding Raw Log record."

The link between the Raw logs and Exec graph Data/Exec graph is clear now but were are the thread names (see red circle of my previous picture) that are displayed in the graph coming from?
Sometimes those name get displayed before the application run (so Exec grap data buffer is empty at this time).
I think that a name appear once the fct get run at least once but sometimes it is not the case.
For example when running the stairstep project I had the Audio_echo_Task() name being displayed too....

Thanks and best regards,

Anthony

0 AnBer over 12 years ago in reply to AnBer

TI__Mastermind 30110 points

Map file enclosed now.

map.zip

0 AnBer over 12 years ago in reply to AnBer

TI__Mastermind 30110 points

Some updates:

I added the below in my .cfg file and now I start to see some swi on the exec graph:
var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
var SyncSwi = xdc.useModule('ti.sysbios.syncs.SyncSwi');

I am wondering why those definition were not automatically added when selecting the different options in the RTA agent - Module settings.

The EDMA callback fct still does not seem to be shown. May be it is because it is a callback fct and called from a specific context (it is called from the EDMA driver even if the code is in the McASP driver).
Also the SWI posted from the EDMA callback does not appear but it might not be called. I need to investigate further.

0 AnBer over 12 years ago in reply to AnBer

TI__Mastermind 30110 points

The SWI posted from the EDMA callback is really called. The SW BP is hit as shown as in the enclosed picture. But the SWI does not appear in the exec graph.

I think it is because the SWI is posted from the EDMA callback context that is called from the EDMA Hwi context (see enclosed picture from EDMA driver guide).
I guess that from the exec graph point of view the only way to identify the end of the EDMA job is to look at the Hwi entries.

Or is there a way to instrument the code in a simple way so that we can visualize both EDMA callback and swi posted by callback?

Thanks in advance,

screenshot.zip

0 Steven Connell over 12 years ago in reply to AnBer

TI__Mastermind 45025 points

Anthony,

Can you try removing the following lines?

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

The Agent module sets all this up. There's may be a conflict in the LoggerBuf names if the user also installs a logger.

Steve

I kinda think thesee lines are a bad idea:

* Create and install logger for the whole system

var loggerBufParams = new LoggerBuf.Params();

loggerBufParams.numEntries = 32;

var logger0 = LoggerBuf.create(loggerBufParams);

Defaults.common$.logger = logger0;

The Agent module sets all this up. There's probably a conflict in the LoggerBuf names if the user also installs a logger..

0 AnBer over 12 years ago in reply to Steven Connell

TI__Mastermind 30110 points

Thanks Steven,

Just to give some feedback.
- For the audio example I think that at the end the default .cfg file created when importing the project was ok. I was expecting to see some thread that did not run.

- Also I was looking at a modified version of the Audio example too were SyncSwi were used for GIO so
var SyncSwi = xdc.useModule('ti.sysbios.syncs.SyncSwi');
was needed.

- The EDMA callback is really called from the HWI context. I can see it by adding some Log_info0() statement in the Mcasp_localEdmaCallback() src code.
By looking at the time stamps from Printf logs and the time stamps from Exec graph/Raw logs I can see that Mcasp_localEdmaCallback() is run within the HWI.

- One thing I am not sure is the meaning of:
GIO.common$.diags_INTERNAL = Diags.RUNTIME_ON;
GIO.common$.diags_INTERNAL = Diags.RUNTIME_OFF;
I was not able to find info on what it refers too.

0 Steven Connell over 12 years ago in reply to AnBer

TI__Mastermind 45025 points

AnBer said:
- One thing I am not sure is the meaning of:
GIO.common$.diags_INTERNAL = Diags.RUNTIME_ON;
GIO.common$.diags_INTERNAL = Diags.RUNTIME_OFF;
I was not able to find info on what it refers too.

The XDC module "xdc.runtime.Defaults" contains a common$ variable that's "common" to all modules. It contains default values for all modules *unless* a given module overrides the common$ object with its own values.

This is the case above. The GIO module is overriding the xdc.runtime.Defaults values with its own value (i.e. enabling diagnostics for the GIO module).

Here's some excerpts from the XDCtools help:

module xdc.runtime.Defaults

This module defines default values for common$ structure. If other modules do not set common$ properties explicitly, these values will be used.

DIAGS_INTERNAL

Enables internal asserts. Default is ALWAYS_OFF. When set to ALWAYS_ON, requires diags_ASSERT to be ALWAYS_ON.

Steve

Processors

Processors forum

SYSBIOS - SWI and EDMA callback fct not appearing in exec graph when running Audio example on OMAP-L138?