Introduction¶
Purpose¶
Sensor Controller Studio is used to write, test and debug code for the CC26xx/CC13xx Sensor Controller. The tool generates a Sensor Controller Interface driver, which is a set of C source files to be compiled into the System CPU (ARM Cortex-M3/M4/M33) application. These source files contain the Sensor Controller firmware image and associated definitions, and generic functions that allow the System CPU application to control the Sensor Controller and exchange data.
The Sensor Controller is a small CPU core that is highly optimized for low power consumption and efficient peripheral operation. The Sensor Controller is located in the CC26xx/CC13xx auxiliary (AUX) power/clock domain, and can perform simple background tasks autonomously and independently of the System CPU and the MCU domain power state. Such tasks include but are not limited to:
- Analog sensor polling, using ADC or comparator
- Digital sensor polling, using SPI, I2C or other protocols
- Capacitive sensing, using current source, comparator and time-to-digital converter (TDC)
- Waveform generation, for example for LCDs
The Sensor Controller is user programmable, using a simple programming language with syntax similar to C. This allows for sensor polling and other tasks to be specified as sequential algorithms, rather than static configuration of complex peripheral modules, timers, DMA, register programmable state machines, event routing and so on. The main advantages are:
- Flexibility
- Dynamic reuse of hardware resources
- Ability to perform simple data processing without need for dedicated hardware
- Observability and debugging options
For example, the following code samples an analog sensor and notifies the System CPU application if needed:
// Select ADC input
adcSelectGpioInput(AUXIO_A_SENSOR_OUTPUT);
// Enable the ADC (fixed reference, 2.7 us sample time, manual trigger)
adcEnableSync(ADC_REF_FIXED, ADC_SAMPLE_TIME_2P7_US, ADC_TRIGGER_MANUAL);
// Sample the sensor and store the ADC value
adcGenManualTrigger();
adcReadFifo(output.adcValue);
// Disable the ADC
adcDisable();
// Notify the application if above the threshold
if (output.adcValue > SENSOR_THRESHOLD) {
fwGenAlertInterrupt();
}
The Sensor Controller task algorithms can efficiently be evaluated, debugged and verified using Sensor Controller Studio. The resulting Sensor Controller Interface driver can be treated as a black box, and can be integrated painlessly into the System CPU application.
There is a Command Line Interface that can be used for build automation.
Sensor Controller and AUX Domain Hardware Overview¶
Sensor Controller Studio supports the CC13x0/CC26x0, CC13x2/CC26x2 and CC13x4/CC26x4 chip families.
Hardware Functionality¶
The Sensor Controller is located in the CC13xx/CC26xx AUX domain, and has access to hardware functionality located in the AUX domain.
The Sensor Controller has, with few exceptions, no access to peripherals, RAM, flash or registers in the MCU and AON domains. This separation allows the MCU domain to enter and exit standby mode independently of the Sensor Controller. The System CPU has access to all AUX domain peripherals.
The AUX domain hardware functionality is listed in the table below:
| Hardware functionality | CC13x0/CC26x0 | CC13x2/CC26x2 and CC13x4/CC26x4 |
| AUX domain / Sensor Controller | ||
| Sensor Controller Engine (power-optimized 16-bit CPU core) | Yes | Yes |
| AUX RAM (Sensor Controller instruction and data memory) | 2 KB = 1024 x 16-bit words | 4 KB = 2048 x 16-bit words |
| Programmable wake-up sources | 1 | 3 |
| Wake-up from AON_RTC channel 2 | Yes | Yes |
| Analog peripherals | ||
| ADC (12-bit, 200 kHz analog to digital converter) | Yes | Yes |
| COMPA (continuous time comparator) | Yes | Yes, improved |
| COMPB (low-power clocked comparator) | Yes | Yes, improved |
| ISRC (0 to 20 uA current source) | Yes | Yes |
| Reference DAC (8-bit DAC for COMPA/COMPB reference) | Yes | |
| Digital peripherals | ||
| TDC (96 MHz time to digital converter) | Yes | Yes |
| Pulse counter (16-bit asynchronous) | Yes | Yes, improved |
| Timer 0 (synchronous timer) | Yes, 16-bit | Yes, 16-bit, improved |
| Timer 1 (synchronous timer) | Yes, 8-bit | Yes, 16-bit, improved |
| Timer 2 (16-bit asynchronous PWM/sequencing timer) | Yes | |
| Microsecond delay timer | Yes | |
| AUX I/O controllers (8 pins each) | 2 | 4 |
| Hardware semaphores (for peripheral sharing with System CPU) | 8 | 8 |
| Multiply and accumulate accelerator (40-bit accumulator) | Yes | |
| Serial interfaces | ||
| SPI (serial peripheral interface) | Bit-banged | Yes, hardware peripheral |
| I2C master (400 kHz or 100 kHz) | Bit-banged | Bit-banged |
| I/O pins | ||
| Analog and digital capable general-purpose I/O pins | Up to 8 | Up to 8 |
| Digital-only general-purpose I/O pins | Up to 8 | Up to 24 |
| System | ||
| Observation signal output (AUX event bus signal to GPIO) | 1 | |
| AON_BATMON read access (temperature and voltage) | Yes | |
| AON_RTC read access (16-bit second, 16-bit subsecond) | Yes | |
| MCU domain and power supply system status | Yes | |
| VDDR recharge status and interaction | Yes | |
See the Chip Family Migration Guide for detailed overview of the differences between the chip families.
See the Assembly Language Reference for detailed technical information about the Sensor Controller Engine CPU core.
For the CC13x4/CC26x4 chip family, the Sensor Controller has restricted access to AUX_DDI0_OSC registers. The device startup code provided by TI (setup.c / driverlib.lib) enables access permissions needed for COMPB and TDC.
Power and Clock Management¶
The below sections describe for each device family the available power modes, and clock frequencies in each power mode depending on the System CPU state.
The main improvements in the CC13x2/CC26x2 and CC13x4/CC26x4 device family are:
- 2 MHz clock generated by RCOSC MF
- Low-power mode (power supply system off, some analog/digital peripherals are unavailable)
- Faster wake-up times
CC13x0/CC26x0 Operation Modes¶
The Sensor Controller is in active mode when running task code, and in standby mode otherwise.
The Sensor Controller firmware framework, which is integrated in the generated driver, handles the transitions into and out of standby mode autonomously.
All peripheral modules are available in active mode, unless they are used by the System CPU. A small number of peripherals can be used in standby mode to trigger Sensor Controller wake-up.
The table below shows the Sensor Controller / AUX domain clock source and frequency for the different modes of operation:
| Sensor Controller / AUX domain operation state | Frequency and source | System CPU / MCU domain active | System CPU / MCU domain standby |
| Active | Sensor Controller clock: | 24 MHz (SCLK_HF / 2) | 24 MHz (SCLK_HF / 2) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 24 MHz (SCLK_HF / 2) | |
| Standby with event trigger | Sensor Controller clock: | 24 MHz (SCLK_HF / 2) | 32 kHz (SCLK_LF) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 32 kHz (SCLK_LF) | |
| Standby without event trigger | Sensor Controller clock: | 24 MHz (SCLK_HF / 2) | No clock |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | No clock |
CC13x2/CC26x2 and CC13x4/CC26x4 Operation Modes¶
The Sensor Controller is in active mode or low-power mode when running task code, and in standby mode otherwise.
The Sensor Controller firmware framework, which is integrated in the generated driver, handles the transitions into and out of standby mode autonomously.
The Sensor Controller configuration and task code can trigger transitions between the active and low-power modes. The Sensor Controller wakes up to the power mode that was used when it entered standby.
All peripheral modules are available in active mode, unless they are used by the System CPU. Peripheral modules that require active mode (SCLK_HF and/or other system functionality) are not available in low-power mode. A small number of peripherals can be used in standby mode to trigger Sensor Controller wake-up.
A complete overview of peripheral availability and clock sources is given in:
- The Power and Clock Settings Panel document
- The Dynamic Power Control resource description
The table below shows the Sensor Controller / AUX domain clock source and frequency for the different modes of operation:
| Sensor Controller / AUX domain operation state | Frequency and source | System CPU / MCU domain active | System CPU / MCU domain standby |
| Active with Sensor Controller at 24 MHz | Sensor Controller clock: | 24 MHz (SCLK_HF / 2) | 24 MHz (SCLK_HF / 2) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 24 MHz (SCLK_HF / 2) | |
| Active with Sensor Controller at 2 MHz | Sensor Controller clock: | 2 MHz (derived from SCLK_HF / 2) | 2 MHz (derived from SCLK_HF / 2) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 24 MHz (SCLK_HF / 2) | |
| Low-power | Sensor Controller clock: | 2 MHz (derived from SCLK_HF / 2) | 2 MHz (SCLK_MF) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 2 MHz (SCLK_MF) | |
| Standby with Timer 0/1 event trigger | Sensor Controller clock: | 32 kHz (derived from SCLK_HF / 2) | 32 kHz (SCLK_LF) |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | 32 kHz (SCLK_LF) | |
| Standby without Timer 0/1 event trigger | Sensor Controller clock: | No clock | No clock |
| AUX bus clock: | 24 MHz (SCLK_HF / 2) | No clock |
Communication with the System CPU Application¶
The Sensor Controller tasks and System CPU application exchange data through shared memory in the AUX RAM. Sensor Controller Studio generates type definitions and other needed definitions for easy access to these variables.
A pair of event signals is used by the Sensor Controller Interface driver to control the Sensor Controller tasks:
- To Sensor Controller: CTRL initiates a control operation that starts or stops Sensor Controller tasks
- From Sensor Controller: READY indicates that the control interface is idle and ready for another control operation
Another pair of event signals is used by the Sensor Controller to notify the System CPU and exchange data:
- From Sensor Controller: ALERT wakes up the System CPU if currently in standby mode, and generates a callback (interrupt)
- To Sensor Controller: ACK indicates that the System CPU has handled the last alert and is ready for another
The event signalling is handled internally by the Sensor Controller Interface driver and the Sensor Controller firmware framework, but is exposed to the application through function calls and callbacks.
Sensor Controller Interface Driver¶
The generated Sensor Controller Interface driver (SCIF) consists of three pairs of C header and source files that are used in the application running on the System CPU. The driver includes:
- The driver setup, containing:
- The AUX RAM image (containing machine code and data for the Sensor Controller)
- Data structure definitions (for easy access to Sensor Controller configuration, state and input/output data)
- Constant definitions (matching relevant constants used in the Sensor Controller code)
- I/O mapping, task data structure information and other parameters for driver internal use
- A generic application programming interface (API) for:
- Initializing the driver (including I/O pin configuration and event routing)
- Task control (for starting, stopping and manually executing Sensor Controller tasks)
- Task data exchange (for producing input data to and consume output data from Sensor Controller tasks)
- Uninitializing the driver (allowing the application to switch SCIF driver setup)
- An operating system abstraction layer (OSAL) that:
- Ensures seamless integration with the selected operating system, for example TI-RTOS
- Ensures seamless integration with the power and clock management framework running on the System CPU
Tailored How-To-Use Guide¶
For the generated SCIF driver, Sensor Controller Studio also outputs a tailored how-to-use guide (HTML document).
The guide is divided into two main sections:
- Getting Started: Basic steps to add the SCIF driver to the System CPU application.
- Further Integration: Detailed task control, other SCIF driver features, and helpful information.
The guide contains only relevant information for each generated SCIF driver.
The guide contains code snippets that can be copied and pasted directly into the application source code.
Doxygen Documentation¶
The SCIF driver header and source files are documented using Doxygen syntax. This documentation includes project-specific information, such as names, descriptions, I/O mapping overview, constants and task data structures.
For the generated SCIF driver, Sensor Controller Studio outputs a doxyfile (that is, a project file for Doxygen), and a Windows batch file for running Doxygen on this SCIF driver.
Sensor Controller Programming Model¶
Sensor Controller Studio is project based. All data associated with a Sensor Controller project is stored in a single file (*.scp). Each project may contain up to eight Sensor Controller tasks, for example capacitive sensing and ADC measurement. The output of a project is a single SCIF driver.
The task code programming language uses a syntax that is similar to C, but has limited features compared to C since it specifically targets the Sensor Controller Engine’s instruction set and architecture. For example, there is only support for 16-bit variables.
Hardware peripherals and software algorithms are available as resources . For each task, a set of resources must be selected and configured to enable different types of functionality such as:
- Analog and digital peripheral modules (for example ADC)
- Analog and digital general purpose I/O pins
- Simple and complex software algorithms
- Bit-banged serial interfaces
- Task scheduling and event handling
- Communication with the System CPU
Each task resource enables a set of procedures (equivalent to functions in C), with associated constants and variables. The task code can call these procedures to access hardware modules, firmware framework features and optimized software algorithms.
It is possible to add user-specified constants and variables, which can be linked to resource configuration values (for example the number of ADC input pins).
The programming model and firmware framework are optimized for low overhead when communicating with the System CPU application, low AUX RAM memory footprint, and efficient use of the Sensor Controller’s instruction set. To minimize power consumption the Sensor Controller enters standby mode automatically when it is idle.
Sensor Controller Tasks¶
A Sensor Controller task consists of the following components:
- Resources, with associated configurations, procedures and I/O pins
- Constants
- Data structures
- Task code blocks
Sensor Controller tasks are fully independent and cannot transfer data or control each other.
Data Structures¶
Each Sensor Controller task stores its global variables in a standardized set of data structures. The data structures are located in the AUX RAM, which is mapped into the System CPU’s and DMA’s memory address space. The data structures for a task are:
- cfg : Used to perform run-time configuration of the task, before the task is started
- input : Used to pass input data to the task (for example dynamic parameters for an external sensor)
- output : Used to pass output data to the System CPU application (for example accelerometer data)
- state : Internal variables used to store the task’s state between iterations
The output data structure can be single- or multiple-buffered. The task can alert the System CPU application (with interrupt generation) to request data exchange, or the application can simply poll the data structure variables (if the System CPU wakes up periodically).
Task Code Blocks¶
The task algorithm is divided into four types of code blocks:
- Initialization Code : Runs one time when the task is started through the task control interface
- Performs one-time hardware initialization to reduce execution time
- Sets up task data and hardware for special behavior during the first execution
- Schedules the next iteration of the Execution Code and/or sets up an Event Handler Code trigger
- To run iterations of the Sensor Controller task, one or both of the following code blocks can be implemented:
- Execution Code : Runs each time the task is scheduled for execution, based on periodic ticks from the RTC
- Executes the task algorithm, for example sampling capacitive touch buttons, simple data filtering, processing and buffering
- Alerts the System CPU application to perform data exchange or signalize events when needed (for example when an array of ADC samples is full)
- Schedules the next iteration of the Execution Code and/or sets up an Event Handler Code trigger
- Event Handler Code : Runs one time when the trigger that was set up occurs, for example an edge or level on an AUX I/O pin, or after a variable delay
- The timer trigger is typically used to run Sensor Controller tasks at irregular intervals, or to follow up on actions peformed by the Execution Code
- The GPIO trigger is typically used to respond to external interrupts
- Other event triggers are available depending on the chip family
- Alerts the System CPU application to perform data exchange or signalize events when needed (for example when accelerometer data indicates movement)
- Sets up another Event Handler Code trigger if needed
- Execution Code : Runs each time the task is scheduled for execution, based on periodic ticks from the RTC
- Termination Code : Runs one time when the task is stopped through the task control interface
- Shuts down hardware left active between task iterations
- Performs final (partial) data exchange if needed
The CC13x0/CC26x0 device family supports one event trigger and one Event Handler Code block per project.
The CC13x2/CC26x2 and CC13x4/CC26x4 device families support three independent event triggers and up to three Event Handler Code blocks per project.
High-Level Program Flow¶
The Sensor Controller Engine does not support preemption, which means that one task code block cannot interrupt another task code block. While this is a limitation, it prevents actions of one task (for example SPI communication) from interfering with another task’s measurements (for example capacitive touch).
A Sensor Controller task is typically executed in short iterations. It is possible to implement tasks that run for longer periods of time, but this will prevent other tasks from running during that time.
Task Testing and Debugging¶
Sensor Controller Studio provides a generic, easy-to-use environment for ad-hoc and exhaustive testing, and for low-level debugging of tasks.
Task testing can be performed on one task at a time, using an XDS100v3, XDS110 or XDS200 JTAG debug probe for interfacing with the CC26xx/CC13xx device. While testing, the Sensor Controller Studio acts as the System CPU application and is responsible for controlling the Sensor Controller task. Values of all data structure members (from cfg, input, output and state) are logged after each task iteration. These values can be displayed graphically in Sensor Controller Studio, and can also be saved to file for external analysis.
Low-level task code debugging allows for single-stepping instructions or running with breakpoints the initialization, execution, event handler and termination code blocks. Debugging is performed on the generated assembly code.
Because the Sensor Controller tasks will execute asynchronously with the System CPU application, and mostly while the MCU power/clock domain is in standby, there is normally little to be gained from debugging the Sensor Controller code together with the System CPU application code. This option is therefore not supported.
Run-Time Logging¶
Sensor Controller Studio provides a generic, easy-to-use environment for evaluating and optimizing performance of tasks while these run at full speed, as they would in the actual application.
Run-time logging can be performed using a generic System CPU application image programmed by Sensor Controller Studio (through an XDS100v3 or XDS110 JTAG debug probe), or it can be performed using a custom application image programmed manually into flash. Commands and data are then transferred over UART, using a protocol based on the network processor interface (NPI).
The task data structures can individually be selected as either logged or editable. Logged data structures can be displayed graphically in Sensor Controller Studio, and can also be saved to file for external analysis. Editable data structures can be modified by Sensor Controller Studio while the tasks are running on the Sensor Controller.
Prerequisites¶
Driver¶
The generated Sensor Controller Interface driver depends on register definitions and basic operating system functionality. These dependencies are included in the following SDKs:
- SimpleLink CC13X0 SDK
- SimpleLink CC2640R2 SDK
- SimpleLink CC13xx CC26xx SDK
The driver is also compatible with previous SDK generations:
- SimpleLink CC13x2 CC26x2 SDK
- TI-RTOS for CC26xx and CC13xx
- TI-RTOS for SimpleLink Wireless MCUs
The Revision History lists all compatible SDKs releases for your current Sensor Controller Studio version. The generated driver will normally also be compatible with future SDK releases, since it depends only on basic SDK functionality.
The driver source files are compatible with the following compilers/IDEs:
- IAR Embedded Workbench for ARM (EWARM)
- TI Code Composer Studio (CCS)
- Keil MDK-ARM
- ARM GCC
Examples¶
Examples with associated files are configured and patched when opened through the Sensor Controller Studio Start Page Panel . This allows support for different target chips (when supported by the example hardware platform) and for different SDK releases. Example project files are provided for the IAR EWARM and TI CCS toolchains.
The Revision History lists all supported SDKs releases for your current Sensor Controller Studio version.
The example application project files require one of the following:
- For CC13x0 and CC26x0 devices:
- IAR EWARM 8.20.1 or later
- TI CCS 7.3.0 or later
- For CC13x2 and CC26x2 devices:
- IAR EWARM 8.50.1 or later
- TI CCS 10.2.0 or later
- SimpleLink CC13x2 26x2 SDK 4.30 or later: SysConfig (TI System Configuration Tool). The SysConfig version must match the SDK. See the SDK release notes for details.
Note that the examples depend on device support in the IAR EWARM and TI CCS toolchains. The SDKs also have toolchain dependencies.