CC3220SF-LAUNCHXL: Minimize SPI overhead time (with manual CS)

I am also trying to use the RTOS Load Analysis, since it seems that the processor time in between the SPI transfers is also too long. So I would like to know what is happening at these time moment (since it differs quite a lot).

However, CCS keeps complaining that my instrumentation status is inadequate while I enabled all the modules that are required I think.

The following should be sufficient to fulfill the "REQUIRED: Enable RTOS Load Analysis - Task Load", right?

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.loadLoggerSize = 256;
LoggingSetup.mainLoggerSize = 512;
LoggingSetup.sysbiosLoggerSize = 2048;
LoggingSetup.loadLogging = true;
LoggingSetup.sysbiosTaskLogging = true;
LoggingSetup.sysbiosSwiLogging = true;
LoggingSetup.sysbiosHwiLogging = false;

Dear Michael,

Thanks for your reply. I am indeed using a GPIO controlled CS. My configuration is however slightly I noticed:

    {
        .baseAddr = GSPI_BASE,
        .intNum = INT_GSPI,
        .intPriority = (~0),
        .spiPRCM = PRCM_GSPI,
        .csControl = SPI_HW_CTRL_CS,
        .csPolarity = SPI_CS_ACTIVELOW,
        .pinMode = SPI_4PIN_MODE,
        .turboMode = SPI_TURBO_OFF,
        .scratchBufPtr = &spiCC3220SDMAscratchBuf[CC3220SF_LAUNCHXL_SPI1],
        .defaultTxBufValue = 0,
        .rxChannelIndex = UDMA_CH6_GSPI_RX,
        .txChannelIndex = UDMA_CH7_GSPI_TX,
        .minDmaTransferSize = 10,
        .mosiPin = SPICC32XXDMA_PIN_07_MOSI,
        .misoPin = SPICC32XXDMA_PIN_06_MISO,
        .clkPin = SPICC32XXDMA_PIN_05_CLK,
        .csPin = SPICC32XXDMA_PIN_NO_CONFIG

I am a little suprised that I missed the csControl flag in my code when I changed the config of csPin to NO_CONFIG. It does work with the config csControl set to hardware pin and 4 PIN mode. If I change it to software and 3PIN mode, it will probably optimized the speed slightly, since the SPI hardware tries to do the CS itself. I will try with that configuration when I am back in the office next week.

Sorry that my picture was not well explained, but 2 separate SPI transfers are shown. I was only talking about the transfer in the first CS low cycle. During this CS cycle (which is software controlled) the code that I showed before is executed (so with 2 SPI_transfer() calls). I was suprised that there was such a big gap in between them, but that is probably because of the 4PIN mode. My guess is that the SPI controller tries to set and unset the non-configured CS-pin without raising an error.  This probably explains why there is such a big gap in between the two transfers.

Maybe these changes will help me already to reach the right speed. The last thing I could think for speedup would be the DMA control. My hope would be that the program could continue preparing the next SPI transfer (so including malloc() + memcpy() calls) and eventually other tasks as well, and that a mutex before CS activation would guarantee that only 1 SPI call is done at the time. The callback would then release the SPI controller again. This would be the maximum I could get from the SPI interface, since it would be 100% utilized in that case. However I hope that this won't be necessary with the changes above.

The driverlib would not be so trivial indeed, but I also doubt if I would gain a significant speedup (seen the small function pointer implementation of the TI drivers in the SDK). I can probably better spent my time in optimizing the other parts of the code.

Regarding the logging: yes. I have BIOS.logsEnabled = true; The rest of the config is shown below:

/* ================ Clock configuration ================ */
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
/*
 * Default value is family dependent. For example, Linux systems often only
 * support a minimum period of 10000 us and multiples of 10000 us.
 * TI platforms have a default of 1000 us.
 */
Clock.tickPeriod = 1000;



/* ================ Defaults (module) configuration ================ */
var Defaults = xdc.useModule('xdc.runtime.Defaults');
/*
 * A flag to allow module names to be loaded on the target. Module name
 * strings are placed in the .const section for debugging purposes.
 *
 * Pick one:
 *  - true (default)
 *      Setting this parameter to true will include name strings in the .const
 *      section so that Errors and Asserts are easier to debug.
 *  - false
 *      Setting this parameter to false will reduce footprint in the .const
 *      section. As a result, Error and Assert messages will contain an
 *      "unknown module" prefix instead of the actual module name.
 */
//Defaults.common$.namedModule = true;
Defaults.common$.namedModule = false;



/* ================ Error configuration ================ */
var Error = xdc.useModule('xdc.runtime.Error');
/*
 * This function is called to handle all raised errors, but unlike
 * Error.raiseHook, this function is responsible for completely handling the
 * error with an appropriately initialized Error_Block.
 *
 * Pick one:
 *  - Error.policyDefault (default)
 *      Calls Error.raiseHook with an initialized Error_Block structure and logs
 *      the error using the module's logger.
 *  - Error.policySpin
 *      Simple alternative that traps on a while(1) loop for minimized target
 *      footprint.
 *      Using Error.policySpin, the Error.raiseHook will NOT called.
 *  - Error.policyMin
 *      Lightweight policy function that does minimum processing and returns.
 */
//Error.policyFxn = Error.policyDefault;
//Error.policyFxn = Error.policySpin;
Error.policyFxn = Error.policyMin;

/*
 * If Error.policyFxn is set to Error.policyDefault, this function is called
 * whenever an error is raised by the Error module.
 *
 * Pick one:
 *  - Error.print (default)
 *      Errors are formatted and output via System_printf() for easier
 *      debugging.
 *  - null
 *      Errors are not formatted or logged. This option reduces code footprint.
 *  - non-null function
 *      Errors invoke custom user function. See the Error module documentation
 *      for more details.
 */
//Error.raiseHook = Error.print;
Error.raiseHook = null;
//Error.raiseHook = "&myErrorFxn";

/*
 * If Error.policyFxn is set to Error.policyDefault, this option applies to the
 * maximum number of times the Error.raiseHook function can be recursively
 * invoked. This option limits the possibility of an infinite recursion that
 * could lead to a stack overflow.
 * The default value is 16.
 */
Error.maxDepth = 2;

/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
 * Checks for Hwi (system) stack overruns while in the Idle loop.
 *
 * Pick one:
 *  - true (default)
 *      Checks the top word for system stack overflows during the idle loop and
 *      raises an Error if one is detected.
 *  - false
 *      Disabling the runtime check improves runtime performance and yields a
 *      reduced flash footprint.
 */
//halHwi.checkStackFlag = true;
halHwi.checkStackFlag = false;

/*
 * The following options alter the system's behavior when a hardware exception
 * is detected.
 *
 * Pick one:
 *  - Hwi.enableException = true
 *      This option causes the default m3Hwi.excHandlerFunc function to fully
 *      decode an exception and dump the registers to the system console.
 *      This option raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.enableException = false
 *      This option reduces code footprint by not decoding or printing the
 *      exception to the system console.
 *      It however still raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.excHandlerFunc = null
 *      This is the most aggressive option for code footprint savings; but it
 *      can difficult to debug exceptions. It reduces flash footprint by
 *      plugging in a default while(1) trap when exception occur. This option
 *      does not raise an error with the Error module.
 */
//m3Hwi.enableException = true;
//m3Hwi.enableException = false;
m3Hwi.excHandlerFunc = null;

/*
 * Enable hardware exception generation when dividing by zero.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions when dividing by zero
 *  - 1
 *      Enables hardware exceptions when dividing by zero
 */
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;


/* ================ Idle configuration ================ */
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
/*
 * The Idle module is used to specify a list of functions to be called when no
 * other tasks are running in the system.
 *
 * Functions added here will be run continuously within the idle task.
 *
 * Function signature:
 *     Void func(Void);
 */
//Idle.addFunc("&myIdleFunc");

Idle.addFunc('&Power_idleFunc');  /* add the Power module's idle function */


/* ================ Kernel (SYS/BIOS) configuration ================ */
var BIOS = xdc.useModule('ti.sysbios.BIOS');
/*
 * Enable asserts in the BIOS library.
 *
 * Pick one:
 *  - true (default)
 *      Enables asserts for debugging purposes.
 *  - false
 *      Disables asserts for a reduced code footprint and better performance.
 */
//BIOS.assertsEnabled = true;
BIOS.assertsEnabled = false;

/*
 * A flag to determine if xdc.runtime sources are to be included in a custom
 * built BIOS library.
 *
 * Pick one:
 *  - false (default)
 *      The pre-built xdc.runtime library is provided by the respective target
 *      used to build the application.
 *  - true
 *      xdc.runtime library sources are to be included in the custom BIOS
 *      library. This option yields the most efficient library in both code
 *      footprint and runtime performance.
 */
//BIOS.includeXdcRuntime = false;
BIOS.includeXdcRuntime = true;

/*
 * The SYS/BIOS runtime is provided in the form of a library that is linked
 * with the application. Several forms of this library are provided with the
 * SYS/BIOS product.
 *
 * Pick one:
 *   - BIOS.LibType_Custom
 *      Custom built library that is highly optimized for code footprint and
 *      runtime performance.
 *   - BIOS.LibType_Debug
 *      Custom built library that is non-optimized that can be used to
 *      single-step through APIs with a debugger.
 *
 */
BIOS.libType = BIOS.LibType_Custom;
//BIOS.libType = BIOS.LibType_Debug;

/*
 * Runtime instance creation enable flag.
 *
 * Pick one:
 *   - true (default)
 *      Allows Mod_create() and Mod_delete() to be called at runtime which
 *      requires a default heap for dynamic memory allocation.
 *   - false
 *      Reduces code footprint by disallowing Mod_create() and Mod_delete() to
 *      be called at runtime. Object instances are constructed via
 *      Mod_construct() and destructed via Mod_destruct().
 */
BIOS.runtimeCreatesEnabled = true;
//BIOS.runtimeCreatesEnabled = false;

/*
 * Enable logs in the BIOS library.
 *
 * Pick one:
 *  - true (default)
 *      Enables logs for debugging purposes.
 *  - false
 *      Disables logging for reduced code footprint and improved runtime
 *      performance.
 */
BIOS.logsEnabled = true;
//BIOS.logsEnabled = false;



/* ================ Memory configuration ================ */
var Memory = xdc.useModule('xdc.runtime.Memory');
/*
 * The Memory module itself simply provides a common interface for any
 * variety of system and application specific memory management policies
 * implemented by the IHeap modules(Ex. HeapMem, HeapBuf).
 */

/*
 * Use HeapMem primary heap instance to use linker-defined memory region
 * Add HeapTrack on top to find over-writes, invalid frees, and
 * aid in finding the correct sizing of the heap and memory leaks.
 */
var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
HeapMem.primaryHeapBaseAddr = "&__primary_heap_start__";
HeapMem.primaryHeapEndAddr = "&__primary_heap_end__";

var heapMemParams = new HeapMem.Params();
heapMemParams.usePrimaryHeap = true;

var HeapTrack = xdc.useModule('ti.sysbios.heaps.HeapTrack');
var heapTrackParams = new HeapTrack.Params;
heapTrackParams.heap = HeapMem.create(heapMemParams);
Program.global.heap0 = HeapTrack.create(heapTrackParams);
//Program.global.heap0 = HeapMem.create(heapMemParams);

Memory.defaultHeapInstance = Program.global.heap0;


/* ================ Program configuration ================ */
/*
 *  Program.stack must be set to 0 to allow the setting
 *  of the system stack size to be determined in the example's
 *  linker command file.
 */
Program.stack = 0;


/*
 * Uncomment to enable Semihosting for GNU targets to print to the CCS console.
 * Please read the following TIRTOS Wiki page for more information on Semihosting:
 * processors.wiki.ti.com/.../TI-RTOS_Examples_SemiHosting
 */

if (Program.build.target.$name.match(/gnu/)) {
    //var SemiHost = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
}



/* ================ Semaphore configuration ================ */
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');
/*
 * Enables global support for Task priority pend queuing.
 *
 * Pick one:
 *  - true (default)
 *      This allows pending tasks to be serviced based on their task priority.
 *  - false
 *      Pending tasks are services based on first in, first out basis.
 *
 *  When using BIOS in ROM:
 *      This option must be set to false.
 */
//Semaphore.supportsPriority = true;
Semaphore.supportsPriority = false;

/*
 * Allows for the implicit posting of events through the semaphore,
 * disable for additional code saving.
 *
 * Pick one:
 *  - true
 *      This allows the Semaphore module to post semaphores and events
 *      simultaneously.
 *  - false (default)
 *      Events must be explicitly posted to unblock tasks.
 *
 */
//Semaphore.supportsEvents = true;
Semaphore.supportsEvents = false;


/* ================ Swi configuration ================ */
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
/*
 * A software interrupt is an object that encapsulates a function to be
 * executed and a priority. Software interrupts are prioritized, preempt tasks
 * and are preempted by hardware interrupt service routines.
 *
 * This module is included to allow Swi's in a users' application.
 */


/* ================ System configuration ================ */
var System = xdc.useModule('xdc.runtime.System');
/*
 * The Abort handler is called when the system exits abnormally.
 *
 * Pick one:
 *  - System.abortStd (default)
 *      Call the ANSI C Standard 'abort()' to terminate the application.
 *  - System.abortSpin
 *      A lightweight abort function that loops indefinitely in a while(1) trap
 *      function.
 *  - A custom abort handler
 *      A user-defined function. See the System module documentation for
 *      details.
 */
//System.abortFxn = System.abortStd;
System.abortFxn = System.abortSpin;
//System.abortFxn = "&myAbortSystem";

/*
 * The Exit handler is called when the system exits normally.
 *
 * Pick one:
 *  - System.exitStd (default)
 *      Call the ANSI C Standard 'exit()' to terminate the application.
 *  - System.exitSpin
 *      A lightweight exit function that loops indefinitely in a while(1) trap
 *      function.
 *  - A custom exit function
 *      A user-defined function. See the System module documentation for
 *      details.
 */
//System.exitFxn = System.exitStd;
System.exitFxn = System.exitSpin;
//System.exitFxn = "&myExitSystem";

/*
 * Minimize exit handler array in the System module. The System module includes
 * an array of functions that are registered with System_atexit() which is
 * called by System_exit(). The default value is 8.
 */
System.maxAtexitHandlers = 2;

/*
 * Enable System_printf() to display floats.  Use the longer '%f%$L%$S%$F'
 * if your code has SYS/BIOS instrumentation enabled (Asserts/Error/Log),
 * as is typical with the 'debug' profile.
 */
//System.extendedFormats = '%f%$L%$S%$F';
System.extendedFormats = '%f%$S';

/*
 * The System.SupportProxy defines a low-level implementation of System
 * functions such as System_printf(), System_flush(), etc.
 *
 * Pick one pair:
 *  - SysMin
 *      This module maintains an internal configurable circular buffer that
 *      stores the output until System_flush() is called.
 *      The size of the circular buffer is set via SysMin.bufSize.
 *  - SysCallback
 *      SysCallback allows for user-defined implementations for System APIs.
 *      The SysCallback support proxy has a smaller code footprint and can be
 *      used to supply custom System_printf services.
 *      The default SysCallback functions point to stub functions. See the
 *      SysCallback module's documentation.
 */
//var SysMin = xdc.useModule('xdc.runtime.SysMin');
//SysMin.bufSize = 1024;
//System.SupportProxy = SysMin;
var SysCallback = xdc.useModule('xdc.runtime.SysCallback');
System.SupportProxy = SysCallback;
//SysCallback.abortFxn = "&myUserAbort";
//SysCallback.exitFxn  = "&myUserExit";
//SysCallback.flushFxn = "&myUserFlush";
//SysCallback.putchFxn = "&myUserPutch";
//SysCallback.readyFxn = "&myUserReady";



/* ================ Task configuration ================ */
var Task = xdc.useModule('ti.sysbios.knl.Task');
/*
 * Check task stacks for overflow conditions.
 *
 * Pick one:
 *  - true (default)
 *      Enables runtime checks for task stack overflow conditions during
 *      context switching ("from" and "to")
 *  - false
 *      Disables runtime checks for task stack overflow conditions.
 */
//Task.checkStackFlag = true;
Task.checkStackFlag = false;

/*
 * Set the default task stack size when creating tasks.
 *
 * The default is dependent on the device being used. Reducing the default stack
 * size yields greater memory savings.
 */
Task.defaultStackSize = 512;

/*
 * Enables the idle task.
 *
 * Pick one:
 *  - true (default)
 *      Creates a task with priority of 0 which calls idle hook functions. This
 *      option must be set to true to gain power savings provided by the Power
 *      module.
 *  - false
 *      No idle task is created. This option consumes less memory as no
 *      additional default task stack is needed.
 *      To gain power savings by the Power module without having the idle task,
 *      add Idle.run as the Task.allBlockedFunc.
 */
Task.enableIdleTask = true;
//Task.enableIdleTask = false;
//Task.allBlockedFunc = Idle.run;

/*
 * If Task.enableIdleTask is set to true, this option sets the idle task's
 * stack size.
 *
 * Reducing the idle stack size yields greater memory savings.
 */
Task.idleTaskStackSize = 512;

/*
 * Reduce the number of task priorities.
 * The default is 16.
 * Decreasing the number of task priorities yield memory savings.
 */
Task.numPriorities = 16;



/* ================ Text configuration ================ */
var Text = xdc.useModule('xdc.runtime.Text');
/*
 * These strings are placed in the .const section. Setting this parameter to
 * false will save space in the .const section. Error, Assert and Log messages
 * will print raw ids and args instead of a formatted message.
 *
 * Pick one:
 *  - true (default)
 *      This option loads test string into the .const for easier debugging.
 *  - false
 *      This option reduces the .const footprint.
 */
//Text.isLoaded = true;
Text.isLoaded = false;



/* ================ Types configuration ================ */
var Types = xdc.useModule('xdc.runtime.Types');
/*
 * This module defines basic constants and types used throughout the
 * xdc.runtime package.
 */



/* ================ Application Specific Instances ================ */

/* ================ Diagnostics configuration ================ */
//var Diags = xdc.useModule('xdc.runtime.Diags');
/*
 * You use the Diags module to set and clear bits in a module's diagnostics
 * mask for the purpose of controlling diagnostics within that module. A
 * module diagnostics mask controls both Assert and Log statements
 * within that module, disabling these statements yields
 * code savings.
 */

/* ================ Logging configuration ================ */
//var Log = xdc.useModule('xdc.runtime.Log');
/*
 * Modules and the application code generate Log_Event events by calling
 * the Log module's functions.
 * Disabling all Log statements here will allow the optimizer to completely
 * remove all Log code from the application.
 *
 * Note: In order to generate Log events in your application both the Diags
 *       and the Log mask must be set. See the SYS/BIOS API guide for
 *       more information.
 */

/*
 * LoggingSetup configures TI-RTOS modules to capture user-specified information
 * such as CPU Load, Task Load and Task Execution so that it can be
 * displayed by System Analyzer.
 */
//var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
//LoggingSetup.loadLoggerSize = 256;
//LoggingSetup.mainLoggerSize = 512;
//LoggingSetup.sysbiosLoggerSize = 1024;

/* ================ Main configuration ================ */
var Main = xdc.useModule('xdc.runtime.Main');
/* Configuration of this Main module is used for all code not in a module */

/* ================ POSIX configuration ================ */
var Settings = xdc.useModule('ti.posix.tirtos.Settings');

/* ================ Event configuration ================ */
var Event = xdc.useModule('ti.sysbios.knl.Event');

/* ================ Mailbox configuration ================ */
var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox');

/* ================ Logging configuration ================ */
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.sysbiosLoggerSize = 1024;
LoggingSetup.loadLogging = false;

Best regards,
MJ

Dear Michael,

Thanks for your advice. Tomorrow I will test the CS software changes, so I will hope that will be enough.
To optimize the rest of the execution: Could you help me out why I can't open the load analyser? My config filed is added in my previous post. I think I have turned on almost all logging possibilites, but still says that that Task Load should be enabled.

Regards,
MJ

I just did the testing with 3 PIN SPI and Software CS control, and now the large gap between two consecutive SPI_transfer() calls has disappeared. A malloc call is therefore not needed anymore, which speeds up the total write SPI command.
During debugging I also noticed that the transceiver that is connected should have plenty of time with such high SPI speeds. I am now asking the manufacturer of the transceiver what could be the cause.

As mentioned in the previous post: I am still interested in analyzing the Task load, so it would be great if you could help me out with that.

Regards,
MJ