When set to false, Assert checking code is removed from the final compiled kernel. This option can considerably improve runtime performance as well as significantly reduce the application's code size.

The application gets to determine the type of gate (lock) that is used in the TI RTS library. The gate will be used to guarantee re-entrancy of the RTS APIs.

The type of gate depends on the type of threads that are going to be calling into the RTS library. For example, if both Swi and Task threads are going to be calling the RTS library's printf, GateSwi should be used. In this case, Hwi threads are not impacted (i.e. disabled) during the printf calls from the Swi or Task threads.

If NoLocking is used, the RTS lock is not plugged and re-entrancy for the TI RTS library calls are not guaranteed. The application can plug the RTS locks directly if it wants.

Numerous gate types are provided by SYS/BIOS. Each has its advantages and disadvantages. The following list summarizes when each type is appropriate for protecting an underlying non-reentrant RTS library.

• GateHwi: Interrupts are disabled and restored to maintain re-entrancy. Use if only making RTS calls from a Hwi, Swi and/or Task.

• GateSwi: Swis are disabled and restored to maintain re-entrancy. Use if only making RTS calls from a Swi and/or Task.

• GateMutex: A single mutex is used to maintain re-entrancy. Use if only making RTS calls from a Task. Blocks only Tasks that are also trying to execute critical regions of RTS library.

• GateMutexPri: A priority inheriting mutex is used to maintain re-entrancy. Blocks only Tasks that are also trying to execute critical regions of RTS library. Raises the priority of the Task that is executing the critical region in the RTS library to the level of the highest priority Task that is block by the mutex.

The default value of rtsGateType depends on the type of threading model enabled by other configuration parameters. If taskEnabled is true, GateMutex is used. If swiEnabled is true and taskEnabled is false: GateSwi is used. If both swiEnabled and taskEnabled are false: xdc.runtime#GateNull is used.

If taskEnabled is false, the user should not select GateMutex (or other Task level gates). Similarly, if taskEnabled and swiEnabledare false, the user should not select GateSwi or the Task level gates.

Valid options include the following:

Specifies the type of heap to use for the system heap. The system heap is used to allocate instance object state structures, such as Task objects and their stacks, Semaphore objects, etc.

If set to "HeapCallback" the user must also configure the HeapCallback module with the necessary callback functions. HeapCallback_create() will be called at initialization time with a NULL HeapCallback_Params argument.

If set to "HeapUser", no system heap will not be created at startup. The user can create a heap at runtime and use the Memory_setDefaultHeap() API to register the heap with the Memory module. Or, you can use this option for applications that do not require a heap.

Valid options include the following:

If the BIOS.heapType configuration parameter is set to "HeapMin" or "HeapMem", and the BIOS.heapBaseAddr and BIOS.heapEndAddr are not set, then the system heap will be created with this size.

The BIOS.heapBaseAddr configuration parameter defines the base address of the system heap. A symbol from the linker command file is often used for this parameter.

The BIOS.heapEndAddr configuration parameter defines the end address of the system heap. A symbol from the linker command file is often used for this parameter.

This configuration parameter will add a HeapTrack instance on top of the system heap. HeapTrack adds a tracker packet to every allocated buffer and displays the information in RTOS Object Viewer (ROV). An assert will be raised on a free if there was a buffer overflow.

The following behaviors occur when taskEnabled is set to false:

• Static Task creation will result in a fatal build error.
• The Idle task object is not created. (The Idle functions are invoked within the start() thread.)
• Runtime calls to Task_create will trigger an assertion violation via xdc.runtime.Assert#isTrue.

The following behaviors occur when swiEnabled is set to false:

• Static Swi creation will result in a fatal build error.
• Runtime calls to Swi_create will trigger an assertion violation via xdc.runtime.Assert#isTrue.
• See other effects as noted for clockEnabled = false;

The following behaviors occur when clockEnabled is set to false:

• Static Clock creation will result in a fatal build error.
• No Clock Swi is created.
• The Clock_tickSource is set to Clock_TickSource_NULL to prevent a Timer object from being created.
• For APIs that take a timeout, values other than NO_WAIT will be equivalent to WAIT_FOREVER.

When set to false, all Log code is removed from the final compiled kernel. This option can considerably improve runtime performance as well as significantly reduce the application's code size.

Warning: When logs are generated, this setting will have the side effect of requiring task stacks to be sized large enough to absorb two interrupt contexts rather than one. See the discussion on task stacks in Task for more information.

If set to true, Module_create() and Module_delete() are callable at runtime. Resources for these will be allocated on the heap. If false, Module_create() and Module_delete() are not callable at runtime

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.

Like most other module configuration parameters, the Clock.tickPeriod config parameter value is accessible in runtime C code as "Clock_tickPeriod".

"Clock_TickSource_TIMER": The Clock module automatically configures a a Timer instance to drive the Clock tick.

"Clock_TickSource_USER": The Application is responsible for calling "Clock_tick()" periodically.

"Clock_TickSource_NULL": The Clock module is disabled. In this case, it is an error for the application to ever call Clock_tick().

If this parameter is not set to "Clock_TickSource_TIMER", Clock_tickStart(), Clock_tickStop(), and Clock_tickReconfig(), have no effect.

The default is "Clock_TickSource_TIMER".

Valid options include the following:

This parameter specifies the tick mode to be used by the underlying Timer.

With "Clock_TickMode_PERIODIC" the timer will interrupt the CPU at a fixed rate, defined by the tickPeriod.

With "Clock_TickMode_DYNAMIC" the timer can be dynamically reprogrammed by Clock, to interrupt the CPU when the next tick is actually needed for a scheduled timeout. "Clock_TickMode_DYNAMIC" is not supported on all devices, and may have some application constraints.

Valid options include the following:

All Clock instances are executed in the context of a single Swi. This parameter allows you to control the priority of that Swi.

The default value of this parameter is Swi.numPriorities - 1; i.e., the maximum Swi priority.

When set to 'true', a Semaphore can be configured to support task priority-based queueing.

When set to 'false', all Semaphores support only first-in, first-out task queueing.

The default for this parameter is true.

When set to 'true', a Semaphore can be configuered with an embedded Event object which will get 'posted' whenever Semaphore_post() is called.

When set to 'false' no Semaphores can be configured with embedded Event objects.

The default for this parameter is false.

The maximum number of priorities supported is target-specific and depends on the number of bits in a UInt data type. For 6x and ARM devices the maximum number of priorities is therefore 32. For the C28x, the maximum number of priorities is 16.

The maximum number of priorities supported is target specific and depends on the number of bits in a UInt data type. For 6x and ARM devices the maximum number of priorities is therefore 32. For C28x devices, the maximum number of priorities is 16.

Default is obtained from the device-aware Settings table ( ti/sysbios/family/Settings.js).

Default is obtained from the device-aware Settings table ( ti/sysbios/family/Settings.js).

See the "vitalTaskFlag" decription in the BIOS Users' Guide

This function will be called repeatedly while no tasks are ready to run.

Ordinarily (in applications that have tasks ready to run at startup), the function will run in the context of the last task to block.

In an application where there are no tasks ready to run when BIOS_start() is called, the allBlockedFunc function is called within the BIOS_start() thread which runs on the system/ISR stack.

By default, allBlockedFunc is initialized to point to an internal function that simply returns.

By adding the following lines to the config script, the Idle functions will run whenever all tasks are blocked:

Task.enableIdleTask = false;
Task.allBlockedFunc = "Idle_run";

If this flag is set to false, while the ti.sysbios.hal.Hwi#checkStackFlag is set to true, only the first byte of the stack is initialized.

This is also useful for inspection of stack in debugger or core dump utilities. Default is true.

The check consists of testing the top of stack value against its initial value (see initStackFlag). If it is no longer at this value, the assumption is that the task has overrun its stack. If the test fails, then the E_stackOverflow error is raised.

Default is true.

To enable or disable full stack checking, you should set both this flag and the ti.sysbios.hal.Hwi#checkStackFlag.

note: Enabling stack checking will add some interrupt latency because the checks are made within the Task scheduler while interrupts are disabled.

When set to true, a task is constructed that continuously calls the Idle_run() function, which, in turn calls each of the configured Idle functions.

When set to false, no Idle Task is created and it is up to the user to call the Idle_run() function if the configured Idle functions need to be run. Or, by adding the following lines to the config script, the Idle functions will run whenever all tasks are blocked:

Task.enableIdleTask = false;
Task.allBlockedFunc = "Idle_run";

By default, interrupts are disabled within certain critical sections of the task scheduler when switching to a different task thread. This default behavior guarantees that a task stack will only ever absorb ONE ISR context. Nested interrupts all run on the shared Hwi stack.

While most users find this behavior desirable, the resulting impact on interrupt latency is too great for certain applications.

By setting this parameter to 'true', the worst case interrupt latency imposed by the kernel will be reduced but will result in task stacks needing to be sized to accommodate one additional interrupt context.

If this feature is enabled, an Idle function is installed that deletes dynamically created Tasks that have terminated either by falling through their task function or by explicitly calling Task_exit().

A list of terminated Tasks that were created dynmically is maintained internally. Each invocation of the installed Idle function deletes the first Task on this list. This one-at-a-time process continues until the list is empty.

note: This feature is disabled by default.

warning: When this feature is enabled, an error will be raised if the user's application attempts to delete a terminated task. If a terminated task has already been automatically deleted and THEN the user's application attempts to delete it (ie: using a stale Task handle), the results are undefined and probably catastrophic!

Use the C pre-processor's FILE and LINE macros to add file name and line number to the output string. You can set this parameter to 'false' to save flash space on the target.

If this parameter is set to true, a software breakpoint opcode will be used to halt the processor when an Assert is raised.

You can use this parameter to decide at the configuration time what happens when an error is raised. The program can either return back to the caller, call System_abort(), or spin indefinitely.

Valid options include the following:

If set to a non-null value, the referenced function is always called when an error is raised, even if the Error policy is TERMINATE or SPIN.

By default, this function is set to Error_print which causes the error to be formatted and output via System_printf. Setting this configuration parameter to null indicates that no function hook should be called.

@see #HookFxn @see #print

If set to true, error details will be printed using System_printf(). System_printf() is a fairly big function that uses a lot of flash. You can set this parameter to false to avoid pulling in System_printf().

If set to true, error strings will be stored in the .const section which will be loaded and take up space on the target. If set to false, the error strings will be placed in a separate section .error_str section which can be be placed in a no load section that won't be loaded on the target.

Use the C pre-processor's FILE and LINE macros to add file name and line number to the output string. You can set this parameter to 'false' to save flash space on the target.

Valid options include the following:

This function is called when the application calls System_abort() function. If the user supplied funtion returns, the abort function of the ANSI C Standard library is called. For more information see the System_abort() documentation.

By default, this function is configured with a default abort function. This default abort function spins forever and never returns.

This function is called when the application calls System_exit() function. If the user supplied function returns, the ANSI C Standard Library atexit processing will be completed. For more information see the System_exit() documentation.

By default, this function is configured with a default exit function. The default exit function does nothing and returns.

This function is called when the application calls System_flush() function.

By default, this function is configured with a default flush function. The default flush function does nothing and returns.

This function is called whenever the System module needs to output a character; e.g., during System_printf() or System_putch().

By default, this function is configured with a default putch function. The default putch function drops the characters.

This function is called by the System module prior to performing any character output to check if the SystemSupport module is ready to accept the character.

By default, this function is configured with a default ready function. The default ready function returns true always.

If this parameter is set to a non-null value, the specified function will be called by System_flush() to output any characters buffered within SysMin.

For example, if you define a function named "myOutputFxn", the following configuration fragment will cause SysMin to call "myOutputFxn" whenever the character buffer is flushed. @p(code) var SysMin = scripting.addModule("/ti/sysbios/runtime/SysMin"); SysMin.outputFxn = "myOutputFxn"; @p

If this parameter is not set, a default function will be used which uses the ANSI C Standard Library function fwrite() (or HOSTwrite in the TI C Run Time Support library) to output accumulated output characters.

An internal buffer of this size is allocated. All output is stored in this internal buffer.

If 0 is specified for the size, no buffer is created, all output is dropped, and SysMin_ready() always returns false.

If the application's target is a TI target, the internal buffer is flushed via the HOSTwrite function in the TI C Run Time Support (RTS) library.

If the application's target is not a TI target, the internal buffer is flushed to stdout via fwrite(..., stdout).

Setting this parameter to false reduces the footprint of the application at the expense of not getting output when the application ends via a System_exit(), System_abort(), exit() or abort().

Module used to handle the bulk of System support functionality.

Valid options include the following:

Maximum number of System_atexit handlers set during runtime via the System_atexit() function.

This configuration parameter allows users to plug in their own abort function. By default, System_abortStd, which calls ANSI C Standard abort() is plugged in. Alternatively, System_abortSpin can be plugged which loops infinitely.

This configuration parameter allows users to plug in their own exit function. By default, System_exitStd, which calls ANSI C Standard exit() is plugged in. Alternatively, System_exitSpin can be plugged which loops infinitely.

This string specifies the set of optional argument conversion specifiers required by the application. By reducing the number of optional conversions understood by the System printf methods, it is possible to significantly reduce the code size footprint of the System module. This configuration parameter enables one to balance printf functionality against code size footprint.

The format of this string is simply a concatenated list of the desired conversion specifiers (with the leading % character). For example, to support %f, set extendedFormats to "%f".

To disable all optional converstions, set extendedFormats to null or the empty string "".

For a complete list of supported extensions, see the System_printf "Extended_Format_Specifiers" section.

Note: If an optional conversion is used by some part of the application and it is not specified in extendedFormats, the conversion character(s) and leading % are treated as ordinary characters to be output. As a result, all subsequent arguments will almost certainly be converted using the wrong conversion specifier!

Valid options include the following:

This will enable/disable the tracking of the maximum number of allocations for a HeapBuf instance. This maximum refers to the "all time" maximum number of allocations for the history of a HeapBuf instance, not the current number of allocations.

This function is called when HeapCallback_alloc() is called.

This parameter is configured with a default alloc function. The default alloc function returns NULL.

This function is called when HeapCallback_create() is called.

This parameter is configured with a default create function. The default create function returns 0.

This function is called when HeapCallback_delete() is called.

This parameter is configured with a default delete function.

This function is called when HeapCallback_free() is called.

This parameter is configured with a default free function.

This function is called when HeapCallback_getStats() is called.

This parameter is configured with a default getStats function. The default getStats function does not make any changes to stats structure.

This function is called at boot time to initialize the custom heap manager.

This parameter is configured with a default init function. The default init function is a noop and does nothing.

This function is called when HeapCallback_isBlocking() is called.

This parameter is configured with a default isBlocking function. The default isBlocking returns FALSE.

Valid options include the following:

If true, a HeapMin_E_freeError error occurs when trying to free a buffer.

If false, no error occurs and the free() does nothing.

All interrupts configured with equal or less priority (equal or higher number) than disablePriority are disabled by Hwi_disable. Interrupts configured with higher priority (smaller number) than Hwi.disablePriority are non-maskable (ie zero-latency).

The default setting is the second highest interrupt priority defined for the device (typically '0x20' for devices which support 8 priority values). This results in priority 0 (and all other values in the same priority group, ie 0x00 thru 0x1f) being the zero-latency, non-maskable interrupt priority. All other priorities are disabled with Hwi_disable().

Valid options include the following:

This value will be written to the PRIGROUP field within the NVIC's Application Interrupt and Reset Control Register (Hwi_nvic.AIRCR). It defines how the 8 bit priority values are interpreted by the hardware.

Valid options include the following:

These setting are written to Hwi_nvic.CCR at startup time.

Valid options include the following:

This is useful for inspection of the stack in the debugger or core dump utilities for stack overflow and depth. Default is true.

When set to 'true', an idle function is added to the idle loop that checks for a Hwi stack overrun condition and raises an Error if one is detected.

The check consists of testing the top of stack value against its initial value. If it is no longer at this value, the assumption is that the ISR stack has been overrun. If the test fails, then the "Hwi_E_stackOverflow" error is raised.

Default is true.

This option provides the user with the ability to optimize interrupt dispatcher performance when support for interrupt nesting is not required.

warning: Setting this parameter to false will disable interrupts during the execution of your Hwi functions.

This option provides the user with the ability to optimize interrupt dispatcher performance when it is known that Swis will not be posted from any of their Hwi threads.

warning: Setting this parameter to false will disable the logic in the interrupt dispatcher that invokes the Swi scheduler prior to returning from an interrupt. With this setting, Swis MUST NOT be posted from Hwi functions!

The default is 'true'.

This option provides the user with the ability to optimize interrupt dispatcher performance when it is known that no Task scheduling APIs (ie Semaphore_post()) will be executed from any of their Hwi threads.

warning: Setting this parameter to false will disable the logic in the interrupt dispatcher that invokes the Task scheduler prior to returning from an interrupt.

Default is 'true'.

When this is enabled, the exception handler will fully decode an exception and dump the registers to the system console.

When disabled, the exception context is only available using ROV.

The default is determined by the value of Hwi.enableException.

If the user does NOT set this parameter, then the following default behavior is followed:

If Hwi.enableException is true, then the internal 'Hwi_excHandlerMax' function is used. This exception handler saves the exception context then does a complete exception decode and dump to the console, then raises an Error. The exception context can be viewed within CCS in the ROV Hwi module's Exception view.

If Hwi.enableException is false, then the internal 'Hwi_excHandlerMin' function is used. This exception handler saves the exception context then raises an Error. The exception context can be viewed within CCS in the ROV Hwi module's Exception view.

If the user sets this parameter to their own function, then the user's function will be invoked with the following arguments:

Void myExceptionHandler(UInt *excStack, UInt lr);

Where 'excStack' is the address of the stack containing the register context at the time of the exception, and 'lr' is the link register value when the low-level-assembly-coded exception handler was vectored to.

If this parameter is set to 'null', then an infinite while loop is entered when an exception occurs. This setting minimizes code and data footprint but provides no automatic exception decoding.

Set to false to disable the Boot module from trimming the device. The device must be trimmed for proper operation. If the Boot module doesn't do this, the application must explicitly call SetupTrimDevice().

Set to true to link in the default CCFG data structure in driverlib.

If non-NULL, postUpdate is run immediately after each update.

If this parameter is set to true, an Idle function, which computes and updates the CPU load, is added to the Idle loop.

When updateInIdle is enabled, this period determines the minimum elapsed time between updates of the load statistics in the idle loop.

When this parameter is set to true, Hwi processing time is accumulated between successive calls of update and, as part of Load_update, an event with this cumulative time is logged. This time, together with the total elapsed time, is used to estimate the CPU load due to any Hwi instances run between these updates.

When this parameter is set to true, Swi processing time is accumulated between successive calls of update and, as part of Load_update, an event with this cumulative time is logged. This time together with the total elapsed time is used to estimate the CPU load due to any Swi instances run between these updates.

When this parameter is set to true, each Task's processing time is accumulated between successive calls of update and, as part of Load_update, an event with this cumulative time is logged for each task. This time together with the total elapsed time is used to estimate the CPU load due to each Task run between these updates.

If this parameter is set to true, Load_update() will calculate the CPU load for the elapsed time. In some cases, the user may prefer to use the statistics gathered by the Load module and do the CPU load calculation themself. Set this parameter to false, to disable the Load module's CPU load calculations. This can improve performance of the Load_update() call.

During CPU load measurement, the minimum time observed executing the idle loop together with the count of the number of times the idle loop runs id used to compute the total idle time. However, since the actual time spent in the idle loop will almost always be greater then the observed minimum, the idle time is almost always under estimated.

This configuration parameter can be used to compensate for this underestimate by placing a lower bound on the minimum time used in the CPU measurements. The minimum idle time used to compute CPU load is guarenteed to be greater than or equal to minIdle.