Sensor Controller Studio (SCS) Frequently Asked Questions

This FAQ post will contain a list of the most common questions regarding the use of Sensor Controller Studio (SCS). SCS is still under development and we continue to work on and release maintenance releases which includes both (potential) bug fixes and new features. Feedback is appreciated.

— Abbreviations—

— Getting Started —

What is the Sensor Controller and what is Sensor Controller Studio (SCS)?

The Sensor Controller is the terminology used to describe the sensor module in the CC26xx and CC13xx family of devices. This is in a separate power domain (AUX_PD) which contains a dedicated low power 16-bits processor, 2 KB RAM, Peripherals (ADC, Comparator, timers, TDC, etc). This module is designed for ultra low power and high flexibility. The sensor controller has the ability to do its own power and clock management of AUX_PD, independently of the MCU domain. Sensor Controller Studio (SCS) is a GUI tool used to write, test and debug code for the CC26xx/CC13xx Sensor Controller. This GUI tool generates a Sensor Controller Interface driver, which is a set of C source files that are compiled into the System CPU (ARM Cortex-M3) application. These source files contain the Sensor Controller firmware image and allow the System CPU application to control and exchange data with the Sensor Controller.

How do I get started using SCS and where can I find documentation?

1. Download and install SCS.
2. Download and install the desired version of TI-RTOS.
3. Open SCS and check out the “Getting Started Guide/Tutorial” found in the top right corner of the Start Page. Chapter 5 in this document contains a tutorial based on the SmartRF06EB development platform. Tutorials for simplelink Academy in CCS will be published in the near future.

You can press F1 (Help Menu) in SCS or go to the “Help->Sensor Controller Studio Help” menu item in Sensor Controller Studio (SCS) to open the comprehensive help documentation. This covers almost everything except for for the generated driver API documentation which is found directly in the driver source files (scif.c, scif_framework.c, scif_osal_tirtos.c/scif_osal_none.c).

• For all details of the sensor controller domain read the following chapter “AUX – Sensor Controller with Digital and Analog Peripherals” which can be found in the TRM.
• Link to SCS product page.

How much power does the sensor controller use?

In short, very little. Look at this thread post for some details. An even more detailed description will be written in the future:

https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/467128/1681248#1681248

At what clock frequency does the Sensor Controller run at?

Refer to section 17.5.2.1 Active Mode in the TRM. The sensor controller, which is in the AUX power domain, has power modes which is independent upon the device power mode. In active mode the SCS framework will enable the 24 MHz clock source (derived from SCLK_HF). In standby mode the SCS framework will either turn off the clock or switch to the low speed 32 kHz clock if TIMER or GPIO event trigger is enabled. This is also the speed at which the sensor controller processor is running at. The maximum frequency is 24 MHz, and the configuration of clock division is controlled by the system CPU by configuring the AON_WUC:AUXCLK.SCLK_HF_DIV register.

— Integrating Sensor Controller Driver with Application —

This section contains guidelines for how to integrate a SC driver into an application.

Which Files Do I Need to Add to My Application/Project?

(Optional) Move the SCS project file (.scp) into your project folder and set the Source code output directory to your source project folder. Then the SCS compiled source files (driver and framework) will be updated directly in your application workspace.

SCS will generate the following files that you need to include (mandatory) in your project:
- scif.c ( AUX RAM Image, IO Mapping, SC RAM variables memory address, some low level functions)
- scif.h
- scif_framework.c ( General Driver Framework )
- scif_framework.h
- scif_osal_tirtos.c ( OS Specific )
- scif_osal_tirtos.h

What Code Changes is Required to My Application?

In the examples that is included in the SCS Installer the main.c or main_tirtos.c is pre-made application source code which will run on the main application processor (APP CPU). There is multiple ways on how to synchronize the sensor controller processor (SCP) and the APP-CPU. In the Analog Light Sensor example a TI-RTOS task is pending on a semaphore which is released in the HWI call back function scTaskAlertCallback. This callback is triggered by an event that is generated at the end of the SC task execution if the fwGenAlertInterrupt() procedure has been called. When the task is released from pending on the semaphore, new data is read from AUX RAM (ADC light sensor bin value). This use demonstrates low power because the system will enter standby when the task is pending on the semaphore and the callback HWI will allow the system to wake up from sleep.

The application developer must chose how to integrate and synchronize the main application with the sensor controller driver. Below there is listed a few general concepts in TI-RTOS that can be used for use cases that is similar to the analog light sensor example. The only way to set up signalling that can wake the main system is through enabling the callback which will run in HWI context.

• From HWI Callback:
  • Post semaphore to release application task.
  • Post SWI that will handle processing (only for very short processing, usually not recommended).
  • Process within HWI (only for very short processing, usually not recommended).
• Without HWI Callback:
  • APP-CPU can poll on variable in AUX RAM.
  • APP-CPU can read out results from AUX RAM (no synchronization).
  • APP-CPU can start and wait for end of single SC task iteration (SC Initialization-, Execution- and Termination- code run once).

For more general training on our devices (including TI-RTOS concepts) check out our SimpleLink Academy Training:
http://software-dl.ti.com/lprf/simplelink_academy/overview.html

— Technical Deep Diving —

...

— Troubleshooting  —

UART Emulator bug (SCS release 1.2.0): When enabling BV_SCIF_UART_ALERT_RX_BYTE_TIMEOUT event, RX byte timeout event can trigger infinitely after reception of first byte.

Place the attached fix (uart_emulator.asm) into C:\Users<xxxxxx>\Documents\Texas Instruments\Sensor Controller Studio\proc_defs

/cfs-file/__key/communityserver-discussions-components-files/538/uart_5F00_emulator.asm