Motor Control with TI Multicore MCUs Using Simulink
Overview
Are you facing challenges in developing motor control systems for multicore microcontrollers, such as partitioning control algorithms, managing inter-processor communication, or synchronization between cores?
Attend this webinar to learn how Model-Based Design helps you design motor control applications for multicore MCUs such as TI C2000 F2837xD / F2838xD devices.
In this webinar, a MathWorks engineer will highlight issues that can arise when using a multicore MCU for motor control applications. You will learn how to use Simulink with SoC Blockset and Motor Control Blockset to design a two-core implementation of a field-oriented control (FOC) algorithm – higher control-loop rates will be achieved by allocating the current and velocity controllers to the two processor cores.
A TI engineer will discuss TI’s multicore devices and review the architectures that are being used in today’s motor control applications.
Highlights
- Modeling a velocity control system of a PMSM motor with field-oriented control
- Modeling the TI C2000 F2837xD architecture and simulating the complete system with the dual-core MCU
- Modeling MCU peripheral behavior, such as ADC-PWM synchronization
- Generating the motor control application using Embedded Coder with SoC Blockset
- Deploying the compiled application to the TI Delfino F28379D LaunchPad
- Performing simultaneous real-time multicore on-device profiling
About the Presenters
John Kluza has a background in product management of electrical systems, with experience at Sensata Technologies, Aquion Energy and Satcon Technology Corporation. He currently manages strategic partnerships for embedded hardware companies for MathWorks. John earned a B.S. degree in mechanical engineering from Lehigh University, an M.S. degree in mechanical engineering from Penn State University, and an M.S. in management and engineering from the Sloan School at the Massachusetts Institute of Technology.
Ramesh Ramamoorthy is the Lead Motor Drive System Design Architect with Texas Instruments. Ramesh has wide experience in the design and development of motor drives and power electronics in automotive, industrial and appliance sectors, spanning system architecture design, hardware, software and control systems, and holds three patents. Ramesh earned his bachelor of engineering degree in electrical engineering at the University of Madras and his M.Tech degree in electrical engineer from the Indian Institute of Technology, Madras.
Pradeep Karikere Siddagangaiah is a Development Manager at MathWorks specializing in creating solutions for embedded systems customers. Pradeep joined MathWorks in 2013 and has been building customer solutions that combine MathWorks software with embedded hardware for more than eight years. Pradeep holds a master’s degree in software systems from BITS Pilani, India.
Recorded: 28 Oct 2021
In this webinar, we'll be covering motor control with a multicore TI C2000 microcontroller using Simulink. During this event, we'll show how to use MathWorks tools to solve common multicore microcontroller programming challenges such as partitioning control algorithms across multiple cores, managing inter-processor communications, and synchronizing peripherals.
I'm John Kluza, and I'm the partner manager for MathWorks relationship with TI. In the past, I've been with MathWorks as a consulting engineer and application engineer. Outside of MathWorks, I've also brought several products to market in the electric power space, batteries, inverters, and fault protection. Joining me on the line are Pradeep Siddagangaiah from MathWorks and Ramesh Ramamoorthy from TI who'll get into further depth on the products. We appreciate you signing interview this talk today, and we reserved time for questions at the end, so please type them into the chat as they come up, and we'll address them at the end.
So I'll start off with a brief introduction to MathWorks and MathWorks tools that work with the C2000. Ramesh will then discuss multicore see 2000 devices and some applications they are commonly used in. And then, Pradeep will do a demo session showing how C2000 hardware can be modeled, along with algorithms in Simulink to optimize multicore designs.
MathWorks was started in Natick, Massachusetts in 1984 and headquarters remains there. So the picture in the slide shows the new buildings at headquarters. We've also expanded worldwide to have offices in 16 countries, and recently surpassed $1 billion in revenue. We now have 5,000 employees and over 5 million users. Our flagship products in MATLAB and Simulink, and all the other products we discuss here today are built on top of that foundation. We're excited to continue to accelerate the pace of engineering and science.
MathWorks tools are widely used in industry and commonly taught in academia. We excel where the problems are hard and the consequences are serious. Some of our biggest markets are automotive and aerospace, but we also have large user bases in many other industries. We commonly see multicore motor control come up in many of these industries, especially automotive, industrial machinery, and medical devices.
Now, onto the solutions that are specific to C2000. We offer three products that have C2000 specific support. Our most mature C2000 product is the Embedded Coder Support Package, which has been updated every release with new features and processor support for nearly 20 years. This enables users to automatically generate C code optimized for the C2000, including peripheral drivers from a simulated model by using embedded coders infrastructure. More recently, we've expanded our support for C2000 by offering motor control blockset, which streamlines the development of motor control algorithms, including field oriented control.
Now the focus of this talk will be on this SoC Blockset Support Package for C2000 which adds tools for modeling multicore devices and targeting multiple cores simultaneously for simulating. SoC Blockset Support Package can stand on its own for modeling multicore devices, but it's frequently used with the Embedded Coder Support Package to also generate and deploy C code to the device after modeling it in Simulink. I'll discuss the workflow these tools enable on the next slide.
Metrics tools are often used in a model based design workflow. Model based design has been shown by our customers to reduce time and cost in development, while improving performance of complex systems. The concept of model based design is to use a graphical executable model as one source of truth throughout the design process with everything referencing that same model, from link requirements documents to automatically generated C code.
The model's used to simulate the system frequently as the design evolves, allowing earlier testing and avoiding costly lab time, while addressing issues early in the design process when they're simplest to fix. The same models then used on that to automatically generate code for prototyping on hardware or for deployment in production.
Now in multicore situations the simplest model is used to capture the algorithms for the controller in the plant, as well as the processor hardware architecture. The impact of the hardware architecture can then be observed in simulation at the same time as the system algorithms are being developed. So when the design is ready to be tested on our hardware, implementation is automated with one-click code generation and deployment. Parameter tuning data logging and code profiling on the processor are available from within the model.
When the design is complete and ready for production deployment, customizable optimized production quality code can be generated from the model and integrated with existing hand coded infrastructure. All the code is automatically linked back to the model element that it was produced by for traceability.
Now throughout this process, verification and validation tools in the SoC blockset and Simulink allow the user to do advanced profiling and diagnostics on the model and the generated code, including data on how they run on the multicore hardware. Now Ramesh from TI will tell us more about multicore C2000 devices and their applications.
Hello. Welcome to the introductory presentation on C2000 multicore processors for motor control. This is Ramesh Ramamoorthy, C2000 systems engineer with the Texas Instruments, based in Sugar Land, Texas near Houston.
C2000 micro-controllers are scalable, low latency, real time micro-controllers designed for high-performance control of power electronics systems. This based on 25 years of experience maximizing control efficiency, and enabling higher switching frequency technologies.
That's a broad portfolio from low-cost, small-packaging, high-performance, multi-core packages, covering low to high end application segments. It is architected around the concept of sensing control system feedback signals, then processing the sensory data, then activating the control peripherals. And all these based on communication with external world.
For sensing it has a maximum of for fast and accurate configurable 12 or 16-bit ADCs. It has multiple analog comparators built in with the DACs for reference setting for sensing unsafe operating conditions. It has peripherals to support Quadrature Encoders.
It also has delta sigma filter modules that supports up to sync three. It also has delta sigma filter modules available that supports up to sync three. Our activation, our control. It has multiple, highly flexible, high resolution, variable modules, tightly coupled to sensing units such as UDC and QEP.
For processing, the MCU family can scale from 60 MIPs to 925 MIPs of floating point performance. For communication, there's a wide range of peripherals from SCA, UART, CAN, all the way to USB, EtherCAT, and Ethernet. Expertise is provided through various end equipment, system examples, reference designs, and software libraries.
Currently there are a couple of active multi-core processors from C2000 families available for motor control. They are the F2837x and the F2838x series of MCUs. Each of these MCUs have two C2000 cores. Each core has a floating point unit, the trigonometric math unit, and a CLA, which is a satellite, floating point compute engine, the disposal of each core or offloading some compute intensive tasks.
The F2838x device contains an additional M4 core to deal with communications and housekeeping. Besides, each device has peripherals, and capability to support control, connectivity, and functional safety.
What you see here is a very top level overview of C2000 F2838xD device. It has a dedicated Arm Cortex M4 core to provide fully programmable communication subsystem, consisting of EtherCAT or 10/100 Ethernet MAC. NFD, USB, 200 Mbps FSI, and multiple serial ports.
For real time control, it provides 800 MIPs DSP performance, with the extended 64-bit FPU, and fast trigonometric functions. Besides a range of sensing and control peripherals, or flexible interface to external systems, it has CLBs an acronym for configurable logic block, that provides for FPGA-like customization of digital logics. For functional safety the F2837D core is TUV-certified for ASIL-B.
For security the device has AES hardware accelerator to split up encryption and decryption. What you see here is a very top level view of C2000 F2837xD device. It's pretty similar to the F2838x device, except that it does not have Arm Cortex M4 core and its sequence system. Everything else remaining the same.
For functional safety, it can provide a systematic capability of ASIL-D or SIL-3, and diagnostic coverage of ASIL-B, or SIL-2 are appropriate standards. These devices are fully supported by various hardware and software tools that can be accessed from TI website. For motor control, or digital power control, there are plenty of literature available from TI website. Here I will just highlight the Inter Processor Communication facility, available on chip for cross communication in this multi-core setup.
There are various message RAMs available for Inter Core communication. Between each pair of cores, there are two message RAMs, one for carrying message to the other core, while the second one for receiving message from the other core. For any given message RAM, only one core can write a message, while the other core can only read.
As shown in the diagram above, where CPU1 and CPU2 are the two cores, for CPU1 to send a message to CPU2 we write the message in C1 to C2 message RAM, followed by setting up a flag. And CPU2 sees this flag being set, it will read the message and send an acknowledgment for confirmation. It can also be configured to generate interrupts, if needed.
There are a few other configurations, as well. Some of the potential end applications of the multicore MCU are shown here. They all have multiple requirements in control, connectivity, functional safety, and security, requiring to meet various ISO standards. These require heavy computing power, and powerful set of peripherals.
The representative industrial drive with functional safety is shown here. This is a four axis drive that need to do coordinated motion control based on commands received from an upstream PLC, requiring certain ISO 13849 or IEC 61508 performance metrics. The server motor could be AC induction motor type, or permanent magnet synchronous motor type.
The encoder could be any type. It could be analog or digital. And current sensing could be on the north or bottom side, or interface analog sensing, or it could be delta sigma type. PLC communication could be any of the means discussed here.
In this setup the multi-core processor helps to share the compute burden of control and functional safety across various cores to provide a compact high-end solution. For example, one of the cores can perform all the control actions, while another core could act as one of the safety channels in a multi-safety channel system architecture.
The Cortex M4 core would provide the communication interface needed to work with the upstream PLC. The flexible peripherals, such as the configurable logic block can help interface with various digital encoder types, such as EnDAT, BISS, HDSL, or any other formats. The powerful PWM and ADC peripherals provide precise pulse rates and precisely timed precision feedback measurements for control action.
Fast current loops for high-bandwidth requirements can be implemented using the C2000 core for precise control processing. In brief, we can say that multi-core architecture from C2000 for motor control can support the nuances needed for high-end, high performance, industrial server drives. Thank you.
Hello, and welcome. Thanks, Ramesh, for giving interaction to C2000 multi-core processors, and for initial applications to our viewers. This is Pradeep K S, development manager with MathWorks, based in Bangalore, India. As Ramesh mentioned, multi-core processor helps to share the burden of control and functional safety algorithms across various cores to provide a compact, high-end solution.
The common examples of multi-core usage would be to divide the application into real-time tasks, such as control loops, and non-real time tasks, such as external communications, diagnostics. You can also partition your algorithm to achieve higher loopage. Another option is to implement redundancy for safety critical applications.
Today, we will use the example of BMSM motor control, and look into how you can use a SoC Blockset to partition real time motor control application, to run on multiple cores on DAC F28379D board, and achieve higher BW frequency.
We will also compare the results against a single core application, to show the benefits of the dual core application approach. OK, before we dive into the details, I would like to give you a quick show of the example we will walk through today. This is a shipping example from a SoC Blockset for the BMSM motor field-oriented control.
As John, mentioned SoC Blockset's a support package for TI C2000 enables you to efficiently use complex multi-core C2000 processors, and provides complete model-based, design workflow for multi-core MCUs with a single model from simulation to implementation on the hardware. Hardware component and device driver behavior simulation to uncover implementation issues without core generation. Enhanced on device profiling with streaming, task execution, and CPU utilization information in the STI.
Single-click workflow for multi CPU core generation with synchronization. So also supports F2837xD F2838xD processors as part of the support package. In this example, I'm using a C2000 multi-core processor, F28379D launchpad development kit to verify the behavior on the hardware.
Here you can see F28379D functional block diagram showing the two available cores highlighted in yellow and green, as well as inter-processor communication. Also you see a Simulink model that represents the motor control closed-loop system.
This model simulates dual core motor controller for a permanent magnet synchronous motor inverter system. Before we talk on partitioning, let's understand how a code is represented in the signaling system model shown here. Let's begin with Task Manager block which is highlighted in green.
This block simulates the execution of software tasks as they would be expected to behave on a processor. Tasks can be a timer-driven, or an event-driven. Inside a single reference model block, the timer-driven tasks are represented as rates, and event-driven tasks are represented as function core subsystem.
The Task Manager executes individual tasks based on their parameters such as, period, duration, trigger, priority, or processor code. And the combination of that task with the state of other tasks and their priorities in the running model. Task Manager helps identify timing problems like rate overruns, and undesired rate preemption, in applications with multiple tasks due to resource constraint and task differences.
Simulating multitasking applications with SoC Blockset will help you in detecting these problems early in the development stage. Multi-core model contains at least two Task Manager blocks, each connected to a model reference block representing the process to be run on a separate core. The controller subsystems highlighted in green represents the partition algorithms running on different processors.
The current control is running on core 2, and the speed control and position estimation on core 1, respectively. Here is a functional block diagram of inter-processor communication data transfer in C2000 architecture. Applications running on different cores can utilize the message RAMs, and share the S RAM blocks to pass data between cores at a fixed address known to both the cores.
Now let's see how we can represent the same data exchange model in Simulink. Interpersonal communication consists of data write, data channel, and the data read simulating blocks. These blocks simulate communication between bare metal processors, executing on separate processors. The shared message RAM is represented using IPC data channel blocks, which are highlighted in green color in this model.
IPC data channel block provides a channel for asynchronous data transfer between two processors. This block also generates a task event signal that triggers the Task Manager block to execute the associated event-driven task on the receiving processor. Then the process data write block asynchronously sends messages to another processor in an SoC using an inter-process data channel.
The inter-process data read block asynchronously receives message from another processor in an SoC using an inter-process data channel block. IPC data write and read blocks are part of each core model reference blocks as shown in this picture. The data integrity during this IPC communication is handled using the romic instructions of the processor at the driver level, and with some smart logic.
Associate Blockset also provides simulation of peripheral devices, like ADC, PWM, present on these devices. These block helps in studying the typical design challenges associated with peripherals and scheduling in motor control applications. For example, like ADC, PWM synchronization to achieve current sensing at the midpoint of PWM period, incorporating sensor delays to achieve the desired controller response for the closed loop system, studying different PWM settings while designing special algorithms.
You can address these design problems in simulation phase using system model. Now let's quickly look at these peripheral interface blocks. The ADC block simulates the analog to digital conversion of the hardware board. The input analog signal gets sampled and converted into a representative digital value. But wait, there is more.
A start event message signals the block to sample the input analog voltage signal. When the conversion completes, the block emits the digital representation of the analog signal, and sends an event to a Task Manager block. At this point, a connected task can execute, which is a new ADC sample.
Now let's look at the PWM interface block, which simulates the PWM output of the hardware board. This block gets duty cycle data messages from a connected PWM write block, that can either generate a switching pulse with modulated waveform, or pass the duty cycle value to the output. This block also output a triggering event, which can then be connected to the start port of the ADC interface block to synchronize ADC and PWM events in the closed loop systems.
OK, now let's have a look at the Model Configuration for multi-core application. Click on the system on chip tab, and then click hardware settings to open the configuration parameters window. In the hardware implementation tab, the processing unit parameter is configured to none, indicating that it is the top level system model.
Now let's open one of the Model Configuration parameters window of the reference to model block within the system model to see how it is configured to run on a specific core. In the hardware implementation tab of referenced model, the processing unit parameter could be configured to C28x CPU 1, or C28x CPU2. This means that the process would run on either CPU 1, or CPU 2.
Now we have learned different modeling components of the system model. Let's look at the initial situation, meaning the single core approach, in which we have started with the PWM frequency of 20 kilohertz, and now we want to rise to 40 kilohertz. In this model, motor control algorithm is running on single core.
The generated PWM frequency is 20 kilohertz, and the execution time of current loop task driven by ADC interrupt is taking 26 microseconds. And the execution time of speed loop is 5 microsecond. With this data, now let's run the simulation and view the results in STI.
Now we can see that with 20 kilohertz, everything works fine as expected without a task overrun. And the motor speed is tracking the reference speed. Now let's reverse the PWM frequency to 40 kilohertz, and run the simulation again.
Now the speed feedback from the motor is zero, where it is expected to follow the reference speed highlighted in green color. This is because the current loop task is overrunning, leading to the drop of the speed loop task as shown in the graph on the bottom. Because with 40 kilohertz PWM frequency, the current loop task is expected to finish its execution within 25 microseconds, but it is taking 26 microseconds.
You can also analyze this behavior on the hardware, using task profiling capability of the SoC block set. Therefore to address this issue, let's partition the field oriented control algorithm cross two cores. Is there a meaningful way to partition that algorithm? Yes. Because by looking at our algorithm, the algorithm shows that we have a cascade controller with inner current loop, and an outer speed loop.
This means that we can use these two loops to split the algorithm, and therefore partition it to run on the two available course, as shown on the right side, and also make use of the inter-processor communication between these two cores to exchange data. As I've already said TI 28379D has two cores, and therefore our model contains two Task Manager blocks, and two model reference block, respectively.
Representing the speed loop, which will run on core one, as well as the current loop, which will run on core two. The data transfer between the cores are handled by a inter-process data channel block. Now let's run the simulation of a dual core model with 40 kilohertz, and view the results in STI.
OK, in this figure, you can see that at 40 kilohertz PW frequency, the speed feedback from the motor is tracking the reference value as expected. Now let's proceed with programming the TI LaunchPad board to verify the behavior with the hardware test. We provide a guided workflow app called Associate Builder Tool to either build and deploy, or to run the model in external mode on the hardware.
The Associate Builder Tool steps through the various stages of building and executing an associate model on an MCU board. You can use this tool to configure the peripheral register settings, map model task to interrupt service routines, set up a folder to store all generated files, choose between different build actions, validate that model has all required components for generating a programming file, build the model using TI code composer studio Tools Families, and finally load the programs file to your board and run the application.
Now let's launch the Associate Builder Tool to run the model in external mode to capture the hardware results. Click on the system on chip tab and then click configure, build, and deploy button, to launch the SoC Builder app. You need to assign this event-driven task created in Task Manager to the event sources available with the selected hardware board and your model.
To do this, launch task mapping app from the Associated Builder app. Using the task mapper tool, you can view and edit the assignment of tasks to the microcontroller interrupts. Also check the task to interrupt map of your model for any conflict between tasks. Automatically map tasks to ISS. In this motor control example, you need to map ADC interrupt task to respective ADC module ISR, as shown in this picture.
All timer-driven tasks are mapped to the internal schedule elements. To decouple the targeting information from the modeling, we provide a peripheral configuration app. Using this tool, you can view and edit the assignment of peripherals to MCU peripheral registers. Check the peripheral to register map of your model for any conflicts between peripherals.
Once the tasks and peripherals are configured, follow the instructions on the Associate Builder app to run the model in external mode and view the results in STI viewer. This figure shows the speed responses during a simulation and hardware runs, and compares the results of the single core application running the current loop with 50 microseconds, and a PWM frequency of 20 kilohertz.
Again as the dual core application running the current loop with 50 microsecond, and a PWM frequency of 20 kilohertz, as well as the current loop with 25 microseconds, and the PWM frequency of 40 kilohertz, respectively. On the top left, we can see from simulation results that we don't get an improvement by the dual core approach if the current loop runs by 50 microseconds, and the PWM frequency is set to 20 kilohertz.
But by using the dual core approach and rising the frequency from 20 kilohertz to 40 kilohertz- which wasn't possible using a single core approach- if you maybe remember, we can see from simulation results that the rise time and speed will improve. Last, on the bottom, you can see a comparison of hardware and results, single core, and dual core. Proving that the simulation results and the fact that the dual core approach enables us to use a higher PWM frequency, and therefore achieving a higher sampling rate, which results in an improved rise time and speed.
As you can see now the race time and the speed improves for a faster current loop, which we were able to make it happen by partitioning the FOC algorithm on both the course of the DI board. Well, with this conclusion, I'll let John to close today's webinar with a short summary. Thanks, everyone.
Well Thanks for the presentation, Pradeep. As we just saw in the demo using SoC Blockset to develop applications for TI C2000 micro-controllers, enables and strengthens model-based design. Locks for inter-processor communications and task management, give us the ability to evaluate algorithms running on multi-core TI micro-controllers.
Models for PWMs and ADCs provide the detail and simulation, to predict how applications will run on hardware. And the deployment workflow automates co-generation, compilation, and programming of C2000 boards, where we can analyze performance in hardware. This lets engineers accomplish more using desktop simulation without frequent hardware testing.
Now before we go to Q&A, I'd like to point out where you can go online for more information. We have a landing page on MathWorks.com, with all the TI and C2000 content in one place. And if you need to connect with the team, you can use TI@MathWorks.com. On the TI.com side, there's a C2000 landing page, and each product which has MathWorks support includes a link to more information about MathWorks tools.
Now here I'll quickly open up MathWorks.com, and show you what you might find useful there. So if you go to that link, you'll go to the main TI landing page for the MathWorks. We'll discuss the different parts that we support, and how embedded Coder can support even the ones that don't have built in support. If you go to the link for C2000, then you'll find all of the products that we just discussed.
So you can actually go and click on the SoC Blockset support package page for some further details about it. And it also will give you a link to actually download the package. So this is a free download for existing users of the SoC Blockset.
And similarly, the Embedded Coder support package is a free add-on for existing users of Embedded Coder. If you go back one page, you'll actually see that there is a video-- a getting started video for Embedded Coder, including how to install it. And there's actually a similar behavior for the SoC Blockset.
So hopefully you get a chance to have a look at this on your own.