NXP Semiconductors PMSMRT1180 MCUXpresso SDK Field Oriented Control FOC of 3 Phase PMSM User Guide

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 project includes all the available functions and routines. This project serves for development and testing purposes.

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\boards\\demo_apps\mc_pmsm\pmsm_enc\ contains the following folders and files:
• 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\middleware\motor_control\ contains these subfolders:
• 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\middleware\motor_control\pmsm\pmsm_float\ folder contains these subfolders common to the other motor-control projects:
• 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 + (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:

1. Set the MID: Command variable to STOP.

2. 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

3. 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).

4. Set the measurement configuration parameters in the MID: Config set of variables.

5. Start the measurement by setting MID: Command to RUN.

6. 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.

7. 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

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>