1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Lights Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Logic Control (Main model overview) Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  What is next? Export to & Debug generated code to S32 Design Studio IDE Others Getting Started with FRDM-A-S32K312 using Model-Based Design  Note: This index is updated as new articles are published.

  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.

  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

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

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.

This page summarizes all Model-Based Design Toolbox tutorials and articles related to BMS on S32K3xx & S32K1xx Product Family   MBDT for BMS & MBDT for S32K3xx:   MBDT for S32K1xx: How to use RDDRONE-BMS772 with MBDT   

This page summarizes all Model-Based Design Toolbox topics related to the BMS Product Family. Model-Based Design Toolbox for BMS- Release Notes: Rev 1.1.0 - Model-Based Design Toolbox for BMS rev 1.1.0  Rev 1.0.0 - Model-Based Design Toolbox for BMS rev 1.0.0 

General Installer and Setup Installation Troubleshooting  TPL Communication TPL communication troubleshooting TPL Communication with multiple BCCs FreeMASTER Configuration FreeMASTER not detected on the HVBMU Board  TD Handler TD Handler indexing 

  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for BMS – version 1.1.0     The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for BMS version 1.1.0 RTM. This release is an Add-On for the NXP Model-Based Design Toolbox for S32K3xx 1.4.0, which supports automatic code generation for battery cell controllers and applications prototyping from MATLAB/Simulink. This product adds support for MC33775A, MC33774A, MC33772C, MC33664, and MC33665A and part of their peripherals, based on BMS SDK components (Bcc_772c, Bcc_772c_SL, Bcc_775a, Bcc_774a, Bms_TPL3_SL_E2E, Bms_common, Phy_664, Phy_665a). In this release, we have enhanced the integration with the Model-Based Design Toolbox for S32K3xx version 1.4.0, added support for the BMS SDK 1.0.2 and BMS SDK 1.0.2 SL, and MATLAB support for the latest versions. This product comes with battery cell controller examples, targeting the NXP HVBMS Reference Design Bundle Using ETPL (RD-HVBMSCTBUN) and 800 V Battery Management System (BMS) Reference Designs Using ETPL (RD-HVBMSCT800BUN).   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983088   Technical Support: NXP Model-Based Design Toolbox for BMS issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP Battery Cell Controllers derivatives: MC33775A MC33774A MC33772C MC33665A MC33664   Support for the following peripherals (BMS SDK components): Bcc_775a Bcc_774a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E   Support for MC33775A, MC33774A and MC33772C Battery Cell Controllers & MC33664PHY and MC33665PHY The toolbox provides support for the MC33775A, MC33774A, MC33772C, MC33664 and MC33665A. The MC33775A, MC3774A, and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications performing ADC conversions of the differential cell voltages and battery temperatures, while the MC3366 and MC33665A are transceiver physical layer transformer drivers, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for BMS show how to communicate between the S32K344/S32K358 and the MC33775A, MC33774A, and MC33772C via the MC33664/MC33665 transceivers.  For the MC33775A and MC33774A, the examples show how to configure the battery cell controllers to perform Primary and Secondary chain conversions and read the cell voltage conversion results from the MC33775A/MC33774A, while for the MC33772C the examples show how to configure the Battery cell controller to read the pack current. All the converted values are displayed to the user over the FreeMASTER application.               BMS SDK version supported: SW32K3_BMS_SDK_4.4_R21-11_1.0.2 SW32K3_BMS_SL_SDK_4.4_R21-11_1.0.2_DEMO Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a More than 15 examples showcasing the supported functionalities: MC33775A Configuration and data acquisition example MC33774A Configuration and data acquisition example MC33772C Configuration and data acquisition example RD-HVBMSCTBUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits) RD-HVBMSCT800BUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits)   For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s Battery Cell Controllers together with S32K3xx MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for BMS version 1.1.0 is fully integrated with MATLAB® environment.     Target Audience: This release (1.1.0) is intended for technology demonstration, evaluation purposes, and battery management systems prototyping using NXP Battery Cell Controllers and S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt   DEMO High Voltage Battery Management System with Model-Based Design: The HVBMS with MBDT demo, running on the NXP HVBMS Reference Design and NXP GoldBox, combines the MathWorks Simulink application example Design and Test Lithium Ion Battery Management Algorithms  together with the NXP’s Model-Based Design Toolbox for BMS  Blocks to automatically generate, build, and deploy standalone BMS applications on the NXP targets. Here are the main highlights of this demo: Develop a High-Voltage Battery Management System application to run on the NXP's HVBMS Reference Bundle using the Model-Based Design paradigm Model, Develop, and Validate BMS Applications in MATLAB and Simulink Automatically Generate code, Build, and Deploy hardware-aware applications on NXP microcontrollers and processors Monitor and Tune the application using FreeMASTER and Vehicle Network Toolbox at runtime Create a Cloud Digital twin with NXP GoldBox and AWS with data processing in MATLAB Cloud          

  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32M2xx – version 1.0.0 RTM   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32M2xx version 1.0.0. This release supports automatic code generation for S32M2xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32M2xx Automotive Microprocessors. This new 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, DPGA, GDU, GPT, MCL, PWM, MCU, PORT, QDEC, UART). In this release, we have also added support for FreeMASTER, AMMCLib, and MATLAB support for the latest versions. The product comes with over 60 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 – S32M2 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3785898   Technical Support: NXP Model-Based Design Toolbox for S32M2xx 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 S32M2xx derivatives: S32M241 S32M242 S32M243 S32M244 S32M274 S32M276   Support for the following peripherals (MCAL components): ADC AE DIO CAN DPGA GDU GPT MCL PWM MCU PORT QDEC UART   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   Integrates the Automotive Math and Motor Control Library version 1.1.34: All functions in the Automotive Math and Motor Control Functions Library v1.1.34 are supported as blocks for simulation and embedded target code generation.   Integration with FreeMASTER We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB® versions R2021a R2021b R2022a R2022b R2023a R2023b   Support for custom board initialization Toolbox 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.       Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the hardware configuration once. After it is saved as a custom default project, it can be used for every model that is being developed.     Integration with S32 Config Tools version v1.7:       Integration with S32 Design Studio The toolbox automatically generates the <model_name>_Config folder, next to the Simulink model location, providing the 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. The 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: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode   Support for profiling in PIL mode:   Examples for every peripheral/function supported: We have added over 60 examples, including: CDD Blocks (Ae, Dpga, Gdu, Mcl, Qdec) Communication (Can, Uart) AMMCLib IO Blocks (Adc, Dio, Pwm) ISR Blocks (Hardware Interrupt Handler) MCAL Blocks (Gpt) Utility Blocks (FreeMASTER) 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 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 S32M2xx MCUs and evaluation board solutions out-of-the-box with: Model-Based Design Toolbox for S32M2xx version 1.0.0 is fully integrated with MATLAB® environment in terms of installation:     Target Audience This release (1.0.0) is intended for technology demonstration, evaluation purposes, and prototyping of S32M2xx MCUs and Evaluation Boards.   Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt      

    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for BMS – version 1.0.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for BMS version 1.0.0 EAR. This release is an Add-On for the NXP Model-Based Design Toolbox for S32K3xx 1.4.0, which supports automatic code generation for battery cell controllers and applications prototyping from MATLAB/Simulink. This new product adds support for MC33775A, MC33772C, MC33665A BCCs and part of their peripherals, based on BMS SDK components (Bcc_772c, Bcc_772c_SL Bcc_775a, Bms_TPL3_SL_E2E, Bms_common, Phy_665a). In this release, we have added the integration with the Model-Based Design Toolbox for S32K3xx version 1.4.0, added support for the BMS SDK 1.0.1, and MATLAB support for the latest versions. The product comes with battery cell controller examples, targeting the NXP HVBMS Reference Design boards.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3720278   Technical Support: NXP Model-Based Design Toolbox for BMS issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP Battery Cell Controllers derivatives: MC33775A MC33772C MC33665A   Support for the following peripherals (BMS SDK components): Bcc_775a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications that perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344, the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.             BMS SDK version supported (1.0.1) Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a   Examples of the functions supported: MC33775A Configuration and data acquisition example MC33772C Configuration and data acquisition example RD-HVBMSCTBUN Configuration and data acquisition example   For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s Battery Cell Controllers together with S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for BMS version 1.0.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience: This release (1.0.0 EAR) is intended for technology demonstration, evaluation purposes, and battery management systems prototyping using NXP Battery Cell Controllers and S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.4.0 RFP   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.4.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, LIN, GPT). To enable BMS applications development, the toolbox offers support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 120 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=14146527   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL LIN CAN SPI UART GPT DIO   Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model. Moreover, the toolbox provides the option to save and export the initialization sequence to a file which can be later used for other models as well – in this way, the customization of the board initialization sequence can be done only once, even if applicable for other models as well. Such a file can be then imported as an external Board Initialization Template.   Custom Linker Files and Startup Code: The toolbox allows the selection of custom linker files and startup code to be used during the build process. By enabling the Use Custom Linker or/and Use Custom Startup Code checkboxes, this feature is activated, allowing the users to Browse for specific files.   Support for Referenced Configurations The Model-Based Design Toolbox for S32K3xx enables the usage of Referenced Configurations, a Simulink feature which allows users to share the configuration of an application with multiple models.   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (3.0.0) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.32: All functions in the Automotive Math and Motor Control Functions Library v1.1.32 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.   Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.   Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 120 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (LIN, SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached. MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.4.0 is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.4.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt          

    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.3.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.3.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated S32 Configuration Tools, RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 115 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13957417   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K311 S32K312 S32K314 S32K322 S32K324 S32K341 S32K342 S32K344 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.       Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (v3.0.0 CD04) – only for S32K311, S32K358 and S32K396 New S32 Configuration Tools version supported (v1.6) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.31: All functions in the Automotive Math and Motor Control Functions Library v1.1.31 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 115 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.3.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience This release (1.3.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt