Introduction

This is the entry level guide on how to use the Sensor Controller with the GUI tool, Sensor Controller Studio (SCS). You will generate, download and debug code on the Sensor Controller processor (16-bit custom low power RISC processor). The Sensor Controller can access the peripherals which reside in the Sensor Controller Domain (AUX Domain).

Abbreviations / terminology

Prerequisites

Software

In order to start with this exercise you will need to download the correct Software Development Kit (SDK) for your LaunchPad. This training covers the CC13x0, CC13x2, CC2640R2 and the CC26x2 device families.

The following software applies for all device families:

• Code Composer Studio version 9.2 or later
  Make sure that CCS is using the latest updates: Help → Check for Updates

• Sensor Controller Studio version 2.5.0 or later

Hardware

One LaunchPad connected with a USB micro cable:

• LAUNCHXL-CC1310,
• LAUNCHXL-CC1312R1,
• LAUNCHXL-CC1350,
• LAUNCHXL-CC1352R1,
• LAUNCHXL-CC1352P,
• LAUNCHXL-CC26x2R1, or
• LAUNCHXL-CC2640R2.

Getting Started

Set up Desktop Environment

1. Make sure CCS is installed. You can find version info in the menu: Help → About Code Composer Studio

   

2. Make sure the correct SDK is installed. If it is installed to the default directory it should be located here: C:\ti\simplelink_<device>_sdk_x_xx_xx_xx

3. Run the setup_sensor_controller_studio_xxx.exe downloaded from the link above and install.

4. Open SCS and click Updates → Check for Updates. If any new patches are available, click Updates → Manage Updates... and apply all new patches. Note that the picture below is only used as an example. You may have a newer version, and there may be no patches available.

   

Connect LaunchPad

Simply connect the micro-USB cable from your computer to the LaunchPad as shown in the figure below:

When the LaunchPad is connected, the Windows Device Manager (Start → Run → mmc devmgmt.msc → Ok) should show you the following devices connected:

Task 1 – Set up Project in SCS

You will now configure the ADC Window Monitor example code in SCS and import the pre-made project into CCS. These are the steps that will be covered in more details in the sub-chapters below:

• Configure the SCS example project for your device.
• Generate the Sensor Controller driver from the SCS project.
• Import the premade CCS project specification which will import these files:
  • Main source example file that show how to integrate a Sensor Controller driver. This file is pre-made and is not part of the generated Sensor Controller driver.
  • Sensor Controller driver.
  • Sensor Controller driver framework.

Configure the Sensor Controller Example Project

• Open SCS and double-click on the "ADC Window Monitor" LaunchPad example project as shown in the figure below.
  

Now an Example Configuration Window will appear (refer to figure below). Do as follows:

• Select Target chip device name.
• Select correct SDK release.
• Change Output base directory to C:\ti\scs_academy.
• Your settings should match the screen shot below.
  

When the project is opened in SCS, the main source project and IDE project files will automatically be populated into the output base directory. The default path here is your documents folder C:\Users\<your user>\Documents\Texas Instruments\Sensor Controller Studio\examples where <your user> is your windows user name (%USERPROFILE%).

Generate the Sensor Controller Driver

• Go to the Code Generator Pane in SCS (CTRL+G) and press Generate driver source code.
• Verify that the driver is generated successfully in the event log. Then press View output directory (button is located at the bottom right corner).

SCS generates the SCIF driver and framework. Example projects included with SCS are based on pre-made code which resides in its own example directory in the installation directory. Each example project includes hard-coded examples of simple main application source files (main.c/main_tirtos.c) along with project files for both CCS and IAR.

Never open Sensor Controller Studio example projects directly from the installation directory. You should instead always open example projects from within Sensor Controller Studio. Doing modifications to an example project which were opened from the installation directory would be permanent. Sensor Controller Studio uses these files to restore examples in your base output directory, allowing you to always restore the original example project.

To integrate a driver into your custom application you need to create your own main application source file (running on the main application processor). You can use the SCS examples as a reference and starting point. The Sensor Controller firmware image is found in the driver file scif.c. A more human- readable format of the Sensor Controller assembler source code is available in the assembler listing file sce.lst.

Import to Code Composer Studio

Do the following:

• Open CCS and press Project → Import CCS Project

  

• Select C:\ti\scs_academy\adc_window_monitor_launchpad as the search- directory. This is the SCS project output base directory, which was set in the example configuration.

• Select adc_window_monitor_launchpad_tirtos project and press Finish.

  

• Compile the project. Press the hammer icon, or right click your project in the Project Explorer window then click Build Project, to build in CCS.

• Verify that the build completes without errors.

Configure the debugger connection

The correct debugger type (XDS110 for LaunchPad) is selected by default when you import the project. If more than one debugger of the same type connected, the GUI will query which debugger you want to use. Simply click on the debugger of choice and press OK.

If the debugger connection has already been configured, but you want to change to a different debugger connection, see instructions below for how this can be changed manually.

Expand instructions for manual debugger selection in CCS Desktop

Make sure you only have one debugger of the same type connected when checking the serial number.

• Open the file targetConfigs/CC2650F128.ccxml.
• Change the connection to XDS110 USB Debug Probe if needed.
• Click on Target Configuration

• Click on the top-level node (XDS110 USB Debug Probe)
• Choose 'Select by serial number'
• Start command prompt and call c:\ti\ccs\ccs_base\common\uscif\xds110\xdsdfu.exe -e to enumerate the connected debugger. This will give you the serial number of the device.

C:\ti>c:\ti\ccs\ccs_base\common\uscif\xds110\xdsdfu.exe -e

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2014 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...


<<<< Device 0 >>>>

VID: 0x0451    PID: 0xbef3
Device Name:   XDS110 with CMSIS-DAP
Version:       2.2.4.2
Manufacturer:  Texas Instruments
Serial Num:    0000FF01
Mode:          Runtime

Found 1 device.

C:\ti>

Finding XDS110 serial number

• Insert the serial number. Above it's 0000FF01.
• Save the settings.
• Test the connection.
• Do this for both the App and the Stack projects.

You can also change the serial number to something easier to remember, or in case two debuggers have the same serial number.

C:\ti>c:\ti\ccs\ccs_base\common\uscif\xds110\xdsdfu.exe -m

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2015 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...


<<<< Device 0 >>>>

VID: 0x0451    PID: 0xbef3
Device Name:   XDS110 with CMSIS-DAP
Version:       2.2.4.2
Manufacturer:  Texas Instruments
Serial Num:    BADEABBA
Mode:          Runtime

Switching device into DFU mode.

C:\ti>c:\ti\ccs\ccs_base\common\uscif\xds110\xds110\xdsdfu.exe -s ABCDEF01 -r

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2015 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...

Setting serial number to "ABCDEF01"...

c:\ti>

Optionally change the serial number

Task 2 - Download and Debug with CCS

• Make sure that your HW is connected as instructed earlier in this guide.
• Press the Debug button (bug icon) or press F11 to start the debug session.
• Then press Resume (F8) to allow the code to run. The ADC will sample the configured input pin (DIO23) at an interval and will notify the main application processor if the measured/converted ADC input value change to either below or above a set window threshold. The main application processor will read out the result and set:
  • Red LED (DIO6) if ADC input > high threshold.
  • Green LED (DIO7) if ADC input < low threshold.

Breakpoints and source browsing in CCS

• In main_tirtos.c set breakpoints inside the two if statements as shown below in CCS by double clicking the desired lines or pressing CTRL+SHIFT+B.

// Wait for an ALERT callback
Semaphore_pend(Semaphore_handle(&semScTaskAlert), BIOS_WAIT_FOREVER); // Waiting for alert from Sensor Controller

// Clear the ALERT interrupt source
scifClearAlertIntSource();

// Indicate on LEDs whether the current ADC value is high and/or low
if (scifTaskData.adcWindowMonitor.output.bvWindowState & SCIF_ADC_WINDOW_MONITOR_BV_ADC_WINDOW_LOW) {
    PIN_setOutputValue(hLedPins, Board_GLED, 1);    // Set breakpoint here (Ctrl+Shift+B)
} else {
    PIN_setOutputValue(hLedPins, Board_GLED, 0);
}
if (scifTaskData.adcWindowMonitor.output.bvWindowState & SCIF_ADC_WINDOW_MONITOR_BV_ADC_WINDOW_HIGH) {
    PIN_setOutputValue(hLedPins, Board_RLED, 1);    // Set breakpoint here (Ctrl+Shift+B)
} else {
    PIN_setOutputValue(hLedPins, Board_RLED, 0);
}

• Now run the application (F8) and alternate the ADC input (DIO23) between High (3V3) and low (GND) and observe which breakpoint is hit in the code. Press resume (F8) after the breakpoint is hit to allow the code to resume from halt. The picture below show you how to connect the ADC input to high or low with a jumper or wire.
  

• Find the address of the scifTaskData struct. Tips: press CTRL+H for advanced search options in CCS.

• Find out in which context the scTaskAlertCallback function is called.

• Terminate the adc_window_monitor_launchpad project (Ctrl + F2 or red square icon).

Task 3 - Download and Debug with SCS

In this task you will debug the Sensor Controller task directly from Sensor Controller Studio. Sensor Controller Studio taking over the role of the System CPU application and interacting with the Sensor Controller task through the debugger. More detailed information about this can be read in the SCS Help viewer (press F1 in SCS and go to Task Testing Panel). We will now debug the Sensor Controller task without any application running on the main application processor.

• In SCS, go to the Task Testing panel by clicking on the tab or pressing Ctrl + T.
• In the Task Testing window, if you have multiple projects open; select the ADC Window Monitor for LaunchPad project like shown in the screen shot below.
• Be sure to select low-level workflow before connecting to target.

When taking over the role of the System CPU application during task testing and debugging, SCS cannot interact with the Sensor Controller in real-time, and also has no knowledge of what a task iteration (during task testing) actually is. The sequence of events that will occur during a task iteration must therefore be specified, and this is done by listing a sequence of actions. In this example you can simply set up Run Execution Code.

Verify your Task Testing window matches the screenshot below before starting task testing.

• Start a debug session by connecting to target (F12).
• Set the threshold values in the cfg RAM variables as shown in the screen shot below. These values are set by the main application and therefore needs to be set manually in task testing.
  
• Run the initialization code once (F6).
• Run task iterations continuously (F5).
• Experiment and adjust the input level on the ADC input. You can use a jumper and connect the DIO23 pin to 3V3 and GND. Observe the adcValue and bvWindowState in the graph window as in the screen shot below.

The icons and hot keys for debugging alter meaning and form during each step which means the hot keys, for example F6, have different actions during the different phases. This makes it easier to restart the execution code as you can press F6 twice or press the same icon twice to run termination code and initialization code again before starting the execution code again.

Now you will start a task testing (assembler code) debugging session:

• When you are satisfied press stop (F6).
• Run the termination code (F6).
• Run the initialization code once (F11).
• Start a debug session of one task iteration (CTRL + F11).
• Place a breakpoint as shown in the image below where the converted ADC input value is stored to the RAM variable output.value (F9).
• Press run continuously (F5).
• Now you should hit the breakpoint. Single step in the code by pressing F11 and observe the new value being loaded into output.adcValue (seen on right pane). Change the input ADC value, repeat the process and verify the new measured input voltage.
  

Task 4 - Understand

In this task you will try to grasp the basic flow of the ADC Window Monitor example program and solve a quiz to make sure you understand the concepts. Code from the Sensor Controller or the main application is presented in the format shown in the table below.

Program Flow (ADC Window Monitor for LaunchPad)

Here is a brief step-by-step list on the program flow for the ADC Window Monitor project:

Boot and Initialization

1) The complete application including the Sensor Controller driver will be loaded as a flash image on to the device.

2) On boot, the main() function will configure a task, initialize a semaphore and boot the TI-RTOS kernel (BIOS_start()).

3) In the task function (taskFxn) everything needed for the Sensor Controller driver will be configured:

• (1) Construct Sensor Controller framework semaphore.
• (2) Interrupt handlers are registered.
• (3) Load Sensor Controller program image to the Sensor Controller RAM and configure the complete driver setup which includes IO Mapping, Domain Clocks, control and data variables, HWI's and more. For more details refer to the source code.
• (4) Schedule periodic wakeup interval for the Sensor Controller.
• (5) Write upper and lower window limits directly to Sensor Controller RAM.

• (6) The Sensor Controller task is started and the initialization code will run once.

  Select text

    // Initialize the Sensor Controller
    scifOsalInit();                                         // (1)
    scifOsalRegisterCtrlReadyCallback(scCtrlReadyCallback); // (2)
    scifOsalRegisterTaskAlertCallback(scTaskAlertCallback); // (2)
    scifInit(&scifDriverSetup);                             // (3)
    scifStartRtcTicksNow(0x00010000 / 8);                   // (4)
  
    /*  Configure and start the Sensor Controller's
    *   ADC window monitor task (not to be confused with RTOS tasks)
    */
    scifTaskData.adcWindowMonitor.cfg.adcWindowHigh = 800;  // (5)
    scifTaskData.adcWindowMonitor.cfg.adcWindowLow  = 400;  // (5)
    scifStartTasksNbl(BV(SCIF_ADC_WINDOW_MONITOR_TASK_ID)); // (6)
  

Program Loop Running

4) TI-RTOS task will then pend on the semaphore semScTaskAlert (device enter sleep/standby).

5) The Sensor Controller wakes up every 125 ms (interrupt from RTC channel 2 compare event) and runs the execution code as scheduled (fwScheduleTask(1);).

6) The execution code will trigger an ADC conversion. If the ADC value is below or above the set window thresholds it wakes up the TI-RTOS task (fwGenAlertInterrupt();).

7) The triggered HWI calls scTaskAlertCallback which posts the semScTaskAlert semaphore.

8) The TI-RTOS task taskFxn iterate once through the while-loop.

9) LED's are set/cleared and the interrupt source cleared.

10) Repeat steps 5) to 9) forever (while-loop).

Review SCS Project Panes

Review the open project (ADC Window Monitor for LaunchPad) in SCS and review the project panels. Press F1 and navigate to the Project Panel section where you find all the details for every panel in the project. The table below lists all the project panels with a very short description.

Termination Code will only run once when task is stopped by the application processor (scifStopTasksNbl()) or at the end of a single iteration for all task code blocks (scifExecuteTasksOnceNbl()). In the "ADC Window Monitor" example the termination code never runs and is therefore left blank.

Panel (Tab)	Description
	Define project name, location, chip/OS configuration, description and add tasks.
	CC13x2/CC26x2 devices only: Configure power and clock modes for various parts of the project.
	Configure task name, description and resources for every Task in the project.
	Code that will run once when task is initialized.
	The Execution Code will run when scheduled by fwScheduleTask(). Is only available if the RTC-Based Execution Scheduling resource is enabled.
	The Event Handler Code will run when its corresponding event is triggered. Is only available if any Event Trigger resources are enabled, e.g. GPIO Event Trigger.
	Termination code run once on task exit or never if the task runs forever.
	Configure I/O functions to I/O pins.
	Compile task code and generate application framework.
	Test and debug a single Sensor Controller task.
	Rune-Time Logging panel for evaluating and optimizing performance.

Review Sensor Controller Task Code

Browse the different task codes (initialization, execution, event handler, termination) and answer the following quiz.

Task 5 - Bonus Tasks (Low to Intermediate Level)

These tasks will let you get hands on and modify Sensor Controller task code, modify application code (TI-RTOS) as well as discuss ADC accuracy.

Bonus Task 1 - Read and Correct ADC Value

In this task you will read the raw ADC value directly from the Sensor Controller RAM in the TI-RTOS main application and correct for ADC gain error and ADC offset error. The ADC offset and gain error are calculated in production test and stored in FCFG1. The driverlib file aux_adc.h contains functions that can retrieve and apply these corrections to a raw ADC conversion result as well as reverse a corrected value back to the equivalent raw ADC result value. These functions must be run in the main application as the computations are too demanding for the Sensor Controller processor. For example, if the driver needs to trigger on a precise ADC value threshold you can calculate the corresponding raw value in the main application and write the value directly to the Sensor Controller RAM. You will do this in the exercise Configure Microvolt Threshold below.

Read ADC Value Directly from Sensor Controller RAM

The framework (scif.h) defines structs for all the Sensor Controller RAM variables. Try to read the raw adc result after an ADC conversion takes place. Simply access the correct sub-members of the scifTaskData struct. The figure below will guide you to the correct struct member variable.

Expand Code Solution (snippet from main_tirtos.c):

Select text

 // Wait for an ALERT callback
 Semaphore_pend(Semaphore_handle(&semScTaskAlert), BIOS_WAIT_FOREVER);

 // Clear the ALERT interrupt source
 scifClearAlertIntSource();

 // Read ADC value
 int32_t adcValue = (int32_t) scifTaskData.adcWindowMonitor.output.adcValue;  // Set breakpoint here (CTRL+SHIFT+B.)

• After you have written code to read the raw ADC value, set breakpoint at the line where the value is read (CTRL+SHIFT+B.)
• Compile, download and debug in CCS by pressing F11.
• When ready to run, press F8 to run to breakpoint.
• After the the breakpoint is hit, right-click on the read variable and press Add Watch Expression...
• Press ok on the dialog box.
• Single step (over) F6 and observe the value.
• Change the ADC input voltage and repeat the steps above to verify correct behavior.

Correct Raw ADC Value and Convert to Microvolts

In this sub-task you will correct the raw ADC value and modify the main application code to set/clear LED's depending on threshold values given in microvolt. Direct links for specific devices are given below:

• Review the driverlib API documentation for aux_adc which contains all the functions you need to solve this task.

  • The driverlib API can be found under the docs folder in your SimpleLink SDK installation, i.e.
    <SDK>/docs/driverlib_cc13xx_cc26xx/docs_overview_driverlib_cc13xx_cc26xx.html.

  • Or, you can find the driverlib API in the TI Resource Explorer. For example, the SimpleLink CC13x0 SDK would have the following path:
    Software → SimpeLink CC13x0 SDK - v:*version* → Documents → DriverLib → Driverlib Documentation

• Correct the Raw ADC value (offset error and gain error).
• Convert the corrected ADC value to microvolts.
• Compile, download and debug (F11).
• Add watch expression for both the raw adc value and the corrected version. Single step in debug mode and observe the delta.

Expand Task Code Solution (main_tirtos.c):

Select text

#include <ti/devices/DeviceFamily.h>
#include DeviceFamily_constructPath(driverlib/aux_adc.h)

void taskFxn(UArg a0, UArg a1) {

    int32_t adcOffset = AUXADCGetAdjustmentOffset(AUXADC_REF_FIXED);
    int32_t adcGainError = AUXADCGetAdjustmentGain(AUXADC_REF_FIXED);
    int32_t adcValue, adcCorrectedValue, adcValueMicroVolt;

    PIN_Handle hLedPins;

    // Enable LED pins
    hLedPins = PIN_open(&ledPinState, pLedPinTable);

    // Initialize the Sensor Controller
    scifOsalInit();
    scifOsalRegisterCtrlReadyCallback(scCtrlReadyCallback);
    scifOsalRegisterTaskAlertCallback(scTaskAlertCallback);
    scifInit(&scifDriverSetup);
    scifStartRtcTicksNow(0x00010000 / 8);

    // Configure and start the Sensor Controller's ADC window monitor task (not to be confused with OS tasks)
    scifTaskData.adcWindowMonitor.cfg.adcWindowHigh = 800;
    scifTaskData.adcWindowMonitor.cfg.adcWindowLow  = 400;
    scifStartTasksNbl(BV(SCIF_ADC_WINDOW_MONITOR_TASK_ID));

    // Main loop
    while (1) {

        // Wait for an ALERT callback
        Semaphore_pend(Semaphore_handle(&semScTaskAlert), BIOS_WAIT_FOREVER);

        // Clear the ALERT interrupt source
        scifClearAlertIntSource();

        // Read ADC value
        adcValue = scifTaskData.adcWindowMonitor.output.adcValue;

        // Correct ADC raw value
        adcCorrectedValue = AUXADCAdjustValueForGainAndOffset((int32_t) adcValue, adcGainError, adcOffset);

        // Convert ADC value to Microvolts.
        adcValueMicroVolt = AUXADCValueToMicrovolts(AUXADC_FIXED_REF_VOLTAGE_NORMAL,adcCorrectedValue);

        // Indicate on LEDs whether the current ADC value is high and/or low
        if (scifTaskData.adcWindowMonitor.output.bvWindowState & SCIF_ADC_WINDOW_MONITOR_BV_ADC_WINDOW_LOW) {
            PIN_setOutputValue(hLedPins, Board_GLED, 1);
        } else {
            PIN_setOutputValue(hLedPins, Board_GLED, 0);
        }
        if (scifTaskData.adcWindowMonitor.output.bvWindowState & SCIF_ADC_WINDOW_MONITOR_BV_ADC_WINDOW_HIGH) {
            PIN_setOutputValue(hLedPins, Board_RLED, 1);
        } else {
            PIN_setOutputValue(hLedPins, Board_RLED, 0);
        }

        // Acknowledge the alert event
        scifAckAlertEvents();
    }

} // taskFxn

Configure Microvolt Threshold

Now you will configure new threshold values based on microvolt. Convert from microvolt to raw value (AUXADCMicrovoltsToValue) and calculate the raw threshold values with corrections for gain error and offset error (AUXADCUnadjustValueForGainAndOffset).

• Define new thresholds for the window monitor:
  • Window High = 0.8 Volts (800000 microvolts)
  • Window Low = 0.4 Volts (400000 microvolts)
• Calculate the corresponding raw values and write these to the appropriate Sensor Controller configuration variables.
• Compile, download and debug (F11).
• If you have an external power supply you can apply voltages to the ADC input (DIO23) to verify if the Sensor Controller window monitor triggers on the expected voltage values.

    /* Set threshold based on microVolt */
    int32_t adcThresholdLowMicro = 400000;      // 0.4 Volt
    int32_t adcThresholdHighMicro = 800000;     // 0.8 Volt

    int32_t adcThresholdLow = AUXADCMicrovoltsToValue(AUXADC_FIXED_REF_VOLTAGE_NORMAL, adcThresholdLowMicro);
    int32_t adcThresholdHigh = AUXADCMicrovoltsToValue(AUXADC_FIXED_REF_VOLTAGE_NORMAL, adcThresholdHighMicro);

    int32_t adcThresholdLowRaw = AUXADCUnadjustValueForGainAndOffset(adcThresholdLow, adcGainError, adcOffset);
    int32_t adcThresholdHighRaw = AUXADCUnadjustValueForGainAndOffset(adcThresholdHigh, adcGainError, adcOffset);

    // Configure and start the Sensor Controller's ADC window monitor task (not to be confused with OS tasks)
    scifTaskData.adcWindowMonitor.cfg.adcWindowHigh = adcThresholdHighRaw;
    scifTaskData.adcWindowMonitor.cfg.adcWindowLow  = adcThresholdLowRaw;
    scifStartTasksNbl(BV(SCIF_ADC_WINDOW_MONITOR_TASK_ID));

Bonus Task 2: GPIO Event Handler

Now you will change the Sensor Controller driver from being a window monitor to trigger on either low or high input value on DIO23 (ADC input). For this you will use the GPIO Event Trigger resource in Sensor Controller. This will cause the Sensor Controller driver to trigger on interrupt instead of scheduling execution code and therefore all the content in the execution code can be removed. In the default ADC Window Monitor example project (main_tirtos.c), periodic wakeups based on RTC compare events is configured:

/* Wake up Sensor Controller every 125 ms
 * 1 second (0x00010000) / 8 = 125 ms. */
scifStartRtcTicksNow(0x00010000 / 8);

Every time the Sensor Controller wakes up it will check if a task is scheduled to run its execution code. If the previously run Sensor Controller code scheduled an execution with argument 1:

/* Schedule execution at the next Sensor Controller
 * RTC scheduled wakeup. */
fwScheduleTask(1);

If there is only execution code in the Sensor Controller driver and every execution task is scheduled to run at every 10 wakeups (fwScheduleTask(10);) the Sensor Controller would wakeup 10 times and do nothing else except waste energy. In this case you should reconfigure the wakeups (scifStartRtcTicksNow(0x00010000);) and schedule the execution code to run at every wakeup (fwScheduleTask(1);). But in this task you do not need scheduling or the execution code as the event handler code is triggered to run directly after every interrupt. Let's start the task with a fresh copy of the ADC Window Monitor example project.

• Delete the modified ADC Window Monitor project in CCS and SCS:
  • To delete a project in CCS, right-click on the project, then press Delete and OK.
    
  • Delete the physical project stored in C:\ti\scs_academy\adc_window_monitor_launchpad. If you want to save the work for future references simply rename the folder instead.
  • Close the project in SCS.

• Open clean ADC Window Monitor for LaunchPad project
  • Open the ADC Window Monitor project in SCS as you did in the start of this training. Now a fresh copy of the project will be spawned at the set output base directory.
  • Import the project in CCS.
  • In main_tirtos.c: disable the Sensor Controller periodic wakeups:
    Select text

    //    scifStartRtcTicksNow(0x00010000 / 8);
    

• Modify the Sensor Controller driver:

  • Open task resources by navigating to the Task Panel for the ADC Window Monitor.
  • Press the help viewer button on the GPIO Event trigger. Review the help text.
    
  • In task panel under the Task resources, enable "Digital Input Pins", "System CPU Alert" and "GPIO Event Trigger":
    
  • Go to the I/O Mapping tab and select DIO23 as input.
    
  • In initialization code, set up gpio trigger to trigger on high match (evhSetupGpioTrigger).
  • Copy the behavior from the execution code into the event handler code so that the application defined in main_tirtos.c will behave as before. Also set up the next GPIO trigger.
  • Remove all contents in execution code.
  • Generate the Sensor Controller driver (CTRL+G).

• Compile run and test project in CCS (F11).

output.bvWindowState = 0;
evhSetupGpioTrigger(0, AUXIO_I_GPIO_IN, 1, EVH_GPIO_TRIG_ON_MATCH);

if(output.bvWindowState == BV_ADC_WINDOW_LOW) {
    output.bvWindowState = BV_ADC_WINDOW_HIGH;
    // Set up the next interrupt trigger
evhSetupGpioTrigger(0, AUXIO_I_GPIO_IN, 0, EVH_GPIO_TRIG_ON_MATCH);
} else {
    output.bvWindowState = BV_ADC_WINDOW_LOW;
    // Set up the next interrupt trigger
    evhSetupGpioTrigger(0, AUXIO_I_GPIO_IN, 1, EVH_GPIO_TRIG_ON_MATCH);
}
fwGenAlertInterrupt();