Main Content

Using the Control Law Accelerator (CLA)

This example shows how to use the Control Law Accelerator (CLA) available on some of the TI Piccolo processors.

Required Hardware:

For the LED blinking model:

  • TI® Piccolo F28069, F28035, F28004x or Delfino F28377S board.

For the motor control application model:

  • TI® DRV8312 Three-Phase Brushless Motor Control Kit (DRV8312-C2-KIT or DRV8312-69M-KIT) with F28035 or F28069 Piccolo processor

  • Three-phase PMSM with Hall sensors attached to connector J10 of the DRV8312EVM board

Available versions of example models:

Task 1: Using the CLA with an LED Blinking Example

The following figure shows an example model configured to use the CLA available on the hardware.

This model generates code for a Simulink model where one part of the algorithm runs on the Control Law Accelerator (CLA) available on the device. The CLA is a co-processor that allows parallel processing. Utilizing the CLA for time-critical tasks frees up the main CPU to perform other system and communication functions concurrently.

The following section shows how to trigger a CLA task, exchange data from the C28x CPU to the CLA using memory sections like CpuToCla1MsgRAM and Cla1ToCpuMsgRAM, schedule C28x interrupts at the end of the CLA task, and replace the standard linker command file to include CLA specific linking attributes.

CLA Task Block

In the c28069blink_cla.slx model, a CLA Task block is provided to trigger a CLA task. This block runs the downstream function-call subsystem on the CLA. On the CLA Task block mask, you can specify the CLA task number and the associated interrupt triggering source. Ensure that you are using the CLA Trigger block from the library matching the hardware board selected in the Configuration Parameters. CLA task trigger source options are different for different processors. The downstream function-call subsystem is executed using the selected CLA Task when the selected interrupt triggers. In this example, CLA Task1 is used and "Software" is selected as the trigger source, which means that the CLA task is triggered at the sample rate provided in the sample time parameter.

Select Inline Code Generation for CLA Subsystem

For the CLA task subsystem, select the "Function packaging" as "Inline" under the "Code Generation" tab of the Block Parameters. To open the Block Parameters, right-click on the CLA subsystem and select "Block Parameters(Subsystem)".

Changing the Standard Linker Command File

For F28035 and F28069 processors, a specific linker command file has to be selected to assign CLA memory sections. In the Model Configuration Parameters, under Hardware Implementation > Target hardware resources > Build options, "Use custom linker command file" is selected and the pre-configured "c28069_cla.cmd" is used as linker command file. This file adds CLA memory sections description and can be found in the "src" directory at the root of the support package installation.

Interrupt Generation after CLA Task Completion

A CLA interrupt is generated when the CLA Task completes. CLA Task1 interrupt (CPU = 11, PIE = 1-8) is used as the interrupt source on the C28x Hardware Interrupt block. The function-call subsystem 'System executes at completion of CLA Task1' is executed when the interrupt occurs. GPIO pin 34 (connected to the LED on control cards; for LaunchPad boards the GPIO pin number is different) toggles on every occurrence of the CLA Task1 interrupt.

Data Exchange between the CLA and the C28x CPU

CLA storage classes can be loaded in the model (Embedded Coder > Code Interface > Embedded Coder Dictionary > Manage Packages) as shown in the following figures.

All the interfaces between CLA and CPU need to be placed in specific memory sections. To gain specific access to these sections, Select Embedded Coder > Code Mappings > Data stores and Signal/States for CpuToCla1MsgRAM and Cla1ToCpuMsgRAM. For more information, refer to Code Mappings.

Model Configuration Required while Using the CLA

In Model Configuration Parameters > Code Generation > Optimization, the Default parameter behavior parameter must be set to Inlined. This is to avoid the creation of model structure global variables, as CLA cannot access global data.

Discrete State Variables

All discrete state variables used inside CLA function-call subsystems must be stored in Cla1DataRam. For example, delay blocks and integrators must be set to use the Cla1DataRam storage class for state variables. See the 'State Attributes' of the Delay block inside cla_subsystem for an example.

Other Guidelines to Consider while using the CLA

Avoid the creation of sub-functions provided on atomic subsystems inside CLA function-call subsystems as this creates nested functions that are not supported on the CLA.

The specificity of the CLA may require more operations on the model or may prevent the use of Simulink features. Make sure to go through the list of limitations provided in the CLA C compiler documentation. Make sure to use the features of Embedded Coder to restrict the generated code in the limited syntax supported by the CLA C compiler.

Run the Model

  1. Open the example model, c28069blink_cla.slx, c28035blink_cla.slx, c28004xblink_cla.slx, c28377Sblink_cla.slx, c28379D_cpu1_blink_cla.slx, or c28379D_cpu2_blink_cla.slx.

  2. Open Configuration Parameters and select the required tool chain on the Code Generation pane.

  3. Press Ctrl+B to build a binary executable and to automatically load and run the executable on the selected target.

Task 2: Debug Code on the CLA

The debug function /*__mdebugstop()*/ is present at the beginning of the CLA task (__interrupt void Cla1Task1 ( void )) in the generated cla_task.cla file.

  1. Enable the debug function __mdebugstop() by removing the block comments around it.

  2. Compile the source code or build the CCS project.

  3. For debug instructions visit:

Task 3: Ensure Data Integrity Between CPU and CLA

Data integrity issues may occur when:

  • The data transfer is not atomic. For example, data transfers where the data size is more than the atomic size (uint16).

  • Tasks are not synchronized. For example, the CLA is triggered asynchronously.

  • Sample time of the CPU and the CLA are different.

To ensure data integrity, data must be protected either using a double buffer algorithm or by synchronizing both the CPU and the CLA.

In this model, the CPU and the CLA are not syncrhonized because the CLA is triggered asynchronously using an ePWM interrupt. To ensure data integrity, a double buffer algorithm along with control flags (Read_index and Write_index) are used.

In the double buffer algorithm, two buffers are used for data exchange. The CPU checks the buffer that is being read by the CLA using the Read_index flag and writes the data to the other buffer. Similarly, the CLA checks the buffer that is being written by the CPU using the Write_index flag and reads the data from the other buffer.

By using the double buffer logic, data integrity is ensured even though the CPU and the CLA are not synchronous.

Run the Model

  1. Open the c28069dataintegrity_cla.slx model.

  2. On the Hardware tab, Click Build, Deploy & Start > Build Stand-Alone or press Ctrl+B to build and download the executable file on the CPU.

Task 4: Permanent Magnet Synchronous Motor Field-Oriented Control (FOC) Using CLA

The following figure shows a Permanent Magnet Synchronous Motor Field-Oriented Control (FOC) example model, which runs the FOC algorithm on the CLA.

This model implements the Field-Oriented Control (FOC) of a Permanent Magnet Synchronous Motor using the CLA. The FOC algorithm is implemented with a CLA Task and PWM duty cycles are refreshed on completion of CLA Task using the corresponding interrupt. This example requires a DRV8312 kit with an F28069 or F28035 Control card. All the considerations listed in the blinking LED example are applied in this example.

In this model, data integrity is ensured by synchronizing the CPU and the CLA. The CLA is software triggered using the sample time inherited from the inputs. The Simulink scheduler ensures that all inputs are ready before the CLA subsystem is triggered.

In this example, a closed-loop Field-Oriented Control algorithm is used to regulate the speed and torque of a three-phase Permanent Magnet Synchronous Motor (PMSM). This example uses C28x peripheral blocks from the Embedded Coder Support Package for Texas Instruments C2000 Processors. The algorithm in this example uses an asynchronous scheduling. The pulse width modulation (PWM) block triggers the ADC conversion. At the end of conversion, the ADC posts an interrupt that triggers the main FOC algorithm.

Configure the interrupt operation with Configuration Parameters > Hardware Implementation > Hardware board settings > Target hardware resources > External Interrupt.

Model Calibration Using DRV8312EVM

The 'Position Sensing Switch' in the model allows you to select sensorless position sensing or position sensing using Hall sensors. In case of sensorless (default), no calibration is needed. If using Hall sensors for position sensing, Hall sensors have to be connected to J10 of the DRV8312EVM board. The model concatenates the three Hall signals into a variable with Hall_A being the Least Significant Bit (LSB) and Hall_C being the Most Significant bit (MSB) of the variable.

The 'Speed Request Switch' allows you to select the source of the speed request. By default the speed will come from a normalized constant setting the speed request to half the acceptable speed range (0.5). For the DRV8312EVM, you can also select the speed request to come from potentiometer R66.

Interpretation of Hall Sensor Signals

This section is not relevant if using sensor-less control. The model is configured with one interrupt for each Hall signal. In each Hall interrupt, there are four meaningful Hall values. Any other Hall value indicates a hardware problem. The Hall value read in a particular interrupt holds information about the motor's direction of rotation. For example, in Hall_A interrupt, reading a Hall value of 2 indicates that the motor is spinning in direction 0 and a falling edge has just occurred. If the model detects a direction change, it invalidates the direction and speed of the motor. For the speed to be valid, the model requires two consecutive edges with the same direction. Otherwise, the model sets a flag to invalidate the speed.

The following logic applies to the corresponding flag updates:

  1. New_direction = Hall_direction

  2. New_valid_flag = Previous_direction == Hall_direction;

  3. Global_speed_and_direction_ready_flag = New_valid_flag && Old_valid_flag;

The Field Oriented Control algorithm takes a position signal from 0 to 1 reflecting an electrical revolution. If the speed signal is valid, the model performs a linear extrapolation from the Hall reading and accurately estimates the position.

Principle of the Hall based position estimation algorithm:

  1. Read the halls.

  2. Get the value of the latest timer (timer captured from the last interrupt that triggered).

  3. Convert the time that elapsed from the previous edge to an electrical angle using the current speed.

  4. If the speed information is not valid (speed is invalid after a direction change, at startup, when motor is stopped, when speed is too low...), the algorithm assumes that the position is in the middle of the 60 electrical degrees defined by the Hall reading. The maximum position signal error in these cases is therefore 30 electrical degrees.

The Hall decoder will be referenced (position = 0) when Hall_A is rising in direction 0. A Hall_position_offset variable is used to inform the FOC algorithm of the position difference between the Hall reference and the back EMF waveforms of the motor. Like the QEP example, this value has to be calibrated by comparing the Hall signals with the back EMF waveforms of the motor. In the DRV8312 example, Hall_position_offset is normalized on the electrical revolution and is set to 0.57, to match the characteristics of the motors included in the DRV8312EVM.

Run the Model

  1. Open the example model c28069pmsmfoc_cla.slx or c28035pmsmfoc_cla.slx

  2. Open Configuration Parameters and select the required tool chain on the Code Generation pane.

  3. Press Ctrl+B to build a binary executable and to automatically load and run the executable on the selected target.


Specific interactions between the CLA and the C28x CPU along with CLA C compiler limitations force the modeling practices to be followed. Below is a list of concepts that reflects modeling practices described in this example:

  • The CLA application code can only be triggered by a C28x event. CLA Task can be triggered by C28x CPU via software or by different peripheral interrupts.

  • All the interfaces between CLA and CPU need to be placed in specific memory locations. The CpuToCla1MsgRAM memory section is used to exchange data from the C28x to the CLA. The Cla1ToCpuMsgRAM memory section is used to exchange data from the CLA to the C28x.

  • The CLA application code does not have access to global variables.

  • Early versions of the CLA C compiler support only 2 levels of function calls. CLA interrupt service routines may call leaf functions only. Leaf functions may not call other functions.

  • Recursive function calls are not supported.

  • Integer division, modulus, and integer unsigned comparison are not supported with the CLA C compiler.

For more details and an exhaustive list of limitations visit:

These limitations must be considered when modeling in Simulink®.


  • Ensure that the Code Generation Tools version used supports the CLA C Compiler.

  • Ensure that the latest C/C++ header files with CLA support are installed on your system.

More About