Main Content

Using the Control Law Accelerator (CLA)

This example uses:

Open Model

This example shows how to use the Control Law Accelerator (CLA) available on some of the TI® processors using C2000™ Microcontroller Blockset.

Introduction

C2000™ Microcontroller Blockset enables you:

  • Using the CLA with an LED Blinking Example

  • Data Integrity Between CPU and CLA

  • Signal Monitoring of CLA Output

  • Permanent Magnet Synchronous Motor Field-Oriented Control (FOC) Using CLA

Prerequisites

Complete the following tutorials:

Required Hardware

For the LED blinking model:

  • TI® F28069, F28035, F28004x, F28379D or F28377S board.

For Signal Monitoring of CLA Output:

  • TI F28379D LaunchPad

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. Open the c28069blink_cla model.

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.

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.

Method 1 - Using Nonreusable Function Code Generation for CLA Subsystem to Blink an LED

In this method, cla_subsystem is triggered by a software at a rate of 0.5sec and is configured with Nonreusable function as Function packaging. For more, Method 1 - Nonreusable Function Code Generation for CLA Subsystem (Recommended).

Following are the CLA Subsystem block configurations done for this model. To open the block Parameters, right-click on the CLA subsystem and select Block Parameters(Subsystem). Ensure the specified parameter values are the same if you want to run this example on the other hardware board.

Run the Model

  1. Open any one of the example model, c28069blink_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.

Method 2 - Using Inline Code Generation for CLA Subsystem to Blink an LED

In this method, cla_subsystem is triggered by a software at a rate of 0.5 sec and is configured with Inline as Function packaging. For more, Method 2 - Inline Code Generation for CLA Subsystem.

Following are the CLA Subsystem block configurations done for this model. To open the block Parameters,right-click on the CLA Subsystem and select Block Parameters(Subsystem). Ensure the specified parameter values are the same if you want to run this example for other hardware board.

Run the Model

  1. Open the example model, c28035blink_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: 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. Open the c28069_dataintegrity_cla model.

In the double buffer algorithm, two buffers mydoublebuf0 and mydoublebuf1 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. For example, when Read_index is 0, data will be read from mydoublebuf0 in CLA.

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 3 : Signal Monitoring of CLA Output

In this task you will,

  • Configure the c28379D_cmpss_cla_blink.slx model to read data from the DAC and CMPSS block and blink an LED inside the CLA task.

  • Monitor & Tune the model to observe the CLA output.

Input to the CLA Subsystem input1 is stored in CpuToCla1MsgRAM using code mappings. CLA Subsystem is configured with Nonreusable function Function packaging. For more, see Method 1 - Nonreusable Function Code Generation for CLA Subsystem (Recommended).

Configure the Model

1. Open the Using CMPSS Inside CLA to blink an LED model. This model is configured for TI Delfino F28379D LaunchPad hardware.

2. To run the model on other TI C2000 processors, press Ctrl+E to open the Configuration Parameters dialog box and select the required hardware board by navigating to Hardware Implementation > Hardware board.

Driver block Configuration inside CLA

Following are the driver blocks CLA configurations done for this model. Double-click on the blocks to open block parameter configurations. Ensure the specified parameter values are the same if you want to run this example for other hardware board.

Run the Model

1. Open Hardware tab and click Monitor & Tune.

2. Use the diagnostic viewer to follow the build progress and wait until the code loads and runs on the target hardware.

3. Observe the logged data on the Scope block and LED blinking.

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

Input to this Generating Raw Space Vectors (c28035pmsmfoc_cla/FOC Algorithm/Torque Control Algorithm/Generating Space Vectors) is stored in CpuToCla1MsgRAM using code mappings. Generating Raw Space Vectors is configured with Nonreusable function Function packaging. For more, see Method 1 - Nonreusable Function Code Generation for CLA Subsystem (Recommended).

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

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 C2000™ Microcontroller Blockset. 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.

Task 5: CLA Custom Code Inclusion

In this task you will,

  • Include a custom CLA file in the model

  • Custom CLA file calculates the exponential value of a fraction and sends the output to Simulink.

  • Monitor & Tune to observe the CLA output. Open the c28379D_custom_code_cla.slx

In this model, we are accessing a function defined in a custom cla file from CLA Task. The user can configure his own custom CLA code and include it in the build process as shown in this example.

Inputs to the CLA Subsystem input1 and input2 are stored in CpuToCla1MsgRAM using code mappings. CLA Subsystem is configured with Nonreusable function Function packaging. For more, see Method 1 - Nonreusable Function Code Generation for CLA Subsystem (Recommended).

Configure the Model

1. Open the Using CLA Custom Code Inclusion model. This model is configured for TI Delfino F28379D LaunchPad hardware.

2. To run the model on other TI C2000 processors, press Ctrl+E to open the Configuration Parameters dialog box and select the required hardware board by navigating to Hardware Implementation > Hardware board.

3. In Configuration Parameters dialog box, navigate to Code Generation > Custom Code > Code information > Source files and select the customcode.cla file.

Function Caller block Configuration inside CLA

Following are the Function Caller block CLA configurations done for this model. Double-click on the blocks to open block parameter configurations. Ensure the specified parameter values are the same if you want to run this example for other hardware board.

calcuateexpvalue(u,v) is a user defined function, defined in a custom CLA file(customcode.cla) called from the CLA Task in the cla_task.cla file.

Run the Model

1. Open Hardware tab and click Monitor & Tune.

2. Use the diagnostic viewer to follow the build progress and wait until the code loads and runs on the target hardware.

3. Observe the value of exponential e^(input1/input2) on the Display block.

Other Things to Try

  • Try to run the example with different driver blocks and analyse the results.

More About