NXP Model-Based Design Tools Knowledge Base

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

NXP Model-Based Design Tools Knowledge Base

Discussions

Sort by:
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.   
View full article
    Product Release Announcement EDGE PROCESSING   NXP Model-Based Design Toolbox for i.MX RT Crossover MCUs – version 1.3.0     The Edge Processing Tools Team at NXP Semiconductors is pleased to announce the release of the Model-Based Design Toolbox for i.MX RT 1xxx Series version 1.3.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s i.MX RT 117x, 106x, 102x & 101x Series of crossover MCUs.   NXP Download Location https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   MATHWORKS Download Location https://www.mathworks.com/matlabcentral/fileexchange/81051-nxp-support-package-imxrt1xxx   Version 1.3.0 Release Content Automatic C code generation based on MCUXpresso SDK 2.11.0 drivers and MCUXpresso Configuration Tools 11.0 initializations from MATLAB®/Simulink® for: i.MX RT 1076: MIMXRT1176DVMAA,MIMXRT1176AVM8A,MIMXRT1176CVM8A i.MX RT 1075: MIMXRT1175DVMAA,MIMXRT1175AVM8A,MIMXRT1175CVM8A i.MX RT 1073: MIMXRT1173CVM8A i.MX RT 1072: MIMXRT1172DVMAA,MIMXRT1172AVM8A,MIMXRT1172CVM8A i.MX RT 1071: MIMXRT1171DVMAA,MIMXRT1171AVM8A,MIMXRT1171CVM8A i.MX RT 1061: MIMXRT1061CVJ5A,MIMXRT1061CVL5A,MIMXRT1061DVJ6A,MIMXRT1061DVL6A i.MX RT 1062: MIMXRT1062CVJ5A,MIMXRT1062CVL5A,MIMXRT1062DVJ6A,MIMXRT1062DVL6A i.MX RT 1064: MIMXRT1064CVJ5A,MIMXRT1064CVL5A,MIMXRT1064DVJ6A,MIMXRT1064DVL6A i.MX RT 1011: MIMXRT1011CAE4A,MIMXRT1011DAE5A i.MX RT 1024: EVKMIMXRT1024     Multiple options for configuration of MCU packages, Build Toolchain and embedded Target Connections are available via Simulink Model Configuration UI       Multiple MCU peripherals and Drivers are supported. The following subsystems highlighted in red as supported in Simulink environments in various forms: blocks, files, options                           i.MX RT 117x derivatives     i.MX RT 106x derivatives i.MX RT 101x derivatives     Basic and Advanced Simulink Block configuration modes via MCUXpresso Configuration Tools 11.0 UIs for Pins, Clocks, and Peripherals       MATLAB/Simulink versions 2019a – 2021b are supported for Design, Simulation, Code Generation, and Deployment of applications on i.MX RT 117x,106x, 102x & 101x Series. Other i.MX RT devices will be supported in future versions of the toolbox. Support for Software-in-Loop (SiL), Processor-in-Loop (PiL), and External Mode (classic serial, XCP Over Serial, and XCP over Ethernet). RTCESL – Real-Time Control Embedded Software Motor Control and Power Conversion Libraries (limited support designed for Motor Control applications). A future update will enhance the number of functionalities supported by Simulink.     Simulink Example library with more than 200 models to showcase various functionalities:   Integrated PMSM Motor Control Sensor/Sensor-less application for both IMXRT1060-EVK and IMXRT1170-EVK:     Target Applications with MATLAB/Simulink This release of the Model-Based Design Toolbox can be used to design, build, and test applications from multiple domains: INDUSTRIAL AC Meters Motion Control Robotics HMI SMART CITY/HOME Video Surveillance Identification Appliances Speakers   AUTOMOTIVE HVAC ECU     Target Audience This release is intended for technology demonstration, evaluation purposes, and prototyping for i.MX RT 1xxx MCUs and their corresponding Evaluation Boards: EVK-MIMXRT1170 EVK-MIMXRT1060 EVK-MIMXRT1064 EVK-MIMXRT1010 EVK-MIMXRT1024       Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt Technical by System Tools: https://web.microsoftstream.com/channel/618ab630-c8da-4fa8-ade8-5aa70a353124      
View full article
Model-Based Design Toolbox supporting i.MX RT Crossover MCU. System modeling, simulations, automatic code generation, validation, and verification MATLAB & Simulink workflows are now available on the i.MX RT microcontroller by reusing MCUXpresso ecosystem: MCUXpresso SDK MCUXpresso Configuration Tool MCUXpresso IDE,GCC
View full article
In this video we discuss about how the motor phase commutation works. This is an essential topic to understand how the motor rotates based on 6-step commutation technique.   We discuss about: - How to build the commutation table based on hall pattern identification  - How to control the PWM sequence to implement a 6-step/trapezoidal commutation NOTE: Chinese viewers can watch the video on YOUKU using this link 注意:中国观众可以使用此链接观看YOUKU上的视频
View full article
      Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for HCP – 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 HCP version 1.0.0. This release supports automatic code generation from MATLAB/Simulink for S32G2xx and S32G2xx Automotive MPUs. This new product adds support for running Processor-in-Loop simulation on S32G274A (ARM Cortex-A53) and S32S247TV (ARM Cortex-R52).   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/product?child_plneID=683951   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 Supported Evaluation Boards GoldBox Development Platform (S32G-VNP-RDB2 Reference Design Board) GreenBox II Development Platform Support for MATLAB versions: R2020a R2020b R2021a Simulation mode: We provide support for Processor-in-Loop (PIL) simulation mode with code execution profiling:   Includes the HEV demo:     Includes an Example library that covers: Software-in-Loop, Processor-in-Loop   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 and S32S2xx  processors and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for HCP version 1.0.0 (EAR) 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 prototyping S32G2xx and S32S2xx and Evaluation Boards.   Useful Resources Examples, Trainings and Support: https://community.nxp.com/community/mbdt  
View full article
This video explains the steps required to build a control system based on Field Oriented Control theory. Step by step it is shown how the Park and Clarke Transformations works, how the values on stationary vs. rotating frames look like and what does it takes to build  a digital control system around FOC concepts with S32K144 Evaluation Board
View full article
    Product Release Announcement EDGE PROCESSING NXP Model-Based Design Toolbox for DSC MC56F8x MCUs - version 1.0.0 Bucharest, Romania  December 15th , 2021   The Edge Processing Tools Team at NXP Semiconductors is pleased to announce the release of the Model-Based Design Toolbox for DSC MC56F8x Series version 1.0.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s DSC MC56F81xxx and MC56F83xxx Series of MCUs based on DSP568000E core. NXP Download Location https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX MATHWORKS Download Location https://www.mathworks.com/matlabcentral/fileexchange/103600-nxp-support-package-dsc  Version 1.0.0 Release Content Automatic C code generation based on MCUXpresso SDK 2.7.3 drivers and MCUXpresso Configuration Tools 10.0 initializations from MATLAB®/Simulink® for:   MC56F81xxx        MC56F81868VLH, MC56F81646VLF, MC56F81648VLH, MC56F81663VLC,      MC56F81666VLF, MC56F81668VLH, MC56F81743VLC, MC56F81746VLF,      MC56F81748VLH, MC56F81763VLC, MC56F81766VLF, MC56F81768VLH,             MC56F81866VLF, MC56F81643VLC                                     MC56F83xxx     MC56F83789VLL, MC56F83683VLH, MC56F83686VLL, MC56F83689VLL,     MC56F83763VLH, MC56F83766VLK, MC56F83769VLL, MC56F83783VLH,     MC56F83786VLK, MC56F83663VLH   Multiple options for configuration of MCU packages, Build Toolchain and embedded Target Connections are available via Simulink Model Configuration UI     Multiple MCU peripherals and Drivers supported. The following subsystems highlighted in red as supported in Simulink environments in various forms: blocks, files, options MC56F81xxx derivatives MC56F83xxx derivatives   Basic and Advanced Simulink Block configuration modes via MCUXpresso Configuration Tools 10.0 UIs for Pins, Clocks, and Peripherals   MATLAB/Simulink versions 2020a – 2021b are supported for Design, Simulation, Code Generation, and Deployment of applications on MC56F81xxx and MC56F83xxx Series. Other MC56F8x devices will be supported in future versions of the toolbox. Support for Software-in-Loop (SiL), Processor-in-Loop (PiL); RTCESL – Real-Time Control Embedded Software Motor Control and Power Conversion Libraries for DSP568000E core.     Simulink Example library with more than 100 models to showcase various functionalities:   Integrated PMSM Motor Control Sensor/Sensor-less application for MC56F83000-EVK: Integrated application that uses the on board FXOS8700CQ accelerometer and magnetometer sensor for both MC56F81000-EVK and MC56F83000-EVK.    Target Applications with MATLAB/Simulink This release of the Model-Based Design Toolbox can be used to design, build, and test applications from multiple domains: INDUSTRIAL AC Meters Motion Control Robotics HMI       Target Audience This release is intended for technology demonstration, evaluation purposes, and prototyping for DSC MC56F8x MCUs and their corresponding Evaluation Boards: EVK-MC56F81000 EVK-MC56F83000 Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt    
View full article
      Product Release Announcement Automotive Processing   NXP Model-Based Design Toolbox   for S12ZVMx – version 1.4.0     Austin, Texas, USA September 9, 2020 The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S12ZVMx version 1.4.0. This release supports automatic code generation for S12ZVM peripherals and applications prototyping from MATLAB/Simulink for NXP S12ZVMx Automotive Microprocessors. This new release adds extended MATLAB version support (R2015a-R2020a), integrates with AMMCLib v1.1.21, is compatible with MathWorks Automotive Advisory Board checks, adds over 50 new examples and more.   FlexNet Location: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Activation link: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Technical Support: NXP Model-Based Design Toolbox for S12ZVMx issues are 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 S12ZVMx derivatives: S12ZVM 32/L31/16: MC9S12ZVM16 MC9S12ZVML31 MC9S12ZVM32 S12ZVML/C 128/64/32: MC9S12ZVML32 MC9S12ZVML64 MC9S12ZVMC64 MC9S12ZVML128 MC9S12ZVMC128 S12ZVMC256: MC9S12ZVMC256   Integrates the Automotive Math and Motor Control Library release 1.1.21: All functions in the Automotive Math and Motor Control Functions Library v1.1.21 are supported as blocks for simulation and embedded target code generation for: Bit Accurate Model for 16-bit fixed-point implementation Bit Accurate Model for 32-bit fixed-point implementation Bit Accurate Model for floating-point single precision implementation             Extended support for MATLAB versions We extended support for our toolbox to cover a wider range of MATLAB releases – starting from R2015a and going up to R2020a. This way we want to avoid locking out users that have constraints regarding MATLAB versions. Motor control examples We have added new motor control examples – BLDC (closed loop) and PMSM (closed loop, sensorless):   MAAB Checks (MathWorks Automotive Advisory Board) The toolbox is compatible with MathWorks Automotive Advisory Board checks – reports can be generated from Model Advisor:   Updated examples: We have added over 50 new examples, including: Motor control (both BLDC and PMSM) AMMCLib GDU (Gate Drive Unit) Profiler 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 S12ZVMx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for S12ZVMx  Online Installer Guide Add-on allows users to install NXP solution directly from the Mathwork’s website or directly from MATLAB IDE. The Support Package provide a step-by-step guide for installation and verification. NXP Model-Based Design Toolbox for S12ZVM 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 S12ZVMx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings and Support: https://community.nxp.com/community/mbdt                                                    
View full article
This video demonstrates how to: SPI Master configuration SPI Slave configuration Ping-Pong data message Data visualization via FreeMASTER
View full article
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for HCP – version 1.3.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.3.0. This release supports automatic code generation from MATLAB/Simulink for S32G2xx, S32R41x, and S32S2xx MCUs. This new product adds support S32R41 Cut 1.1 and S32G3, C++ code generation for S32G2 and S32G3,  Radar examples for S32R41, and support for MATLAB versions R2021a - R2023b for running in Software-in-the-Loop and Processor-in-the-Loop modes.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3742498   Technical Support: NXP Model-Based Design Toolbox for HCP 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 S32G2xx derivatives: S32G274A Automatic C code generation from MATLAB® for NXP S32G3xx derivatives: S32G399A Automatic C code generation from MATLAB® for NXP S32R4x derivatives: S32R41 (including Cut 1.1) Automatic C code generation from MATLAB® for NXP S32S2xx derivatives: S32S247TV Supported Evaluation Boards GoldBox 2 Development Platform (S32G-VNP-RDB2 Reference Design Board) GoldBox 3 Development Platform (S32G-VNP-RDB3 Reference Design Board) X-S32R41-EVB Development Board GreenBox 2 Development Platform Support for MATLAB® versions: R2021a R2021b R2022a R2022b R2023a R2023b S32G2 and S32G3 support: SIL and PIL simulation modes with code execution profiling. C++ code generation. S32R41 support: SIL and PIL simulation modes. Code execution profiling using PMU cycle counter. Tools updates: S32 Flash Tool v2.1.4, S32 Debugger v3.5 Includes an Example library with 20+ examples that cover: Software-in-Loop (SIL), Processor-in-Loop (PIL) MathWorks Automotive Adaptive Cruise Control Using FMCW and MFSK Technology examples ported to S32R41: MSFK Radar Range and Speed Estimation of Multiple Targets FMCW Radar Multiple Targets Range and Speed Estimation       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, S32G3xx, S32S2xx, and S32R41 MCUs and evaluation board solutions out-of-the-box with: Model-Based Design Toolbox for S32M2xx version 1.3.0 is fully integrated with MATLAB® environment in terms of installation:     Target Audience This release (1.3.0 RFP) is intended for technology demonstration, evaluation purposes and prototyping of S32G2xx, S32G3xx, S32R41, and S32S2xx MCUs and Evaluation Boards..   Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt      
View full article
1.      Introduction The article presents a basic application in Simulink® for the MR-BMS771 that can be used as a starting point for a Battery Management System application. The configuration provided covers most of the peripherals available on the MR-BMS771 reference design. 1.1. Board Overview             The MR-BMS771 is a standalone Battery Management System reference design, suitable for mobile robotics projects (drones, rovers) which require from 8 up to 14 cells. These cells can be LiPo cells, but other chemistries, like LiFePO4, work as well. The main components are: MCU: S32K146 (S32K1 Microcontroller for Automotive General Purpose) Battery Cell Controller: MC33771C (14 Channel Li-Ion Battery Cell Controller IC) System Ba Chip: UJA1169A (Mini High-Speed CAN System Basis Chip) SIC Transceiver: TJA1463 (CAN Signal Improvement Capability Transceiver) 1.2. Board pinout (High quality images can be found in the 'MRBMS771_PINOUT.zip' achieve at the bottom of this article)             1.3. Prerequisite software MATLAB® R2016A Simulink® MATLAB® Coder™ Simulink® Coder™ Embedded Coder® Support Package for ARM® Cortex®-M Processors S32K1xx MBDT Toolbox Version 4.3.0 FreeMASTER Run-Time Debugging Tool   1.4. Prerequisite hardware MR-BMS771 CAN Bus Terminator Resistors (DRONE-CAN_TERM) OLED Display 128x32 pixels External Thermistor with cable Serial to USB converter CAN interface for USB 14-cell Battery Emulator 12V DC Power Supply Multilink Debug Probe   1.5. Hardware connections Connect the followings: OLED display to J23 CAN Terminator to J28 CAN interface for USB to J3 Serial to USB converter to J19[2] and J19[3] J27 to J20 (connect both CAN instances to the same bus) Debug probe to J2   2. Model configuration 2.1. Initialize the model             The first step that must be done when creating an application using the S32K1xx toolbox is to create a blank Simulink model and add the MBD_S32K1xx_Config_Information block. To add a block from S32K1xx toolbox to a model, open the Library Browser and search for NXP Model-Based Design Toolbox for S32K1xx MCUs, then select the desired block and drag and drop it into the canvas of the Simulink model previously created. The configuration block must be configured for the MR-BMS771: select the Target MCU->Family to S32K146 and CLOCK->XTAL Frequency MHZ to External 32. Depending on the deploying method used, settings must be modified in Target Connection. In this example, the download on the target is done via JTAG using the USB Multilink PEMicro.   2.2. System Basis Chip – UJA1169ATK             The System Basis Chip (SBC) is an external component that integrates a CAN transceiver and various functions, such as an external watchdog, a serial peripheral interface or LIMP output. In the MR-BMS771 design, the UJA1169ATK is used to provide a High-Speed CAN transceiver and a configurable watchdog.             Out of the box, the SBC is running in Forced Normal Mode, which means that the watchdog is disabled, but the CAN transceiver is operation. The SBC is initialized and configured via Low Power Serial Peripheral Interface 0 (LPSPI0).             Important! If the SBC is running in Normal Mode, the MCU must reset the watchdog, otherwise, the SBC triggers a hardware reset. Therefore, if the user wants to debug the application in S32Design Studio for ARM, the SBC must be either running in Forced Normal mode or in Software Development mode.             Note! To enable the Software Development Mode, the SBC must be running in Forced Normal Mode. Consult UJA1169A datasheet (7.12.2 Restoring factory preset values) for further details about restoring factory preset values.             Since the SBC is configured by the MCU via the LPSPI, the LPSPI0 must be initialized before the SBC config block. Drag and drop a LPSPI_Config block in the model and configure it as below:             Since the UJA1169 is an external IC, the configuration block can be found in External Devices:   2.3. Signal Improvement Capability Transceiver – TJA1463             Signal Improvement Capability (SIC) transceiver is an external component that allows the MCU to send/receive via high-speed classical CAN and CAN-FD. To put the transceiver in Normal mode, the following conditions must be met: Enable pin (PTA6) must be set to high Standby pin (PTB12) must be set to high (Note! Standby pin is active low)   2.4. FlexCAN             The Controller Area Network (CAN) is a standard communication protocol used in automotive world. Multiple devices can join the same CAN bus and transmit data to each other using only two differential signals: CAN high and CAN low. It is mandatory to use termination resistors to passively pull the state of the signals to a recessive state.             The configuration block for FlexCAN can be found in S32K1xx Core, System, Peripherals and Utilities -> Communication Blocks -> CAN Blocks.               In this example, both CAN interfaces are using to the same CAN bus, by the cable that connects the J27 to J20. Since the CAN interfaces are relatively close to each other and connected to the same CAN bus, only one pair of termination resistors are required.            The FCAN instance 0 is connected to the UJA1169 SBC via RX:PTE4 and TX:PTE5. The configured bitrate is 500Kbit/s.               The FCAN instance 1 is connected to the TJA1463 via RX:PTA12 and TX:PTA13. The configured bitrate must be similar to the CAN0’s bitrate (500Kbit/s).   2.5. Gate Driver             The gate driver is an interface between microcontroller and high-power components. It is controlled by a D-type flip flop, and it allows the MCU to disconnect the electrical loads attached to Power OUT pads from the power supply (Power IN pads).             To toggle the gate driver, a precise sequence must be followed. The Data Input pin of the D-type flip flop (U10) is active low and must be set to the desired state of the gate driver (set to low to enable the gate driver, respectively to high to disable it). The CLK pin of the flip flop is a rising edge triggered clock signal input pin. In order to propagate the state of the data input pin, the CLK must be set to low, then high and finally low again.             Note! To assure that this sequence is kept in order, it is recommended to manually set the priorities of each GPIO write block. To set the priority of a block, right click on the block then select ‘Properties’. The lower the number written in ‘Priority’ field represents the higher the priority of the block when the code is being generated.   2.6. SSD1306 OLED             The OLED display used in this example is a 128 x 32 pixels display. The data is sent from the MCU via the LPI2C0 (J23). This means that before adding the LCD_Config block, the configuration block for LPI2C0 must be added to the model.  It can be found in S32K1xx Core, System and Peripherals and Utilities -> Communication Blocks -> I2C blocks.   This type of display is supported by the S32K1xx toolbox. The configuration block can be found in External Devices (in Library Browser).             To configure the display, select he LPI2C instance 0 and SSD1306 address to 60 (represented in decimal format, hex: 0x3C). It might be possible that the address of your display might differ.   Note! MCU configures the OLED via the I2C. Therefore, the LPI2C0 must be initialized before the OLED Config block. Note! It is possible that height of the display might not be properly set. If the text on the screen doesn’t appear correctly, try to set the height to 64 pixels.   2.7. Battery Cell Controller (BCC) – MC33771C             The battery Cell Controller MC33661C is a Li-Ion battery cell controller IC designed for automotive and industrial applications. It supports both standard SPI and transformer isolated daisy chain communication (TPL). In the MR-BMS771 reference design, the SPI interface is used to communicate with the BCC.             Like the UJA1169 SBC, the first step is to add an LPSPI_Config block to the model. The only thing to configure now is to set the interface to LPSPI1 and make sure the correct pins are selected. The baud rate, role and other advanced settings are going to be configured later, directly from the BCC block.               The MC33771C is an external component, and the configuration block can be found in External Devices -> Battery Management System -> BMS_3377xC.   The following settings must be configured in MC3377xC_Config block: Configuration tab: General Settings: Instance: 0 Mode: SPI SPI Mode: Device: MC33771C Cell number: 14 SPI tab: SPI instance: 1 SPI CS Selection: LPSPI1_PCS0 Pack settings tab: Shunt resistance: 500 uOhm (shunt resistor R1 is mounted on the MR-BMS771) Note! In the Configuration tab, the Instance dropdown refers to the BCC instance and not to the SPI instance used to communicate with the BCC. After the MC3377xC_Config block is properly configured (especially after the SPI instance is selected), you need to click on the Config SPI for BCC as Master button from the SPI tab (highlighted by the orange rectangle in the image above). This way, the LPSPI1 is automatically configured to allow the MCU to properly communicate with the BCC.   Note! MCU configures the BCC via the SPI. Therefore, the LPSPI1 must be initialized before the MC33771C_Config block.   2.8. FreeMASTER             FreeMASTER is an user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of the embedded software applications. The connection between MCU and FreeMASTER application can be done via the following interfaces: UART CAN Debugger Probe/On-board debugger interface In this example, the LPUART1 interface is used to exchange data with the FreeMASTER application. LPUART1 interface is accessible via the J19 connector. The FreeMaster_Config block can be found in Utility Blocks category.               In the FreeMaster_Config block, the LPUART1 instance must be selected. The RX pin is PTC6 and TX pin is PTC7.   Note! In case the right cable is not available to be connected to the J19, the FreeMASTER can be used over the debug probe. In this case, the FreeMASTER config block is not required.   3. Structure of the application             The recommended workflow when developing an application using S32K1xx toolbox is to divide the application in 3 main parts: Inputs Algorithm Outputs The Inputs and Outputs parts are hardware depended (should include mostly S32K1xx blocks) and ideally, should only handle the peripherals connected to the MCU (e.g., read data from sensors/ICs, toggle LEDs, show data on a display etc.). On the other hand, for a better reusability, the Algorithm should be kept hardware independent, it shouldn’t include any S32K1xx blocks. This part receives data from the Input part, does its computations, and then send the results to the Output part to take the corresponding actions. The main advantage of this approach is that the Algorithm can be validated in simulation scenarios, such as Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL). Edge cases can be consistently reproduced in simulation environments, without risking to damage the actual hardware. For example, when working with Li-Ion cells, overtemperature or overvoltage real-world scenarios can damage the cells and might even start a fire. Another advantage of keeping the Algorithm hardware independent is that it can use algorithms developed by other experts in MATLAB ecosystem, drastically reducing the prototyping time. Moreover, in case the application must be ported to another NXP hardware platform, only the Input and Output must be updated with the new blocks, but the already validated Algorithm part can be moved to the new model without any modifications. Taking all these suggestion into consideration, the application looks like this: Input MC3377xC_Get_Values block reads data from MC33771C Battery Cell Controller and stores it in multiple variables MC3377xC_Fault_Get_Status block reads the error codes from the BCC, in case any fault is detected Algorithm Increment a variable and generate the message (subsystem GenerateFCANMessage) that needs to be sent via both FCAN interface Generic_Algorithm is a dummy subsystem and formats the PackVoltage and PackCurrent to be properly displayed on the OLED display toggleLED variable is negated at every step execution to toggle the onboard LED_GREEN Output UJA1169_Reset_Watchdog resets the SBC’s watchdog to avoid the forced restart of the MCU FCAN0_Send_ID_0x3FE and FCAN1_Send_ID_0x3FE blocks send messages over the CAN interfaces. Messages with ID 0x3FE are sent over FCAN0 (UJA1169), whereas messages with ID 0x3FF are sent over FCAN1 (TJA1463) LCD_Display_Current block displays the PackCurrent value on the first line of the OLED display LCD_Display_Voltage block displays the PackVoltage value on the second line of the OLED display Toggle_Green_LED block toggles the onboard green LED   4. Deployment             The application is now complete. The next step is to deploy it onto the target, MR-BMS771. To generate the code and download the generated files on the target, the Embedded Coder needs to be open, then the Build button should be clicked.               Right after the build process is started, the View diagnostic button becomes available, and it is a good practice to always have it open. It displays valuable information about the build process, such as various warnings or errors. Note! The debug probe drivers are not bundled in the S32K1xx toolbox. Please visit the debug probe manufacturer to download and install the required drivers.             If the build process is successfully completed, the .mot and .elf files should be generated in the _rtw folder (automatically created next to the model). In the Diagnostic Viewer, the sizes for each section of the .elf file are displayed in Berkeley format. Now, all the required files are generated and compiled. Depending on the settings from the MBD_S32K1xx_Config_Information block (Target Connection -> Mode -> Download code after build), the download process can be triggered. In the figure below is an example of a Diagnostic Viewer log of a complete deploy procedure (files generation, compilation and download).                 Note! It is important that the SBC watchdog is not enabled, otherwise the MCU is restarted during the download procedure.   5. Validation             Once the application is deployed onto the target, FreeMASTER project can be opened (.pmpx file) to set up the communication protocol and to select the file (.elf) that contains all the information about the variables present in the model.             The communication interface used in this example is a USB-to-Serial convertor (step 3 in the image below). If the UART port used by the MR-BMS771 is not known, all ports can be checked and scanned (step 5). If a target is detected, a dialog appears to confirm the port and baud rate used.       Note! If an USB-to-Serial converter is not available, a debug probe can be used as a communication interface. At step 3, select the third option: Connect Through a debugger probe or on-board debugger interface. The next steps depend on the type of the debugger probe. The next step is to verify that the .elf file used to read variables’ addresses has the correct path. Open the project’s Options and under the MAP Files tab, the path to the .elf file is shown.   Note! The .elf file is always generated in the _rtw folder created next to the model.   Finally, the data should be visible in the Variable Watch (as raw data) or in the Cell Voltages oscilloscope view.   Note! In order to access the variables in FreeMASTER application, they must be declared as volatile.             To read the messages sent on the CAN bus by both CAN interfaces, a CAN to USB converter is required. Message are sent in pair at each execution step. Messages with the ID 3FE are sent by CAN0 interface, while messages with ID 3FF are sent by CAN1 interface. The fifth byte of the message is incremented at each step.   5. Conclusion             This article presents an overview of the workflow when using the NXP Model Based Design Toolbox for S32K1xx. It enables most of peripherals available on a custom hardware design (MR-BMS771) and guides the user from the model creation up to application deployment and validation.               NXP is a trademark 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.                      
View full article
1. Introduction The scope of this article is to show how easy it is to use MBDT, FreeMASTER and some knowledge in electronics to create a simple and useful project: monitor USB voltage and current consumption.  I used this setup it to monitor USB voltage and current while my smartphone is charging, but it can be used in other purposes too, like monitoring power consumption of some devices connected on USB charger/power bank/PC, or it can be used to find some charging issues, or maybe you just want to find out if your phone charger supports fast charging, or to characterize a power bank.  2. Overview 2.1 Functional Description This project can measure USB voltage and current by measuring USB voltage and a voltage drop across a resistor through which current flows from a USB power source to a USB load. The voltage given by current flow is amplified by an electronic circuit and sampled by MPC5744P-DEVKIT board through the ADC converter, then data is sent to PC and then are displayed through a FreeMASTER project as numerical values and as oscilloscope chart. The MPC5744P-DEVKIT board is programmed by MBDT. To build this simple project, you need three components: Matlab with MBDT toolbox installed, FreeMASTER Run-Time Debugging Tool, a very simple electronic circuit, and an MPC5744P-DEVKIT.  As can be seen in fig.1, the project can be split into two main parts: Hardware Setup and Software Setup. Fig. 1: USB Voltage And Current Monitor block diagram 2.1 Hardware Setup Custom Electronic Board The simplest way to measure current is to use a simple resistor connected in series with the load (USB output in our case). The Ohm law gives us a linear relationship between voltage and current in an electrical circuit: U = R * I  U is the voltage (measured in volts V) drop across the resistor, R is the resistance of the resistor (measured in ohm Ω) and I is the current (measured in amps A) which we need to measure. Most of the USB chargers can supply a maximum of 3A and most of the smartphones can drain less than 3A. Giving that I considered designing this circuit to measure around maximum 3A. Let suppose that we use a simple 1ohm resistor. If we do simple math using Ohm formula, then it can be seen that for 3A the voltage across our resistor (there) will be 3V (U = 1 * 3). Fig. 2: USB connectors and current "sensor" In Fig. 2 on the left side is a USB input connector, on the right side is the output USB connector and both GND lines are connected through R1 current sensor. The current "I" will flow, as can be seen in Fig. 2, from USB input through VBUS  line to VBUS on USB output, than will flow through our load connected to USB output and then through GND on the same connector thru R1 and at least to GND on USB input connector. This current will create a voltage across R1 (UR1) equal with 3V (if we use 3 amps current and 1-ohm resistor). One of USB standard charging it specifies that the lowest (standard) voltage it's 5V. In our case, using this 1 ohm resistor will cause 3V loss, then the voltage at USB outputs will be 2V (unacceptable). In most of the digital electronic circuits, when it's used 5 volts power, the voltage tolerance it's about 10% (0.5V) which means the voltage can be between 4.5V and 5.5V. Let's try to create a maximum voltage drop across this resistor about 3 times lower than the 0.5V, e.g.: 150mV. Then the current sensor resistor is R1 = 0.15V / 3A = 0.05ohm.  To measure this drop voltage we could use any ADC channel on MPC5744P-DEVKIT, but if the voltage reference of ADC is set to 5V, the resolution of ADC is 5V/4096 = 1.22mV, which means the equivalent ADC resolution corresponding to current measurement is about 24mA (1.22mV correspond to 24mA). If we consider electrical noise on USB connectors, it's very possible that the out signal will be "drowned" in electrical noise or the results will be not very satisfactory.  The solution to that problem is to "rescale" this 0V --> 0.15V range to 0V --> 5V. We can do that by using operational amplifier circuits.  I used what I found on the moment in my electronic components, an LM358 IC.  This IC is not the best, but for the demo, it's ok to be used.       Fig. 3: USB current and voltage monitor A few ideas of this electronic design:  this IC contains two operational amplifiers,  first amplifier coefficient is set thru R5 and R4 (34 amplification coefficient) and the signal is connected on his noninverting input, the lowest current that can be measured is approx. 0.7mA, the second amplifier is set as a buffer amplifier, note: if the maximum current used by the load is maximum 3A, the Zenner diode it's not necessary. By using this amplifier, the range is rescaled to 0 --> 5.1V.  To measure the voltage at USB input we use R9 and R10 divider resistor and will use the formula U_R9 = U_USB * ( R9/(R9 + R10)). And by using for R9 10K and for R10 33K  the voltage measured by ADC for maximum USB standard charging is U_R9 = 20V * (10/(43)) = 4.65V. This circuit has been developed on prototyping PCB. The outputs of this circuit are connected to two ADC (current signal to PTB13 and voltage signal to PTB14) channels of MPC5744P-DEVKIT and those can be found on CN1 connector ("USB voltage", "USB current" and GND). MPC5744P-DEVKIT Evaluation Board The main scope of this devkit is to get current and voltage data from the custom board and to convert it to digital data and send it to the PC through the UART interface.  As can be seen in fig. 4, I used three wires to connect the custom electronic board to the devkit (two ADC and GND).  On MPC5744P-DEVKIT the ADC voltage reference must be set to 5V (jumper J19 --> 2-3) and the data will be sent to PC through UART (USB --> OpenSDA). The MPC5744P-DEVKIT must be connected to PC thru USB cable. All other jumpers can be let in the default state. Fig. 4: Hardware setup (load is a USB led light) 2.1 Software Setup MBDT Application Model            For software development, I used Matlab with the MBDT toolbox. The first step is to create a new Simulink project using MBDT. The project contains three main parts: configuration blocks variable declaration blocks main loop, where the values are taken from the output of ADC block, and after using some simple maths functions, resulted in values are stored in current and voltage variables. After getting the values from ADC blocks, we must apply some math functions to reverse the effect created in the electronic circuit. Part of the configuration blocks contain: MPC5744P configuration block, ADC configuration block, which has two channels are configured, FreeMASTER block used to observe the current, voltage, and other parameters over UART through the FreeMASTER protocol. Part of the variables declaration is used to declare all variables used to get values from ADC peripheric, intermediate values, and final values.  Part of the main loop consists of simple mathematical functions that have the role to convert ADC values to current and voltage values. The first thing executed is taking the ADC current and voltage values, then those values are converted to floating-point type the multiplied with a constant (ADC_Vref /ADC_resolution = 5/4095) which represent ADC voltage resolution. Then, for USB current value, the result must be divided with operational amplifier factor (34), after that, we could subtract from the result that operational amplifier input offset (if it is measured any relevant value) and the last thing to do to get the USB current is to convert from voltage to current using ohm law (U = R * I).  To get the USB voltage, the first step is similar to the USB current value, using the resistor divider formula we get the final value. For using different opamp IC, if the non-inverting input is too high, it is recommended to be measured while the electric circuit is on and the value to be updated in the model (variable Current_offset).  Fig. 5: MBDT Application Model FreeMASTER project To view data in real-time, the first thing is to open the FreeMASTER project and, select "Tools", then "Connection Wizard ...", then hit "Next" button, select the first option "Use the direct connection to an on-board USB port", then select the serial com port assigned to MPC5744P-DEVKIT and 115200 baud rate. The USB current and voltage can be observed In the FreeMASTER project as a numerical value and as an oscilloscope view by selecting "RAW data" to plot raw ADC USB current and voltage values. To plot the real USB current and voltage values, in the Project Tree, please select "Voltage and current" oscilloscope. Fig. 6: FreeMASTER USB current and voltage monitor In Fig. 6 it can be seen current and voltage variations in time for fast charging transitions when my smartphone is connected to the original charger.
View full article
    Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for S32Z/E – version 1.3.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 S32Z/E version 1.3.0. This release supports automatic code generation for ARM Cortex-R52 and DSP/ML processor cores from MATLAB and Simulink for NXP S32Z/E Automotive Real-Time Processors. This new release supports S32Z/E2 families and its cores (Real-Time ARM Cortex-R52 cores and DSP/ML processor). It also supports Multicore, 41 Operators highly optimized for DSP/ML processor, Processor-in-Loop Simulation mode, RTD components (ADC, PWM, DIO, CAN, UART, GPT), FreeMASTER, AMMCLib, and execution profiling. The product comes with 120 examples, covering all DSP/ML processor Operators and demonstrating the usage of the peripherals (e.g.: I/O control, timers and scheduling, communication) and multicore concurrent execution.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=6450481   Technical Support: NXP Model-Based Design Toolbox for RADAR 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 S32Z2/E2 packages, including rev. B0 S32E2xx-bga975 S32Z2xx-bga594 S32Z2xx-bga400 Automatic C code generation from MATLAB® for NXP S32Z2/E2 cores ARM Cortex-R52 Cluster 0 and Cluster 1 cores DSP/ML processor Multicore support using Concurrent Execution from Simulink Homogeneous multicore execution between ARM Cortex-R52 Cluster 0 and Cluster 1 cores using IPCF Heterogenous multicore execution between ARM Cortex-R52 Cluster 0 Core 0 and SPF2 core using OpenAMP MCAL components supported (based on RTD version 2.0.0) ADC PWM DIO CAN UART GPT Software-in-the-Loop and Processor-in-the-Loop (SIL/PIL) simulation modes MATLAB scripts   Simulink models Includes MATLAB API and Simulink Library blocks for the 41 Operators highly optimized for DSP/ML processor Includes AMMCLib (v1.1.38) blocks and examples FreeMASTER support and examples Support for MATLAB versions: R2022a R2022b R2023a R2023b R2024a 120 examples: 41 Operators for DSP/ML processor Multicore I/O control Timers and scheduling Communication (CAN) SiL, PiL FreeMASTER   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 ARM Cortex-R52 cores and DSP/ML processor from NXP’s S32Z/E Realt-Time Processors and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32Z/E version 1.3.0 is fully integrated within MATLAB® environment.   Target Audience: This release (1.3.0) is intended for technology demonstration, evaluation purposes, and prototyping on NXP S32Z/E Real-Time Processors and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      
View full article
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for RADAR – version 1.0.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 RADAR version 1.0.0. This release supports automatic code generation for ARM Cortex-A53, NXP SPT Accelerator and NXP LAX Accelerator cores from MATLAB for NXP S32R45 Automotive Microprocessors. This release adds support for code generation and execution on both LAX cores,  OpenMP code generation for parallel execution of for loops, and Processor-in-the-Loop (PIL) simulation, improves the code generation and Radar processing demo, and adds support for new exponential, logarithmic, min, max, and thresholding LAX kernels. The product comes with 60+ examples, covering the supported RSDK SPT and LAX Kernels from 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=6450491   Technical Support: NXP Model-Based Design Toolbox for RADAR 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 Code generation and execution on both LAX cores Support for execution of RSDK SPT kernels: rangeFFT, dopplerFFT, NonCohComb 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 exp, log, log2, log10, min, max, thresbit cospi, sinpi, tanpi, cispi, sincpi acospi, asinpi, atanpi, atan2pi Processor-in-the-Loop (PIL) simulation mode Improved code generation and reduced memory usage Support for Radar SDK version 1.2.0 Support for MATLAB versions: R2023a R2023b R2024a R2024b More than 60 examples showcasing the supported functionalities: Cholesky Gauss-Newton Eigen (new) Kalman Filter Linear Regression Large Matrix Multiplication Navier-Stokes QR Factorization (updated) MUSIC DoA (updated) Radar processing demo – Automated Driving Toolbox scenario (updated) Standalone and Processor-in-the-Loop (PIL) simulation Range FFT, Doppler FFT, and Non-Coherent Combining offloaded to NXP SPT accelerator MUSIC DoA offloaded to NXP LAX accelerator     Radar processing demo – RoadRunner Toolbox scenario (new) Processor-in-the-Loop (PIL) simulation     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 ARM Cortex-R52 core, NXP SPT Accelerator, and NXP LAX Accelerator from NXP’s S32R45 processor and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for RADAR version 1.0.0 is fully integrated with MATLAB® environment.   Target Audience: This release (1.0.0) is intended for technology demonstration, evaluation purposes, and prototyping on NXP S32R45 Processors and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt    
View full article
In this video we show the hall pattern identification procedure that can be applied to any motor in case you have no datasheet available. We will read the hall sensors outputs via the microprocessor and save the information for later use.   We show: - How to prepare the Hardware setup - How to go over each identification table - row by row - to apply DC voltage and rotate the rotor in different sectors 360 degrees. NOTE: Chinese viewers can watch the video on YOUKU using this link 注意:中国观众可以使用此链接观看YOUKU上的视频
View full article
This video is part of the https://community.nxp.com/thread/467938  Workshop module and shows how to implement a simple V/F (V/Hz) scalar control to spin the PMSM in open loop using Space Vector Modulation and trapezoidal speed profile.
View full article
BLDC Closed Loop Speed Control example for MPC574xP(Panther)+MotorGD Features: - Commutation based on HALL sensor transitions - Speed PI controller - Speed estimator based on HALL A transition time - Example made for Linix Motor (phA-white/phB-blue/phC-green) Copyright (c) 2017 NXP version 1.0.0 Model Based Design ToolBox
View full article
This video is part of the Module 7: Torque Control  Workshop module and shows how to implement a FOC and control the PMSM torque and flux using standard PI controllers. This method is used to spin the PMSM in open loop using Space Vector Modulation. The video shows how to implement a control system with two control loops: FAST and SLOW
View full article
  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    
View full article
Hello all, sharing the latest version of S12ZVM Power Dissipation Calculator started by Carlos Vazquez and Anita Maliverney. With this excel sheet is possible estimate the power dissipated for any MCU of S12ZVM family, considering: supply voltages, digital modules, gate drive unit, charge pump, communication transceivers, etc.   Updated static and dynamic consumption current of S12ZVMC256, S12ZVM32 and S12ZVMB. Regards.
View full article