NXP Model-Based Design Tools Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Model-Based Design Tools Knowledge Base

Labels

Discussions

Sort by:
PMSM Motor Control Application for S32K396 with MBDT and Custom Code Examples were designed on XS32K396-BGA-DC EVB and 3-phase PMSM pre-driver board(with connection cable) MATLAB Simulink-based project (s32k396_pmsm_mc_mbdt) is build using Model-Based Design Toolbox (MBDT) and can be downloaded from NXP Model-Based Design Toolbox for S32K3xx - version 1.5.0 or newer releases. For all models file and document, please find the attachment. 1. Introduction This article aims to introduce and demonstrate how a PMSM control algorithm targeting the S32K396 MCU can be designed inside the Simulink ® environment. The demo introduced by this article is built using (but is not part of) the NXP ® Model-Based Design Toolbox (MBDT) for S32K3xx, hence it has not been fully tested inside the MBDT development environment, neither been passed through the verification and validation processes imposed for the applications delivered within the toolbox. The demo presented in the following article is just an example of how NXP's software and hardware products can be used for developing motor control algorithms, using the MATLAB ® and Simulink ecosystem capabilities. The S32K39 is an Arm ® Cortex ® -M7 based Microcontroller series which runs up to 320 MHz, which contains an advanced motor control co-processor (eTPU) designed with the purpose of offloading the main CPU from motor control tasks, and a high-resolution PWM. It is developed to meet the next generation SiC traction inverter requirements and to enable high efficiency and low latency features. Also, S32K39 is suitable for applications like Automotive Inverter, On-board Charger (OBC), and High-performance Battery Management System (BMS). The NXP Model-Based Design Toolbox (MBDT) is a comprehensive collection of tools that plug into the MATLAB and Simulink model-based design environment to support verification, validation, and rapid prototyping of complex algorithms for real targets based on NXP microcontrollers and processors. For enabling hardware access from the Simulink applications development environment, MBDT offers integration with Real-Time Drivers (RTD) for controlling the system and peripheral devices. The configuration of the on-board peripherals, pins, and clocks, is realized by enabling the integration with dedicated configuration tools, like NXP’s S32 Configuration Tools delivered inside the toolbox, and EB Tresos. MBDT delivers a library of Simulink blocks, which implement functionalities of MCU peripherals and generate code on top of specific drivers' functions. Together with these, the toolbox integrates the AMMCLIB library, for facilitating the development of motor control algorithms. The toolbox offers support for software-in-the-loop and processor-in-the-loop (SIL and PIL) development workflows, allowing the design, verification and validation at each development step. It also generates and deploys code automatically, from Simulink models, to start up the MCU and run complex applications, which enables control engineers and embedded developers to shorten project life cycles. Hence, by using NXP's Model-Based Design Toolbox, complex algorithms, which can be modelled, simulated and verified hardware independently, using the rich ecosystem of solutions the MathWorks ® environment provides, can be tailored to become hardware aware for targeting specific NXP platforms. The S32K39 is an Arm Cortex-M7-based Microcontroller series, which contains an advanced motor control co-processor (eTPU), a high-resolution PWM, and runs up to 320 MHz. It is developed to meet the next-generation SiC traction inverter requirements and to enable high efficiency and low latency features. Also, S32K39 is suitable for applications like Automotive Inverter, On-board Charger (OBC), and High-performance Battery Management System (BMS). This demo aims to give a quick start guide on building up a motor control system with NXP MBDT on S32K396. It contains the environment setup, module configuration, system initialization, and interruption structure, Permanent Magnet Synchronous Motor (PMSM) control algorithm, and FreeMASTER configuration. 2. Hardware and Software Setup For more details on how this can be achieved, the following diagram is introduced, mapping the PMSM algorithm on top of the existing hardware for the S32K396 MCU. The App, Algorithm, Data processing section can be implemented using Simulink libraries blocks, AMMCLib blocks and Simulink custom code functionalities to include eTPU drivers that address this co-processor access and control. The MBDT section is covered by the blocks provided by the toolbox, ensuring hardware access to the peripherals implied in such applications, while the MCU, Motor, circuits refers to the hardware elements used for the design.  The following picture presents the application mapping of the software and hardware used to develop PMSM Motor Control on S32K396: Figure 2.1 Application mapping of software and hardware used to develop PMSM Motor Control on S32K396 For an overview of the elements necessary for modeling such a diagram inside a Simulink model, the following picture is introduced, showcasing the software components and functionalities that can be used inside this scenario, which will be furtherly detailed in the following sections. Figure 2.2 Software Components for modeling the PMSM Motor Control on S32K396 This demo aims to give a quick start guide on building up a motor control system with NXP MBDT on S32K396. It contains the environment setup, module configuration, system initialization, and interrupts structure, Permanent Magnet Synchronous Motor (PMSM) control algorithm, and FreeMASTER configuration, demonstrating the following features: 3-phase PMSM speed Field Oriented Control. Integrated eTPU software resolver functions for position and speed measurement. Develop PIL models for hardware simulation and PIL test. Application control user interface using FreeMASTER debugging tool. (Please get more details on FreeMASTER from section 9 and the references part) 2.1 Required software S32 Design Studio for S32 Platform 3.5 EB tresos Studio 29.0 FreeMASTER 3.2 MATLAB R2023b with “Embedded Coder ® for ARM Cortex-M Processors” NXP Model-Based Design Toolbox for S32K3xx version 1.5.0 SW32K3_S32M27x_RTD_R21-11_4.0.0_P19(contained in the toolbox) 2.2 Required hardware The following is a list of required hardware: Boards: XS32K396-BGA-DC EVB and MC33937 MOSFETs pre-driver (with connection cable). Motor: 3-phase PMSM TGT2-0032-30-24. Debugger: Lauterbach for Cortex-M7 or Multilink PE micro debugger. Power: 12V power supply for EVB and 24V power supply for pre-driver board. PCIE Cable. Micro USB Cable. Note: The debugger Lauterbach is not integrated in the MBTD tool, it is only a method to debug the code. 2.3 Prepare the demo The central controller EVB board runs the control algorithm, and the pre-driver drives the motor. Connect the hardware devices with the following steps: Figure 2.3.1 Hardware Setup Connect the PMSM’s three-phase winding to J4 on the pre-driver and connect the resolver signal to J8 on the pre-driver. Connect motor control signals from J14 on the pre-driver to J44 on the EVB board. Connect the debugger between JTAG J20 and the computer. Connect the USB cable between J15 and the computer, then the EVB LED D30 will be solid green. Plug in the 12V power supply port J1 on the EVB board, then the EVB LED D4 will be solid green. Plug in the 24V driver power on port J13 of the pre-driver, and then the pre-driver LED D14 will be solid yellow. 2.4 Running the demo Please refer to the  S32K396_MBDT_BASED_MOTOR_CONTROL_Quick_Start_Guide_0_9_0.pdf  in the project doc folder. 3. Demo blocks introduction In the following figure, an overview of the main Simulink model is presented. The motor control application model has the following structure: Initialization and Interrupt. Figure 3.1 Simulink Application Top Model  Var Init contains the variables used by the model and can be visualized in FreeMASTER. Initialize subsystem contains the FreeMASTER configuration, state machine and control mode initialization, and BCTU hardware trigger enablement. This subsystem is executed only once, at the beginning of the application. Hardware Interrupt Callback calls the motor control block to run. This block delivered by the MBDT, allows the implementation of specific actions inside a callback function which is executed when an interrupt occurs on the configured peripheral instance, at a specific event. Callbacks are associated with specific events inside the configuration project used with the model, which ensures the on-board configuration of the peripherals, pins, and clocks. Motor Control function-call subsystem runs every time an ADC interrupt occurs. Inside the Motor Control subsystem, as illustrated below, the ADC hardware trigger is disabled (Step 1) until the PMSM control algorithm calculation is finished (Step 2), and reenabled at the end of this computation (Step 3). The priority order of the generated code is achieved by setting the “Priority” value, accessible inside the Properties of each Simulink block. Figure 3.2 Motor Control Subsystem The pmsm_mc_algo algorithm is a subsystem reference model. It collects the input sensor signals, calculates the PMSM control algorithm, and drives PWMs to generate the output voltage. Following figure shows the main blocks: Current Voltage Measurement reads BCTU FIFO data and calls the following blocks. Board Buttons control the motor with hardware pins on board. State Machine subsystem contains the Stateflow® of the motor control application and each state will call a dedicated function block. Enable Outputs enables the PWM output function. Disable Outputs disables the PWM output function. Green LED Toggle controls a green LED to blink. Update PWM calls the MBDT PWM block to update the duty cycle value. Figure 3.3 PMSM Motor Control Algorithm 4. Startup initialization The startup initialization is a subsystem of the initialize function block. It’s used to configure some basic functionality at the start of the application: FreeMASTER Config which configures the UART to communicate with FreeMASTER GUI. FreeMASTER Config block allows the users to configure the FreeMASTER embedded-side software driver, which implements the serial interface between the application and the host PC. It actually inserts the service in the application, and it is the only one mandatory to be added to the Simulink canvas in order to have the FreeMASTER functionality available. Gpt_StartTimer enables one GPT channel for pre-driver MC33937 dead time configuration. Adc_CtuEnableHwTrigger enables the BCTU hardware trigger feature. Set the event and state to reset values and set the default control mode as speed control. Figure 4.1 Initialize Subsystem 5. Interrupt and measurements This part describes the configuration and usage of BCTU and ADC modules for analog data capturing. BCTU is triggering parallel ADC conversions for 3-phase current measurements. After all measurements are fulfilled, the BCTU FIFO notification is used to read the stored ADC data and to call the main control loop of the application for further processing.  5.1 Interrupt configuration and service The following picture shows the configuration for the BCTU FIFO notification callback feature. The BCTU FIFO 1 is used to store the ADC results, the watermark value decides when to call the function configured in the notification. Also, enabling the BCTU IRQ in configuration is required. Figure 5.1.1 BCTU Watermark Notification Configuration  Figure 5.1.2 BCTU Interrupt Enablement In the Simulink model, the configured notification for BCTU is selected inside the Hardware Interrupt Callback block. This will execute the connected function-call subsystem when the End-of-Conversion interrupt occurs. Figure 5.1.3 Interrupt Callback Subsystem 5.2 Measurements of currents and voltage This section describes the measurement of analog quantities: 3-phase currents and DC bus voltage. BCTU receives the hardware trigger to start the ADC measurements (parallel conversions). Once all results have been stored into the FIFO, the interrupt will call the main control loop. BCTU FIFO notification is used to call the main loop of the motor control, which ensures the sampling is finished before using them. How to get sampled values for processing is presented in this section. The following picture shows the steps and operations to transfer the current and voltage to their real physical values. To acquire the currents and voltage from BCTU FIFO for further processing, the Adc block from MBDT library is used and the Adc_CtuReadFifoData is selected.  Figure 5.2.1 Process converted data to physical values 6. eTPU resolver Software resolver is now widely used in the Inverter application, which can help to save the BOM (Bill of Materials) cost. The eTPU on S32K39 supplies a function to the customer to implement a software resolver via a software package. It uses one eTPU channel to generate a 50% duty-cycle PWM output signal to be passed through an external low-pass filter and used as a resolver excitation signal. In the resolver position sensor, this excitation signal is modulated by the sine and cosine of the actual motor angle. The feedback Sine and Cosine signals are sampled by an SDADC and processed by a followed DSP. The conversion results can be transferred to eTPU DATA RAM by DMA. Then, the eTPU can process the digital samples of resolver output signals and output the position and speed for the FOC. For more details about the eTPU resolver, please refer to AN13038. Figure 6.1 eTPU Resolver Diagram 6.1 Resolver functions call in MATLAB The eTPU Resolver Block is not yet available in MBDT. The System Output block is used to insert custom code for getting resolver data. The getMotorControlResolver(&mbd_ebt_DW_FOC_one.Resolver_SW) function is used to get resolver data. Figure 6.1.1 Simulink custom code for eTPU access The speed and angle are estimated from the Resolver Angle subsystem and are provided to the slow & fast control loops. Finally, the sine and cosine values from the estimated electrical angle are computed. Figure 6.1.2 Computation of the speed and angle 7. State machine This is a critical part of the motor control application model, each state has a dedicated block to handle the related functions. Figure 7.1 Motor Control States Implementation The state machine block controls the workflow of the motor control application, it has been designed using Stateflow. Figure 7.2 Finite State Machine 8. PWM control and update Subsystems Enable Outputs and Disable Outputs control the output of PWM. They are called by the state functions. In the subsystems, the flag PWM_enabled and gate driver output status are changed via the pwm_enable_output or the pwm_disable_output function. Figure 8.1 Enable Outputs Subsystem Figure 8.2 Disable Outputs Subsystem Update PWM subsystem is used to generate the PWM duty cycle value according to the output from the control loop. This value is eventually set for the FlexPWM peripheral to generate PWM voltages to drive the motor. The FlexPWM is configured to generate complementary signals for bridges and is updated synchronously according to a reload signal in the EB project. Here it is only needed to pass the duty cycle values to the Pwm function in the model. Figure 8.3 PWM Duty Cycle Values Computation Figure 8.4 PWM Duty Cycle Values Update 9. Buttons Buttons are used to control the running of the motor. The algorithm reads the value of the button from the board to change the running state or speed. The Dio block in the MBDT library is used to read the value of I/O. The I/O port of buttons has been configured in the EB project. Two buttons on the board are used to increase or decrease the running speed of the motor. Also, they are used to clear the fault information when pressed together. One button is used to control the start or stop of the motor. The following picture shows the subsystem for the button control logic. Figure 9.1 Buttons Control Logic 10. FreeMASTER GUI FreeMASTER is a user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of embedded software applications. To enable FreeMASTER in this project, the interface needs to be configured first. MBDT supplies blocks to support FreeMASTER’s configuration. In this project, LPUART_0 is used to transmit data between the GUI and the board. The following figure shows the MCAT GUI, which can be used to observer parameters/variables and also used to control the status of the motor. It can be found in the project folder, under “./mbd/FreeMASTER_control”. Figure 10.1 MCAT GUI 11. PIL model PIL represents a verification and validation step where the code generated for the developed control algorithm is cross-compiled and deployed on the target hardware, then stimulated with test inputs from the Simulink application executed on the host PC, containing the plant model. The test inputs are sent to the target via Serial Communication. By enabling this simulation mode, users could test the performance of the processor long before having the final hardware design, testing whether the model and the generated code are numerically equivalent, and being able to perform code execution profiling. Hence, for this motor control design, we have also developed a PIL model (pil_model_ebt) used to verify the model-generated code on the S32K396 microcontroller. The PIL top model contains two parts: Simulation Model and Hardware Model. The Simulation Model contains the model of the real system (pre-driver and PMSM), as depicted inside Section 11.1. The Hardware Model contains the control algorithm which is the same as in the application previously introduced (mbd_ebt.slx). For the hardware Model part, the code will be generated, built and an executable file will be deployed on hardware. Input and output signals processing blocks will generate the necessary test inputs for the code that runs on the hardware controller, as depicted in the screenshot below. Figure 11.1 PIL Top Model 11.1 PIL Model introduction The PIL top model runs the simulation model part inside the Simulink environment and exchanges signal data with the hardware controller through Serial Communication. 11.2 Simulation model The simulation model simulates the hardware of the pre-driver and PMSM using Simscape™ Electrical™ blocks. Duty to PWM simulates the function of a central aligned FlexPWM with the frequency of 20kHz. Inverter simulates three-phase full-bridge circuit with the same parameters as in MC33937 MOSFETs pre-driver. PMSM is defined with the same parameters as the real motor. Resolver is simplified as an ideal rotational motion sensor. Phase Current Sensing, Bus Current Sensing and Bus Voltage Sensing are built up regarding MC33937 MOSFETs pre-driver. SARADC block samples signal simultaneously with the PWM module and generates a function call after data conversion is completed. Figure 11.2.1 PIL Host Model 11.3 Hardware model The hardware model is a referenced model that generates code and deploys it into the microcontroller. It’s called by ADC conversion completion signal. In the initialization process, it initializes the global variables and drivers. In the normal running process, when a function call comes, the model will calculate the input signal, run the state machine, and generate the output signal in the order defined in subsystem “pmsm_mc_algo”. Figure 11.3.1 PIL Target Model 12. Conclusions NXP's MBDT enables the usage of hardware optimized tools: Real-Time Drivers (RTD), Automotive Math and Motor Control Library (AMMCLib), Configuration (S32 Configuration Tools and EB Tresos), and Build Tools in the Simulink environment. This article gives examples on the construction and environment setup process for designing motor control models, and how they can be verified and validated through PIL simulation before being deployed on the target hardware. It focuses on how NXP’s Model-Based Design Toolbox and the software NXP provides could be used together with MathWorks tools and functionalities for rapid prototyping complex embedded designs on NXP targets. Together with the rich MathWorks ecosystem, it allows users to model complex algorithms, and generate optimized code for the NXP’s microcontrollers and processors, ensuring thus a fast and reliable programming environment. Please note that the demo was not fully tested inside MBDT ecosystem and application development workflow it proposes, as the depicted example uses custom code functionalities for addressing the eTPU co-processor access, currently not supported by MBDT, and a specific version of the RTD, different than the one the toolbox was released and tested with. For more information about MBDT, tutorials, webinars and other resources, please visit the MBDT Community Page. You might also visit NXP.com for additional information on the development ecosystem that NXP offers. 13. References 3-phase Motor Control Kit with S32K396 The workshop “3-Phase PMSM Control Workshop with NXP's Model-Based Design Toolbox” from NXP Community Module 4: Space Vector Modulation from NXP Community MC33937: 3-Phase Field Effect Transistor Pre-driver. Automotive Math and Motor Control Library Set for NXP S32K3xx devices. FreeMASTER Run-Time Debugging Tool. Application Note: AN13902: 3-Phase Sensorless PMSM Motor Control Kit with S32K344 using MBDT Blocks
View full article
The content of this article is identical to the AN13902: 3-Phase Sensorless PMSM Motor Control Kit with S32K344 using MBDT Blocks
View full article
Introduction The application is based on an example of basic GPIO for S32K144 (gpio_s32k14_mbd_rtw). The application is extended to fit the needs of motor control application running a sensorless PMSM Field Oriented Control algorithm. Therefore, certain modes (states) and transitions (events) are implemented. NOTE: Theory of Finite state machines defines states and events (transitions). Following design uses approach which may seem to mix states and transitions at some point. Some states are run just once, thus they may be considered as transitions only. However, the design is considered as an example and may be extended in terms of additional checks for external events, making these "one-shot" states the actual states. The design has been well known from NXP Automotive Motor Control Development Kits and it has been well accepted by majority of customers. Therefore, the same concept is presented for MATLAB Simulink. Finite State Machine Design The application structure should introduce a systematic tool to handle all the tasks of motor control as well as hardware protection in case of failure. Therefore, a finite state machine is designed to control the application states using MATLAB Simulink Stateflow Chart (Stateflow library/Chart). The motor control application requires at least two states - "stop" represented by "ready" state and "run" represented by "run" state. However, some additional states need to be implemented to cover e.g. power-on situation, where the program waits for various auxiliary systems (system basis chip, DC-bus to be fully charged, memory checks, etc.). In addition, the motor control application and specifically the sensorless field oriented control requires additional states to calibrate the sensors and to start the motor with known position. Therefore, transition from READY state to RUN state is done through an initialization sequence of CALIB (sensors calibration) and ALIGN (initial rotor position alignment or detection) states. To stop the motor, the application goes back to the READY state via INIT (state variables initialization). While the INIT state is designed to clear all the internal accumulators and other variables (but the parameters can be changed in the run time and not reset to the default settings), the RESET state is introduced to enable power-on or "default configuration" or "soft reset" initialization in the case of the motor control parameters are changed using FreeMASTER or other user interface. All the states are linked with an output event which is traced out of the state machine chart block. These events can be used as trigger points for calling the handlers (state functions). The transitions are driven by the input value of the state machine, treated as an event using a simple comparison (e.g. [u==e_start]). To change the state, the event/input value should be changed. If the event has changed, the state machine changes the state only in case of there is an existing action linked with the current state and the event. The state machine is designed to be used in the application using Event input (to signal the event), State output (to indicate the current state) and Event triggers outputs (to call the state functions / handlers). Following application has been built to show an example of the state machine usage. Following tables show the nomenclature of the states and events: State Purpose Value Reset Power-on / Default settings / Soft-reset state. May include some HW checking sequence or fault detection. 1 Init Initialization of control state variables (integrators, ramps, accumulators, variables, etc.). May include fault detection 2 Ready Stand-by state, ready to be switched-on. Includes fault detection, e.g. DC-bus overvoltage or high temperature 3 Calib Calibration state to calibrate ADC channels (remove offsets). Includes fault detection 4 Align Alignment state to find the rotor position and to prepare to start. Includes fault detection 5 Run Motor is running either in open-loop or sensorless mode. Includes fault detection 6 Fault Fault state to switch off the power converter and all the peripherals to a safe state. 7 Input events are the triggers which initiate a change of current state. Input Event Purpose Value e_init_done Asserted when the Init state has finished the task with success 1 e_start Asserted when a user sends the switch-on command 2 e_calib_done Asserted when all the required ADC channels are calibrated 3 e_align_done Asserted when the initial rotor alignment / position detection is done 4 e_stop Asserted when a user sends the switch-off command 5 e_fault Asserted when a fault situation occurs 6 e_fault_clear Asserted when a user sends the "clear faults" command or when the situation allows this 7 e_reset Asserted when a user sends the "reset" command to start over with default settings 8 Output events are used to trigger the Motor Control State Handlers and correspond to actual state. These events are triggered with every state machine call. Therefore, the state machine shall be aligned with the control algorithm. For example, it shall be placed within the ADC "conversion completed" interrupt routine or PWM reload interrupt routine. Finite State Machine Usage The state machine shall be used in good alignment with the control algorithm. The usual way of controlling a motor is to have a periodic interrupt linked with the ADC conversion completed or with the PWM reload event (interrupt). The state machine shall be called within this event handler, right after all the external information is collected (voltages, currents, binary inputs, etc.) to let the state machine decide, which state should be called next. Internal event/state handling inside of the state machine is clearly described by the state machine block definition. Output event triggers are configured to provide clear function-based code interface to the state machine. That means, the output events shall be connected to a function designed to handle the state task. For example, in Run state, the run() output event is triggered with every state machine call, while within the Run state function the whole motor control algorithm is called. If an input information is supposed to switch the state, a simple condition shall be programmed to change the Event variable (defined as a global variable). For example, if a user sends the "stop" command, the Event is set to "e_stop" and the state machine will switch to the Init state. For more complex triggering of output functions, additional output events can be programmed within the state machine definition. Template state handler function is based on the function caller block. In general, the function blocks can work with global variables, thus there is no need for inputs or outputs. Thanks to global Event variable, event-driven state machine can react on events thrown inside a state handler function or outside of the state machine (e.g. based on other asynchronous interrupt). An example of a simple template is shown below. In this example, the function represents the Reset state, which is supposed to be run after the power-on reset or to set all the variables to its default settings. Therefore, the first part is dedicated to hardware-related settings, the second part is covering the application-related settings. The third part checks whether all the tasks are done. If yes, the e_reset_done event is thrown (stored into the Event variable). In this case, the ResetStatus variable is obviously always going from zero to two with no additional influence. Therefore, the final condition may be removed (even by the MATLAB optimization process during compilation). If there is an external condition, such as a waiting for an external pin to be set, then it makes sense to use such "status" variable as a green light for completing the state task and throwing the "done" event. Embedded C code Implementation In default settings, MATLAB Embedded Coder generates the state machine code in a fashion of switch-case structure. This might be not very useful for further code debugging or for manual editing. Therefore, the function call subsystem block parameters should be changed as shown below. The function packaging option is set to "Nonreusable function", other settings might be left at default values. This will keep the state machine code structure in switch-case, however the state handlers function calls will be generated as static functions (instead of putting the code inside the switch-case). Following code sample is a part of the state machine code generated in the stateMachineTest.c example code. The state machine decides based on the State variable, which is internally stored in the stateMachineTest_DW.is_c1_stateMachineTest. Based on the stateMachineTest_DW.Event, a transition is initiated. Finally, the state handler function is called, in this case stateMachineTest_Resetstate(). void stateMachineTest_step(void) { /* ...  */       switch (stateMachineTest_DW.is_c1_stateMachineTest) { /* ... */       case stateMachineTest_IN_Reset:             rtb_y = 1U;             /* During 'Reset': '<S5>:35' */             if (stateMachineTest_DW.Event == stateMachineTest_e_reset_done) {               /* Transition: '<S5>:37' */               stateMachineTest_DW.is_c1_stateMachineTest = stateMachineTest_IN_Init;               /* Entry 'Init': '<S5>:1' */               rtb_y = 2U;             } else if (stateMachineTest_DW.Event == stateMachineTest_e_fault) {               /* Transition: '<S5>:46' */               stateMachineTest_DW.is_c1_stateMachineTest = stateMachineTest_IN_Fault;               /* Entry 'Fault': '<S5>:18' */               rtb_y = 7U;             } else {               /* Outputs for Function Call SubSystem: '<Root>/Reset state' */               /* Event: '<S5>:49' */               stateMachineTest_Resetstate();               /* End of Outputs for SubSystem: '<Root>/Reset state' */             }             break; /* ... */       }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ /* ... */ }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The reset state function is compiled based on priorities set in each block of the Simulink model. If no priorities are set, the default ones are based on the order of adding them to the model. Therefore, it is very important to verify and eventually change the priorities as requested by its logical sequence. This setting can be changed in the block properties as shown below. The priority settings is shown after the model is updated (Ctrl+D) as a number in the upper right corner of each block. State Machine Test Application Testing application is designed to test all the features of the state machine, targeting the S32K144EVB. To indicate active states, RGB LED diode is used in combination with flashing frequency. On-board buttons SW2 and SW3 are used to control the application. The application is running in 10 ms interrupt routine (given by the sample time). There is an independent LPIT interrupt controlling the LED flashing. After the power-on reset, the device is configured and the RESET state is entered, where additional HW and application settings are performed. Then, the application runs into the INIT state with a simulated delay of approx. 2 seconds, indicated by the blue LED diode flashing fast. After the delay, the READY state is entered automatically. Both buttons are handled by another state machine, which detects short and long button press. While the short press is not directly indicated, the long press is indicated by the red LED diode switched on. By a short pressing of the SW2, the application is started, entering the CALIB state first, followed by the ALIGN state and finally entering the RUN state. The CALIB and ALIGN states are indicated by higher frequency flashing of the blue LED, while the RUN state is indicated by the green LED being switched on. The application introduces a simulation of the speed command, which can be changed by long pressing of the SW2 (up) or SW3 (down) within the range of 0 to 10,000. Moreover, to simulate a fault situation, the e_fault event is thrown once the speed command reaches value of 5,000. The FAULT state is entered, indicated by the red LED flashing. To clear the fault, both SW2 and SW3 should be pressed simultaneously. The INIT state is entered, indicated by the blue LED diode flashing fast. Following tables show the functions and LED indication. Button Press lenght Function SW2 short press Start the application SW2 long press Increase the speed command (indicated by the red LED diode ON) SW3 short press Stop the application SW3 long press Decrease the speed command (indicated by the red LED diode ON) SW2+SW3 short press Clear faults State LED Flashing Reset - Init Blue period 50 Ready Blue period 500 Calib Blue period 250 Align Blue period 100 Run Green always on Fault Red period 100 any Red always on when a long press of SW2 or SW3 is detected Running the example The example can be built and run along with the Model Based Design Toolbox for S32K14x, v3.0.0. This version has been created using MATLAB R2017a. Please follow the instructions and courses on the NXP Community page prior to running this example. Usage of the S32K144EVB with no connected extension boards is recommended, however this example doesn't use any HW interfaces except of (please refer to the S32K144EVB documentation): S32K144 pin S32K144EVB connector Usage PTD15 J2.2 GPIO output / strength: High / Red LED PTD0 J2.6 GPIO output / strength: High / Blue LED PTD16 J2.4 GPIO output / strength: High / Green LED PTC12 J2.10 GPIO input / Button SW2 PTC13 J2.12 GPIO input / Button SW3 PTC6 J4.4 UART1 / RxD / FreeMASTER PTC7 J4.2 UART1 / TxD / FreeMASTER The application works also with the FreeMASTER application. Users can connect to the target and watch or control the application. The FreeMASTER project is attached as well, however, the ELF file location needs to be updated in the FreeMASTER project settings after the application is built and run.
View full article
BLDC Closed Loop Speed Control example for MPC574xP(Panther)+MotorGD Features: - Commutation based on HALL sensor transitions - Speed PI controller - Speed estimator based on HALL A transition time - Example made for Linix Motor (phA-white/phB-blue/phC-green) Copyright (c) 2017 NXP version 1.0.0 Model Based Design ToolBox
View full article
BLDC OpenLoop Voltage Control example for MPC574xP(Panther)+MotorGD Features: - Commutation based on HALL sensor transitions - Voltage read via SW1(++) and SW2(--) - Voltage can be read from POT if VoltageReqSource=0 - Motor can rotate CW (default) or CCW via SW1/SW2 Copyright (c) 2017 NXP version 1.0.1 Model Based Design ToolBox
View full article