How to build Tutorial4C for the C66X

How to build the Tutorial 4C project for the C66X

under construction...

The Tutorial 4C project for the C66X leverages the components and framework provided by MCSDK 2.X, and uses the same approach that is used by the <MCSDK 2.x Install Dir>\demos\image_processing\ipc\evmc6678l demo, which splits processing into two projects: a master project that handles the network protocol stack and runs on CPU 0, and a slave project that runs on CPUs 1-7, and uses IPC for communication with CPU 0.

Two Tutorial 4C projects for C66X (one for the master project and one for the slave) can be created by unzipping the Media:SystemAnalyzer_Tutorial4C_66X.zip file into a temporary directory and importing the projects into CCS (check the "Copy projects into your workspace" checkbox).

Here's how the projects look once they have been imported into CCS:

Let's take a look at how these two projects are constructed.

Master CPU Project

The Master CPU is responsible for the initialization of the device upon startup, for running the network stack, and for routing messages to the various 'slave' CPU cores.

The initialization code that is run is provided in evmInit.c, and is invoked as part of the BIOS startup functions by the following configuration script entry:

Startup.firstFxns.$add('&EVM_init');

In MCSDK 2.X, the network protocol stack is provided by the NDK package, which is included as part of the "Low Level Driver" (LLD) suite of packages. The LLD handles many of the details associated with the use of the hardware queues that are provided by the C66X architecture, including resource management and packet assembly.

MCSDK 2.X also supplies a Chip Support Library and Platform Development Kit that supports the C66X family. The following configuration script is included in the message.cfg file in order to use these technologies in the Master CPU's project.

/* Load the PDK packages */
var Csl  = xdc.useModule('ti.csl.Settings');
var Pa   = xdc.useModule('ti.drv.pa.Settings');
var Cppi = xdc.loadPackage('ti.drv.cppi');     
var Qmss = xdc.loadPackage('ti.drv.qmss');

/* Load the Platform/NDK Transport packages */
var PlatformLib  = xdc.loadPackage('ti.platform.evmc6678l');
var NdkTransport = xdc.loadPackage('ti.transport.ndk');

The LLD packages require the application to implement some hook functions for resource manager and OSAL implementation These hook functions are provided by the files resourcemgr.c, platform_osal.c and netCtrlCallbackFns.c . (See link http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Platform_Development_Kit_.28PDK.29 for more info).

The "Event Combiner Module" (ECM) that is provided by sysbios is used to support interrupt management on the C66X device. The associated .cfg script is shown below:

var Ecm       = xdc.useModule('ti.sysbios.family.c64p.EventCombiner');

/*
 * Enable Event Groups here and registering of ISR for specific GEM INTC is done
 * using EventCombiner_dispatchPlug() and Hwi_eventMap() APIs
 */

Ecm.eventGroupHwiNum[0] = 7;
Ecm.eventGroupHwiNum[1] = 8;
Ecm.eventGroupHwiNum[2] = 9;
Ecm.eventGroupHwiNum[3] = 10;
 

A "main" task thread is provided that handles the network stack. this thread calls a function named "master_main" which is located in the netCtrlCallbackFns.c file. Here is the configuration script that sets up the task for this function:

/* Create the task used for the master CPU operations (see netCtrlCallbackFns.c)  */
var tskMainThread        =  Task.create("&master_main");
tskMainThread.stackSize  = 0x2000;
tskMainThread.priority   = 0x5;
tskMainThread.instance.name = "master_main";

The same 'single image' message.c file that was described in the Tutorial 4C description is used for the application as is used in the C647X case. The configuration script that is needed to set up UIA's service manager and the IPC and MasterProc modules is quite similar to that described in Tutorial 4C:

/* Load and configure the IPC packages */
var MessageQ     = xdc.useModule('ti.sdo.ipc.MessageQ');
var Ipc          = xdc.useModule('ti.sdo.ipc.Ipc');
var HeapBufMP    = xdc.useModule('ti.sdo.ipc.heaps.HeapBufMP');
var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion');
var MultiProc    = xdc.useModule('ti.sdo.utils.MultiProc');

MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2", "CORE3", "CORE4", "CORE5", "CORE6", "CORE7"]);

/* Synchronize all processors (this will be done in Ipc_start) */
Ipc.procSync = Ipc.ProcSync_ALL;

/* Shared Memory base address and length */
var SHAREDMEM           = 0x0c200000;
var SHAREDMEMSIZE       = 0x00200000;

SharedRegion.setEntryMeta(0,
    { base: SHAREDMEM, 
      len:  SHAREDMEMSIZE,
      ownerProcId: 0,
      isValid: true,
      name: "MSMCSRAM_IPC",
    });

/*
 *  This example is a multi-core example, so UIA's ServiceMgr 
 *  must be configured to collect events from multiple cores.
 */ 
var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.topology = ServiceMgr.Topology_MULTICORE;
ServiceMgr.masterProcId = 0;
ServiceMgr.transportType = ServiceMgr.TransportType_ETHERNET;

The LoggingSetup configuration is the same as that used by the Slave project, and will be described in that section.

Configuring the Master project's build options

To access the master project's build options, right click on the project in the CCS Project Explorer and select Build Options.

1) Ensure that the TI_MCSDK_INSTALL_DIR build variable is properly defined.

• In the CCS Build Options, click on "CCS Build" in the left hand pane, and then click on the Build Variables tab. Check the "Show system variables" checkbox to show all defined variables. If there is no entry for TI_MCSDK_INSTALL_DIR click on the Add button to add a new variable. If the variable exists but is incorrectly configured, click on the Edit button to change it.

2) Add the MCSDK 2.X install dir to the RTSC repositories that are used by the project. This allows us to use the platform file that is provided with the MCSDK 2.X installation for our project.

• In the CCS Build Options, click on "General" in the left hand pane, and then click on the RTSC tab.
• Click the "Add..." button to add the MCSDK 2.X install dir as a RTSC package, using the build variable we defined in the previous step:
  

3) Select the packages and platform file that are to be used by the Master project:

4) Add paths to the MCSDK 2.X include files

• In the CCS Build Options, click on CCS Build / C6000 Compiler

• Under C6000 Compiler, select "Include Options"

(Note: unlike the C647X projects, there are no special build variables or library files that need to be referenced. The .cfg script pulls in the libraries that are needed via "xdc.loadPackage" statements.

Slave CPU Project

Since the Slave CPUs do not have to support the network stack or initialize the device, the project code and configuration script is much simpler subset of that used by the Master CPU project.

One of the differences between the master and slave configuration scripts is the way the ServiceMgr is configured. Here's the Slave CPU .cfg script that configures the ServiceMgr:

/* ================ UIA configuration ================ */
/*
 *  This example is a multi-core example, so UIA's ServiceMgr 
 *  must be configured to collect events from multiple cores.
 */ 
var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.topology = ServiceMgr.Topology_MULTICORE;
ServiceMgr.masterProcId = 0;
/* For releases earlier than UIA_1_00_02_35, change the next line to 
ServiceMgr.transportType = ServiceMgr.TransportType_FILE;
*/
ServiceMgr.transportType = ServiceMgr.TransportType_NULL; 

The key difference is that the transportType has changed from TransportType_ETHERNET to TransportType_NULL (or TransportType_FILE for older versions of the UIA package). The ServiceMgr for both the master and slave CPUs use MessageQ for inter-processor communication.

The LoggingSetup configuration controls which SysBios modules are to log events and specifies the various logger buffer sizes to be used. Because we are dealing with devices that have multiple CPU cores, we need to disable any events that are not needed for analysis and configure larger logger buffer sizes in order to minimize the amount of data that is dropped. Here's the .cfg script that the Tutorial 4C C66X projects use:

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
/* Enable logging of events from non-XDC code and increase the main logger size: */
LoggingSetup.mainLogging = true;
LoggingSetup.mainLoggerSize = 8*1024;

/* Increase the sysbios logger size and turn Hwi and Swi logging off */
LoggingSetup.sysbiosTaskLogging = true;
LoggingSetup.sysbiosSwiLogging = false;
LoggingSetup.sysbiosHwiLogging = false;
LoggingSetup.sysbiosLoggerSize = 140*1024;

/* Turn off load logging to reduce event throughput */
LoggingSetup.loadLogging = false;
/* If you want to enable load logging, the following lines
 * show how to configure the logger size and the period of the
 * load measuements: 
LoggingSetup.loadLoggerSize = 32768;
Load.windowInMs = 100;
*/

/* The overflow logger captures dropped events so that a minimum number of events are always 
 * guaranteed to be captured leading up to a breakpoint.  For remote access situations,
 * you can save memory by setting the size of this logger to 0. */
LoggingSetup.overflowLoggerSize = 0;
LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_NONJTAGTRANSPORT;

Memory Partitioning

How to load and run:

Group slave cores together. Reset Master CPU core: system reset, then reset.