NXP Semiconductors PMSMRT1180 MCUXpresso SDK Field Oriented Control FOC of 3 Phase PMSM User Guide
- June 16, 2024
- NXP Semiconductors
Table of Contents
- NXP Semiconductors PMSMRT1180 MCUXpresso SDK Field Oriented Control FOC of
- 1. Introduction
- 2 Hardware setup
- 3 Processors features and peripheral settings
- 4 Project file and IDE workspace structure
- 5 Motor-control peripheral initialization
- 6 User interface
- 7 Remote control using FreeMASTER
- 8 Conclusion
- 9 Acronyms and abbreviations
- 10 References
- 11 Useful links
- 12 Revision history
- Legal information
- Read User Manual Online (PDF format)
- Download This Manual (PDF format)
NXP Semiconductors PMSMRT1180 MCUXpresso SDK Field Oriented Control FOC of
3 Phase PMSM User Guide
PMSMRT1180
Document information
1. Introduction
SDK motor control example user guide describes the implementation of the motor-control software for 3-phase Permanent Magnet Synchronous Motors (PMSM) using following NXP platforms:
• i.MX RT1180-EVK (MIMXRT1180-EVK)
• Freedom Development Platform for Low-Voltage, 3-Phase PMSM Motor Control
(FRDM-MC-LVPMSM)
The document is divided into several parts. Hardware setup, processor features, and peripheral settings are described at the beginning of the document. The next part contains the PMSM project description and motor control peripheral initialization. The last part describes user interface and additional example features.
Available motor control examples types with supported motors, and possible control methods are listed in Table 1.
Table 1. Available example type, supported motors and control methods
SDK motor control example description:
• pmsm_enc – pmsm example uses float arithmetic, the example contains sensored
and also sensorless field
oriented vector control (FOC). This example can be used for sensor and
sensorless motor control application
both. Default motor configuration is tuned for the Linix 45ZWN24-40 motor.
The SDK motor control example contains several additional features:
• FreeMASTER pmsm_float_enc.pmpx project provides a simple and user-friendly
way for algorithm tuning, software control, debugging, and diagnostics.
• MCAT – Motor Control Application Tuning page based on the FreeMASTER runtime
debugging tool.
• MID – Motor parameter identification.
The control software and the PMSM control theory, in general, are described in Sensorless PMSM Field- Oriented Control (FOC) (document DRM148).
2 Hardware setup
The following chapter describes the used hardware and the setup needed for proper example working
2.1 Linix 45ZWN24-40 motor
The Linix 45ZWN24-40 motor is a low-voltage 3-phase permanent-magnet motor
with hall sensor used in PMSM applications. The motor parameters are listed in
Table 2.
Table 2. Linix 45ZWN24-40 motor parameters
The motor has two types of connectors (cables). The first cable has three wires and is designated to power the motor. The second cable has five wires and is designated for the hall sensors’ signal sensing. For the PMSM sensorless application, only the power input wires are needed.
2.2 Teknic M-2310P motor
The Teknic M-2310P-LN-04K motor is a low-voltage 3-phase permanent-magnet motor used in PMSM applications. The motor has two feedback sensors (hall and encoder). For information on the wiring of feedback sensors, see the data sheet on the manufacturer webpage. The motor parameters are listed in Table 3.
Table 3. Teknic M-2310P motor parameters
For the sensorless control mode, you only need the power input wires. If used with the hall or encoder sensors, connect the sensor wires to the NXP Freedom power stage.
2.3 FRDM-MC-LVPMSM
In a shield form factor, this evaluation board effectively turns an NXP
Freedom development board or an evaluation board into a complete motor-control
reference design. It is compatible with existing NXP Freedom development
boards and evaluation boards. The Freedom motor-control headers are compatible
with the Arduino R3 pin layout.
The FRDM-MC-LVPMSM low-voltage, 3-phase Permanent Magnet Synchronous Motor (PMSM) Freedom development platform board has a power supply input voltage of 24 VDC to 48 VDC with reverse polarity protection circuitry. The auxiliary power supply of 5.5 VDC is created to supply the FRDM MCU boards. The output current is up to 5 A RMS. The inverter itself is realized by a 3-phase bridge inverter (six MOSFETs) and a 3-phase MOSFET gate driver. The analog quantities (such as the 3-phase motor currents, DC-bus voltage, and DC-bus current) are sensed on this board. There is also an interface for speed and position sensors (encoder, hall). The block diagram of this complete NXP motor-control development kit is shown in Figure 5.
Figure 5. Motor-control development platform block diagram
The FRDM-MC-LVPMSM board does not require a complicated setup. For more information about the Freedom development platform, see www.nxp.com.
Note:
There might be a wrong FRDM-MC-LVPMSM series in the market (series
VV19520XXX). This series is populated with 10 mOhm shunt resistors and noisy
operational amplifiers which affect phase current measurement. The mc_pmsm
example is tuned for original FRDM-MC-LVPMSM board with 20 mOhm shunt
resistors.
2.4 i.MX RT1180 Evaluation Kit
The MIMXRT1180-EVK are two-layer low-cost through-hole USB-powered PCBs. At
its heart lies the i.MX RT11xx crossover MCU. The dual core i.MX RT1180 runs
on the Cortex-M7 core at 800 MHz and Arm Cortex- M33 at 240 MHz, while
providing best-in-class security.
Table 4. MIMXRT1180-EVK jumper settings
All others jumpers are open.
Figure 7. MIMXRT1180-EVK board with highlighted jumper settings
For a correct connection, the motor-control application requires remove and solder some zero resistors. Please, remove and solder zero resistors according table below.
Table 5. Add and remove resistors
For locate resistors on the board see layout on board web page. For more information about the MIMXRT1180- EVK hardware (processor, peripherals, etc.), see the nxp.com
2.4.1 Hardware assembling
1. Connect the FRDM-MC-LVPMSM shield on top of the MIMXRT1180-EVK board
(there is only one possible option).
Note: Watch out for unwanted connections between bottom of FRDM-MC-PMSM and
jumpers on top of MIMXRT11xx-EVK.
2. Connect the 3-phase motor wires to the screw terminals (J7) on the Freedom
PMSM power stage.
3. Plug the USB cable from the USB host to the Debug USB connector J53 on the
EVK board.
4. Plug the 24-V DC power supply to the DC power connector on the Freedom
PMSM power stage.
Figure 8. Assembled Freedome system
Note: The example has been tested on the board with schematic number: SCH-50577 REV C2.
3 Processors features and peripheral settings
This chapter describes the peripheral settings and application timing.
3.1 i.MX RT1180
The i.MX RT series of crossover MCUs are part of the EdgeVerse™ edge computing
platform and feature Arm® Cortex®-M cores, high performance real-time
functionality and MCU usability at a cost-effective price. The i.MX RT1180
crossover MCU family includes a Gb time sensitive networking (TSN) switch to
enable real-time rich networking integration that handles both time-sensitive
and industrial real-time communication. The i.MX RT1180 supports multiple
protocols, bridging communications between real-time Ethernet and industry 4.0
systems. This family includes a state-of-the-art EdgeLock secure enclave, a
dual core architecture with both an 800 MHz Cortex-M7 and a 240 MHz Cortex-M33
for ultimate design flexibility. The i.MX RT1180 is supported by an extensive
developer ecosystem, featuring MCUXpresso software and tools, for an optimal
microcontroller design experience.
For more information, see i.MX RT1180 Crossover MCU Family web pages.
3.1.1 RT1180 – Hardware timing and synchronization
Correct and precise timing is crucial for motor-control applications.
Therefore, the motor-control-dedicated peripherals take care of the timing and
synchronization on the hardware layer. In addition, you can set the PWM
frequencies as a multiple of the ADC interrupt (ADC ISR) frequency where the
FOC algorithm is calculated. In this case, the PWM frequency is equal to the
FOC frequency.
Figure 9. Hardware timing and synchronization on i.MX RT1180
• The top signal shows the PWM_AT (PWM phase A – top) and PWM_AB (PWM phase A – bottom). The dead time is emphasized at the PWM top and PWM bottom signals.
• The eFlexPWM submodule SM0 generates trigger 0 (ADC Trigger) when the
counter counts to a value equal to the VAL4 value. ADC Trigger is delayed of
approximately Tdeatime/2. This delay ensures correct current sampling at the
duty cycles close to 100 %.
• When the ADC conversion is completed, the ADC_ISR (ADC interrupt) is
entered. The FOC calculation is done in this interrupt.
3.1.2 RT1180 – Peripheral settings
This section describes the peripherals used for the motor control. On i.MX
RT1180, three submodules from the enhanced FlexPWM (eFlexPWM) are used for
6-channel PWM generation and two 12-bit ADCs for the phase currents and DC-bus
voltage measurement. The eFlexPWM and ADC are synchronized via submodule 0
from the eFlexPWM. The following settings are located in the mc_periph_init.c
and peripherals.c files and their header files.
3.1.2.1 PWM generation – PWM1
-
Six channels from three submodules are used for the 3-phase PWM generation. Submodule 0 generates the master reload at event every nth opportunity, depending on the user-defined macro M1_FOC_FREQ_VS_PWM_FREQ.
-
Submodules 1 and 2 get their clocks from submodule 0.
-
The counters at submodules 1 and 2 are synchronized with the master reload signal from submodule 0.
-
Submodule 0 is used for synchronization with ADC. The submodule generates the output trigger after the PWM reload, when the counter counts to VAL4.
-
Fault mode is enabled for channels A and B at submodules 0, 1, and 2 with automatic fault clearing.
Note: The PWM outputs are re-enabled at the first PWM reload after the fault input returns to zero. -
The PWM period (frequency) is determined by how long the counter takes to count from INIT to VAL1. By default, INIT = -MODULO/2 and VAL1 = MODULO/2 -1 where MODULO = FastPeripheralClock / M1_PWM_FREQ.
-
Dead time insertion is enabled. Define the dead time length in the M1_PWM_DEADTIME macro.
3.1.2.2 Analog sensing – ADC1 and ADC2
ADC1 and ADC2 are used for the MC analog sensing of currents and DC-bus
voltage.
• The ADCs operate as 12-bit with the single-ended conversion and hardware
trigger selected.
• ADC1 and ADC2 are controlled by the same trigger source. The trigger source
is the PWM submodule 0.
3.1.2.3 Quadrature Decoder (eQDC) module
The QD module is used to sense the position and speed from the encoder sensor.
• The direction of counting is set in the M1_POSPE_ENC_DIRECTION macro.
• The modulo counting and the modulus counting roll-over/under to
increment/decrement revolution counter are enabled.
3.1.2.4 Peripheral interconnection for – XBAR
The crossbar is used to interconnect the trigger from the PWM to the ADC and
to connect the encoder (connected to GPIO) to the QD.
• The PWM output trigger (generated by submodule 0) is configured in pinmux.c.
• The encoder signal Phase A and Phase B are configured in pinmux.c.
3.1.2.5 Slow-loop interrupt generation – TMR1
The QuadTimer module TMR1 is used to generate the slow-loop interrupt.
• The slow loop is usually ten times slower than the fast loop. Therefore, the
interrupt is generated after the counter counts from CNTR0 = 0 to COMP1 =
FastPeripheralClock / (16U * Speed Loop Freq). The speed loop frequency is set
in the M1_SPEED_LOOP_FREQ macro and equals 1000 Hz.
• An interrupt (which serves the slow-loop period) is enabled and generated at
the reload event.
3.2 CPU load and memory usage
The following information applies to the application built using one of the
following IDE: MCUXpresso IDE, IAR, Keil MDK or CodeWarrior. The memory usage
is calculated from the *.map linker file, including FreeMASTER recorder buffer
allocated in RAM. In the MCUXpresso IDE, the memory usage can be also seen
after project build in the Console window. The table below shows the maximum
CPU load of the supported examples. The CPU load is measured using the SYSTICK
timer. The CPU load is dependent on the fast-loop (FOC calculation) and slow-
loop (speed loop) frequencies. The total CPU load is calculated using the
following equations:
CPU load measured without defined RAM_RELOCATION macro. Measured CPU load and memory usage applies to the application built using IAR IDE.
Note: The maximum CPU load is depending on executing functions from RAM or
flash memory. Executing functions can be speeding up in RTCESL_cfg.h header
file by using macro RAM_RELOCATION.
Note: Memory usage and maximum CPU load can differ depending on the used IDEs
and settings.
4 Project file and IDE workspace structure
All the necessary files are included in one package, which simplifies the
distribution and decreases the size of the final package. The directory
structure of this package is simple, easy to use, and organized logically. The
folder structure used in the IDE differs from the structure of the PMSM
package installation, but it uses the same files. The different organization
is chosen due to better manipulation of folders and files in workplaces and
the possibility of adding or removing files and directories. The
packmotor
4.1 PMSM project structure
The directory tree of the PMSM project is shown in below.
Figure 10. Directory tree
The main project folder
packmotor
• iar: for the IAR Embedded Workbench IDE.
• armgcc: for the GNU Arm IDE.
• mdk: for the uVision Keil IDE.
• m1_pmsm_appconfig.h: contains the definitions of constants for the
application control processes,parameters of the motor and regulators, and the
constants for other vector-control-related algorithms. When you tailor the
application for a different motor using the Motor Control Application Tuning
(MCAT) tool, the tool
generates this file at the end of the tuning process.
• main.c: contains the basic application initialization (enabling interrupts),
subroutines for accessing the MCU peripherals, and interrupt service routines.
The FreeMASTER communication is performed in the background infinite loop.
• board.c: contains the functions for the UART, GPIO, and SysTick
initialization.
• board.h: contains the definitions of the board LEDs, buttons, UART instance
used for FreeMASTER, and so on.
• clock_config.c and .h: contains the CPU clock setup functions. These files
are going to be generated by the clock tool in the future.
• mc_periph_init.c: contains the motor-control driver peripherals
initialization functions that are specific for the board and MCU used.
• mc_periph_init.h: header file for mc_periph_init.c. This file contains the
macros for changing the PWM period and the ADC channels assigned to the phase
currents and board voltage.
• freemaster_cfg.h: the FreeMASTER configuration file containing the
FreeMASTER communication and features setup.
• pin_mux and .h: port configuration files. Generate these files in the pin
tool.
• peripherals.c and .h: MCUXpresso Config Tool configuration files.
The main motor-control folder
packmotor
• pmsm: contains main PMSM motor-control functions.
• freemaster: contains the FreeMASTER project file pmsm_float_enc.pmpx. Open
this file in the FreeMASTER tool and use it to control the application. The
folder also contains the auxiliary files for the MCAT tool.
The packmotor
• mc_algorithms: contains the main control algorithms used to control the FOC
and speed control loop.
• mc_cfg_template: contains templates for MCUXpresso Config Tool components.
• mc_drivers: contains the source and header files used to initialize and run
motor-control applications.
• mc_identification: contains the source code for the automated parameter-
identification routines of the motor.
• mc_state_machine: contains the software routines that are executed when the
application is in a particular state or state transition.
• state_machine: contains the state machine functions for the FAULT,
INITIALIZATION, STOP, and RUN states.
5 Motor-control peripheral initialization
The motor-control peripherals are initialized by calling the MCDRV_Init_M1() function during MCU startup and before the peripherals are used. All initialization functions are in the mc_periph_init.c source file and the mc_periph_init.h header file. The definitions specified by the user are also in these files. The features provided by the functions are the 3-phase PWM generation and 3-phase current measurement, as well as the DC-bus voltage and auxiliary quantity measurement. The principles of both the 3-phase current measurement and the PWM generation using the Space Vector Modulation (SVM) technique are described in Sensorless PMSM Field-Oriented Control (document DRM148).
The mc_periph_init.h header file provides the following macros defined by the
user:
• M1_MCDRV_ADC_PERIPH_INIT: this macro calls ADC peripheral initialization.
• M1_MCDRV_PWM_PERIPH_INIT: this macro calls PWM peripheral initialization.
• M1_MCDRV_QD_ENC: this macro calls QD peripheral initialization.
• M1_PWM_FREQ: the value of this definition sets the PWM frequency.
• M1_FOC_FREQ_VS_PWM_FREQ: enables you to call the fast-loop interrupt at
every first, second, third, or nth PWM reload. This is convenient when the PWM
frequency must be higher than the maximal fast-loop interrupt.
• M1_SPEED_LOOP_FREQ: the value of this definition sets the speed loop
frequency (TMR1 interrupt).
• M1_PWM_DEADTIME: the value of the PWM dead time in nanoseconds.
• M1_PWM_PAIR_PH[A..C]: these macros enable a simple assignment of the
physical motor phases to the PWM periphery channels (or submodules). You can
change the order of the motor phases this way.
• M1_ADC[1,2]PH[A..C]: these macros assign the ADC channels for the phase
current measurement.
The general rule is that at least one-phase current must be measurable on both
ADC converters, and the two remaining phase currents must be measurable on
different ADC converters. The reason for this is that the selection of the
phase current pair to measure depends on the current SVM sector. If this rule
is broken, a preprocessor error is issued. For more information about the
3-phase current measurement, see Sensorless PMSM Field-Oriented Control
(document DRM148).
• M1_ADC[1,2]_UDCB: this define is used to select the ADC channel for the
measurement of the DC-bus voltage.
In the motor-control software, the following API-serving ADC and PWM
peripherals are available:
• The available APIs for the ADC are:
– mcdrv_adc_t: MCDRV ADC structure data type.
– void M1_MCDRV_ADC_PERIPH_INIT(): this function is by default called during
the ADC peripheral initialization procedure invoked by the MCDRV_Init_M1()
function and should not be called again after the peripheral initialization is
done.
– void M1_MCDRV_CURR_3PH_CHAN_ASSIGN(mcdrv_adc_t): calling this function
assigns proper ADC channels for the next 3-phase current measurement based on
the SVM sector.
– void M1_MCDRV_CURR_3PH_CALIB_INIT(mcdrv_adc_t): this function initializes
the phase-current
channel-offset measurement.
– void M1_MCDRV_CURR_3PH_CALIB(mcdrv_adc_t): this function reads the current
information from the unpowered phases of a stand-still motor and filters them
using moving average filters. The goal is to obtain the value of the
measurement offset. The length of the window for moving the average filters is
set to eight samples by default.
– void M1_MCDRV_CURR_3PH_CALIB_SET(mcdrv_adc_t): this function asserts the
phase-current measurement offset values to the internal registers. Call this
function after a sufficient number of M1_MCDRV_CURR_3PH_CALIB() calls.
– void M1_MCDRV_ADC_GET(mcdrv_adc_t): this function reads and calculates the
actual values of the 3-phase currents, DC-bus voltage, and auxiliary quantity.
• The available APIs for the PWM are:
– mcdrv_pwma_pwm3ph_t: MCDRV PWM structure data type.
– void M1_MCDRV_PWM_PERIPH_INIT: this function is by default called during the
PWM periphery initialization procedure invoked by the MCDRV_Init_M1()
function.
– void M1_MCDRV_PWM3PH_SET(mcdrv_pwma_pwm3ph_t): this function updates the
PWM phase duty cycles.
– void M1_MCDRV_PWM3PH_EN(mcdrv_pwma_pwm3ph_t): this function enables all PWM
channels.
– void M1_MCDRV_PWM3PH_DIS(mcdrv_pwma_pwm3ph_t): this function disables all
PWM channels.
– bool_t M1_MCDRV_PWM3PH_FLT_GET(mcdrv_pwma_pwm3ph_t): this function returns
the state of the overcurrent fault flags and automatically clears the flags
(if set). This function returns true when an overcurrent event occurs.
Otherwise, it returns false.
• The available APIs for the quadrature encoder are:
– mcdrv_qd_enc_t: MCDRV QD structure data type.
– void M1_MCDRV_QD_PERIPH_INIT(): this function is by default called during
the QD periphery initialization procedure invoked by the MCDRV_Init_M1()
function.
– void M1_MCDRV_QD_GET(mcdrv_qd_enc_t): this function returns the actual
position and speed.
– void M1_MCDRV_QD_SET_DIRECTION(mcdrv_qd_enc_t): this function sets the
direction of the quadrature encoder.
– void M1_MCDRV_QD_SET_PULSES(mcdrv_qd_enc_t): this function sets the number
of pulses of the quadrature encoder.
– void M1_MCDRV_QD_CLEAR(mcdrv_qd_enc_t*): this function clears the internal
variables and decoder counter.
Note: Not all macros are available for every motor control example type.
6 User interface
The application contains the demo mode to demonstrate motor rotation. You can operate it either using the user button, or using FreeMASTER. The NXP development boards include a user button associated with a port interrupt (generated whenever one of the buttons is pressed). At the beginning of the ISR, a simple logic executes and the interrupt flag clears. When you press the button, the demo mode starts. When you press the same button again, the application stops and transitions back to the STOP state.
The other way to interact with the demo mode is to use the FreeMASTER tool.
The FreeMASTER application consists of two parts: the PC application used for
variable visualization and the set of software drivers running in the embedded
application. The serial interface transfers data between the PC and the
embedded application.
This interface is provided by the debugger included in the boards.
The application can be controlled using the following two interfaces:
• The user button on the development board (controlling the demo mode):
– MIMXRT1180-EVK – SW8
• Remote control using FreeMASTER (Following chapter):
– Setting a variable in the FreeMASTER Variable Watch. See chapter Section 7.4
Identify all motor parameters if you are using your own motor (different from
the default motors). The automated parameter identification is described in
the following sections.
7 Remote control using FreeMASTER
This section provides information about the tools and recommended procedures
to control the sensor/ sensorless PMSM Field-Oriented Control (FOC)
application using FreeMASTER. The application contains the embedded-side
driver of the FreeMASTER real-time debug monitor and data visualization tool
for communication with the PC. It supports non-intrusive monitoring, as well
as the modification of target variables in real time, which is very useful for
the algorithm tuning. Besides the target-side driver, the FreeMASTER tool
requires the installation of the PC application as well. You can download the
latest version of FreeMASTER at www.nxp.com/freemaster. To run the FreeMASTER
application including the MCAT tool, double-click the pmsm_float_enc.pmpx file
located in the middleware\motor_control\freemaster folder. The FreeMASTER
application starts and the environment is created automatically, as defined in
the *.pmpx file.
Note: In MCUXpresso, the FreeMASTER application can run directly from IDE in
motor_control/freemaster folder.
7.1 Establishing FreeMASTER communication
The remote operation is provided by FreeMASTER via the USB interface. To
control a PMSM motor using FreeMASTER, perform the steps below:
1. Download the project from your chosen IDE to the MCU and run it.
2. Open the FreeMASTER project pmsm_float_enc.pmpx . The PMSM project uses
the TSA by default, so it is not necessary to select a symbol file for
FreeMASTER.
3. To establish the communication, click the communication button (the green
“GO” button in the top left-hand corner).
Figure 13. FreeMASTER communication setup window
2. Ensure, that your computer is communicating with the plugged board. Unplug and then plug in the USB cable and reopen the FreeMASTER project.
7.2 TSA replacement with ELF file
The FreeMASTER project for motor control example uses Target-Side Addressing
(TSA) information about variable objects and types to be retrieved from the
target application by default. With the TSA feature, you can describe the data
types and variables directly in the application source code and make this
information available to the FreeMASTER tool. The tool can then use this
information instead of reading symbol data from the application’s ELF/Dwarf
executable file.
FreeMASTER reads the TSA tables and uses the information automatically when an
MCU board is connected.
A great benefit of using the TSA is no issues with the correct path to
ELF/Dwarf file. The variables described by TSA tables may be read-only, so
even if FreeMASTER attempts to write the variable, the target MCU side denies
the value. The variables not described by any TSA tables may also become
invisible and protected even for read-only access.
The use of TSA means more memory requirements for the target. If you do not want to use the TSA feature, you must modify the example code and FreeMASTER project.
To modify the example code, follow the steps below:
1. Open motor control project and rewrite macro FMSTR_USE_TSA from 1 to 0 in
freemaster_cfg.h file.
2. Build, download, and run motor control project.
3. Open FreeMASTER project and click to Project > Options (or use shortcut
Ctrl+T).
4. Click to MAP Files tab and find Default symbol file (ELF/Dwarf executable
file) located in IDE output folder.
Figure 14. Default symbol file
5. Click OK and restart the FreeMASTER communication.
For more information, check FreeMASTER User Guide.
7.3 Motor Control Aplication Tuning interface (MCAT)
The PMSM sensor/sensorless FOC application can be easily controlled and tuned
using the Motor Control Application Tuning (MCAT) plug-in for PMSM. The MCAT
for PMSM is a user-friendly page, which runs within the FreeMASTER. The tool
consists of the tab menu and workspace as shown in Figure 15. Each tab from
the tab menu (4) represents one submodule which enables tuning or controlling
different application aspects. Besides the MCAT page for PMSM, several scopes,
recorders, and variables in the project tree (5) are predefined in the
FreeMASTER project file to further the motor parameter tuning and debugging
simplify. When the FreeMASTER is not connected to the target, the “Board
found” line (2) shows “Board ID not found”. When the communication with the
target MCU is established, the “Board found” line is read from Board ID
variable watch and displayed. If the connection is established and the board
ID is not shown, press F5 to reload the MCAT HTML page.
There are three action buttons in MCAT (3):
• Load data – MCAT input fields (for example, motor parameters) are loaded
from mX_pmsm_appconfig.h file (JSON formatted comments). Only existing
mX_pmsm_appconfig.h files can be selected for loading. Loaded
mX_pmsm_appcofig.h file is displayed in grey field (7).
• Save data – MCAT input fields (JSON formatted comments) and output macros
are saved to mX_pmsm_appconfig.h file. Up to 9 files (m1-9_pmsm_appconfig.h)
can be selected. A pop-up window with the user motor ID and description
appears when a different mX_pmsm_appcofig.h file is selected. The motor ID and
description are also saved in mX_pmsm_appcofig.h as a JSON comment. The
embedded code includes m1_pmsm_appcofig.h only at single motor control
application. Therefore, saving to higher indexed mX_pmsm_appconfig.h files has
no effect at the compilation stage.
• Update target – writes the MCAT calculated tuning parameters to FreeMASTER
Variables, which effectively updates the values on target MCU. These tuning
parameters are updated in MCU’s RAM. To write these tuning parameters to MCU’s
flash memory, m1_pmsm_appcofig.h must be saved, code recompiled, and
downloaded to MCU.
Note: Path to mX_pmsm_appcofig.h file also composed from Board ID value.
Therefore, FreeMASTER must be connected to the target, and Board ID value read
prior using Save/Load buttons.
Note: Only Update target button updates values on the target in real time.
Load/Save buttons operate with mX_pmsm_appcofig.h file only.
Note: MCAT may require Internet connection. If no Internet connection is
available, CSS and icons may not be properly loaded.
Figure 15. FreeMASTER + MCAT layout
1. Tab content
2. Connected board
3. User buttons
4. Tab menu
5. Project tree
6. Variable watch
7. Loaded configuration
In the default configuration, the following tabs (4) are available:
- Application concept: welcome page with the PMSM sensor/sensorless FOC diagram and a short application description.
- Parameters: this page enables you to modify the motor parameters, hardware and application scales specification, alignment, and fault limits.
- Current loop: current loop PI controller gains and output limits.
- Speed loop: this tab contains fields for the specification of the speed controller proportional and integral gains, as well as the output limits and parameters of the speed ramp. The position proportional controller constant is also set here.
- Sensors: this page contains the encoder parameters and position observer parameters.
- Sensorless: this page enables you to tune the parameters of the BEMF observer, tracking observer, and open-loop startup.
- Output file: this tab shows all the calculated constants that are required by the PMSM sensor/sensorless FOC application. It is also possible to generate the m1_pmsm_appconfig.h file, which is then used to preset all application parameters permanently at the project rebuild.
- Online update : this tab shows actual values of variables on target and new calculated values, which can be used to update the target variables.
Every sublock in FreeMASTER project tree (5) has defined several variables in
variable watch (6).
The following sections provide simple instructions on how to identify the
parameters of a connected PMSM motor and how to tune the application
appropriately.
7.3.1 MCAT tabs description
This chapter describes MCAT input parameters and equations used to calculate
MCAT output (generated) parameters. In the default configuration, the below
described tabs are available. Some tabs may be missing if not supported in the
embedded code. There are general constants used at MCAT calculations listed in
the following table:
Table 8. Constants used in equations
7.3.1.1 Application concept
This tab is a welcome page with the PMSM sensor/sensorless FOC diagram and a
short description of the application.
7.3.1.2 Parameters
This tab enables modification of motor parameters, specification of hardware
and application scales, alignment, and fault limits. All inputs are described
in the following table. MCAT group and MCAT name help to locate the parameter
in MCAT layout. Equation name represents the input parameter in equations
below.
Table 9. Parameters tab inputs
Output equations (applies for saving to mX_pmsm_appcofig.h and also for
updating a corresponding FreeMASTER variable):
• M1_U_MAX = UdcbMax / UmaxCoeff
• M1_FREQ_MAX = Nmax / 60 Pp
• M1_ALIGN_DURATION = AlignDuration / speedLoopSampleTime
• M1_CALIB_DURATION = CalibDuration / speedLoopSampleTime
• M1_FAULT_DURATION = FaultDuration / speedLoopSampleTime
• M1_FREEWHEEL_DURATION = FreewheelDuration / speedLoopSampleTime
• M1_E_BLOCK_PER = EblockPer
• M1_SPEED_ANGULAR_SCALE = 60 / (Pp 2 pi)
• M1_N_MIN = Nmin / 60 (Pp 2 pi)
• M1_N_MAX = Nmax / 60 (Pp 2 pi)
• M1_N_ANGULAR_MAX = (60 / (Pp 2 pi))
• M1_N_NOM = Nnom / 60 (Pp 2 pi)
• M1_N_OVERSPEED = Nover / 60 (Pp 2 pi)
• M1_UDCB_IIR_B0 = (2 pi UdcbIIRf0 currentLoopSampleTime) / (2 + (2 * pi
- UdcbIIRf0 currentLoopSampleTime))
• M1_UDCB_IIR_B1 = (2 pi UdcbIIRf0 currentLoopSampleTime) / (2 + (2 * pi - UdcbIIRf0 * currentLoopSampleTime))
• M1_UDCB_IIR_A1 = -(2 pi UdcbIIRf0 * currentLoopSampleTime – 2) / (2 + (2
- pi UdcbIIRf0 currentLoopSampleTime))
• M1_SCALAR_VHZ_FACTOR_GAIN = UphNomk_factor/100/(NnomPp/60)
• M1_SCALAR_INTEG_GAIN = 2piPpNmax/60currentLoopSampleTime/pi
• M1_SCALAR_RAMP_UP = speedLoopIncUpcurrentLoopSampleTime/60Pp
• M1_SCALAR_RAMP_DOWN = speedLoopIncDowncurrentLoopSampleTime/60Pp
7.3.1.3 Current loop
This tab enables current loop PI controller gains and output limits tuning.
All inputs are described in the following table. MCAT group and MCAT name help
to locate the parameter in MCAT layout. Equation name represents the input
parameter in equations bellow.
Table 10. Current loop tab input
Output equations (applies for saving to mX_pmsm_appcofig.h and also for
updating a corresponding FreeMASTER variable):
• M1_CLOOP_LIMIT = currentLoopOutputLimit / UmaxCoeff / 100
• M1_D_KP_GAIN = (2 currentLoopKsi 2 pi currentLoopF0 Ld) – Rs
• M1_D_KI_GAIN = (2 pi currentLoopF0)^2 Ld currentLoopSampleTime /
DiscMethodFactor
• M1_Q_KP_GAIN = (2 currentLoopKsi 2 pi currentLoopF0 Lq) – Rs
• M1_Q_KI_GAIN = (2 pi currentLoopF0)^2 Lq currentLoopSampleTime /
DiscMethodFactor
7.3.1.4 Speed loop
This tab enables speed loop PI controller gains and output limits tuning,
required speed ramp parameters, feedback speed filter tuning, and position P
controller gain tuning (available at sensored/encoder applications only). MCAT
group and MCAT name help to locate the parameter in MCAT layout. Equation name
represents the input parameter in equations bellow.
Table 11. Speed loop tab input
Output equations (applies for saving to mX_pmsm_appcofig.h and also for
updating a corresponding FreeMASTER variable):
• varKt = 3 Ke / (sqrt(3))
• M1_SPEED_PI_PROP_GAIN = (2 pi / 60 (4 speedLoopKsi pi speedLoopF0)
- J / varKt)
• M1_SPEED_PI_INTEG_GAIN = (2 pi / 60 ((2 pi speedLoopF0) (2 pi speedLoopF0) J) / (varKt 10) speedLoopSampleTime)
• M1_SPEED_RAMP_UP = (speedLoopIncUp speedLoopSampleTime / (60 / (Pp 2 pi)))
• M1_SPEED_RAMP_DOWN = (speedLoopIncDown speedLoopSampleTime / (60 / (Pp * 2 - pi)))
• M1_SPEED_IIR_B0= (2 pi speedLoopCutOffFreq * currentLoopSampleTime) / (2
- (2 pi speedLoopCutOffFreq currentLoopSampleTime))
• M1_SPEED_IIR_B1 = (2 pi speedLoopCutOffFreq currentLoopSampleTime) / (2 + (2 pi speedLoopCutOffFreq currentLoopSampleTime))
• M1_SPEED_IIR_A1 = -(2 pi speedLoopCutOffFreq currentLoopSampleTime –
- / (2 + (2 pi speedLoopCutOffFreq * currentLoopSampleTime))
7.3.1.5 Sensors
Available at sensored (encoder) applications only. This tab enables setting
the encoder properties and tuning encoder’s tracking observer. MCAT group and
MCAT name help to locate the parameter in MCAT layout. Equation name
represents the input parameter in equations bellow.
Table 12. Sensors tab input
Output equations (applies for saving to mX_pmsm_appcofig.h and also for
updating a corresponding FreeMASTER variable):
• M1_POSPE_KP_GAIN = (4.0 pi sensorObsrvParKsi sensorObsrvParF0)
• M1_POSPE_KI_GAIN = ((2pisensorObsrvParF0)^2 sensorObsrvParSampleTime)
• M1_POSPE_INTEG_GAIN = (sensorObsrvParSampleTime / pi / DiscMethodFactor)
• M1_POSPE_ENC_N_MIN = sensorEncNmin
• M1_POSPE_MECH_POS_GAIN = (32768/((sensorEncPulseNumber*4)/2))
7.3.1.6 Sensorless
This tab enables BEMF observer and Tracking observer parameters tuning and
open-loop startup tuning. MCAT group and MCAT name help to locate the
parameter in MCAT layout. Equation name represents the input parameter in
equations bellow.
Table 13. Sensorless tab input
Output equations (applies for saving to mX_pmsm_appcofig.h and also for updating a corresponding FreeMASTER variable):
• M1_I_SCALE = (Ld / (Ld + currentLoopSampleTime Rs))
• M1_U_SCALE = (currentLoopSampleTime / (Ld + currentLoopSampleTime Rs))
• M1_E_SCALE = (currentLoopSampleTime / (Ld + currentLoopSampleTime Rs))
• M1_WI_SCALE = (Lq currentLoopSampleTime / (Ld + currentLoopSampleTime
Rs))
• M1_BEMF_DQ_KP_GAIN = ((2 sensorlessBemfObsrvKsi 2 pi
sensorlessBemfObsrvF0 Ld – Rs))
• M1_BEMF_DQ_KI_GAIN = (Ld (2 pi sensorlessBemfObsrvF0)^ 2
currentLoopSampleTime)
• M1_TO_KP_GAIN = 2 sensorlessTrackObsrvKsi 2 pi
sensorlessTrackObsrvF0
• M1_TO_KI_GAIN = ((2 pi sensorlessTrackObsrvF0)^ 2)
currentLoopSampleTime
• M1_TO_THETA_GAIN = (currentLoopSampleTime / pi)
• M1_OL_START_RAMP_INC = (sensorlessStartupRamp currentLoopSampleTime / (60
/ (Pp 2 pi)))
• M1_MERG_SPEED_TRH = (sensorlessMergingSpeed / (60 / (Pp 2 pi)))
• M1_MERG_COEFF = ((sensorlessMergingCoeff / 100) sensorlessMergingSpeed
Pp
currentLoopSampleTime) / 60
• TO_IIR_cutoff_freq = 1 / (2 speedLoopSampleTime) 0.8
• M1_TO_SPEED_IIR_B0 = (2 pi TO_IIR_cutoff_freq currentLoopSampleTime) /
(2 + (2 pi
TO_IIR_cutoff_freq currentLoopSampleTime))
• M1_TO_SPEED_IIR_B1 = (2 pi TO_IIR_cutoff_freq currentLoopSampleTime) /
(2 + (2 pi
TO_IIR_cutoff_freq currentLoopSampleTime))
• M1_TO_SPEED_IIR_A1 = -(2 pi TO_IIR_cutoff_freq currentLoopSampleTime –
2) / (2 + (2 pi
TO_IIR_cutoff_freq * currentLoopSampleTime))
7.4 Motor Control Modes – How to run motor
In the “Project Tree”, you can choose between the scalar and FOC control using
the appropriate FreeMASTER tabs. The FreeMASTER variables can control the
application, corresponding to the control structure selected in the FreeMASTER
project tree. This is useful for application tuning and debugging. The
required control structure must be selected in the “M1 MCAT Control” variable.
To turn on or off the application, use “M1 Application Switch” variable.
Set/clear “M1 Application Switch” variable also enables/disables all PWM
channels.
Before motor starts, several conditios have to be completed:
1. Connected power supply to the inverter with the correct voltage value.
2. If you want to use sensored control (encoder feedback), connect the
encoder to the inverter.
3. No pending fault. Check variable “M1 Fault Pending” in “Motor M1” project tree subblock. If there is some value, first remove the cause of the fault, or disable fault checking. (for example in variable “M1 Fault Enable Blocked Rotor”)
7.4.1 Scalar control
The scalar control diagram is shown in figure below. It is the simplest type
of motor-control techniques. The ratio between the magnitude of the stator
voltage and the frequency must be kept at the nominal value. Therefore, the
control method is sometimes called Volt per Hertz (or V/Hz). The position
estimation BEMF observer and tracking observer algorithms run in the
background, even if the estimated position information is not directly used.
This is useful for the BEMF observer tuning. For more information, see the
Sensorless PMSM Field-
Oriented Control (document DRM148).
For run motor in scalar control, follow these steps:
1. Switch project tree subblock on “Scalar & Voltage Control”.
2. Switch variable “M1 MCAT Control” on “SCALAR_CONTROL”.
3. In variable “M1 Scalar Freq Required” set required frequency. (i.e. 20Hz)
4. Set variable “M1 Application Switch” to “1”. Motor start spinning.
5. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.4.2 Open loop control mode
Open loop mode (its diagram is shown in figure below) is similar in function
to the Scalar control mode. However, it provides more flexibility in
specifying required parameters. This mode allows you to set specific angle and
frequency, according to the following equation:
Besides setting voltage in DQ axis, when using this mode you can also enable current controllers and specify required currents in D and Q axis. Therefore, this function can be utilized for current controller parameter tuning.
Please, bear in mind that current controllers cannot be enabled/disabled in SPIN state (user must turn the Application Switch OFF before enabling/disabling current controllers).
For run motor in Voltage – Open loop control, follow these steps:
1. Switch project tree subblock on “Openloop Control”.
2. Switch variable “M1 MCAT Control” on “OPEN_LOOP”.
3. In variable “M1 Openloop Required Ud” and “M1 Openloop Required Uq” set
required values.
4. In variable “M1 Openloop Theta Electrical” set required initial position.
5. In variable “M1 Openloop Required Frequency Electrical” set required
frequency.
6. Set variable “M1 Application Switch” to “1”. Motor start spinning.
7. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
For run motor in Current – Open loop control, follow these steps:
1. Switch project tree subblock on “Openloop Control”.
2. Switch variable “M1 MCAT Control” on “OPEN_LOOP”.
3. Set variable “M1 Openloop Use I Control” to “1”.
4. In variable “M1 Openloop Required Id” and “M1 Openloop Required Iq” set
required values.
5. In variable “M1 Openloop Theta Electrical” set required initial position.
6. In variable “M1 Openloop Required Frequency Electrical” set required
frequency.
7. Set variable “M1 Application Switch” to “1”. Motor start spinning.
8. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.4.3 Voltage control
The block diagram of the voltage FOC is shown in Figure 19. Unlike the scalar
control, the position feedback is closed using the BEMF observer and the
stator voltage magnitude is not dependent on the motor speed. Both the d-axis
and q-axis stator voltages can be specified in the “M1 MCAT Ud Required” and
“M1 MCAT Uq Required” fields. This control method is useful for the BEMF
observer functionality check.
For run motor in voltage control, follow these steps:
1. Switch project tree subblock on “Scalar & Voltage Control”.
2. Switch variable “M1 MCAT Control” on “VOLTAGE_FOC”.
3. In variable “M1 MCAT Uq Required” and “M1 MCAT Ud Required” set required
voltages.
4. Set variable “M1 Application Switch” to “1”. Motor start spinning.
5. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.4.4 Current (torque) control
The current FOC (or torque) control requires the rotor position feedback and
the currents transformed into a dq reference frame. There are two reference
variables (“M1 MCAT Id Required” and “M1 MCAT Iq Required”) available for the
motor control, as shown in Figure 20. The d-axis current component “M1 MCAT Id
Required” controls the rotor flux. The q-axis current component of the current
“M1 MCAT Iq Required” generates torque and, by its application, the motor
starts running. By changing the polarity of the current “M1 MCAT Iq Required”,
the motor changes the direction of rotation. Supposing the BEMF observer is
tuned correctly, the current PI controllers can be tuned using the current FOC
control structure.
For run motor in current control, follow these steps:
1. Switch project tree subblock on “Current Control”.
2. Switch variable “M1 MCAT Control” on “CURRENT_FOC”.
3. In variable “M1 MCAT Iq Required” and “M1 MCAT Id Required” set required
currents.
4. Set variable “M1 Application Switch” to “1”. Motor start spinning.
5. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.4.5 Speed FOC control
As shown in Figure 21, the speed PMSM sensor/sensorless FOC is activated by
enabling the speed FOC control structure. Enter the required speed into the
“M1 Speed Required” field. The d-axis current reference is held at 0 during
the entire FOC operation.
For run motor in speed FOC control, follow these steps:
1. Switch project tree subblock on “Speed Control”.
2. Switch variable “M1 MCAT Control” on “SPEED_FOC”.
3. Choose between sensored and sensorless control in variable “M1 MCAT POSPE
Sensor”.
4. In variable “M1 Speed Required” set the required speed. (i.e. 1000rpm).
The motor automatically starts spinning.
5. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.4.6 Position (servo) control
The position of PMSM sensor FOC is shown in Figure 22 (available for
sensored/encoder based applications only). The position control using the P
controller can be tuned in the “Speed loop” menu tab. An encoder sensor is
required for the feedback. Without the sensor, the position control does not
work. A braking resistor is missing on the FRDM-MC-LVPMSM board. Therefore, it
is necessary to set a soft speed ramp (in the “Speed loop”
menu tab) because the voltage on the DC-bus can rise when braking the quickly
spinning shaft. It may cause an overvoltage fault.
For run motor in position (servo) control, follow these steps:
1. Switch project tree subblock on “Position Control”.
2. Switch variable “M1 MCAT Control” on “POSITION_CNTRL”.
3. Swich variable “M1 MCAT POSPE Sensor” to “Encoder [1]”.
4. In variable “M1 Position Required” set the required psition. (i.e. 10
revs).
5. Set variable “M1 Application Switch” to “1”. The motor starts and
automatically stops in the required position.
6. Change “M1 Encoder Direction” if the motor does not spin. (See chapter
Section 7.10.1)
7. Observe motor speed, position, phase currents and other graphs predefined
in subblock scopes and recorders.
7.5 Faults explanation
When the motor is running or during the tuning process, there may be several
fault conditions. Therefore, the motor-control example has an integrated fault
indication located in the variable watch of the “Motor M1” FreeMASTER
subblock. If a fault is indicated, state machine enters the FAULT state.
7.5.1 Variable “M1 Fault Pending”
It shows actually persisting faults, which means that the fault indicated
during fault conditions is accomplished.
For example, if the source voltage is still under the undervoltage fault threshold, the undervoltage pending fault is shown. If the fault condition disappears, the fault pending is cleared automatically. “M1 Fault Pending” is shown in a binary format in the FreeMASTER variable watch. Each place in the variable denotes a different fault condition.
- b 0000 0001 – the overcurrent fault is indicated. If the overcurrent fault is present, the PWMs are automatically disabled. The fault occurs when the DC-Bus current exceeds the Imax value (current-sensing HW scale).
- b 0000 0010 – the undervoltage fault is indicated. The undervoltage fault occurs when the UDCBus voltage (source voltage) is lower than the U DCB under threshold.
- b 0000 0100 – the overvoltage fault is indicated. The overvoltage fault occurs when the UDCBus voltage (source voltage) is higher than the U DCB over threshold.
- b 0000 1000 – the overload fault is indicated. The overload fault occurs when the rotor is overloaded.
- b 0001 0000 – the overspeed fault is indicated. The overspeed fault occurs when the rotor speed exceeds the N over threshold.
- b 0010 0000 – the block rotor fault is indicated. The block rotor fault occurs when the back-EMF voltage is lower than the E block threshold and the duration of the drop is longer than E block per.
Figure 24. Undervoltage fault is indicated (pending)
7.5.2 Variable “M1 Fault Captured”
If any fault condition appears, the fault captured is indicated. Similar to
fault pending, fault captured is shown in the BIN format, but every fault type
has its own variable (“M1 Fault Captured Over Curent” and others). For
example, if the undervoltage fault condition is accomplished, fault captured
is indicated. Fault captured is also indicated after the undervoltage fault
condition disappears. The captured faults are cleared manually by writing
“Clear [1]” to “M1 Fault Clear”.
Figure 25. Undervoltage fault is captured
7.5.3 Variable “M1 Fault Enable”
The fault indication can be unwanted during the tuning process. Therefore, the
fault indication can be disabled by writing “Disabled [0]” to the “M1 Fault
Enable” variables.
Note: The overcurrent fault cannot be disabled.
Note: Fault thresholds are located in the “MCAT parameters” tab.
7.6 Initial motor parameters and harware configuration
Motor control examples contain two or more configuration files:
m1_pmsm_appconfig.h,
m2_pmsm_appconfig.h, and so on. Each contains constants tuned for the selected
motor (Linix 45ZWN24-40 or Teknic M-2310P for the Freedom development platform
and Mige 60CST-MO1330 for the High-voltage platform). The initial motor
parameters and the hardware configuration (inverter) are to MCAT loaded from
m1_pmsm_appconfig.h configuration file. There are tree ways to change motor
configuration corresponding
to the connected motor.
1. The first way is rename the configuration file:
• In the project example folder, find configuration file to be used.
• Rename this configuration file to m1_pmsm_appconfig.h.
• Rebuild project and load the code to the MCU.
2. The second way is to change motor configuration, as described in Section
7.3.
3. The last way is change motor and hardware parameters manually:
• Open the PMSM control application FreeMASTER project containing the
dedicated MCAT plug-in module.
• Select the “Parameters” tab.
• Specify the parameters manually. The motor parameters can be obtained from
the motor data sheet or using the PMSM parameters measurement procedure
described in PMSM Electrical Parameters Measurement (document AN4680). All
parameters provided in Table 14 are accessible. The motor inertia J expresses
the overall system inertia and can be obtained using a mechanical measurement.
The J parameter is used to calculate the speed controller constant. However,
the manual controller tuning can also be used to calculate this constant.
Table 14. MCAT motor parameters
• Set the hardware scales—the modification of these two fields is not required
when a reference to the standard power stage board is used. These scales
express the maximum measurable current and voltage analog quantities.
• Check the fault limits—these fields are calculated using the motor
parameters and hardware scales (see Table 15).
Table 15. Fault limits
- Check the alignment parameters—these fields are calculated using the motor parameters and hardware scales. The parameters express the required voltage value applied to the motor during the rotor alignment and its duration.
- To save the modified parameters into the inner file, click the “Store data” button.
7.7 Identifying parameters of user motor
Because the model-based control methods of the PMSM drives provide high
performance (for example, dynamic response, efficiency), obtaining an accurate
model of a motor is an important part of the drive design and control. For the
implemented FOC algorithms, it is necessary to know the value of the stator
resistance Rs, direct inductance Ld, quadrature inductance Lq, and BEMF
constant Ke. Unless the default PMSM motor described above is used, the motor
parameter identification is the first step in the application tuning. This
section shows how to identify user motor parameters using MID. MID is written
in floating-point arithmetics.
Each MID algorithm is detailed in Section 7.8. MID is controlled via the FreeMASTER “Motor Identification” page shown in Figure 26.
Figure 26. MID FreeMASTER control
7.7.1 Switch between Spin and MID
Users can switch between two modes of application: Spin and MID (Motor
Identification). Spin mode is used for control PMSM (see Section 7.3). MID
mode is used for motor parameters identification (see Section 7.7.2).
The actual mode of application is shown in APP: State variable. The mode is
changed by writing one to APP: MID to Spin request or APP: Spin to MID request
variables. The transition between Spin and MID can be done only if the actual
mode is in a defined stop state (for example, MID not in progress or motor
stopped). The result of the change mode request is shown in APP: Fault
variable. MID fault occurs when parameters identification
still runs, or the MID state machine is in the fault state. A spin fault
occurs when M1 Application switch variable watch is ON, or M1 Application
state variable watch is not STOP.
7.7.2 Motor parameter identification using MID
The whole MID is controlled via the FreeMASTER “Variable Watch”. The Motor
Identification (MID) subblock is shown in Figure 26. Following is the motor
parameter identification workflow:
-
Set the MID: Command variable to STOP.
-
Select the measurement type that you want to perform via the MID: Measurement Type variable:
• PP_ASSIST – Pole-pair identification assistant
• EL_PARAMS – Electrical parameters measurement
• Ke – BEMF constant measurement
• MECH_PARAMS – Mechanical parameters measurement -
Insert the known motor parameters via the MID: Known Param set of variables. All parameters with a nonzero known value are used instead of measured parameters (if necessary).
-
Set the measurement configuration parameters in the MID: Config set of variables.
-
Start the measurement by setting MID: Command to RUN.
-
Observe the MID Start Result variable for the MID measurement plan validity (see Table 19) and the actual MID: State, MID: Faults (see Table 17), and MID: Warnings (see Table 18) variables.
-
If the measurement finishes successfully, the measured motor parameters are shown in the MID: Measured set of variables and MID: State goes to STOP.
7.7.3 MID faults and warnings
The MID faults and warnings are saved in the format of masks in the MID:
Faults and MID: Warnings variables. Faults and warnings are cleared
automatically when starting a new measurement. If a MID fault appears, the
measurement process immediately stops and brings the MID state machine safely
to the STOP state. If a MID warning appears, the measurement process
continues. Warnings report minor issues during the measurement process. For
more details on individual faults and warnings, see Table 17 and Table 18.
The MID measurement plan is checked after starting the measurement process. If a necessary parameter is not scheduled for the measurement and not set manually, the MID is not started and an error is reported via the MID: Start Result variable.
Table 19. MID Start Result variable
7.8 MID algorithms
This section describes how each MID algorithm works.
7.8.1 Stator resistance measurement
The stator resistance Rs is averaged from the DC steps generated by the
algorithm. The DC step levels are automatically derived from the currents
inserted by the user. For more details, refer to the documentation of
AMCLIB_EstimRL function from AMMCLib.
7.8.2 Stator inductances measurement
Injection of the AC-DC currents is used for the inductances (Ld and Lq)
estimation. Injected AC-DC currents are automatically derived from the
currents inserted by the user. The default AC current frequency is 500 Hz. For
more detail, refer to the documentation of AMCLIB_EstimRL function from
AMMCLib.
7.8.3 BEMF constant measurement
Before the actual BEMF constant Ke measurement, the BEMF and Tracking
observers parameters are recalculated from the previously measured or manually
set Rs, Ld, and Lq parameters. To measure Ke, the motor must spin. During the
measurement, the motor is open-loop driven at the user-defined frequency MID:
Config Ke Freq El. Required with the user-defined current MID: Config Ke Id
Required value. When the motor reaches the required speed, the BEMF voltages
obtained by the BEMF observer are filtered and Ke is calculated:
When Ke is being measured, you must visually check whether the motor is spinning properly. If the motor is not spinning properly, perform the steps below:
- Ensure that the number of pp is correct. The required speed for the Ke measurement is also calculated from pp. Therefore, inaccuracy in pp causes inaccuracy in the resulting Ke.
- Increase MID: Config Ke Id Required variable to produce higher torque when spinning during the open loop.
- Decrease MID: Config Ke Freq El. Required variable to decrease the required speed for the Ke measurement.
7.8.4 Number of pole-pair assistant
The number of pole-pairs can only be measured with a position sensor. However,
there is a simple assistant to determine the number of pole-pairs (PP_ASSIST).
The number of the pp assistant performs one electrical revolution, stops for a
few seconds, and then repeats. Because the pp value is the ratio between the
electrical and mechanical speeds, it can be determined as the number of stops
per one mechanical revolution. It is recommended to refrain from counting the
stops during the first mechanical revolution because the alignment
occurs during the first revolution and affects the number of stops. During the
PP_ASSIST measurement, the current loop is enabled, and the Id current is
controlled to MID: Config Pp Id Meas. The electrical position is generated by
integrating the open-loop frequency MID: Config Pp Freq El. Required. If the
rotor does not move after the start of PP_ASSIST assistant, stop the
assistant, increase MID: Config Pp Id Meas, and restart the assistant.
7.8.5 Mechanical parameters measurement
Figure 27. PMSM identification tab
7.9 Electrical parameters measurement control
This section describes how to control electrical parameters measurement, which
contains measuring stator resistance Rs, direct inductance Ld, and quadrature
inductance Lq. There are available 4 modes of
measurement which MID: Config El Mode Estim RL variable can select. Function
MCAA_EstimRLInit_FLT must be called before the first use of MCAA_EstimRL_FLT.
Function MCAA_EstimRL_FLT must be called periodically with sampling period
F_SAMPLING, which can be defined by the user. Maximum sampling frequency
F_SAMPLING is 10 kHz. In the scopes under “Motor identification”, FreeMASTER
subblock can be observed in measured currents, estimated parameters, and so
on.
7.9.1 Mode 0
This mode is automatic. Inductances are measured at a single operating point.
The rotor is not fixed. The user has to specify nominal current (MID: Config
El I DC nominal variable). The AC and DC currents are automatically derived
from the nominal current. The frequency of the AC signal is set to 500 Hz. The
function outputs stator resistance Rs, direct inductance Ld, and quadrature
inductance Lq.
7.9.2 Mode 1
DC stepping is automatic in this mode. The rotor is not fixed. Compared to the
Mode 0, an automatic measurement of the inductances for a defined number
(NUM_MEAS) of different DC current levels is performed using positive values
of the DC current. The Ldq dependency map can be seen in the “Inductances (Ld,
Lq)” recorder. The user has to specify the following parameters before
parameters estimation:
• MID: Config El I DC (estim Lq) – Current to determine Lq. In most cases,
nominal current.
• MID: Config El I DC positive max – Maximum positive DC current for the Ldq
dependency map measurement. Injected AC and DC currents are automatically
derived from the MID: Config El I DC (estim Lq) and MID: Config El I DC
positive max currents. The frequency of the AC signal is set to 500 Hz.
The function outputs stator resistance Rs, direct inductance Ld, quadrature
inductance Lq, and Ldq dependency map.
7.9.3 Mode 2
DC stepping is automatic in this mode. The rotor must be mechanically fixed
after initial alignment with the first phase. Compared to the Mode 1, an
automatic measurement of the inductances for a defined number (NUM_MEAS) of
different DC current levels is performed using both positive and negative
values of the DC current. The estimated inductances can be seen in the
“Inductances (Ld, Lq)” recorder. The user has to specify
following parameters before parameters estimation:
• MID: Config El I DC (estim Ld) – Current to determine Ld. In most cases, 0
A.
• MID: Config El I DC (estim Lq) – Current to determine Lq. In most cases,
nominal current.
• MID: Config El I DC positive max – Maximum positive DC current for the Ldq
dependency map measurement.
In most cases, nominal current.
• MID: Config El I DC negative max – Maximum negative DC current for the Ldq
dependency map measurement.
Injected AC and DC currents are automatically derived from the MID: Config El
I DC (estim Ld), MID: Config El I DC (estim Lq), MID: Config El I DC positive
max, and MID: Config El I DC negative max currents. The frequency of the AC
signal is set to 500 Hz.
The function outputs stator resistance Rs, direct inductance Ld, quadrature
inductance Lq, and Ldq dependency map.
7.9.4 Mode 3
This mode is manual. The rotor must be mechanically fixed after alignment with
the first phase. Rs is not calculated at this mode. The estimated inductances
can be observed in the “Ld” or “Lq” scopes. The following parameters can be
changed during the runtime:
• MID: Config El DQ-switch – Axis switch for AC signal injection (0 for
injection AC signal to d-axis, 1 for injection AC signal to q-axis).
• MID: Config El I DC req (d-axis) – Required DC current in d-axis.
• MID: Config El I DC req (q-axis) – Required DC current in q-axis.
• MID: Config El I AC req – Required AC current injected to the d-axis or
q-axis.
• MID: Config El I AC frequency – Required frequency of the AC current
injected to the d-axis or q-axis.
7.10 Control parameters tuning
To check correct current measuring and proper working of back EMF observer,
follow the steps below:
1. Select the scalar control in the “M1 MCAT Control” FreeMASTER variable
watch.
2. Set the “M1 Application Switch” variable to “ON”. The application state
changes to “RUN”.
3. Set the required frequency value in the “M1 Scalar Freq Required”
variable; for example, 15 Hz in the “Scalar & Voltage Control” FreeMASTER
project tree. The motor starts running.
4. Select the “Phase Currents” recorder from the “Scalar & Voltage Control”
FreeMASTER project tree.
5. The optimal ratio for the V/Hz profile can be found by changing the V/Hz
factor directly using the “M1 V/Hz factor” variable. The shape of the motor
currents should be close to a sinusoidal shape (Figure 28). Use the following
equation for calculating V/Hz factor:
6. Select the “Position” recorder to check the observer functionality. The difference between the “Position Electrical Scalar” and the “Position Estimated” should be minimal (see Figure 29) for the Back-EMF position and speed observer to work properly. The position difference depends on the motor load. The higher the load, the bigger the difference between the positions due to the load angle.
7. If an opposite speed direction is required, set a negative speed value
into the “M1 Scalar Freq Required” variable.
8. The proper observer functionality and the measurement of analog quantities
is expected at this step.
9. Enable the voltage FOC mode in the “M1 MCAT Control” variable while the
main application switch “M1 Application Switch” is turned off.
10. Switch on the main application switch on and set a non-zero value in the
“M1 MCAT Uq Required” variable. The FOC algorithm uses the estimated position
to run the motor.
7.10.1 Encoder sensor setting
The encoder sensor settings are in the “Sensors” tab. The encoder sensor
enables you to compute speed and position for the sensored speed. For a proper
encoder counting, set the number of encoder pulses per one revolution and the
proper counting direction. The number of encoder pulses is based on
information about the encoder from its manufacturer. If the encoder sensor has
more pulses per revolution, the speed and position computing is more accurate.
The counting direction is provided by connecting the encoder signals to the
NXP
Freedom board and also by connecting the motor phases.
To determine the direction of rotation, follow the steps below:
1. Navigate to the “Scalar & Voltage Control” tab in the project tree and
select “SCALAR_CONTROL” in the “M1 MCAT Control” variable.
2. Turn on the application switch. The application state changes to “RUN”.
3. Set the required frequency value in the “M1 Scalar Freq Required”
variable; for example, 15 Hz. The motor starts running.
4. Check the encoder direction. Select the “Encoder Direction Scope” from the
“Scalar & Voltage Control” project tree. If the encoder direction is right,
the estimated speed is equal to the measured mechanical speed. If the measured
mechanical speed is opposite to the estimated speed, the direction must be
changed. The first way is to change “M1 Encoder Direction” variable – only 0
or 1 value is allowed. The second way is invert the encoder wires—phase A and
phase B (or the other way round).
Figure 30. Encoder direction—right direction
Figure 31. Encoder direction—wrong direction
7.10.2 Alignment tuning
For the alignment parameters, navigate to the “Parameters” MCAT tab. The
alignment procedure sets the rotor to an accurate initial position and enables
you to apply full startup torque to the motor. A correct initial position is
needed mainly for high startup loads (compressors, washers, and so on). The
alignment aims to have the rotor in a stable position, without any
oscillations before the startup.
• The alignment voltage is the value applied to the d-axis during the
alignment. Increase this value for a higher shaft load.
• The alignment duration expresses the time when the alignment routine is
called. Tune this parameter to eliminate rotor oscillations or movement at the
end of the alignment process.
7.10.3 Current loop tuning
The parameters for the current D, Q, and PI controllers are fully calculated
using the motor parameters and no action is required in this mode. If the
calculated loop parameters do not correspond to the required response, the
bandwidth and attenuation parameters can be tuned.
1. Select “Openloop Control” in the FreeMASTER project tree, set “M1 MCAT
Control” to “OPENLOOP_CTRL” and switch “M1 Openloop Use I Control” on.
2. Turn the application on by switching “M1 Application Switch” on and then
set “M1 Openloop Requred Id” for rotor alignment. (Rotor alignment always uses
Id, even when you are tuning the Q axis regulator)
3. Mechanically lock the motor schaft and turn the application off.
4. Set the required loop bandwidth and attenuation in MCAT “Current loop” tab
and then click the “Update target” button. The tuning loop bandwidth parameter
defines how fast the loop response is while the tuning loop attenuation
parameter defines the actual overshoot magnitude.
5. Select “Current Controller Id” recorder in project tree, turn the
application on and set the required step amplitude in “M1 Openloop Requred
Id”. Observe the step response in the recorder.
6. Tune the loop bandwidth and attenuation until you achieve the required
response. The example waveforms show the correct and incorrect settings of the
current loop parameters:
• The loop bandwidth is low (100 Hz) and the settling time of the Id current
is long (Figure 32).
Figure 32. Slow step response of the Id current controller
• The loop bandwidth (300 Hz) is optimal and the response time of the Id current is sufficient (Figure 33).
Figure 33. Optimal step response of the Id current controller
• The loop bandwidth is high (700 Hz) and the response time of the Id current is very fast, but with oscillations and overshoot (Figure 34).
Figure 34. Fast step response of the Id current controller
7.10.4 Speed ramp tuning
To tune speed ramp parameters, follow the steps below:
1. The speed command is applied to the speed controller through a speed ramp.
The ramp function contains two increments (up and down) which express the
motor acceleration and deceleration per second. If the increments are very
high, they can cause an overcurrent fault during acceleration and an
overvoltage fault during deceleration. In the “Speed” scope, you can see
whether the “Speed Actual Filtered” waveform shape equals the “Speed Ramp”
profile.
2. The increments are common for the scalar and speed control. The increment
fields are in the “Speed loop” tab and accessible in both tuning modes.
Clicking the “Update target” button applies the changes to the MCU. An example
speed profile is shown in Figure 35. The ramp increment down is set to 500
rpm/sec and the increment up is set to 3000 rpm/sec.
3. The startup ramp increment is in the “Sensorless” tab and its value is
higher than the speed loop ramp.
Figure 35. Speed profile
7.10.5 Open loop startup
To tune open loop startup parameters, follow the steps below:
1. The startup process can be tuned by a set of parameters located in the
“Sensorless” tab. Two of them (ramp increment and current) are accessible in
both tuning modes. The startup tuning can be processed in all control modes
besides the scalar control. Setting the optimal values results in a proper
motor startup. An example startup state of low-dynamic drives (fans, pumps) is
shown in Figure 36.
2. Select the “Startup” recorder from the FreeMASTER project tree.
3. Set the startup ramp increment typically to a higher value than the speed-
loop ramp increment.
4. Set the startup current according to the required startup torque. For
drives such as fans or pumps, the startup torque is not very high and can be
set to 15 % of the nominal current.
5. Set the required merging speed. When the open-loop and estimated position
merging starts, the threshold is mostly set in the range of 5 % ~ 10 % of the
nominal speed.
6. Set the merging coefficient—in the position merging process duration, 100
% corresponds to a one of an electrical revolution. The higher the value, the
faster the merge. Values close to 1 % are set for the drives where a high
startup torque and smooth transitions between the open loop and the closed
loop are required.
7. To apply the changes to the MCU, click the “Update Target” button.
8. Select “SPEED_FOC” in the “M1 MCAT Control” variable.
9. Set the required speed higher than the merging speed.
10. Check the startup response in the recorder.
11. Tune the startup parameters until you achieve an optimal response.
12. If the rotor does not start running, increase the startup current.
13. If the merging process fails (the rotor is stuck or stopped), decrease
the startup ramp increment, increase the merging speed, and set the merging
coefficient to 5 %.
Figure 36. Motor startup
7.10.6 BEMF observer tuning
The bandwidth and attenuation parameters of the BEMF and tracking observer can
be tuned. To tune the bandwidth and attenuation parameters, follow the steps
below:
1. Navigate to the “Sensorless” MCAT tab.
2. Set the required bandwidth and attenuation of the BEMF observer. The
bandwidth is typically set to a value close to the current loop bandwidth.
3. Set the required bandwidth and attenuation of the tracking observer. The
bandwidth is typically set in the range of 10 – 20 Hz for most low-dynamic
drives (fans, pumps).
4. To apply the changes to the MCU, click the “Update target” button.
5. Select the “Observer” recorder from the FreeMASTER project tree and check
the observer response in the “Observer” recorder.
7.10.7 Speed PI controller tuning
The motor speed control loop is a first-order function with a mechanical time
constant that depends on the motor inertia and friction. If the mechanical
constant is available, the PI controller constants can be tuned using the loop
bandwidth and attenuation. Otherwise, the manual tuning of the P and I
portions of the speed controllers is available to obtain the required speed
response (see Figure 37). There are dozens of approaches to tune the PI
controller constants. To set and tune the speed PI controller for a PM
synchronous motor, follow the steps below:
1. Select the “Speed Controller” option from the FreeMASTER project tree.
2. Select the “Speed loop” tab.
3. Check the “Manual Constant Tuning” option—that is, the “Bandwidth” and
“Attenuation” fields are disabled and the “SL_Kp” and “SL_Ki” fields are
enabled.
4. Tune the proportional gain:
• Set the “SL_Ki” integral gain to 0.
• Set the speed ramp to 1000 rpm/sec (or higher).
• Run the motor at a convenient speed (about 30 % of the nominal speed).
• Set a step in the required speed to 40 % of Nnom.
• Adjust the proportional gain “SL_Kp” until the system responds to the
required value properly and without any oscillations or excessive overshoot:
– If the “SL_Kp” field is set low, the system response is slow.
– If the “SL_Kp” field is set high, the system response is tighter.
– When the “SL_Ki” field is 0, the system most probably does not achieve the
required speed.
– To apply the changes to the MCU, click the “Update Target” button.
5. Tune the integral gain:
• Increase the “SL_Ki” field slowly to minimize the difference between the
required and actual speeds to 0.
• Adjust the “SL_Ki” field such that you do not see any oscillation or large
overshoot of the actual speed value while the required speed step is applied.
• To apply the changes to the MCU, click the “Update target” button.
6. Tune the loop bandwidth and attenuation until the required response is
received. The example waveforms with the correct and incorrect settings of the
speed loop parameters are shown in the following figures:
• The “SL_Ki” value is low and the “Speed Actual Filtered” does not achieve
the “Speed Ramp”.
Figure 37. Speed controller response—SL_Ki value is low, Speed Ramp is not
achieved
• The “SL_Kp” value is low, the “Speed Actual Filtered” greatly overshoots,
and the long settling time is unwanted.
Figure 38. Speed controller response—SL_Kp value is low, Speed Actual Filtered
greatly overshoots
• The speed loop response has a small overshoot and the “Speed Actual
Filtered” settling time is sufficient. Such response can be considered
optimal.
Figure 39. Speed controller response—speed loop response with a small overshoot
7.10.8 Position P controller tuning
The position control loop can be tuned using the proportional gain “M1
Position Loop Kp Gain” variable. A proportional controller can be used to
unpretend the position-control systems. The key for the optimal position
response is a proper value of the controller, which multiplies the error by
the proportional gain (Kp) to get the controller output. The predefined base
value can be manually changed. An encoder sensor must be used for a working
position control. The following steps provide an example of how to set the
position P controller for a PM synchronous motor:
1. Select the “Position Controller” scope in “Position Control” tab in the
FreeMASTER project tree.
2. Tune the proportional gain in the position P controller constant:
• Set a small value of “PL_Kp” (M1 Position Loop Kp Gain).
• Select the position control, and set the required position in “M1 Position
Required” variable (for example; 10 revolutions).
• Select the “Position Controller” scope and watch the actual position
response.
3. Repeat the previous steps until you achieve the required position
response.
The “PL_Kp” value is low and the actual position response on the required
position is very slow. PMSMRT1180
Figure 40. Position controller response—PL_Kp value is low, the actual
position response is very slow
The “PL_Kp” value is too high and the actual position overshoots the required
position.
Figure 41. Position controller response—PL_Kp value is too high and the actual
position overshoots
The “PL_Kp” value and the actual position response are optimal.
Figure 42. Position controller response—the actual position response is good
8 Conclusion
This application note describes the implementation of the sensor and sensorless field-oriented control of a 3- phase PMSM. The motor control software is implemented on NXP MIMXRT1180-EVK board with the FRDMMC- LVPMSM NXP Freedom development platform. The hardware-dependent part of the control software is described in Section 2. The motor-control application timing, and the peripheral initialization are described in Section 3. The motor user interface and remote control using FreeMASTER are described in Section 6. The motor parameters identification theory and the identification algorithms are described in Section 7.8.
9 Acronyms and abbreviations
Table 20 lists the acronyms and abbreviations used in this document.
Table 20. Acronyms and abbreviations
10 References
These references are available on www.nxp.com:
• Sensorless PMSM Field-Oriented Control (document DRM148)
• Motor Control Application Tuning (MCAT) Tool for 3-Phase PMSM (document
AN4642)
• PMSM Field-Oriented Control on MIMXRT10xx EVK User’s Guide (document
PMSMFOCRT10xxUG)
• PMSM Field-Oriented Control on MIMXRT10xx EVK (document AN12214)
11 Useful links
• MCUXpresso SDK for Motor Control www.nxp.com/sdkmotorcontrol
• Motor Control Application Tuning (MCAT) Tool
• i.MX RT Crossover MCUs
• FRDM-MC-PMSM Freedome Development Platform
• MCUXpresso IDE – Importing MCUXpresso SDK
• MCUXpresso Config Tool
• MCUXpresso SDK Builder (SDK examples in several IDEs)
• Model-Based Design Toolbox (MBDT)
12 Revision history
Section 12 summarizes the changes done to the document since the initial release.
Table 21. Revision history
Legal information
Definitions
Draft — A draft status on a document indicates that the content is still under
internal review and subject to formal approval, which may result in
modifications or additions. NXP Semiconductors does not give any
representations or warranties as to the accuracy or completeness of
information included in a draft version of a document and shall have no
liability for the consequences of use of such information.
Disclaimers
Limited warranty and liability — Information in this document is believed to
be accurate and reliable. However, NXP Semiconductors does not give any
representations or warranties, expressed or implied, as to the accuracy or
completeness of such information and shall have no liability for the
consequences of use of such information. NXP Semiconductors takes no
responsibility for the content in this document if provided by an information
source outside of NXP Semiconductors.
In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including – without limitation – lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory.
Notwithstanding any damages that customer might incur for any reason whatsoever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors.
Right to make changes — NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof.
Suitability for use — NXP Semiconductors products are not designed, authorized or warranted to be suitable for use in life support, life-critical or safety-critical systems or equipment, nor in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semiconductors and its suppliers accept no liability for inclusion and/or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk.
Applications — Applications that are described herein for any of these products are for illustrative purposes only. NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification.
Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products, and NXP Semiconductors accepts no liability for any assistance with applications or customer product design. It is customer’s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the customer’s applications and products planned, as well as for the planned application and use of customer’s third party customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products.
NXP Semiconductors does not accept any liability related to any default, damage, costs or problem which is based on any weakness or default in the customer’s applications or products, or the application or use by customer’s third party customer(s). Customer is responsible for doing all necessary testing for the customer’s applications and products using NXP Semiconductors products in order to avoid a default of the applications and the products or of the application or use by customer’s third party customer(s). NXP does not accept any liability in this respect.
Terms and conditions of commercial sale — NXP Semiconductors products are sold subject to the general terms and conditions of commercial sale, as published at https://www.nxp.com/profile/terms, unless otherwise agreed in a valid written individual agreement. In case an individual agreement is concluded only the terms and conditions of the respective agreement shall apply. NXP Semiconductors hereby expressly objects to applying the customer’s general terms and conditions with regard to the purchase of NXP Semiconductors products by customer.
Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from competent authorities.
Suitability for use in non-automotive qualified products — Unless this document expressly states that this specific NXP Semiconductors product is automotive qualified, the product is not suitable for automotive use. It is neither qualified nor tested in accordance with automotive testing or application requirements. NXP Semiconductors accepts no liability for inclusion and/or use of non-automotive qualified products in automotive equipment or applications.
In the event that customer uses the product for design-in and use in automotive applications to automotive specifications and standards, customer (a) shall use the product without NXP Semiconductors’ warranty of the product for such automotive applications, use and specifications, and (b) whenever customer uses the product for automotive applications beyond NXP Semiconductors’ specifications such use shall be solely at customer’s own risk, and (c) customer fully indemnifies NXP Semiconductors for any liability, damages or failed product claims resulting from customer design and use of the product for automotive applications beyond NXP Semiconductors’ standard warranty and NXP Semiconductors’ product specifications.
Translations — A non-English (translated) version of a document, including the legal information in that document, is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions.
Security — Customer understands that all NXP products may be subject to unidentified vulnerabilities or may support established security standards or specifications with known limitations. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that may be provided by NXP.
NXP has a Product Security Incident Response Team (PSIRT) (reachable at PSIRT@nxp.com) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products.
NXP B.V. — NXP B.V. is not an operating company and it does not distribute or sell products.
Trademarks
Notice: All referenced brands, product names, service names, and trademarks
are the property of their respective owners.
NXP — wordmark and logo are trademarks of NXP B.V.
Please be aware that important notices concerning this document and the product(s) described herein, have been included in section ‘Legal information’.
© 2024 NXP B.V.
For more information, please visit: https://www.nxp.com
All rights reserved.
Date of release: 5 January 2024
Document identifier: PMSMRT1180
Read More About This Manual & Download PDF:
References
- FreeMASTER Run-Time Debugging Tool | NXP Semiconductors
- MCUXpresso SDK for Motor Control | NXP Semiconductors