1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement.     3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation.     4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent.   Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate.     5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors     6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.

      1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT).     3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow.     4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview.     5 References MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem.     6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.

  1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. Figure 1-1. Role of the Motor Control System within the EV traction domain     2 Table of Contents • Introduction • Overview • Context • References • Conclusion     3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities     4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests.     5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model     6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.

Introduction The following article shows a basic configuration and model for S32K396BMS-EVB that configures the SPI to communicate with the MC33CD1030 MSDI IC mounted on the evaluation board.   Prerequisite software The following software tools were used to develop and deploy the application onto the S32K396BMS-EVB board. MATLAB® R2024b or later Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ® Support Package for ARM ® Cortex ® -M Processors S32K3 MBDT Toolbox Version 1.4.0 BMS MBDT Toolbox Version 1.2.0 FreeMASTER Run-Time Debugging Tool   Prerequisite hardware The application is developed for the following hardware*: S32K396BMS-EVB Debug probe (used to deploy the example and to connect the FreeMASTER application to the board) 12V power supply   Configuration project In this chapter, I show most important settings that must be to allow the MCU to enter standby mode and to be able to wake up and switch to RUN mode again. For more details, please download the files attached and consult the configuration project.   Pins configuration   For the CD1030, only the SPI pins must be configured; LPSPI3 PCS1: PTF18 (OUTPUT) LPSPI3 CLOCK: PTF13 (OUTPUT) LPSPI3 SIN: PTF12 (INPUT) LPSPI3 SOUT: PTF15 (OUTPUT)   Figure 1. Configuration Pins tab - LPSPI pins   Peripherals configuration Platform component The interrupt must be configured for the LPSPi3. To configure it, please go to PLATFORM -> Interrupt Controller and add a new entry into the table, as below. Figure 2. Configuration Platform Component - Enable LPSPI3 interrupt   MCU Component The peripheral clock must be enabled and it can be done from the MCU component -> McuModuleConfiguration -> McuModeSettingsConf. Figure 3. Configuration MCU Component - Enable LPSPI3 peripheral clock   SPI Component The MCU communicates with MC33CD1030 over the LPSPI3. First step is to configure the Spi -> SpiGeneral -> SpiPhyUnit Figure 4. Configuration SPI Component - SpiPhyUnit (LPSPI3)   Then, the Spi->SpiDriver must be configured. Important! The frame size of the SPI messages: It must be 32-bit wide and MSB. Figure 5. Configuration SPI Component - SpiChannel   Figure 6. Configuration SPI Component - SpiExternalDevice   Figure 7. Configuration SPI Component - SpiJob   Figure 8. Configuration SPI Component - SpiSequence   Model configuraiton The Simulink model used to communicate with the MC33CD1030 can be seend in the picture below. It can also be found in the achieve attached to this article. The initialization of the model sets the AsyncMode to interrupt. Figure 9. Simulink Model - Initialization subsystem   The application executes the following tasks at each step: Set up the External Buffer for the LPSPI3 SpiChannel_CD1030. The input for the block must be an array of 4 uint8 elements (in total 4 bytes - 32bit). The control word is the last element, while the first 3 elements are the configure words. The Dest Data output is a data story memory configured as uint8 with the size equal to 4.  Send the command to the MC33CD1030 IC and receive the previous result in CD1030_RecvData_SG data store Increment a variable to check that the application is running   Figure 10. Simulink Model - Full Overview   Validation To validate the application, the FreeMASTER tool is used to connect to the board and initiate the sequence to enter standby mode. To connect the board, you can use the LPUART1 (J6 connector), baud rate 115200. If everything is properly configured, in the FreeMASTER you should see the following in the Variable Watch: The SPI_SetAsyncMode_Status, CD1030_SetupEB_Status and SPI_Transmit_Status should all be 0. The CD1030_RecvData_SG (BIN) and CD1030_RecvData_SG (HEX) should display the content of the CD1030's register 0x3E Read switch status registers SG. The step_counter should increment at each step execution. Figure 11. FreeMASTER Project - Variable Watch   To test that the CD1030 is working, I connect the J10_6 (SG0 - KEY_ON_DIN) to either GND or VCC and we can see that the last bit of the register changes.  Figure 12. FreeMASTER Project - J10_6 connected to GND  Figure 13. FreeMASTER Project - J10_6 connected to VCC   Conclusion   In this article, I presented a basic implementation that allows the S32K396 communicate with the MC33CD1030 IC over the SPI. For further details, please consult the MC33CD1030 reference manual.

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.7.1     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 S32K3 version 1.7.1. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART), and support for the GD3162 Gate Driver based on the S32K396 GD3162 Software. In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 180 examples, covering all the features and functionalities of the toolbox, including new demos for GD3162 Gate Driver 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=7846241   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GD3162 GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (6.0.0)   Integrates S32K396 GD3162 v2.0.2 The toolbox enables access to the GD3162 gate driver for S32K396 derivatives from Simulink models, by delivering a library block (Gd3162) that generates code on top of GD3162 components API.   New S32 Configuration Tools version supported (2024.R1.8)😎   Integration with EB tresos v29.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   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. 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 project template, 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: MCTPTX1AK324 S32K344-WB 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.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     XS32K3X2CVB-Q172     XS32K3X4EVB-Q257     XS32K3XXEVB-Q172     MR-CANHUBK344             S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289             XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.42 All functions in the Automotive Math and Motor Control Functions Library v1.1.42 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.   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   GD3162 Applications The toolbox provides examples for configuring and accessing the external GD3162 gate driver device via SPI communication to demonstrate Dynamic Gate Strength and DC Link Discharge features, supporting both S32 Configuration Tools and EB tresos. Each of them has a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The examples provided in this release include the following topics: - GD3162 Dynamic Gate Strength - GD3162 DC Link Discharge   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.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b R2025a R2025b   Examples for every peripheral/function supported More than 180 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling GD3162 Gate Driver applications (DC Link Discharge and Dynamic Gate Strength) Motor Control applications (BLDC and PMSM) 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 S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.7.1 is fully integrated with MATLAB® environment.   Target Audience: This release (1.7.1) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  1 Table of Contents • Introduction • Context • Component Overview • Design and Implementation • Results • Common Pitfalls & Troubleshooting • Summary & Next Steps • References 2 Introduction This article explains how virtual scenes and driving scenarios can be created and used within a Model-Based Design workflow using MathWorks tools. It focuses on how MATLAB® and Simulink® integrate with RoadRunner and Unreal Engine to enable realistic, repeatable, and scalable simulation environments for developing and validating advanced automotive systems. The article is aligned with the NXP Model-Based Design Toolbox (MBDT) workflow and targets users working on control, perception, and system-level validation. In our demo setup, the same workflow presented in this article was applied to build a Driver-in-the-Loop simulation scenario. By leveraging MATLAB®, Simulink®, RoadRunner, and Unreal Engine, we created a realistic virtual environment that allowed direct interaction with the system running on NXP hardware. This approach highlights the practical value of these simulations, not only for early validation and testing, but also for closing the loop between model-based design and real-time execution on target hardware, enabling faster iteration, safer validation, and improved system reliability. 3 Context As automotive systems become more complex, early validation is increasingly important. Engineers must assess advanced functionality under tight development timelines, often before hardware is available. Model-Based Design supports this need by enabling system logic and behavior to be verified early using executable models. Virtual scenes extend this approach by embedding those models in realistic, controlled environments that reflect real-world operating conditions. Within an NXP-based development workflow, virtual scenes enable teams to explore a wide range of driving situations quickly, safely, and repeatably. Complete applications can be evaluated at Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Processor-in-the-Loop (PIL) stages, helping uncover issues early and reducing risk before hardware integration. This structured use of virtual validation supports smoother transitions from simulation to deployment on automotive microcontrollers. 4 Component Overview Creating and using virtual scenes with MathWorks relies on several tightly integrated components: MATLAB and Simulink – used for algorithm development, control logic, and system modeling. RoadRunner – a dedicated environment for building detailed road networks, traffic infrastructure, and driving scenarios. Unreal Engine – responsible for high-fidelity 3D visualization and sensor realism. Simulation interfaces – enabling data exchange between Simulink, RoadRunner, and Unreal Engine during runtime. 5 Design and Implementation This section describes the design principles and implementation flow used to create virtual scenes and scenarios. The process emphasizes modularity, repeatability, and tight integration with control and system models. 5.1 System Requirements The following prerequisites must be satisfied to build and execute virtual scenes with MATLAB and Simulink and follow our path: MATLAB and Simulink with Automated Driving Toolbox and Simulink 3D Animation Toolbox installed. RoadRunner. Adequate GPU resources for real-time rendering and sensor simulation. These requirements ensure smooth interaction between simulation models and the visualization environment. 5.2 Architecture & Model Description At a higher level, the architecture consists of a Simulink model acting as the system under test, connected to a virtual world generated by RoadRunner and Unreal Engine. The Simulink model publishes vehicle states and receives environmental feedback, such as lane boundaries, traffic participants, or sensor detections. Clear interface definition between the model and the virtual environment is essential. Signals representing vehicle position, velocity, and actuator commands are exchanged at each simulation step, enabling closed-loop execution.   5.3 MATLAB/Simulink Implementation Connecting to RoadRunner and Loading a Scenario MATLAB connects directly to RoadRunner to open projects and load driving scenarios: % Launch RoadRunner and open a project rrApp = roadrunner('C:\RoadRunnerProjects\VirtualScenes'); openProject(rrApp, 'HelloWorld_Project'); % Open a RoadRunner scenario and start simulation scenarioName = 'Intersection_CrossTraffic'; openScenario(rrApp, scenarioName); rrSim = createSimulation(rrApp); start(rrSim); Integrating RoadRunner with Simulink Once configured, Simulink and RoadRunner run synchronously. RoadRunner updates the virtual environment, while Simulink computes vehicle behavior and control actions. sim('ConfiguredVirtualVehicleModel'); close(rrApp); 5.4 Integration (RoadRunner ↔ Unreal Engine) RoadRunner is used to design road geometry, traffic signs, intersections, and actor paths. These assets are exported to Unreal Engine, which provides photorealistic rendering and sensor simulation. % Open the Simulink model open_system('ConfiguredVirtualVehicleModel'); % Path to the RoadRunner project containing the scene scenarioPathFull = 'C:\RoadRunnerProjects\VirtualScenes\HelloWorld_Project'; % Configure the Simulation 3D Scene Configuration block set_param('ConfiguredVirtualVehicleModel/Visualization/3D Engine/3D Engine/Simulation 3D Scene Configuration', ... 'RoadRunnerProjectPath', scenarioPathFull);   5.5 Creating a Custom Scene from Real Map Data Custom scenes can be created by importing real-world map data into RoadRunner. Geographic information such as road layouts and elevation profiles can be converted into editable road networks. This is an example of how to create a custom scene for recreating the Silverstone Racing Circuit in RoadRunner, using OpenStreetMap and Driving Scenario Designer. And the result using Simulink 3D with Unreal Engine.   5.6 Testing & Validation Once scenarios are defined, automated simulation runs can be executed to validate system behavior across multiple variants. Key metrics such as trajectory tracking, sensor coverage, and control stability can be evaluated offline. This systematic testing approach increases confidence before integrating software with NXP hardware targets. 6 Results Using virtual scenes significantly reduces development time. Engineers can identify functional issues early, explore edge cases, and refine algorithms without hardware constraints. In practice, this results in higher software quality at the time of hardware deployment and a smoother transition to real-world testing. 7 Common Pitfalls & Troubleshooting Simulation time overhead can become noticeable when RoadRunner scenes are used directly in the Simulation 3D Scene Configuration block, as Unreal Engine re-imports RoadRunner assets at the start of each simulation. While this is well suited for iterative development and scene refinement, it can slow down repeated runs. Note: For final validation or deployment-oriented testing, improved performance can be achieved by using a precompiled Unreal Engine project, which avoids repeated asset import and significantly reduces startup time. In addition, repeatedly launching RoadRunner for each simulation introduces unnecessary overhead. A recommended practice is to keep RoadRunner running across multiple simulations and reuse the existing connection. This can be achieved using the RoadRunner roadrunner.connect API, allowing MATLAB and Simulink to reconnect to an active RoadRunner instance instead of restarting it for every run, thereby improving iteration speed and overall workflow efficiency. 8 Summary & Next Steps Virtual scenes turn simulation into experience. Combined with an NXP Model-Based Design workflow, MathWorks tools enable engineers to innovate faster, validating complex behavior early while reducing risk, cost, and development effort. Next, these environments can be expanded with high-fidelity sensor models, automated regression testing, and hardware-in-the-loop execution, closing the gap between virtual validation and real-world deployment. 9 References Import OpenStreetMap Data into Driving Scenario — MathWorks Help Driving Scenario Designer App — MathWorks Help RoadRunner — MathWorks Product Page Simulink 3D Animation Toolbox — MathWorks Help OpenStreetMap Automated Driving Toolbox — MathWorks Product Page Visualize 3D Scenes with Unreal Engine — MathWorks Help roadrunner.connect API — MathWorks Help NXP Model-Based Design Toolbox — Community

Real-Time debugging tool for embedded application running on NXP CPUs

Introduction   The following article shows a basic configuration for S32K3 that allows the MCU to transition from RUN mode to a Standby mode.   Prerequisite software   The following software tools were used to develop and deploy the application onto the S32K3 board. MATLAB® R2023b or later Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ® Support Package for ARM ® Cortex ® -M Processors S32K3 MBDT Toolbox Version 1.8.0 FreeMASTER Run-Time Debugging Tool   Prerequisite hardware   The application is developed for the following hardware*: X-RD-K344BMU (MCU: S32K344-Q257) Debug probe (used to deploy the example and to connect the FreeMASTER application to the board) 12V power supply Jumper Wire   Configuration project   In this chapter, I show most important settings that must be to allow the MCU to enter standby mode and to be able to wake up and switch to RUN mode again. For more details, please download the files attached and consult the configuration project. Pins configuration Two pins must be configured for this application: Signal wkpu,14  (of WKPU peripheral) to the PTB17. Direction: Input Pull Select: Pullup Pullup Enable: Enabled Signal gpio, 65 (of SIUL2 peripheral) to the PTC1. Direction: Output     Figure 1. Configuration Pins tab - Dio_Pins_MBDT Functional Group   Clocks configuration A new Functional Group must be created for the Standby Mode. This can be done from the Clocks tab (as shown in the image below).   Figure 2. Configuration Clock tab - Create new Functional Group   Peripherals configuration Dio component   Figure 3. Configuration Dio Component - DioGeneral     Figure 4.  Configuration Dio Component - DioChannel Wkpu_DioChannel     Figure 5.  Configuration Dio Component - DioChannel Green_Led_DioChannel   Port configuration The Port configuration must match the settings configured in the Pins tab (check Pins Configuration chapter).   Figure 6. Configuration Port component - PortPin Wkpu_PortPin     Figure 7. Configuration Port component - PortPin Green_Led_PortPin   Mcu configuration A new McuModeSettingConf must be created. It is going to be used to switch to STANDBY mode.   Figure 8. Configuration Mcu component - McuModuleConfiguration -> McuModeSettingConf   A new McuClockSettingConfig must be created. The MCU will use to this clock tree when it is in standby. All the settings in this newly created McuClockSettingConfig must match the settings made in Clocks tab.     Figure 9. Configuration Mcu component - McuModuleConfiguration -> McuClockSettingsConfig   Make sure that for the new McuClockSettingsConfig, in the configuration tab, the Functional Group created in Figure 2 is selected.     Figure 10. Configuration Mcu component - McuModuleConfiguration -> McuClockSettingsConfig -> Configuration     ICU configuration     Figure 11. Configuration Icu component - IcuConfigSet -> IcuChannels   Note! The first 4 Hardware Channel are internally routed. For the evaluation board that I used, the PTB17 corresponds to the WAKE_14. In the configuration project, the hardware channel must be set to CH18 (to offset the first 4 internally routed hardware channel).     Figure 12. Offset internally routed hardware channels     Figure 13. Configuration Icu component - IcuConfigSet -> IcuWkpu -> IcuWkpuChannels     Figure 14. Configuration Icu component - IcuConfigSet -> IcuHwInterruptConfigList   Model configuration   The Simulink model used to switch from RUN mode to STANDBY mode can be seen in the picture below. It can also be found in the achieve attached to this article. The application executes the following tasks at each steps: Toggle the LED to visually tell if the board is running or in standby mode Increment a variable Check if the enter_standby variable is set to 1. If true, the sequence to enter standby mode is executed.   Figure 15. Simulink Model S32K3_Standby_GPIO_Wkpu     Figure 16. Enter Standby mode routine     Figure 17. Custom code to enter standby mode   Validation   To validate the application, the FreeMASTER tool is used to connect to the board and initiate the sequence to enter standby mode. To connect the board, I used the debug probe.   Figure 18. Connect FreeMASTER tool to the board using debug probe   If everything is properly configured, the FreeMASTER should now be connected to the board. In the Variable Watch, the value of the counter variable is increased each second.  To enter standby mode, the value of the enter_standby variable must be set to 1. If the sequence to enter standby mode is correctly executed, the value of the counter shouldn't be updated anymore and the LED should stop blinking. Also, the board is disconnected from the FreeMASTER board. To exit standby mode, use the jumper wire to connect the PTB17 to a GND pin. The LED should start blinking.   Conclusion   In this article, I presented a basic implementation that allows the S32K344 to enter standby mode. The configuration presented here doesn't maximize the power savings, as the user should take care of putting the pins in a floating state, disable all unnecessary clocks and many more. For further details, please consult the S32K3 reference manual.   This application was based on the examples found in this article: S32K3 Low Power Management AN and demos. Kudos @Shuang!

Table of Contents 1. Introduction 2. Requirements 2.1 Software Required 2.2 Hardware Required 3. NXP Account Login 4. Installation 4.1 PEmicro Driver Installation 4.2 FreeMASTER Installation 4.3 MATLAB® Installation 4.4 MATLAB® Add-Ons Installation 4.5 MBDT for S32K3 v1.8.0 Installation 5. Running a Demo from the MBDT Examples for S32K3 6. Running a Motor Control Demo using MBDT 7. Conclusion 1. Introduction This article aims to help new users prepare and install the necessary software and hardware to use the FRDM Automotive S32K312 with the latest  Model-Based Design Toolbox for S32K3 version 1.8.0. Note: These steps can also be followed with any NXP Evaluation Board from the supported list referenced in the toolbox documentation. S32K312MINI‑EVB Renamed to FRDM‑A‑S32K312: Now part of the FRDM Automotive Ecosystem under its new name, the board keeps the same hardware and adds full ecosystem compatibility for flexible, scalable development.     2. Requirements   2.1 Software Required MATLAB® R2023b or later, with the following Add-ons: AUTOSAR Blockset Embedded Coder Support Package for ARM Cortex-M Processors Motor Control Blockset NXP_Support_Package_S32K3 Stateflow NXP Model-Based Design Toolbox for S32K3 version 1.8.0 FreeMASTER Run-Time Debugging Tool PEmicro Hardware Interface Drivers   2.2 Hardware Required FRDM-A-S32K312 Development Board MCSPTE1AK344 Motor Control Kit, which includes: Sunrise motor  DEVKIT-MOTORGD  12V power supply USB Type-C cable   3. NXP Account Login Open Software Licensing: Support, make sure you are logged into your NXP Account, and select: Click on My NXP Account. Select Software Licensing and Support. Then click on View accounts: These steps will ensure that you are properly authenticated with your NXP Account before proceeding with step 4.5 MBDT for S32K3 v1.8.0 Installation. Keep the page open for the login to persist.   4. Installation Note: Before proceeding, make sure you have full access to your PC or Laptop. Some installers require local admin rights. Contact your IT department to assist you with installation.   4.1 PEmicro Driver Installation After downloading the PEmicro Hardware Interface Drivers: Open the installer package and select the default Destination Folder: Click on Install and then wait for it to finish successfully. Connect the USB cable to your PC and the FRDM Automotive S32K312 board: Open Device Manager to check OpenSDA and the COM port number. OpenSDA - CDC Serial Port → note this COM port number: Note: The COM port number may differ on your system.   4.2 FreeMASTER Installation Download the  FreeMASTER Run-Time Debugging Tool:   Open the installer FMASTERSW32.exe Click Next, then select all available products: Use the default installation path: C:\NXP\FreeMASTER 3.2 Wait for the installation to complete.   4.3 MATLAB® Installation First, check whether MATLAB® R2023b or later is already installed. If so, you can skip this section. For this tutorial, MATLAB® R2025b is downloaded from MathWorks®: Download the matlab_R2025b_Windows.exe (246 MB) file. A MathWorks® Account login is required. After signing in, select the installation directory; the default is C:\Program Files\MATLAB\R2025b For minimum requirements, install the following products: MATLAB® Simulink® AUTOSAR Blockset Embedded Coder MATLAB® Coder Motor Control Blockset Simulink® Coder Stateflow By default, Select All is enabled during install: Wait for the installation to finish. After installation, open MATLAB® and change the default Add-ons path to a shorter path such as C:\MathWorks .   4.4 MATLAB® Add-Ons Installation Open Add-On Explorer and install: Embedded Coder Support Package for ARM Cortex-M Processors NXP Support Package for S32K3 (NXP_Support_Package_S32K3)   4.5 MBDT for S32K3 v1.8.0 Installation After installing the support package, run the following command in MATLAB®: sp_s32k3.nxp.setup(); Select version 1.8.0; the installer will check prerequisites: If any toolboxes are missing, install them before continuing. Click Download to proceed. The Download button opens the Software Terms and Conditions dialog; if the page is not loading properly, follow the steps in 3. NXP Account Login. After reading, click I Agree. Download the SW32_MBDT_S32K3_1.8.0_D2512.mltbx file (approx. 1.6 GB): Once the download completes, browse to the location of the SW32_MBDT_S32K3_1.8.0_D2512.zip file: Click Install to proceed and accept the license agreement. After a few minutes, the dialog will display: Installation successfully completed! Click Next. Select an option such as Open S32K3 Root Folder. MATLAB®'s current folder will change to the root of the toolbox. Click Finish to close the installer. The current folder in MATLAB® is now C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3 :     5. Running a Demo from the MBDT Examples for S32K3 Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\demos\s32k3xx_uart_leds_s32ct Open the model s32k3xx_uart_leds_s32ct.mdl . Click on Hardware Settings: Go to Hardware Board Settings → Hardware → Select Configuration Project Template: For the FRDM-A-S32K312 select Custom: S32K312MINI-EVB S32 Config Tool. A Warning Dialog will appear; click OK. Wait for the configuration update to complete. Click on Apply and close the Configuration Parameters window. Press Build, Deploy & Start (CTRL+B) to generate the code: After the build completes successfully, the executable is downloaded to the board. Open a terminal application and connect to the board's COM port at 115200 baud: Pressing r, g, or b on the keyboard toggles the corresponding RGB LED on the board.   6. Running a Motor Control Demo using MBDT Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\mc\PMSM Open the folder s32k312_mc_pmsm_2sh_s32ct : Open the model s32k312_mc_pmsm_2sh_s32ct.mdl : Press Build, Deploy & Start (CTRL+B) to generate the code. After the executable file is downloaded to the board: Disconnect the FRDM-A-S32K312 board from the PC. Insert the DEVKIT-MOTORGD on top of the FRDM-A-S32K312, ensuring proper pin alignment. Plug in the 12V power supply to the DEVKIT-MOTORGD. Reconnect the USB Type-C cable to the FRDM-A-S32K312.  The RGB LED and User Buttons are on the top side, the Reset Button is on the left side, while the 12V power, Motor Phases, and USB Type-C are on the right side.    Open FreeMASTER s32k312_mc_pmsm_2sh_s32ct.pmpx : Press GO to connect at 115200 baud. In the App Control tab, press On and set Speed Required to 1000 RPM: Apply a small mechanical load to the motor (friction force to the motor shaft) and observe the iABC currents. Here is a short video with the steps above explained:   7. Conclusion These steps conclude the Getting Started with FRDM Automotive S32K312 using the Model-Based Design Toolbox guide. For more details, refer to: s32k312_mc_pmsm_2sh_s32ct_example_readme.html The corresponding example_readme.html for the selected model. Thank you for your time, Stefan V.

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.8.0     The Analog & Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3 version 1.8.0. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K356, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K389, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART). In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 130 examples, covering all the features and functionalities of the toolbox, including new 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=7690521   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K356 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388 S32K389 S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (7.0.0)   New S32 Configuration Tools version supported (2025.R1.8)😎   Integration with EB tresos v32.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   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. 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 project template, 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: S32K312MINI-EVB MCTPTX1AK324 S32K344-WB S32K3-T-BOX 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.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     S32K312MINI-EVB     MCTPTX1AK324     XS32K3X2CVB-Q172     S32K3-T-BOX     MR-CANHUBK344       XS32K3X4EVB-Q257     XS32K3X4EVB-Q172           S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289      S32K389EVB-Q437            XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.42 All functions in the Automotive Math and Motor Control Functions Library v1.1.42 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.   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.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2023b R2024a R2024b R2025a R2025b   Examples for every peripheral/function supported More than 130 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling Motor Control applications (BLDC and PMSM) AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and User Manual 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 S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.8.0 is fully integrated with MATLAB® environment.   Target Audience: This release (1.8.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32ZE – version 1.4.0     The Analog & Automotive Embedded Systems, 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.4.0. This release supports automatic code generation from MATLAB and Simulink for NXP S32Z/E Automotive Real-Time Processors. This new release supports S32Z2/E2 families and its cores (Real-Time ARM Cortex-R52 cores and DSP/ML processor). It also supports Multicore, 41 Mathematical Operators highly optimized for DSP/ML processor, Processor-in-Loop Simulation mode, RTD components (ADC, PWM, DIO, CAN, UART, GPT, SPI, Application Extension), FreeMASTER, AMMCLib, and execution profiling. The product comes with 40 examples, covering DSP/ML 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=7702701   Technical Support: NXP Model-Based Design Toolbox for S32ZE issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: The newly added features are highlighted with bold. Automatic C code generation from MATLAB® for NXP S32Z2/E2 packages: S32E2xx-bga975 S32Z2xx-bga594 S32Z2xx-bga400 GreenBox 3 The toolbox has been tested and validated on the official NXP Evaluation Boards S32E27X-DC S32Z27X-DC GreenBox 3 Rev. B Only S32Z2/E2 chips with DSP/ML option B can use the SPF2 core and associated software Support for the following peripheral components and functions: Application Extension (AE) for S32E: FlexPWM, eTimer, SAR ADC, CTU SPI ADC PWM DIO CAN UART GPT  Multicore support using Concurrent Execution from Simulink Multicore support using Simulink Reference Configurations New Hybrid-Electrical Vehicle (HEV) Example with Virtual Vehicle Composer (VVC) Tool from MathWorks New RTD version supported (2.0.1) New SPF2CE version supported (1.0.0) New AMMCLib version supported (1.1.41) New SPF2 Libraries (MATLAB) version supported (20.4.8) New FreeMASTER Driver version supported (1.4.2) Integration with EB tresos v29.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 Default Configuration Project Templates targeting all the supported derivatives     Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. 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 project template, it can be used for every model that is being developed. Integrates the Automotive Math and Motor Control Library release 1.1.41 All functions in the Automotive Math and Motor Control Functions Library v1.1.41 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.   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)   Multicore support using Concurrent Execution from Simulink     HEV Example using Virtual Vehicle Composer   Support for MATLAB versions We added support for the following MATLAB versions: R2023a R2023b R2024a R2024b R2025a R2025b   More than 40 examples , covering all the peripheral/function supported I/O Control Application Extension (AE) for motor control applications Timers and scheduling Communication (CAN, SPI, UART) Memory handling DSP/ML processor AMMCLib FreeMASTER SIL / PIL Multicore For more details, features, and how to use the new functionalities, please refer to the Release Notes and User Manual 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 S32Z/E Real-Time Processors and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32ZE version 1.4.0 is fully integrated with MATLAB® environment.       Target Audience: This release (1.4.0) is intended for technology demonstration, evaluation purposes, and prototyping S32Z/E Real-Time Processors and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.7.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 S32K3 version 1.7.0. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART), and support for the GD3162 Gate Driver based on the S32K396 GD3162 Software. In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 180 examples, covering all the features and functionalities of the toolbox, including new 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=7608021   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GD3162 GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (6.0.0)   Integrates S32K396 GD3162 v2.0.2 The toolbox enables access to the GD3162 gate driver for S32K396 derivatives from Simulink models, by delivering a library block (Gd3162) that generates code on top of GD3162 components API.   New S32 Configuration Tools version supported (2024.R1.8)😎   Integration with EB tresos v29.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   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. 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 project template, 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: MCTPTX1AK324 S32K344-WB 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.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     XS32K3X2CVB-Q172     XS32K3X4EVB-Q257     XS32K3XXEVB-Q172     MR-CANHUBK344             S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289             XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.41 All functions in the Automotive Math and Motor Control Functions Library v1.1.41 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.   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   GD3162 Applications To demonstrate the integration and support of the GD3162 gate driver IC, we have included a reference Simulink application that configures six GD3162 devices in   a daisy-chain topology using SPI communication. The setup enables sequential initialization, configuration, and status monitoring of each GD3162 device using the S32K396 as a controller MCU.   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.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b R2025a   Examples for every peripheral/function supported More than 180 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling Motor Control applications (BLDC and PMSM) 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 S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.7.0 is fully integrated with MATLAB® environment.   Target Audience: This release (1.7.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 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 S32K3 – version 1.6.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 S32K3 version 1.6.0. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART), and support for the eTPU co-processor based on the S32K3 eTPU Software. In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 180 examples, covering all the features and functionalities of the toolbox, including new 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=6626551   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN eTPU DIO FEE GPT I2C ICU LIN MEM MCL (including DMA support) PWM SPI UART Memory read/write Registers read/write Profiler   New RTD version supported (5.0.0)   Integrates S32K3 eTPU Software v2.0.0 CD01 The toolbox enables access to the eTPU co-processor of the S32K36x/S32K39x derivatives from Simulink models, by delivering a library of blocks that generate code on top of eTPU components APIs: Etpu MotorControl Rdc_Checker   New S32 Configuration Tools version supported (2024.R1.7 Update 😎😎   Integration with EB tresos v29.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   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. 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 project template, 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: S32K344-WB 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.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     XS32K3X2CVB-Q172     XS32K3X4EVB-Q257     XS32K3XXEVB-Q172     MR-CANHUBK344             S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289             XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.39 All functions in the Automotive Math and Motor Control Functions Library v1.1.39 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.   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.   For demonstrating the S32K3 eTPU Software integration, we have included in this release a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b   Examples for every peripheral/function supported More than 180 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling Motor Control applications (BLDC and PMSM) 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 S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.6.0  is fully integrated with MATLAB® environment.   Target Audience: This release (1.6.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 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 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      

  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for S32M2 – 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 S32M2 version 1.1.0. This release supports automatic code generation for S32M2 peripherals and applications prototyping from MATLAB/Simulink for NXP S32M2 Automotive Microprocessors. This product adds support for S32M41, S32M242, S32M43, S32M244, S32M274, S32M276 MCUs and part of their peripherals, based on RTD MCAL components (ADC, AE, DIO, CAN, Can_Trcv, DPGA, GDU, GPT, LIN, LIN_Trcv, MCL, PWM, MCL, MCU, PORT, QDEC, SPI, UART). In this release, we have also added support for FreeMASTER, AMMCLib, and MATLAB support for the latest versions. The product comes with over 85 examples, covering all supported peripherals, and Simulink simulation modes Software-in-the-Loop, Processor-in-the-Loop, and External Mode. Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox. FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=6481361 Technical Support: NXP Model-Based Design Toolbox for S32M2 issues will be tracked through the NXP Model-Based Design Tools Community space. Release Content: Automatic C code generation from MATLAB® & Simulink® for NXP S32M2 derivatives: S32M241 S32M242 S32M243 S32M244 S32M274 S32M276 Support for the following peripherals (MCAL components): ADC AE CAN CAN_Trcv DIO DPGA GDU GPT ISR LIN LIN_Trcv MCL MCU MEMORY PROFILER PWM PORT QDEC SPI UART Profiler in PIL mode Provides 2 modes of operation Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tool or EB Tresos to configure peripherals/pins/clocks Provides Motor Control examples MBDT for S332M2 1.1.0 provides examples for PMSM sensorless, open loop and closed-loop hall sensors motor control applications, supporting S32 Configuration Tools. Each of them has a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. Integrates the Automotive Math and Motor Control Library version 1.1.38 All functions in the Automotive Math and Motor Control Functions Library v1.1.38 are supported as blocks for simulation and embedded target code generation. Integration with FreeMASTER MBDT for S332M2 1.1.0 delivers 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 Custom Default Project MBDT for S332M2 1.1.0 provides support for users to create their own custom default project. This could be very useful when having a custom board design – the configuration for it needing to be created only once. After that configuration is saved as a custom default project, it can be used for other models that are developed. Support for custom board initialization MBDT for S332M2 1.1.0 generates the components’ peripherals initialization function calls as configured in the Board Initialization window, which can be customized to each Simulink model. This feature allows users to set a custom order for the components initialization, the insertion of the Custom code sequences, or share the custom initialization with multiple Simulink models via the Export and Import functionality. Integration with S32 Config Tools version v1.7 Integration with S32 Design Studio MBDT for S332M2 1.1.0 automatically generates the <model_name>_Config folder, next to the Simulink model location, providing user the opportunity to easily import the generated code from Simulink into S32 Design Studio. Each time the code is generated, the  <model_name>_Config folder is updated with the new changes. Toolbox also provides a mechanism to launch an S32 Design Studio instance, with the imported generated code project in the Project Explorer tab from S32DS. Simulation modes       Toolbox provides 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      Support for application execution profiling Custom Linker File and Startup Code Users can choose to use custom files for this process, from the Build Options group which can be found in the Target Hardware Resources, as illustrated in the image below. Examples for every peripheral/function supported       We have added over 60 examples, including: CDD Blocks (Ae, Dpga, Gdu, Mcl, Qdec) Communication (Can, Lin, Spi, Uart) AMMCLib IO Blocks (Adc, Dio, Pwm) ISR Blocks (Hardware Interrupt Handler) MCAL Blocks (Gpt) Utility Blocks (FreeMASTER, Memory, Profiler, Registers) Software-in-the-Loop / Processor-in-the-Loop / 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 Support for MATLAB® versions R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b   The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32M2 MCUs and evaluation board solutions out-of-the-box with:   Target Audience This release (MBDT for S32M2 1.1.0) is intended for technology demonstration, evaluation purposes, and prototyping of S32M2 MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt DEMO Motor Control Rapid Prototyping on NXPs S32M2 with MathWorks and the Model-Based Design Toolbox This training shows how to design and develop motor control algorithms with Simulink® (MathWorks) and the Model-Based Design Toolbox for S32M2. Presentation introduces NXP’s S32M2 family, an integrated solution for 12V Motor Control and 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 target. The FreeMASTER software tool is used to control and monitor the algorithms running on the S32M2. First application focuses on a simple scalar control (also known as open-loop control or Volts per Hertz control) algorithm for a permanent magnet synchronous motor (PMSM). Second application shows how MATLAB and Simulink works together with the MBDT for S32M2 focusing on a workflow of implementing a predictive maintenance motor control application. Toolbox is used to acquire data from an accelerometer mounted on the motor. The motor is spinning at various speeds, and the vibrations are monitored using FreeMASTER. Data is transferred to MATLAB, where is preprocessed and a Support Vector Machine is trained. Then the resulted classifier is transferred to Simulink where together with the Model-Based Design Toolbox for S32M2 code is generated and deployed on the MCU. For more details about the demo mentioned above, please check this webinar a full demo description.        

  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for BMS – version 1.2.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 Battery Management System version 1.2.0 RFP.  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.3 and BMS SDK 1.0.3 SL DEMO, and MATLAB support for the latest versions. This product comes with battery cell controller ready-to-run examples, targeting the NXP HVBMS Reference Design Bundle Using ETPL (RD-HVBMSCTBUN), the 800 V Battery Management System (BMS) Reference Designs Using ETPL (RD-HVBMSCT800BUN) and the 14 V Battery Management System (BMS) Reference Design, Lead-Acid Replacement (RD33772C14VEVM).   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=6477171   Technical Support: NXP Model-Based Design Toolbox for BMS issues will be tracked through the NXP Model-Based Design Tools Community space.   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_GEN1_SDK_4.4_R21-11_1.0.3 SW32K3_BMS_GEN1_SL_SDK_4.4_R21-11_1.0.3_DEMO   Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b   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) and custom code initialization for the FS26 RD-HVBMSCT800BUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits) RD33772C14VEVM Configuration and data acquisition example, communication and custom code initialization for the FS26   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.2.0 is fully integrated with MATLAB® environment.     Target Audience: This release (1.2.0 RFP) 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 Electrification Solutions (High Voltage Battery Management System and Motor Control) with Model-Based Design: The Electrification Solutions with Model-Based Design, shows how the NXP Tools Ecosystem can be used together with the MathWorks ecosystem of toolboxes and solutions to develop complex applications, like the powertrain for electric vehicles, as shown in our demo diagram below. For BMS, virtual battery packs can be created in Simulink and various simulation testing scenarios can be  applied to the BMS algorithms, before deploying on the hardware. The Battery Management System, 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: Model, Develop, and Validate Battery Management Systems and Motor Control Applications in MATLAB® and Simulink® Generate code, Build, and Deploy hardware-aware applications on NXP microcontrollers and processors Monitor and Tune the applications using FreeMASTER and Vehicle Network Toolbox at runtime Create a Cloud Digital Twin with NXP GoldBox and AWS with data processing in MATLAB Cloud Center        

    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    

    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      

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.                      

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.