恩智浦基于模型的设计工具知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

NXP Model-Based Design Tools Knowledge Base

讨论

排序依据:
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
查看全文
General Installer and Setup  How to install the license of MBDT for S32K3?  How to setup the S32K344 toolbox and EVB?  How to export the generated code to S32DS3.4? Export generated projects in MBDT for s32k3XX  Programming methods MBDT for S32k3 using P&E Multilink Custom code usage SENT Protocol Support in S32K3 MBDT Custom project usage How to use custom project configuration Sequential reset S32K344-Q172 sequential reset SIL / PIL / External Mode External mode External mode example wouldn't compile after update  S32K3X4EVB-Q257 with MBDT PIL Example: Not able to run Simple PIL S32CT example Peripherals ADC How to add a new ADC channel using the external configuration tool  SPI How to send 32 bit frames  DIO S32K3x4-Q172P_with_MBDT_Blink_Project DIO and PWM configuration issues ICU PWM Duty cycle measurement PWM PWM raising edge and falling edge detection Interrupt based PWM generation CAN FreeMASTER over CAN connection issue  Apps Motor Control SPI configuration MODEL based design tool box- 32 bit instruction (SIMULINK) 
查看全文
1. INTRODUCTION    This article presents how to use NXP’s Model-Based Design Toolbox (MBDT) to implement an Air Quality Monitor that integrates multiple sensors, which will be configured to run on the 3S32K144 EVB.    The Model-Based Design Toolbox offers a solution for deploying complex applications on NXP hardware directly from Simulink. It incorporates hardware-optimized software, including drivers, libraries, and tools, allowing users to concentrate solely on algorithm development. The toolbox manages the hardware integration, ensuring the applications are hardware-aware. By integrating with the MathWorks ecosystem, the Model-Based Design Toolbox leverages the model-based design paradigm. This enables a programming process based on models, where users create logical diagrams using Simulink blocks for dedicated functions, eliminating the need to write C code for their designs.     This article aims to show how this tool can be used for designing and deploying on an S32K144 Evaluation board an air quality monitor application. Therefore, the steps meant to accomplish this are parted in the following sections:       II. General purpose – what is the aim of the application;       III. Application overview – how the application works and how the sensors are integrated;      IV. Hardware design – the description of the components used;       V. Software design – the execution flow of the application and the model implementation explained in detail;      VI. Conclusion – results of the application.    2. GENERAL PURPOSE    This application shows how easily an Air Quality Monitor can be implemented when using the MBD toolbox for S32K1xx, which helps the users simplify their job by providing the means to use a graphic and visual way to put their idea into use and generate the C code from it, which will be uploaded on the EVB.    3. APPLICATION OVERVIEW     The application displays in FreeMASTER the values of temperature, humidity, dust density, pressure, and the values of eCO2 and TVOC. Those values are read from the sensors connected to the EVB and computed using the algorithms from the libraries corresponding to each sensor, such as Adafruit’s libraries for BMP280 and CCS811, Sparkfun library for HTU21D and the GP2Y1010AU0F library, which are then adapted in Simulink logic. The application will be split into four subsystems, each covering a sensor and its algorithm.    BLOCK DIAGRAM                                                        Figure 1: Block Diagram     4. HARDWARE DESIGN     4.1. Hardware components   The required components for this application are:  S32K144 Evaluation Board  HTU21D, temperature and humidity sensor CCS811, eCO2 and TVOC sensor  BMP280, pressure sensor  GP2Y1010AU0F, dust density sensor        1) S32K144 Evaluation Board  The S32K144EVB is a low-cost evaluation and development board for general-purpose industrial and automotive applications. The board represents the main part of the application as it collects the data from the sensors and applies the algorithm to compute the values shown in FreeMASTER.  For more information about the board, access the following NXP page.      2) Temperature and humidity sensor HTU21D  The HTU21D is an easy-to-use, digital sensor for measuring humidity and temperature levels. It utilizes the I2C communication protocol, making it suitable for various applications, such as an Air Quality Monitor.     3) eCO2 and TVOC sensor CCS811  The CCS811 sensor precisely monitors indoor air quality, measuring TVOCs and carbon dioxide levels in real time. Using the I2C communication protocol, it is easily integrated into air quality monitor applications.     4) Pressure sensor BMP280  The BMP280 sensor accurately measures atmospheric pressure using the I2C communication protocol.     5) Dust density sensor GP2Y1010AU0F  The GP2Y1010AU0F sensor is utilized for the measurement of dust density with high precision. Utilizing an analog output mechanism, it delivers reliable data for comprehensive air quality assessments.    4.2. Electrical schematic    Apart from the components described above (HTU21D sensor, CCS811 sensor, BMP280 sensor and GP2Y1010AU0F sensor), a resistor and a capacitor will be needed.   The following electrical schematic is an example of how the sensors can be connected:                                                             Figure 2: Electrical schematic    5. SOFTWARE DESIGN    5.1. Prerequisite software  To be able to follow the next steps presented in this article, the following software will be necessary:  Matlab® and Simulink® (2021a or newer), including Stateflow ®, MATLAB® CoderTM, Simulink® CoderTM, Embedded Coder®  NXP Support Package S32K1xx    5.2. Model overview   The application uses the Simulink environment to implement the algorithms for computing the data read from the sensors connected to the S32K144 EVB. The model is organized into two big sections: initialization and sensors’ algorithms. For the sensors part, each sensor has its subsystem where the algorithm is implemented.                                                     Figure 3: Application’s model    5.3. INITIALIZATION  The initialization holds the blocks required for our model to work. On the first line, from left to right, the following can be found:        1) The Configuration block for S32K1xx processor family. The required settings of the processor configuration block are the default ones, except for the processor family and the download interface.                           Figure 4: Configuration block for S32K1xx family of processors        2) The LP2IC Configuration block. Here the functioning mode (master or slave) can be changed, and the pins used for communication can be chosen. This application has three sensors that use this communication protocol:  BMP280, whose address is 0x76  CCS811, whose address is 0x5A HTU21D, whose address is 0x40                                            Figure 5: Configuration block for LPI2C        3) The FreeMASTER configuration block. Here the communication interface, the baud rate, and long interrupt serial communication can be set. This component facilitates communication between the S32K144 EVB LPUART1 instance and the FreeMaster tool, via the microUSB serial port.                                Figure 6: Configuration block for FreeMASTER        4) The configuration block for ADC. The ADC converter number and the resolution mode can be selected from here.     Figure 7: Configuration block for ADC    On the second line, the data stores for the variables used in this project can be found. The data type and size for the data stores can be found in the following table:     VARIABLE NAMES  DATA TYPE  SIZE / DIMENSION  SENSOR  aux_temp  uint8  3  BMP280  aux_press  uint8  3  BMP280  BMP280_Temp  uint8  6  BMP280  BMP280_Press  uint8  18  BMP280  BMP280_T  uint16  1  BMP280  BMP280_T2  int16  2  BMP280  BMP280_P  uint16  1  BMP280  BMP280_P2  int16  8  BMP280  raw_press  int32  1  BMP280  raw_temp  int32  1  BMP280  Pressure  double  1  BMP280  buf  uint8  8  CCS811  TVOC  uint16  1  CCS811  eCO2  uint16  1  CCS811  temperature  double  1  HTU21D  humidity  double  1  HTU21D  hum_raw  uint16  1  HTU21D  temp_raw  uint16  1  HTU21D  humcomp  default  default  HTU21D  dustDensity  default  default  GP2Y1010AU0F    Figure 8: Variables    Note! It is important, for the variables to be visible in FreeMASTER, to go to Apps -> Embedded Coder -> Code Interface -> Default Code Mappings -> Data Stores and set all the variables to Volatile.    Figure 9: Embedded Coder selection    Figure 10: Default Code Mappings    5.4. ALGORITHM   The second part of the model consists of every sensor’s subsystem. In each subsystem, the necessary algorithm for computing the data is implemented.   Let’s look at every subsystem and algorithm.       5.4.1. BMP 280 Pressure sensor   For this sensor’s initialization, BMP280_Temp and BMP280_Press will  be used. Top down, five subsystems can be found: Global Initialization Sensor, Temp Calib, read16LE – temp, Press Calib, read16LE – press.     Figure 11: BMP280 subsystems    The purpose of the Global Initialization Sensor is to prepare the sensor for subsequent data reading. This involves transmitting specific data to the sensor using the LPI2C Master Transmit block. These data include values such as 0xF5 and 108, as well as 0xF4 and 111, which serve to configure and calibrate the sensor for upcoming tasks. Having multiple sensors connected using I2C communication protocol, the way the sensor can differentiate between them is by their address. Therefore, the data will be sent to the 0x76 address, which corresponds to the address of the pressure sensor.  Figure 12: Pressure sensor initialization    In Temp Calib subsystem, data is read from the temperature's memory location and placed into the BMP280_Temp data store mentioned earlier. The addresses from which data needs to be read are sequential, so reading begins from the 0x88 address and 6 bits of data are requested, resulting in reading from address 0x88 to address 0x8C inclusively.  Figure 13: I2C Master Multi Transfer    In read16LE – temp subsystem, the add operation is utilized to perform an OR bit operation for calibrating the data and placing it into the BMP280_T data store and the BMP280_T2. LE stands for Little Endian.    Figure 14: Temperature data calibration    For the Press Calib and read16LE – press subsystems, the same operations described previously are performed, but for a greater number of bits. After the initialization is completed, the Else subsystem is entered, where the computing takes place. An auxiliary temperature is computed, which is required for the pressure's formula. For this purpose, the data store named aux_temp will be used. Within this subsystem, there are 2 further subsystems: READ TEMP REGISTER and RAW TEMP.  In READ TEMP REGISTER, data is read from the 0xFA address using an LPI2C Master Multi Transfer, and 3 bits of data are transferred into the aforementioned aux_temp data store.  In RAW TEMP, the raw_temp necessary for the pressure calculation formula is computed.  Similar to the temperature calculation, the pressure calculation data is read from the 0xF7 address into the data store named aux_press, and then the raw_press required for the formula is computed.  For the actual computation of the pressure, an S-Function block with C code inside is utilized, where the algorithm found in the Adafruit Library for BMP280 is included. [1] [functions float Adafruit_BMP280::readTemperature() and float Adafruit_BMP280::readPressure()].  Figure 15: convertPressure S-Function       5.4.2. CCS811 TVOC & eCO2 sensor  For this sensor, during initialization, the same procedure as before is followed: specific data is sent to the sensor using the LPI2C Master Transmit to notify it of the upcoming data reading. Specifically, the predefined data 0xF4 and 0x01, 16 is now transmitted.   Figure 16: Initialization for eCO2 and TVOC sensor    In the Else subsystem, 8 bits of data are read and placed into the buf variable using the LPI2C Master Multi Transfer block. Subsequently, after the necessary data is retrieved from the sensor, the required values are computed, with their formulas sourced from the Adafruit Library for the CCS811 sensor [2]:  _eCO2 = ((uint16_t)buf[0] << 😎 | ((uint16_t)buf[1]);  _TVOC = ((uint16_t)buf[2] << 😎 | ((uint16_t)buf[3]);    Figure 17: Compute data for eCO2 and TVOC values       5.4.3. Humidity & Temperature subsystem  For this sensor, another library [3] will be utilized to obtain the necessary formulas and the algorithm. Initially, for both temperature and humidity readings, the LPI2C Master Multi Transfer block will be employed to retrieve the required values. Specifically, the command to trigger temperature readings is 227, and for humidity, it is 229. Each reading will consist of 3 bits, from which only the most significant bit and the least significant bit will be utilized for temperature and humidity, respectively.  For both of them, the raw values need to be computed. The formulas needed are:  For temperature:  uint16_t rawValue = ((uint16_t) msb << 😎 | (uint16_t) lsb;  temp_raw = rawValue & 0xFFFC;       2. For humidity:  uint16_t rawValue = ((uint16_t) msb << 😎 | (uint16_t) lsb;  hum_raw = rawValue & 0xFFFC;    The temperature is computed using the following formula:  Temperature = temp_raw * (175.72 / 65536.0) – 46.85;    Figure 18: Temperature computing    The humidity is computed using the following formula:  Humidity = (-6) + 125 * (hum_raw / 65536.0) + (25 – Temperature) * (-0.15);    Figure 19: Humidity computing    Figure 20: Temperature and humidity subsystem       5.4.4. Dust Pm2.5 subsystem  For this final sensor, an additional library [4] will be employed to implement our model-based design algorithm for measuring and computing the PM2.5 levels in our surroundings.   In this scenario, the GPIO Write block will be utilized to activate and deactivate the infrared LED on the sensor. Following activation, a 0.28ms delay will be introduced before employing the ADC to read the data, which will then be computed using the provided formula:  dustDensity = (170 * 5 / 1024 – 0.1) * Voltage      Figure 21: Formula applied for dust density    After applying the above-mentioned formula, another delay of 0.04ms will be used and then the LED will be turned off.      Figure 22: Dust Pm2.5 subsystem    5.5. FREEMASTER  To visualize the results from the application, a FreeMASTER project can be created. Once created, the .elf file of the built application can be added by navigating to Project -> Resource files -> "pack" directory setup -> MAP Files -> Default symbol file.  Variables can be added to the Variable Watch section. For this project, the most important ones are Pressure, eCO2, TVOC, humidity, temperature, and dustDensity.    Figure 23: Variable watch section    5.6. HARDWARE SETUP  A possible example for hardware setup is represented in the below picture:  Figure 24: Hardware setup    6. CONCLUSION    The application covers the steps of developing an air quality monitor that monitors how the pressure, TVOC, eCO2, humidity, temperature, and dust density evolve in a room, using the Model-Based Design Toolbox for S32K1 MCUs. It can be a good academic study for how to use the S32K1XX EVB and sensors using the MBDT and for how to adapt C code and use it in a graphic programming environment such as Simulink to simplify your work.      Bibliography:   [1] https://github.com/adafruit/Adafruit_BMP280_Library  [2] https://github.com/adafruit/Adafruit_CCS811  [3] https://github.com/sparkfun/SparkFun_HTU21D_Breakout_Arduino_Library  [4] https://github.com/mickey9801/GP2Y1010AU0F       NXP is a trademark of NXP B.V. All other product or service names are the property of their respective owners. © 2024 NXP B.V. MATLAB, Simulink, and Embedded Coder are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.   
查看全文
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3xx – version 1.5.0     The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.5.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART). In this release, we have also updated RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 140 examples, covering all the features and functionalities of the toolbox, including demos for motor control applications.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983098   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripherals (MCAL components): ADC CAN DIO GPT I2C ICU LIN MEM MCL PWM SPI UART   New RTD version supported  (4.0.0 P19) New S32 Configuration Tools version supported (2024.R1.7) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks   Integrates the Automotive Math and Motor Control Library release 1.1.35        All functions in the Automotive Math and Motor Control Library v1.1.35 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   S32 Design Studio Integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Support for custom default project configuration The toolbox provides support to use and create custom default project configurations. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom default project, it can be used for every model that is being developed.         Such custom projects, addressing specific hardware designs are offered inside the current version of the toolbox to integrate the following EVBs: S32K396-BGA-DC1 MR-CANHUBK344, alongside a set of examples specifically created to target this hardware design and a series of articles (available on NXP Community) demonstrating how to use the toolbox features and functionalities for creating applications for custom boards.   For a complete list of the hardware on which the toolbox was tested and developed, please consult the attached Release Notes document.   Simulation modes We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) including AUTOSAR SW-C deployment External mode     Motor Control Applications The toolbox provides examples for 1-shunt and 2-shunt PMSM and BLDC motor control applications, supporting both S32 Configuration Tools and EB  Tresos. Each of the examples provides a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The toolbox also demonstrates the integration of the Motor Control Blockset in developing such applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a   Examples for every peripheral/function supported More than 140 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Motor Control applications AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3xx version 1.5.0  is fully integrated with MATLAB® environment.   Target Audience: This release (1.5.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      
查看全文
This page summarizes all Model-Based Design Toolbox videos related to BMS. Speed-Up BMS Application Development with NXP's High-Voltage Battery Management System Reference Design and Model-Based Design Toolbox (MBDT) Link to the recording here  This webinar shows how to design and develop Battery Management Systems, with NXP's High-Voltage BMS Reference Design and Model-Based Design Toolbox for S32K3xx, with Simulink® and Embedded Coder. During this webinar, we will introduce the ASIL D High Voltage Battery Management System Reference Resign that comprises a Battery Management Unit (BMU), Cell Monitoring Units (CMU), and a Battery Junction Box (BJB). NXP's HV-BMS Reference Design is a robust and scalable solution including hardware designs, production-ready software drivers, and safety libraries, as well as extensive ISO 26262 Functional Safety documentation. The design significantly reduces the development effort and enables an improved time to market with the latest chipset innovations. Speed Up Electrification Solutions Using NXP Tools Link to the recording here  This video provides an overview of the NXP Software and Tools solutions, designed to help customers to speed up application development with design, simulation, implementation, deployment, testing, and validation. During this session, you will learn about all the steps required to build complete solutions like battery management systems with NXP in-house solutions and NXP Model-Based Design Toolbox with simulation and code generation.
查看全文
This page summarizes all Model-Based Design Toolbox tutorials and articles related to BMS on S32K3xx & S32K1xx Product Family   MBDT for BMS & MBDT for S32K3xx:   MBDT for S32K1xx: How to use RDDRONE-BMS772 with MBDT   
查看全文
This page summarizes all Model-Based Design Toolbox topics related to the BMS Product Family. Model-Based Design Toolbox for BMS- Release Notes: Rev 1.1.0 - Model-Based Design Toolbox for BMS rev 1.1.0  Rev 1.0.0 - Model-Based Design Toolbox for BMS rev 1.0.0 
查看全文
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for LAX – version 1.2.0 RTM   The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for LAX version 1.2.0 RTM. This release supports automatic code generation for ARM Cortex-A53 and NXP LAX Accelerator cores from MATLAB for NXP S32R45 Automotive Microprocessors. This release adds support for RSDK 1.2.0, improves to code generation and Radar processing demo, and adds support for new trigonometric LAX kernels. The product comes with 60 examples, covering the supported RSDK LAX Kernels by MATLAB API and demonstrating the programming of the LAX accelerator from MATLAB environment.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983168   Technical Support: NXP Model-Based Design Toolbox for LAX issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP S32R45: ARM Cortex-A53 NXP LAX Accelerator Support Linux application build and run NXP Auto Linux BSP 37.0 for S32R45 Includes MATLAB API for additional RSDK LAX Kernels highly optimized for LAX accelerator add, sub, mul, div, times, cT, inv abs, abs2, sqrtAbs ¸conj, norm, norm2 diag, eye, zeros, ones, find, sort cospi, sinpi, tanpi, cispi, sincpi acospi, asinpi, atanpi, atan2pi Improved code generation and reduced memory usage Support for Radar SDK version 1.2.0 Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a More than 60 examples showcasing the supported functionalities: Cholesky Gauss-Newton Eigen (new) Kalman Filter Linear Regression Navier-Stokes QR Factorization (updated) MUSIC DoA (updated) Radar processing demo (updated) Range FFT, Doppler FFT, and Non-Coherent Combining offloaded to NXP SPT accelerator MUSIC DoA offloaded to NXP LAX accelerator     For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® experience by allowing customers to evaluate and use NXP LAX Accelerator from NXP’s S32R45 MPU and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for LAX version 1.2.0 is fully integrated with MATLAB® environment.       Target Audience: This release (1.2.0 RTM) is intended for technology demonstration, evaluation purposes, and prototyping on NXP S32R45 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt    
查看全文
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for BMS – version 1.1.0     The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for BMS version 1.1.0 RTM. This release is an Add-On for the NXP Model-Based Design Toolbox for S32K3xx 1.4.0, which supports automatic code generation for battery cell controllers and applications prototyping from MATLAB/Simulink. This product adds support for MC33775A, MC33774A, MC33772C, MC33664, and MC33665A and part of their peripherals, based on BMS SDK components (Bcc_772c, Bcc_772c_SL, Bcc_775a, Bcc_774a, Bms_TPL3_SL_E2E, Bms_common, Phy_664, Phy_665a). In this release, we have enhanced the integration with the Model-Based Design Toolbox for S32K3xx version 1.4.0, added support for the BMS SDK 1.0.2 and BMS SDK 1.0.2 SL, and MATLAB support for the latest versions. This product comes with battery cell controller examples, targeting the NXP HVBMS Reference Design Bundle Using ETPL (RD-HVBMSCTBUN) and 800 V Battery Management System (BMS) Reference Designs Using ETPL (RD-HVBMSCT800BUN).   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983088   Technical Support: NXP Model-Based Design Toolbox for BMS issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP Battery Cell Controllers derivatives: MC33775A MC33774A MC33772C MC33665A MC33664   Support for the following peripherals (BMS SDK components): Bcc_775a Bcc_774a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E   Support for MC33775A, MC33774A and MC33772C Battery Cell Controllers & MC33664PHY and MC33665PHY The toolbox provides support for the MC33775A, MC33774A, MC33772C, MC33664 and MC33665A. The MC33775A, MC3774A, and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications performing ADC conversions of the differential cell voltages and battery temperatures, while the MC3366 and MC33665A are transceiver physical layer transformer drivers, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for BMS show how to communicate between the S32K344/S32K358 and the MC33775A, MC33774A, and MC33772C via the MC33664/MC33665 transceivers.  For the MC33775A and MC33774A, the examples show how to configure the battery cell controllers to perform Primary and Secondary chain conversions and read the cell voltage conversion results from the MC33775A/MC33774A, while for the MC33772C the examples show how to configure the Battery cell controller to read the pack current. All the converted values are displayed to the user over the FreeMASTER application.               BMS SDK version supported: SW32K3_BMS_SDK_4.4_R21-11_1.0.2 SW32K3_BMS_SL_SDK_4.4_R21-11_1.0.2_DEMO Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a More than 15 examples showcasing the supported functionalities: MC33775A Configuration and data acquisition example MC33774A Configuration and data acquisition example MC33772C Configuration and data acquisition example RD-HVBMSCTBUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits) RD-HVBMSCT800BUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits)   For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s Battery Cell Controllers together with S32K3xx MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for BMS version 1.1.0 is fully integrated with MATLAB® environment.     Target Audience: This release (1.1.0) is intended for technology demonstration, evaluation purposes, and battery management systems prototyping using NXP Battery Cell Controllers and S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt   DEMO High Voltage Battery Management System with Model-Based Design: The HVBMS with MBDT demo, running on the NXP HVBMS Reference Design and NXP GoldBox, combines the MathWorks Simulink application example Design and Test Lithium Ion Battery Management Algorithms  together with the NXP’s Model-Based Design Toolbox for BMS  Blocks to automatically generate, build, and deploy standalone BMS applications on the NXP targets. Here are the main highlights of this demo: Develop a High-Voltage Battery Management System application to run on the NXP's HVBMS Reference Bundle using the Model-Based Design paradigm Model, Develop, and Validate BMS Applications in MATLAB and Simulink Automatically Generate code, Build, and Deploy hardware-aware applications on NXP microcontrollers and processors Monitor and Tune the application using FreeMASTER and Vehicle Network Toolbox at runtime Create a Cloud Digital twin with NXP GoldBox and AWS with data processing in MATLAB Cloud          
查看全文
1. Introduction   This article demonstrates how to control a 4-wire server fan based on temperature or user input, using the Model-Based Design Toolbox for S32K1 MCUs. The Model-Based Design Toolbox represents a solution which allows the complex applications deployment on NXP hardware directly from Simulink. By incorporating hardware optimized software, such as drivers, libraries, and tools, the Model-Based Design Toolbox allows the users to focus only on the algorithm development, while making such applications hardware-aware is handled by the toolbox. By the integration with the MathWorks ecosystem, the MBDT leverages the model-based design paradigm, thus enabling a programming process based on models - users to not need to write C code for implementing their designs, but create logical diagrams using Simulink blocks performing dedicated functions. In this article, we will demonstrate how this tool can be used for designing and deploying on an S32K146 Evaluation board a fan speed control application. Thus, the steps proposed for achieving this are described thorughout the article, in the following sections: II. Application overview – how the application works and the links between the components; III. Hardware design – the description of the components used and the electrical diagram; IV. Software design – the application execution flow and the model implementation explained in more detail; V. Conclusion – the results of the application.   2. Application overview   The application has 2 operating modes: automatic and manual. To switch between operating modes, we need to press the SW2 button on the S32K146 board. When starting, the application is in automatic operating mode (the RGB LED of the board lights up green): this means the fan adjusts its speed according to temperature. In manual mode (the RGB LED of the board lights up blue), the fan changes its speed depending on the value supplied by the potentiometer. The graphs and values of fan speed, acceleration, ambient temperature will be displayed in FreeMASTER. Block diagram   Figure 1: Block diagram   3. Hardware design   A. Hardware components The required hardware components are:  S32K146 Evaluation board  Thermistor NTC100K  4-wire PC fan   12V power supply AC-DC.   1) S32K146 Evaluation board The S32K146EVB serves as an affordable evaluation and development board designed for a wide range of industrial and automotive uses. The board is the “brain” of the application, as it collects data from various sensors (e.g.: temperature sensor) and uses the algorithm to regulate the actuators (e.g.: the BLDC motors found in fans).  For more information about the board, please read from here.   2) Thermistor NTC100K A thermistor is a resistor whose resistance is dependent on temperature. The temperature value is calculated using the Steinhart-Hart equation. The Steinhart-Hart coefficients A, B, C vary depending on the type and model of thermistor and the temperature range of interest. To find these coefficients, we use three values of resistance data for three known temperatures. For example, from NTC100K Thermistor Datasheet we get for the temperatures of 15℃, 25℃ and 45℃, corresponding resistance values of 156407 Ω, 100000 Ω and 43659 Ω. It results, according to the equation (2), that the coefficients have the following values:  So, the steps to determine the temperature are to get the thermistor resistance using a voltage divider converter along with an analog-to-digital converter (ADC) and calculate the temperature from the resistance.    3) 4-wire PC fan The fan has 4 pins, being used especially for processors with high power consumption. The simplest fan has 2 pins, one for power and one for ground. The 3-wire fan has an extra pin called “tachometer”, which indicates the speed of the fan (one/two impulses are received for each rotation). With 2-wire and 3-wire fans, the speed is controlled by increasing/decreasing the voltage on the power pin. Instead, the 4-wire fan has a control pin and uses PWM (Pulse Width Modulation) to control the speed.  Before using the fan, we must find out information such as the maximum speed, the number of impulses per rotation given by tachometer and the minimum operating speed if necessary. These things can be looked up in the fan’s datasheet or can be determined experimentally if we have an unknown fan, and we cannot find its datasheet.  The values of the fan used as an example in this article were determined experimentally and we got an approximate maximum speed of 300 rotations per second (18000 rpm), two impulses per rotation and a minimum operating speed of 80 rotations per second (4800 rpm).    4) 12V power supply AC-DC The power supply converts alternating current (AC) electrical energy into direct current (DC) electrical energy with an output voltage of 12 volts. In our application, it will supply the power for the fan.   B. Electrical schematic There are multiple hardware configurations for the fan speed control application. We will use, in addition to the hardware components mentioned above (fan, 12V power supply, thermistor), the potentiometer, the SW2 button and the RGB LED of the S32K146EVB.  We propose the following electrical schematic:  Figure 2: Electrical schematic Note! It is important that all components are connected to the same ground.   C. Hardware setup A possible hardware setup may look like in the following picture:  Figure 3: Hardware setup example   4. Software design   A. Prerequisite software To be able to follow the next steps in this article, the following software is necessary: MATLAB ®  and Simulink ®  (2021a or newer), including Stateflow ® , MATLAB ®  Coder TM , Simulink ®  Coder TM , Embedded Coder ® Model-Based Design Toolbox for S32K1xx 4.3.0   B. Flow chart The application execution flow is based on a state machine, according to the following diagram. Figure 4: State machine The architecture of the application is a closed-loop system, which uses a feedback signal to adjust the fan speed. The current fan speed and the fan acceleration update their values with each tachometer pulse. The difference between the reference speed (set using temperature or potentiometer) and the current speed, alias error signal, is the input to the closed-loop control system, such as a proportional-integral-derivative (PID) controller. The PID controller applies a correction based on proportional, integral, and derivative coefficients to a control function, in our case, it determines the PWM duty cycle to control the fan speed.  Figure 5: Application's model   C. Model Overview From top to bottom (Figure 5), we have 4 big sections:  Initialization Switching between operating modes The operating modes which set the reference speed The control algorithm. Let’s take each section to dive further into the details.    1) Initialization  Figure 6: Initialization section We have on the first line, from left to right, the Configuration block for S32K1xx processor family, the FreeMASTER Configuration Block and two ADC Configuration Blocks. On the second line, we have the pull-up resistance on the tachometer pin and two mapping functions from the temperature value and the ADC potentiometer value to the reference speed. Also, there are variables for current operating mode, temperature value, reference speed, current speed, duty cycle and some other auxiliary variables.  The required configurations of the processor configuration block are the default ones, except for the processor model and the download interface (Figure 7).  For the FreeMASTER configuration block, we set the communication interface (e.g.: LPUART1), the baud rate (e.g.: 19200) and long interrupt serial communication. This component provides an interface where relevant data such as current speed, ambient temperature and many others are displayed. In the ADC configurations blocks, used for reading temperature and potentiometer value, we select the ADC converter number and the resolution mode (e.g.: 10-bit conversion).   Figure 7: Configuration block for S32K1xx family of processors   2) Switching between operating modes We configure the pin PTC12 (SW2) to generate a falling edge interrupt on each button press, using the GPI ISR block. Figure 8: Switching mode section When an interrupt is generated, the value of the operation mode variable is toggled and the color of the LED corresponding to the operating mode lights up (automatic mode – green, manual mode – blue). It also enables/disables the PIT (Periodic Interrupt Timer) interrupt which triggers the ADC reading of the temperature sensor at each one second (Figure 10).  Figure 9: The function called when the interrupt is generated.  Figure 10: Enable/disable PIT interrupt for ADC temperature reading; RGB LED in Automatic & Manual mode   3) Operation modes  Figure 11: Operation modes section Depending on the operating mode, the reference speed is set by the temperature value or the ADC value of the potentiometer. a) Automatic mode In this mode, the PIT block is enabled, and the ADC value of the thermistor is read once per second. The resolution of the ADC is 10 bits. So, it can take values between 0 and 1023, which corresponds to voltage values between 0V and 5V. Let’s assume Vout is the output voltage on the pin PTB13. Also, according to the electrical schematic from Figure 2, we have a voltage divider: We can find out the value of thermistor resistance: And then, we can get the temperature value using the Steinhart-Hart equation (1).  Based on the temperature, we can map a value for reference speed. We can define for this mapping a linear function or whatever we need.  Figure 12: Automatic mode   b) Manual mode In manual mode, the ADC value of the potentiometer is read and mapped to reference speed.  Figure 13: Manual mode   4) The control algorithm  Figure 14: The control algorithm section In this section, the closed loop of the system is implemented using the PID (Proportional-Integral-Derivative) controller. We must tune the coefficients of the PID controller (Kp, Ki, Kd) to produce the optimal control function. There are several methods for tuning: manual, Ziegler-Nichols or using software specialized tools. For this application, the Ziegler-Nichols method was used, and, for fine adjustment, manual tunning was applied. After applying this method, we get the following values: KP = 0.003, KI = 0.003, KD = 0.001.  Figure 15: PID controller configuration With the PWM signal from the PID controller, we control the fan speed via the PWM pin, using the FTM PWM Config block. We configure the block as follows:  Figure 16: Parameters of FTM PWM Config block According to the electrical schematic (Figure 2), the pin used to control the fan speed is PTC1, which corresponds to FTM0_CH1. This means we need to configure the channel 1 from the module 0 of FTM (FlexTimer Module). To get the fan current speed, we need to know the period between two pulses from the tachometer. This can be determined using the FTM Input Capture block, which returns the timestamp in microseconds. Remember that there are two pulses per rotation. We measure the speed once every 10 milliseconds. So, the acceleration has the following value:  Figure 17: Calculation of fan speed and acceleration   D. FreeMASTER To visualize the results of the application, you can create a FreeMASTER project. Add the .elf file of the built application to Project – Resource files – “pack” directory setup – MAP Files – Default symbol file. You can add variables to the Variable Watch section, such as operation mode, current speed, reference speed, temperature (Figure 19). Also, you can create a graph, as in Figure 18, using the FreeMASTER oscilloscope with the current speed and reference speed. In the following figure, we can observe that the system is initially in automatic mode: temperature is about 28 Celsius degrees, which corresponds to an approximate reference speed of 110 rotations per seconds. Then, when SW2 button is pressed (at second 685 on the graph), the system goes into manual mode and the reference speed is set about 236 rotations per second, which is mapped according to the value read from the potentiometer. The current speed (red line) is tracking the reference speed imposed (green line).  Figure 18: Graphic with reference speed and current speed Also, we can track values such as operation mode - boolean value (0 for automatic mode and 1 for manual mode), temperature in Celsius degrees, reference speed and current speed measured in rotations per second, acceleration or the PWM duty cycle used for controlling the fan speed.  Figure 19: Variable watch section   5. Conclusion   In conclusion, the application consists in controlling the fan speed depending on the temperature or the potentiometer value, using the Model-Based Design Toolbox for S32K1 MCUs. It combines notions from systems theory, electronics, and embedded systems, representing an academic study on the use of fans for temperature control in different applications like servers, routers, switches, etc.   Useful links:   1. S32K146EVB:   https://www.nxp.com/document/guide/getting-started-with-the-s32k146-evaluation-board-for-general-purpose:NGS-S32K146EVB  2. NTC100K Thermistor: https://www.tme.eu/Document/f9d2f5e38227fc1c7d979e546ff51768/NTCM-100K-B3950.pdf  https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation#Steinhart%E2%80%93Hart_coefficients  3. 4-wire fan:  https://www.electroschematics.com/4-wire-pc-fan/  https://www.nidec.com/en/product/search/category/B101/M111/S100/NCJ-V40S-E5-57/  4. PID coefficients:  https://control.com/textbook/closed-loop-control/p-i-and-d-responses-graphed/  https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller    NXP is a trademark of NXP B.V. All other product or service names are the property of their respective owners. © 2024 NXP B.V. MATLAB, Simulink, and Embedded Coder are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.  
查看全文
1. Introduction This article shows how to develop an application for the UCANS32K1SIC evaluation board in MATLAB ® and Simulink ® and NXP ® ’s Model-Based Design Toolbox.  1.1. General purpose The UCANS32K1SIC is a CAN signal improvement capability (SIC) evaluation board designed for both automotive (ADAS, Body Control Units etc.) and industrial applications (Building Control, Servos, Mobile Robotic, etc.) In total, there are three UCANS32K1 evaluation boards: UCANS32K146-01 UCANS32K1SCT UCANS32K1SIC In this article, we choose to focus only on one of them, the UCANS32K1SIC evaluation board. The UCANS32K1SIC provides two CAN SIC interfaces and is based on the S32K146 (32-bit Arm ®  Cortex ® -M4) from the S32K microcontroller family. Also, the UCANS32K1SIC features EdgeLock ®  SE050 secure element for authentication and encryption development. For complete details, please access the following link 1.2. Block Diagram     2. The UCANS32K1SIC application example model The UCANS32K1SIC application example proposed in this article (ucans32k1sic_mbd_4_3_0) implements the following actions: Controls the RGB LED (GPO) Reads the Switch state  (GPI) Displays  messages on the LCD screen (“Red Led On”, “Green Led On”, “Blue Led On”) using the I 2 C communication protocol Adds FreeMASTER communication via UART protocol Configures  both instances of the CAN communication protocol (CAN0 and CAN1) and sends/receives messages 2.1. Prerequisite Software For the development of this application, the following software is required: MATLAB ® and Simulink ® (minimum 2020a) Stateflow ® MATLAB Coder ™ Simulink Coder™ Embedded Coder ® Support Package for ARM Cortex-M Processors Model-Based Design Toolbox for S32K1xx 4.3.0 FreeMASTER Run-Time Debugging Tool 3.2 2.2. Prerequisite Hardware For the development of this application, the following hardware is required: UCANS32K1SIC evaluation board DCD-LZ-ADAPT debug adapter with cable, which provides breakout connectors for SWD/JTAG Debugger and FTDI USB-UART CAN Bus Terminator (DRONE-CAN-TERM) with MicroUSB cable CAN cable terminated on both ends OLED Display 128x64 pixels JLink Debug Probe (or any other compatible SWD probe) IXXAT USB-to-CAN V2 (or any other canAnalyser )   3. Simulink model implementation and blocks configuration After the NXP Model-Based Design Toolbox for S32K1xx is installed, the next step is to open the library and drag and drop the necessary blocks. The MCU configuration with MBD_S32K1xx_Config_Implementation block   The first step is to add the MBD_S32K1xx_Config_Information into our Simulink model. This action makes the model aware that it will generate code for the S32K1 microcontroller. Once opening the block, the user needs to choose the processor family inside the MCU tab. For this particular board, the processor is S32K146. Then the system clock frequency (MHz) must also be specified: Clock Frequency Value (80 MHz) External Crystal clock - 8 MHz (check the schematics or other materials)     In the Target Connection tab, the following settings are required: The download interface JTAG and SEGGER JLink software. In our case, the kit comes with the SEGGER JLink so we are selecting this one. In case the JLink software is installed at a different location than the default one, the correct path shall be indicated in the “SEGGER JLink installation path” field.       3.1. Reads the Switch state (GPI) In this application, each push of the button selects which color of the RGB LED is lighten up. So, to be able to control that, the state of the button needs to be read. A variable named “counter” stores the values corresponding to each state (0-RED, 1-GREEN, 2-BLUE). The pin corresponding to the SW button reading must be configured (using the schematic for the UCANS32K1SIC evaluation board).                   With each execution of the main step in the model, the GPI Read block triggers the subsystem where the states of the LED are changed.   3.2. Controls the RGB LED (GPO) When the counter is incremented, the LED changes its state (RED-GREEN-BLUE). This is implemented using the GPO Write blocks. The pins corresponding to each LED color must be configured according to the schematic.   After identifying each pin, they must be set in GPO write blocks as follows: To turn on one of the LEDs colors, set the pin to 0 and to turn it off set it to 1. This is because the LED anode is routed to 3V3 and the cathode is connected to the pin. When the application requires to turn on only one color, the others must be turned off, as might be seen in the screenshots below.                            3.3. Displays messages on the LCD screen (“Red Led On”, Green Led On”, “Blue Led On”) using the I 2 C communication protocol For this example, the OLED display used is 128 x 64 pixels. The LCD communicates with MCU via LPI2C0 (P4). So, in order to communicate with the OLED display, the LPI2C instance must be first configured. LPI2C0 block configuration: The pins corresponding to LPI2C0 instance must be configured according to the schematic.                   Next, the OLED block  needs to be configured as follows:   After the LPI2C0 and OLED blocks are configured, messages can be displayed on the LCD screen using the LCD Write String block. LCD Write String block configuration:           To display the other messages (GREEN LED ON and BLUE LED ON), the steps are the same. To clear the LCD screen and  display another message, the LCD Clear Screen must be used.       3.4. FreeMASTER project via UART protocol FreeMASTER is a user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of embedded software applications. The FreeMASTER block configuration from NXP MBDT for the S32K1xx library uses the following communication interfaces: UART CAN In this example, we used the LPUART1 interface to send/receive messages from the FreeMASTER application. The pins corresponding to LPUART1 (they are routed to the P6 connector) instance must be configured according to the schematic.                              The RxD and TxD pins required routed in the schematics are PTC6 and PTC7. Another parameter that must be configured is the Baud Rate (maximum number of bits per second to be transferred). For this application, the Baud Rate is 115200 kbps.     3.5. Configures of both instances of the CAN communication protocol (CAN0 and CAN1) and sends/receives messages In this subchapter, the goal is to show how to receive/send messages on both CAN instances (CAN0 and CAN1). CAN0 instance First, CAN0 instance needs to be configured. For this action, the CAN configuration block is required. In the General tab, the following settings are: Module: 0 (for the CAN0 instance) Operational Mode: Normal mode Max number of MBs (1-32): 16 The RxD and TxD pins required are: PTE4 and PTE5 (according to the schematic)           In the Bit rate tab, the default Bitrate is 1000Kbit/s, but it depends on the case.     The next step is to choose the operating mode for the CAN transceiver (for UCANS32K1SIC, the CAN transceiver is TJA1463). The TJA1463 is a member of the TJA146x family of transceivers that provide an interface between a Controller Area Network (CAN) or CAN FD (Flexible Data rate) protocol controller and the physical two-wire CAN bus. Control pins STB_N and EN are used to select the operating mode. To simplify the application, the Normal mode has been selected to be set for the entire execution of the application. HIGH-level state on pin STB_N and pin EN selects Normal mode. According to the schematic, for the instance of CAN0, the corresponding pins for STB_N and EN are PTE11 and PTA10. For checking the correctness of the configuration of the settings and application, the transceiver outputs CAN_H and CAN_L are connected to CAN Analyzer, while messages are sent from the PC.           A numeric sequence with the ID 0x3FF is sent continuously while a  message received with ID 0x3FE toggles the PTD15 (Red LED) on each receive. To receive a CAN message asynchronous with the application, the CAN receive interrupt must be used. When a message is received, it triggers the subsystem Rx_0x3FE.     The fcan_s32l_receive block configuration is: Module: 0 Mode: Non-blocking Message Buffer: 14 ID: 3FF ID mask: FFFFFFFF         To send a message with the ID 0x3FF on CAN0, in the fcan_s32l_send block, the following settings are required: Module: 0 Mode: Blocking Timeout (ms): 50 Message Buffer: 15 ID: 3FF       CAN1 instance For the instance of CAN1, the steps are the same as above (the configuration of CAN0), but this time a numeric sequence with ID 0x2FF is sent continuously and a received message with ID 0x3FF will toggle the PTD16 (Green LED) on each receive. A CAN Analyzer is needed to analyze and collect data from the CAN bus and display them on the PC. To use both CAN instances on the same  CAN Analyzer, a hardware connection is needed between CAN0A and CAN1A (or any CAN0 with CAN1). This can be seen in the following diagram:     In this application, the  CAN Analyzer used is IXXAT USB-to-CAN V2 and the software interface is IXXAT canAnalyser3 Mini, but of course, any other CAN Analyzer can be used.       4. Model overview The application is structured in 3 categories as follows: Input (green area): Hardware-dependent blocks that read/receive values from peripherals Algorithm (blue area): Hardware-independent blocks that process the values received from Input blocks, runs the algorithm and controls the outputs. Output (pink area): Hardware-dependent blocks which receive the processed values from the Algorithm blocks.     After all the steps have been followed, the code can be generated, compiled, and deployed on the target. To do so, Go to Simulink -> Apps -> Embedded Coder then click on the Build button.     In the Diagnostic Viewer, the process can be analyzed if there is any error and if the download was successfully completed on the target as in the image below:       The following figure shows the setup:     Conclusion In this article we explained how to use the NXP Model-Based Design Toolbox for S32K1xx to handle the UCANS32K1SIC evaluation board. Access to all the board's peripherals was possible in Simulink by using the Model-Based Design Toolbox, an addon which connects the MATLAB and Simulink high level world with the NXP Tools and Hardware. In this application, we have shown how to control the RGB LED and read the state of the switch; how to display messages on the LCD screen and configure both instances of the CAN communication protocol for sending and receiving messages. We have also added the FreeMASTER communication to monitor or fine-tune the algorithms running on the UCANS32K1SIC board, while the model is available down below.   EdgeLock and NXP are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.
查看全文
Introduction With the latest advances in microcontrollers, they are getting faster and more efficient, being able to successfully run complex algorithms in a reasonable time. One important category are Artificial Intelligence algorithms. Using both NXP ® and MathWorks ® ecosystem, the steps to deploy an AI algorithm to NXP hardware are simplified and straight forward. The article provides guidance on how to implement a State-of-Charge (SoC) estimation algorithm based on a feedforward deep learning network developed by Mathworks' experts (Battery State of Charge Estimation in Simulink Using Deep Learning Network). The algorithm is then deployed on i.MX RT1060 Evaluation Kit using NXP Model Based Design Toolbox for I.MX RT. As the main objective of the article is to demonstrate how to run an AI algorithm on NXP evaluation board, the example is ran in Processor-in-the-Loop (PIL) simulation mode. This type of simulation represents an important step in the validation process of an algorithm, corner cases can be easily replicated as the input data can be directly loaded from MATLAB's workspace. The execution of the algorithm is done on the microcontroller. For a more detailed overview of the execution of the algorithm, code profiling options can be enabled to generate a report which details execution times.   What BMS is Battery Management System (BMS) is a critical component in battery-driven devices, such as electric vehicles. Their main objective is to ensure that the battery pack remains in an optimal and safe operating mode. At the core of the most tasks, the BMS must compute the State-of-Charge (SoC) estimation. To make a precise estimation, the algorithm requires an accurate model of the actual cells, which are difficult to characterize. An alternative to this approach is to create data driven models of the cell using AI methods such as neural networks.   Deep Learning Toolbox The Deep Learning Toolbox™ developed by Mathworks provides a framework for deep neural networks to be used in algorithms. It enables the user to use convolutional neural networks (ConvNets, CNNs) and long short-term memory (LSTM) networks to perform classification and regression on image, time-series and text data. The network and layer graphs are not mandatory to be created in MathWorks ecosystem, as other frameworks can be used, such as TensorFlow™ 2, TensorFlow-Keras, PyTorch ® .   Prerequisite Software To create, build and deploy a Simulink Model onto the i.MX RT RT1060 EVK, the following software is required: MATLAB R2022a Deep Learning Toolbox Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ®  Support Package for ARM Cortex-M Processors i.MX RT MBD Toolbox (version 1.3.0)   Prerequisite hardware The hardware required for this example is i.MX RT1060 Evaluation Kit. The i.MX RT1060 crossover MCUs are part of the EdgeVerse™ edge computing platform. The core of the MCU is a Arm ® Cortex ® -M7 core at 600 MHz. The device is fully supported by NXP’s MCUXpresso Software and Tools, a comprehensive and cohesive set of free software development tools.   Model - Overview The BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox computes the SoC estimation using two methods: first method uses a neural network and the second one uses the extended Kalman filter algorithm. By plotting data generated by these two estimations and comparing it to the true values, it is possible to validate that the FNN predicts the SoC with an accuracy of 3 within a temperature range between -10 C and 25 C.   Note! Before making any modification to the model included in the toolbox, it is recommended to create a backup of the example in order to be able to revert to the original state. For this example, the predictions are done on the i.MX RT1060 evaluation board in PIL mode while the Kalman filter is locally computed on the computer. Referenced Model From the original model, the FNN block must be added in a new blank model. As the newly created model is used in a Referenced model, an input port must be added to received data (make sure the Port dimensions is set to 5), and one output port to return the data computed. The other settings for all these 3 blocks can be left default. Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Top model Based on the BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox, the FNN block must be removed (either deleted or commented). A ModelReference subsystem must be added to the model. In the Block Parameters of the ModelReference subsystem, select the model created and configured above. Simulation Mode must be set to Processor-in-the-Loop (PIL). Another modification that must be done is the sample time of the nnInput Data Read Memory block which must be changed from 0 (continuous) to -1 (inherited).   Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Deployment and validation Now that both models (top model and referenced model) are configured, SIL/PIL manager can be opened from the APPS tab in Simulink. In the SIL/PIL tab, the simulation must be selected to SIL/PIL only (red rectangle) and the System Under Test to Model Blocks in SIL/PIL mode (blue rectangle). Before the simulation is started, the BatterySOCSimulinkEstimation_ini.m script must be executed to load the necessary data into MATLAB's workspace. The script can be found next to the Simulink Model included in the Deep Learning Toolbox. From the top model, the SOC scope can be opened to display the generated data. The simulation can be started from the RUN button within the scope. Note! Diagnostic Viewer can provide important information if there are any errors within the models. If the simulation is successfully deployed on the target, the data plotted into the scope should look like this:   Code profiling Code profiling is an important tool to validate an algorithm as it provides important information about the execution time. The time is measured by the timer configured in Model Settings -> Hardware Implementation -> Hardware board settings -> Target hardware resources -> Profiling Timers. By default, the PIT timer, channel 0, is used. The Code generation can be enabled from Model Settings -> Code Generation -> Verification -> Code execution time profiling -> Measure task execution time. The generated report can either be Coarse (referenced models and subsystems only) or Detailed (all function call sites). When the simulation is completed, a small window is opened. The Profiling report can be opened by clicking on the view the full code execution profiling report.   Conclusion The NXP and Mathworks ecosystems enable the users to deploy an Artificial Intelligence algorithm onto the NXP hardware. In the end, I strongly recommend the users interested in BMS and Artificial Intelligence to watch the Deploying a Deep Learning-Based State-Of-Charge (SOC) Estimation Algorithm to NXP S32K3 Microcontrollers webinar hosted by Javier Gazzarri (MathWorks) and Marius Andrei (NXP).   EdgeVerse and NXP are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. PyTorch, the PyTorch logo and any related marks are trademarks of The Linux Foundation. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder, Deep Learning Toolbox are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks. TensorFlow, the TensorFlow logo and any related marks are trademarks of Google Inc.
查看全文
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for BMS – version 1.0.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for BMS version 1.0.0 EAR. This release is an Add-On for the NXP Model-Based Design Toolbox for S32K3xx 1.4.0, which supports automatic code generation for battery cell controllers and applications prototyping from MATLAB/Simulink. This new product adds support for MC33775A, MC33772C, MC33665A BCCs and part of their peripherals, based on BMS SDK components (Bcc_772c, Bcc_772c_SL Bcc_775a, Bms_TPL3_SL_E2E, Bms_common, Phy_665a). In this release, we have added the integration with the Model-Based Design Toolbox for S32K3xx version 1.4.0, added support for the BMS SDK 1.0.1, and MATLAB support for the latest versions. The product comes with battery cell controller examples, targeting the NXP HVBMS Reference Design boards.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3720278   Technical Support: NXP Model-Based Design Toolbox for BMS issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP Battery Cell Controllers derivatives: MC33775A MC33772C MC33665A   Support for the following peripherals (BMS SDK components): Bcc_775a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications that perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344, the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.             BMS SDK version supported (1.0.1) Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a   Examples of the functions supported: MC33775A Configuration and data acquisition example MC33772C Configuration and data acquisition example RD-HVBMSCTBUN Configuration and data acquisition example   For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s Battery Cell Controllers together with S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for BMS version 1.0.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience: This release (1.0.0 EAR) is intended for technology demonstration, evaluation purposes, and battery management systems prototyping using NXP Battery Cell Controllers and S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      
查看全文
General Installer and Setup  External mode External mode example wouldn't compile after update  Others MPC57xx MBD Toolbox not appears in Simulink Library Browser  Peripherals Apps Motor Control BMS Request for HSD/LSD/MSDI Communication Examples for MPC5775B BMS and VCU Reference Design 
查看全文
  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.4.0 RFP   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.4.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, LIN, GPT). To enable BMS applications development, the toolbox offers support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 120 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=14146527   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL LIN CAN SPI UART GPT DIO   Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model. Moreover, the toolbox provides the option to save and export the initialization sequence to a file which can be later used for other models as well – in this way, the customization of the board initialization sequence can be done only once, even if applicable for other models as well. Such a file can be then imported as an external Board Initialization Template.   Custom Linker Files and Startup Code: The toolbox allows the selection of custom linker files and startup code to be used during the build process. By enabling the Use Custom Linker or/and Use Custom Startup Code checkboxes, this feature is activated, allowing the users to Browse for specific files.   Support for Referenced Configurations The Model-Based Design Toolbox for S32K3xx enables the usage of Referenced Configurations, a Simulink feature which allows users to share the configuration of an application with multiple models.   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (3.0.0) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.32: All functions in the Automotive Math and Motor Control Functions Library v1.1.32 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.   Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.   Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 120 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (LIN, SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached. MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.4.0 is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.4.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt          
查看全文
This page summarizes all Model-Based Design Toolbox videos related to S32K3 Product Family.  NXP MBDT - S32K3 Updates In this video, we discuss the Model-Based Design paradigm and how to take advantage of the MathWorks ecosystem to generate C code automatically for the NXP S32K3xx. We start our discussion with details about MBDT Concept, Development flow, and Advantages. Then we compare the NXP's MBDT for S32K1 vs MBDT for S32K3 where we introduce the usage of an "external configuration" tool to handle the MCU Clocks, Pins, and Components configuration particular the NXP S32 Configuration Tools and EB tresos Studio. We then explain how the new paradigm matches a "true" Model-Based Design Approach and helps the development engineers. Finally, we discuss the Toolbox for S32K3, what NXP products integrate, and what applications look like. Deploying AUTOSAR ™  and Non-AUTOSAR Software Components on NXP S32K3 with MathWorks ®  Tools Link to the recording here AUTOSAR ™  Classic is the proven standard for traditional automotive applications such as powertrain, chassis, body and interior electronics and more. More frequently, OEMs and suppliers would prefer to reuse the tested and proven legacy (non- AUTOSAR) ECU software in next-generation AUTOSAR ECUs. In this webinar, NXP and MathWorks will show how to use NXP Model-Based Design Toolbox (MBDT) together with MathWorks ®  Simulink ®  and Embedded Coder ®  to develop and deploy MCAL configured (non-AUTOSAR) applications on NXP S32K3 microcontrollers for general purpose. Furthermore, we will illustrate how to convert tested non-AUTOSAR application components to AUTOSAR and then verify and deploy MCAL configured AUTOSAR compliant production code on an S32K3 MCU. Deploying a Deep Learning-Based State-of-Charge (SoC) Estimation Algorithm to NXP S32K3 Microcontrollers Link to the recording here Battery management systems (BMS) ensure safe and efficient operation of battery packs in electric vehicles, grid power storage systems, and other battery-driven equipment. One major task of the BMS is estimating state of charge (SoC). Traditional methods for SoC estimation require accurate battery models that are difficult to characterize. An alternative to this is to create data driven models of the cell using AI methods such as neural networks. This webinar shows how to use Deep Learning Toolbox, Simulink, and Embedded Coder to generate C code for AI algorithms for battery SoC estimation and deploy them to an NXP S32K3 microcontroller. Based on previous work done by McMaster University on Deep Learning workflows for battery state estimation, we use Embedded Coder to generate optimized C code from a neural network imported from TensorFlow and run it in processor-in-the-loop mode on an NXP S32K3 microcontroller. The code generation workflow will feature the use of the NXP Model-Based Design Toolbox, which provides an integrated development environment and toolchain for configuring and generating all the necessary software to execute complex applications on NXP MCUs.  A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Link to the recording here  This webinar, co-hosted with MathWorks, shows how to design and develop Motor Control algorithms with Simulink ® , using the Embedded Coder and Model-Based Design Toolbox for S32K3xx. We will introduce the scalable S32K3 MCU family and present its specific motor control modules. We will show how to access and configure the MCU peripherals making the Simulink model hardware aware, and ready to generate, build and deploy the application on the hardware. We will focus on Field Oriented Control (FOC) algorithm and implement a sensorless control of a permanent magnet synchronous motor (PMSM). The FreeMASTER application will be used to control and monitor the algorithm running on the S32K344. NXP MBDT for S32K3 provides an integrated development environment and toolchain for configuring and generating all the necessary software to execute complex applications on NXP MCUs directly from Simulink ® .   Speed-Up BMS Application Development with NXP's High-Voltage Battery Management System Reference Design and Model-Based Design Toolbox (MBDT) Link to the recording here  This webinar shows how to design and develop Battery Management Systems, with NXP's High-Voltage BMS Reference Design and Model-Based Design Toolbox for S32K3xx, with Simulink® and Embedded Coder. During this webinar, we will introduce the ASIL D High Voltage Battery Management System Reference Resign that comprises a Battery Management Unit (BMU), Cell Monitoring Units (CMU), and a Battery Junction Box (BJB). NXP's HV-BMS Reference Design is a robust and scalable solution including hardware designs, production-ready software drivers, and safety libraries, as well as extensive ISO 26262 Functional Safety documentation. The design significantly reduces the development effort and enables an improved time to market with the latest chipset innovations. Speed Up Electrification Solutions Using NXP Tools Link to the recording here  This video provides an overview of the NXP Software and Tools solutions, designed to help customers to speed up application development with design, simulation, implementation, deployment, testing, and validation. During this session, you will learn about all the steps required to build complete solutions like battery management systems with NXP in-house solutions and NXP Model-Based Design Toolbox with simulation and code generation.
查看全文
The content of this article is identical to the AN13902: 3-Phase Sensorless PMSM Motor Control Kit with S32K344 using MBDT Blocks
查看全文
This page summarizes all Model-Based Design Toolbox videos related to HCP Product Family. Deploying Radar Applications to NXP´s S32R41 Processor Using Simulink® Link to the recording here This webinar shows how to use Radar Toolbox, Simulink ®  , and Embedded Coder ®  to generate C code for radar signal processing algorithms for range and speed estimation and deploy them to NXP ® ´s S32R41 high-performance processor for high-resolution radar. Based on MathWorks´ radar example models, we use Embedded Coder to generate optimized C code and run it in Processor-in-the-Loop (PIL) mode on the S32R41 processor. The code generation workflow will feature the use of NXP´s Model-Based Design Toolbox (MBDT), which provides an integrated development environment and toolchain for configuring and generating all the necessary software to execute complex applications on NXP MCUs and processors.
查看全文
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.3.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.3.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated S32 Configuration Tools, RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 115 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13957417   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K311 S32K312 S32K314 S32K322 S32K324 S32K341 S32K342 S32K344 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.       Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (v3.0.0 CD04) – only for S32K311, S32K358 and S32K396 New S32 Configuration Tools version supported (v1.6) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.31: All functions in the Automotive Math and Motor Control Functions Library v1.1.31 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 115 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.3.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience This release (1.3.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt                
查看全文
        Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for HCP – version 1.2.0 RFP       The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for HCP version 1.2.0. This release supports automatic code generation from MATLAB/Simulink for S32G2xx, S32S2xx, and S32R41 MPUs. This new product adds support for new MATLAB versions R2022a and R2022b for running in Processor-in-the-Loop mode.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13897177   Technical Support: NXP Model-Based Design Toolbox for HCP issues will be tracked through NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32G2xx derivatives: S32G274A Automatic C code generation from MATLAB® for NXP S32S2xx derivatives: S32S247TV Automatic C code generation from MATLAB® for NXP S32R4x derivatives: S32R41 Supported Evaluation Boards GoldBox Development Platform (S32G-VNP-RDB2 Reference Design Board) GreenBox II Development Platform X-S32R41-EVB Development Board Support for MATLAB versions: R2020a R2020b R2021a R2021b R2022a R2022b Tools update for S32R41: S32 Flash Tool v2.1 S32 Debugger v3.5 Simulation mode: We provide support for Software-in-Loop (SIL) and Processor-in-Loop (PIL) simulation mode with code execution profiling: Includes an Example library with 16 examples that cover: Software-in-Loop (SIL), Processor-in-Loop (PIL) GUI to help you setup the toolbox and the evaluation board :     For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32G2xx, S32S2xx, and S32R41  processors and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for HCP version 1.2.0 (RFP) is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.2.0 RFP) is intended for technology demonstration, evaluation purposes, and prototyping S32G2xx, S32S2xx, and S32R41 and Evaluation Boards.   Useful Resources Examples, Trainings and Support: https://community.nxp.com/community/mbdt    
查看全文