1 Table of Contents •Introduction •Overview •Context •References •Conclusion 2 Introduction This article walks through the complete process of setting up the NXP Model-Based Design Toolbox (MBDT) and running a first application on NXP hardware. Before starting the installation, make sure that the prerequisite toolboxes are available in MATLAB. By the end of this guide, the reader will have a fully functional MBDT environment and will have successfully generated, compiled, and deployed embedded C code from a Simulink model to NXP hardware. 3 Overview This guide begins with the installation prerequisites and required toolboxes, then continues with the MATLAB Add-On Explorer flow for installing NXP_Support_Package_S32K3 . After the support package is installed, the guide explains how to launch the multistep installer, verify the required toolboxes and installation path, download the toolbox package from NXP, and complete the toolbox installation before running the first application. Installation Scope and Workflow This article focuses on practical installation flow required to start working with the NXP Model-Based Design Toolbox and run a first example application. It covers the software prerequisites, the toolbox setup sequence, and the validation steps needed before opening and deploying a model on the target board. The installation content in this guide should use the current multistep installer flow. Target Audience This article is intended for engineers and technical professionals who want to begin developing embedded applications for NXP hardware using a Model-Based Design workflow. The main target audience includes: Embedded software engineers MATLAB / Simulink developers evaluating NXP hardware Control and algorithm engineers Students and academic researchers using NXP evaluation boards Model-Based Design engineers Hardware integration engineers 4 Context 3.1 Prerequisites Before starting the installation, verify that the following prerequisite toolboxes and setup conditions are met: MATLAB installed - Required by the support package and multistep installer flow. Simulink installed - Required for model-based development and Simulink example execution. Embedded Coder installed - Required for embedded C code generation from Simulink models. MATLAB Coder installed - Required by the current S32K3 support package prerequisites. Simulink Coder installed - Required by the current S32K3 support package prerequisites. Embedded Coder Support Package for ARM Cortex-M Processors installed - Required by the installer verification step and target support flow. NXP account - Required to access the NXP download page and retrieve the toolbox package. Short local installation path - The installation path should be local, short, and should not contain whitespace to avoid setup issues. Figure 1 - MATLAB Add-On Manager confirming requirement are installed 3.2 Toolbox Setup NXP's Model-Based Design Toolbox is delivered as a MATLAB Toolbox Package that can be installed offline or online from MathWorks Add-ons. The recommended installation path uses the NXP Support Package, a graphical wizard that guides through download, installation, and license activation in a single workflow. Note: Throughout this guide, the placeholder {platform} refers to the NXP MCU family targeted by the toolbox (for example S32K3 , S32K1 , S32M2 , MPC57XX , etc.). Each family has its own dedicated Support Package and Toolbox in the MATLAB Add-On Explorer. When following the steps below, replace {platform} with the identifier matching the hardware family in use, for instance, for the S32K3 evaluation boards, the script name becomes NXP_Support_Package_s32k3.m and the path command becomes mbd_s32k3_path . Step 1 - Install NXP Support Package from MATLAB Add-On Explorer Install the current NXP support package directly from the MATLAB Add-On Explorer. This package provides the multistep installer flow used to verify prerequisites, download the toolbox, and guide the installation for S32K3. In MATLAB, navigate to Home → Add-Ons → Get Add-Ons. Figure 2 - Open the Add-On Explorer from the MATLAB Home tab Search for NXP_Support_Package_S32K3 in the Add-On Explorer. Figure 3 - Search results for NXP_Support_Package_S32K3 in the Add-On Explorer Open the package page and click Add to start the installation. Figure 4 - Open the NXP_Support_Package_S32K3 page and click Add Review the license agreement for NXP_Support_Package_S32K3 and click I Accept. Figure 5 - License agreement shown during installation of NXP_Support_Package_S32K3 Wait for the installation to complete. When finished, the Getting Started Guide opens automatically. Figure 6 - Support package installation completed successfully In the MATLAB Command Window, run sp_s32k3.nxp.setup(); to launch the multistep installer. sp_s32k3.nxp.setup(); Figure 7 - Run sp_s32k3.nxp.setup(); from the MATLAB Command Window Step 2 - Use the multistep installer to download and install the toolbox The multistep installer guides you through prerequisite verification, toolbox download, installation, activation, and access to the documentation for S32K3. Figure 8 - Welcome page of the S32K3 multistep installer In the installer, continue to the download step. On the NXP website, review the software terms and conditions and click I Agree before downloading the toolbox package. If the product download page does not open automatically, sign in to your NXP account and open the Product Download page for the required S32K3 toolbox release or click the link from Download page of the S32K3 multistep installer. Figure 9 - Download page of the S32K3 multistep installer Figure 10 - Accept the NXP software terms and conditions before downloading Download the toolbox package from the Product Download page. The installer accepts both .zip and .mltbx files. Figure 11 - Product Download page for the S32K3 MBDT package The setup verification step checks whether all required toolboxes are installed in MATLAB and whether the installation path is valid for the S32K3 toolbox setup. If any dependency is missing or an unsupported version is detected, resolve the issue before continuing to the download and installation steps. Figure 12 - Setup verification page showing required toolboxes and installation path checks Important: It is recommended to install MATLAB and the NXP Toolbox into a location that does not contain special characters, empty spaces, or mapped drives. Use a short local path whenever possible. After downloading the package, return to the installer and continue with the local file selection step. Browse to the downloaded archive or toolbox package and click Install to continue. The installer accepts both .zip and .mltbx files. Figure 13 - Browse to and download the S32K3 MBDT package from the Product Download page Figure 14 - Accept the license agreement for NXP_MBDToolbox_S32K3 Accept the toolbox license agreement to allow MATLAB to complete the MBDT installation. Figure 15 - Toolbox installation in progress After the installation is complete, use the Add-On Manager context menu to open the installed toolbox folder if you need to inspect the package contents or access installed files directly. Wait until the installation finishes. The process may take several minutes depending on the system configuration and package size. Figure 16 - Open the installed toolbox location from MATLAB Add-On Manager Step 4 - Set the Path for Toolchain Generation The MBDT uses Simulink's toolchain mechanism to enable automatic code generation with Embedded Coder. When installed as a MATLAB add-on, the toolbox path is configured automatically. If manual configuration is still required in your environment, run the platform path script from the installation directory. If manual setup is required, in MATLAB change the Current Directory to the toolbox installation folder: ..\MATLAB\Add-Ons\Toolboxes\NXP_MBDToolbox_{platform}\ Then run the configuration script: mbd_{platform}_path Figure 17 - Output of the mbd_{platform}_path script in the MATLAB Command Window 3.3 How to Run an Application With the toolbox installed and the compiler configured, the following steps demonstrate how to open, build, and deploy the LED blinky example - the embedded equivalent of Hello World to an NXP evaluation board. Open an Example Model Open MATLAB and start Simulink by typing simulink in the Command Window (or by clicking the Simulink button on the Home tab). In the Simulink Start Page, open the Simulink Library Browser (View → Library Browser, or press Ctrl+Shift+L). In the Library Browser tree, expand NXP Model-Based Design Toolbox for {platform} to confirm that the NXP blocks are available. This validates that the toolbox is properly registered with Simulink. Open the Example Projects tab from the Simulink Start Page, it lists every example shipped with the MBDT, grouped by peripheral (ADC, CAN, DIO, PWM, UART, etc.). Browse the list, select the example matching your hardware (for instance s32k3xx_dio_s32ct for the LED blinky on FRDM-A-S32K312 / FRDM-A-S32K344 ), and click Open to load the model. Figure 18 - MBDT Examples Library available from the Simulink Library Browser Open the example model ( .slx / .mdl file). Configure the Target Hardware Figure 19 - Model Settings  Figure 20 - Code Generation Tip: Example models that ship with the MBDT are pre-configured for a specific evaluation board. Always verify the hardware target matches your physical board before building. Build and Deploy Connect the NXP evaluation board to the PC via USB. In Simulink, open the Hardware tab and click Build, Deploy & Start (or use Ctrl+B). Monitor the MATLAB Diagnostic Viewer for build status messages. Verify on Hardware Confirm that the application runs on the target hardware as expected - for example, observe the LED blinking at the rate defined in the model. If the application produces serial output, open a terminal and verify the expected data on the communication port. Use debugging or monitoring tools to inspect variable values and system signals from the running application in real time. 5 References NXP Model-Based Design Toolbox - Product Page Automotive SW - S32K3 - Model-Based Design Toolbox Model-Based Design Toolbox S32K3xx Quick Start Guide (PDF) MathWorks Embedded Coder     6 Conclusion This article described the complete setup of the NXP Model-Based Design Toolbox: from installation and compiler configuration to building and deploying a first application to NXP hardware. The next article in the series focuses on the Toolbox Workflow, presenting in detail the end-to-end development flow with the MBDT, from configuring a Simulink model with NXP blocks, through code generation with Embedded Coder, to building, deploying and validating the resulting application on NXP hardware.

      1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Virtual vehicles are becoming a common part of modern automotive development, helping teams validate vehicle behavior, driver interaction, and system integration in realistic digital environments before moving to broader physical testing. Figure 1. Virtual vehicle plant model The goal of this first article is to present the virtual vehicle system used in the Hello World demo at a high level and establish the context for the articles that follow. The focus here is on what the subsystem is, why it is relevant in the demo, and how Model-Based Design supports its development within the MathWorks and NXP ecosystem.     3 Overview The importance of this subsystem lies not only in its functional role of simulating the vehicle and linking it to a physical zonal architecture, but also in how it demonstrates an efficient model-based workflow. Rather than building separate assets for vehicle behavior, driver interaction, visualization, and hardware communication, the workflow starts from a configurable virtual vehicle model that can be tested, extended, and connected to other parts of the system. The Virtual Vehicle Composer is a MathWorks tool that enables you to create a Simulink vehicle model for system-level testing, software integration testing, and driver-in-the-loop workflows. The generated model can simulate key vehicle functions such as powertrain, steering, braking, and overall vehicle dynamics. Powertrain Blockset and Vehicle Dynamics Blockset provide reference applications and component models that help define and simulate vehicle behavior in more detail. Simulink 3D Animation supports visualization and interaction with 3D environments, helping connect the vehicle model to a more realistic driving experience. This accelerates development in several ways: The vehicle can be configured and built from a structured workflow rather than assembled manually from scratch. The same model can support simulation, software integration, and connection to external hardware. The built-in 3D interface with Unreal Engine helps connect the vehicle behavior to a realistic visual environment. RoadRunner scenes and scenarios can be incorporated into the simulation workflow to create interactive driving scenarios. CAN communication and feedback from the physical setup can be integrated into the Simulink-based system model. The same workflow can be extended to support additional sensing paths, such as radar data generation and off-board processing on NXP radar hardware. This series is intended for: Engineers learning Model-Based Design with MATLAB and Simulink Developers working with NXP automotive processors and microcontrollers Teams building virtual validation and hardware-connected automotive demonstrations Engineers interested in Driver-in-the-Loop workflows Students and researchers studying vehicle architectures, simulation, and embedded integration Anyone interested in a reproducible example of simulation-to-hardware integration using MathWorks tools and NXP platforms Readers will gain a clearer, step-by-step understanding of how a virtual vehicle can be created, integrated into a 3D driving scene, connected to a physical zonal platform, and used as part of a broader model-based development workflow.     4 Context Created with the Virtual Vehicle Composer, the Simulink hybrid electric vehicle (HEV) model is used not only for standalone simulation, but is reused as the common integration point for driver inputs, RoadRunner-based scene interaction, including actor scenarios implemented in RoadRunner, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. Figure 2. Virtual vehicle system model In the implemented setup, a driver controls the virtual vehicle through an Xbox-compatible steering wheel and pedals. These inputs are processed by the Simulink model, which updates the vehicle behavior inside a RoadRunner scene rendered through Unreal Engine. At the same time, the virtual vehicle sends key signals such as speed, steering, braking, turn indicators, hazard lights, and beam light commands over CAN to a physical setup that represents an electric vehicle built from multiple NXP reference boards organized in a zonal architecture. The physical platform includes a main node, zonal nodes, and multiple end nodes. These elements receive the simulation-driven commands and reproduce the state of the virtual vehicle in hardware. Communication is bidirectional, so feedback generated by the physical setup can also influence the simulated vehicle. For example, if front or rear parking sensors detect an obstacle, that information can be returned to the virtual vehicle model and used to trigger braking behavior. All major functional aspects of this interaction, including driver input handling, vehicle behavior, signal exchange, and feedback response, are defined in the Simulink model. This supports rapid refinement and validation before deeper integration into the full system. An additional part of the setup extends the virtual vehicle interaction toward sensing and perception workflows. Actor poses from the virtual scene are used to generate a radar cube, which is sent to an NXP S32R45 board that runs a radar processing chain. This expands the role of the virtual vehicle beyond motion and body-domain interaction. It shows how the simulated environment can also stimulate external sensing functions and hardware processing paths as part of the same demo workflow. Figure 3. Virtual Vehicle highlighted within the demo The virtual vehicle component is highlighted in the architecture diagram from Figure 3 to show its position in the overall project setup and its connection to the driver interface, the 3D environment, the physical zonal platform, and the radar processing path. The next articles in the series will build on this system overview and examine the virtual vehicle in more detail, including the software and hardware environment, the model architecture, the vehicle creation workflow, the driver input options, RoadRunner and Unreal integration, CAN communication, and the final results and challenges observed during development.     5 References The following resources provide useful background for the technologies referenced in this article: MathWorks documentation for Virtual Vehicle Composer MathWorks virtual vehicle documentation and examples MathWorks RoadRunner documentation MathWorks documentation for Unreal Engine simulation with Simulink NXP Model-Based Design Toolbox overview     6 Conclusion The virtual vehicle subsystem provides the foundation for the Hello World demo by supplying a reusable vehicle model that supports simulation, validation, and integration within a model-based workflow. This article established its purpose and position in the overall architecture. In the next articles, we will move from this high-level overview to the practical details of how the subsystem is created, connected, and exercised in the complete demo.

  1 Introduction Radar (Radio Detection and Ranging) is a key sensing technology in modern vehicles, used to perceive the environment by transmitting radio waves and analyzing their reflections from surrounding objects. In automotive systems, radar enables reliable detection under a wide range of weather and lighting conditions. This article introduces the automotive radar node of our demo and explains how it can be integrated into a modern vehicle electronic architecture.   2 Table of Contents •Introduction •Overview •Context •References •Conclusion   3 Overview How radar supports automotive systems Within an automotive system, the radar node plays a central role in advanced driver assistance systems (ADAS) and automated driving functions, such as adaptive cruise control, collision avoidance, and blind-spot detection. It continuously measures object presence and motion in the vehicle’s surroundings, providing robust and real-time perception data. In this implementation, the radar application is developed using NXP’s Model-Based Design Toolbox for Radar, a MATLAB add-on developed by NXP. By using this toolbox, developers can design, simulate, and generate code while leveraging the hardware accelerators available on the target platform to achieve high performance and deterministic execution. The offloading of processing to the accelerators is achieved through the integration of the NXP Radar SDK within the MATLAB environment. Target Audience This series of articles serves a wide range of engineering and technical stakeholders involved in the design, development, and integration of radar systems. This chapter outlines the intended audience: Embedded Software Engineers Radar Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and MATLAB Developers Academic and Research Communities   4 Context The radar application is targeted for the NXP S32R45 MCU, a high-performance processor designed specifically for automotive radar signal processing. In the vehicle electronic architecture, the radar node is connected directly to the Central Node, which is responsible for sensor fusion and higher-level decision-making. For each radar frame, the NXP S32R45 MCU detects and processes objects in the field of view and transmits, via CAN, the distance, speed, and direction of each detected object to the Central Node. This structured data exchange enables efficient integration of radar information into the overall vehicle perception and control system.   Figure 1. Example integration of the radar node into a vehicle electronic architecture.   5 References MathWorks Model-Based Design Toolbox for RADAR Community Accelerate the Discrete Fourier Transform with NXP SPT   6 Conclusion In conclusion, the radar node is a fundamental building block of the modern vehicle electronic architecture, providing accurate and reliable perception data that enables advanced safety and automation functions. This introductory chapter has outlined the role of the radar node within the vehicle system and its contribution to environment perception for advanced driving functions. The next chapters will build on this foundation by exploring the radar signal processing chain, the implementation approach, and the main software components that enable the application on the target platform.

    1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Automotive lighting systems play an essential role in vehicle safety, visibility, and communication with other road users. In general, these systems can be grouped into two main categories: Front Lighting and Rear Lighting. Both help provide road illumination for the driver and signal the vehicle's actions and presence to surrounding traffic. Front Lights - General Role and Functions Front lighting improves the driver's visibility in different driving conditions, including low light, nighttime driving, and adverse weather. It includes several key functions commonly found in modern vehicles, such as: Daytime Running Lights (DRL) - increase vehicle visibility during daytime driving Turn Lights - indicate the driver's intention to change direction Head Lights - provide road illumination during nighttime or low-light conditions Fog Lights - improve visibility in fog, rain, snow, or other low-visibility situations Rear Lights - General Role and Functions Rear lighting is primarily used to communicate the vehicle's status and intentions to other road users. It includes important functions such as: Stop Lights - signal braking actions Head Lights - make the vehicle visible from behind Turn Lights - indicate the intended direction of travel Fog Lights - improve vehicle visibility in low-visibility conditions     3 Overview The lighting system presented in this article is developed using a Model-Based Design (MBD) approach. This methodology enables early validation of system behavior, systematic refinement of the control logic, and a direct path from simulation to embedded implementation. The control behavior is modeled in MATLAB/Simulink, where the functionality is structured into modular and reusable components. Stateflow is used to describe the control logic, providing a clear and formal representation of operating modes, state transitions, and event-driven behavior. The Simulink model runs on the NXP S32K3 platform and communicates with other vehicle nodes via CAN Bus. Message reception and signal handling are managed using the Vehicle Network Toolbox, which simplifies CAN communication by utilizing DBC files without introducing additional hand-written interface code. This integration supports a smooth transition from simulation to embedded deployment through automatic code generation, minimizing the risk of discrepancies between modeled behavior and deployed software. Target audience: Engineers interested in Model-Based Design for automotive applications Those learning or experimenting with simulation-based development and control logic Anyone using NXP automotive hardware platforms who wants to faster develop complex applications on real embedded systems Figure 2 - Front Hazard Lights Activated     4 Context In this project, separate models are implemented for front and rear lighting to showcase the physical layout of the car and keep the logic simple and easier to test. Each lighting area handles its own functions, while staying synchronized with overall vehicle behavior through standard vehicle communication.   Figure 1 - Front and Rear Lights System highlighted within the EV architecture All lighting commands are received via the CAN bus, ensuring consistent and predictable behavior for functions such as Daytime Running Lights (DRL), Head Lights, Fog Lights, Turn Indicators, and Stop Lights. Using CAN-based commands reflects standard vehicle communication practices and allows the lighting logic to be evaluated under conditions close to those in a production system. Incoming CAN messages are processed by the lighting module. Based on vehicle states and received commands, the module: interprets CAN signals and system status, prioritizes lighting functions and handles fault-related conditions, turns on the lights. This structure keeps responsibilities clear: the CAN layer provides high-level commands, while the lighting control logic handles decision-making and execution. The result is a deterministic and easy-to-follow path from vehicle-level inputs to visible lighting behavior. In our project, the system uses addressable LEDs, allowing individual control of multiple light segments within each lamp. This enables a realistic representation of modern automotive lighting systems, where lighting units are no longer simple on/off devices but consist of multiple independently controlled segments. Addressable LEDs rely on a dedicated communication protocol to transfer control data such as color, brightness, and activation timing to each individual LED element. To simplify the integration of this protocol and ensure deterministic behavior, the LED communication was configured and integrated using NXP's Model-Based Design workflow. This approach allows the LED control logic and communication timing to be defined, simulated, and validated directly at model level. The system behavior can be easily followed from input to output, since each step is clearly defined. CAN messages trigger specific actions, and the result is directly visible in the LEDs. This makes the logic straightforward to understand and verify.     5 References Model-Based Design Toolbox (MBDT) Community Model-Based Design Toolbox (MBDT) - S32K3 - How To     6 Conclusion This article provides a simple overview of how Model-Based Design can be applied to develop an automotive lighting system using NXP hardware, focusing on the general architecture and design approach. In the following articles, we will explain the configuration, implementation, and deployment of the lighting system on the NXP hardware.

1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction The steering system is an essential and safety-critical component of any vehicle, responsible for controlling the direction of wheel movement and guiding the vehicle along the intended path. In our Hello World with MBDT project, the Steering subsystem delivers this capability by driving a steering motor to a desired angle and direction, transmitting the resulting torque to the road wheels through the steering column and rack-and-pinion assembly. Figure 1. Hello World with MBDT Demo – Steering system This article series presents the Electric Power Steering (EPS) system in Electric Vehicle (EV) architecture and covers the hardware, software, code generation, and vehicle network integration needed to implement the system using a Model-Based Design (MBD) workflow with MathWorks tools and NXP hardware. 3 Overview 2.1. What will this series of articles cover? The articles in this series will present the Steering System within an EV architecture and cover the following topics: Software and Hardware Environment Overview of the MathWorks and NXP tools used to develop, test, and validate the EPS control system. Logic Control Description of the model architecture, signal interfaces, and core control algorithms implemented in the Steering System. Deployment on Real Hardware Integration with physical hardware, the stepper motor, 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. System Validation Presentation of the final implementation results and validation of the complete system behavior. 2.2. What is the Electric Power Steering System? Electric Power Steering (EPS) eliminates the hydraulic pump found in conventional steering systems, instead relying on an electric motor driven by an Electronic Control Unit (ECU). Torque and position sensors mounted on the steering column feed real-time measurements to the ECU, which computes the required assist level and commands the motor accordingly. This on-demand assist approach improves energy efficiency, enables precise tuning of steering feel, and provides a programmable interface for Advanced Driver Assistance Systems (ADAS). Figure 2. Electric Steering Rack and Pinion EPS systems are classified based on where the electric motor is mounted on the steering mechanism. Column Assist Type (C-EPS) - The electric motor and control unit are mounted directly on the steering column inside the cabin. Pinion Assist Type (P-EPS) - The electric motor is attached to the pinion shaft within the steering gear box. Dual-Pinion Assist Type (DP-EPS) - This system separates the assist function from the steering mechanism. One pinion gear connects the steering wheel, while the electric motor applies assistance to a second, separate pinion gear directly on the steering rack. Rack Assist Type (R-EPS) - The electric motor is mounted directly onto the main steering rack, either via a concentric motor around the rack or a belt drive. Steer-by-Wire (SbW) - The mechanical connection (steering column and intermediate shaft) between the steering wheel and the wheels is entirely removed. Key Characteristics of Steer-by-Wire EPS: The wheel's movement is handled completely by electronic sensors, algorithms, and actuators It allows for completely customizable steering ratios Frees up interior cabin space Relies heavily on redundant electronics and fail-safes 2.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric power steering systems, including the following audiences: Mechanical and Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the example vehicle architecture used throughout this series, the Steering System is located in the front zone of the vehicle. The Steering ECU is built around the NXP S32K312 microcontroller, which provides both CAN and LIN connectivity. Note: The NXP S32K312 microcontroller provides the processing performance, peripheral set, and communication interfaces (CAN, LIN) required for automotive steering control applications. The ECU drives the stepper motor to the commanded position and communicates desired angle and direction requests over CAN to the Zonal Controller, which coordinates these signals with the central vehicle control node. 5 References Steering column - Wikipedia Power steering - Wikipedia Electric Power Steering (EPS) System Parts Solutions | NXP Semiconductors Electric power steering system (EPS) Clemson Vehicular Electronics Laboratory: Electric Power-Assisted Steering Electric Steering Rack and Pinion 6 Conclusion This article introduced the Electric Power Steering system architecture, its core components, and its position within a modern EV platform. It outlined the Model-Based Design approach using MATLAB/Simulink and NXP hardware as the development foundation, from algorithm modeling through automatic code generation and hardware deployment. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the EPS control system using MathWorks and NXP solutions.

      1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction This article series explains the role and behavior of a zonal controller communication component in a modern automotive electrical/electronic (E/E) architecture. This first article provides a short, high-level introduction to the zonal node and establishes a common understanding of its main responsibilities. The series gradually explains how this component enables message exchange between in-vehicle communication networks, with a particular focus on routed and broadcast communication over CAN and LIN. Later articles move from these concepts into more detailed design and implementation topics. As the entry point to the Zonal Communication and Control series, this article focuses on the zonal node from an architectural perspective. It does not cover system-level use cases or application-specific configurations, which are addressed in later articles.     3 Overview This article introduces an S32K3-based zonal node and explains how it connects to several in-vehicle networks. In practice, the zonal node sits between central vehicle controllers and local devices such as sensors, actuators, or small control modules, helping messages move between them. The zonal node receives messages from the central controller and forwards them to local nodes, while also sending status information and responses back to the central side. Depending on the system design, it can distribute the same message to multiple nodes or route specific messages only to the intended recipients. In addition to message forwarding, the zonal node may perform limited local processing, such as message filtering, signal aggregation, data validation, or basic decision-making related to communication handling. However, higher-level functional decisions are typically managed by central controllers, with the zonal node focusing primarily on efficient and reliable data exchange. This role becomes clearer in the context of evolving automotive E/E architectures. Traditional designs relied on many purpose-specific electronic control units (ECUs) connected through dedicated wiring. As system complexity increased, that approach added wiring weight, raised cost, and limited scalability. Figure 1. Zonal controller highlighted within the EV architecture Zonal architectures address these limitations by grouping nearby functions within the same physical area of the vehicle and moving more processing into central computing units. In this model, the zonal controller manages local communication and forwards relevant information to the central system. In this context, the S32K3 MCU family supports the required functionality by providing automotive communication interfaces such as CAN FD and LIN. On devices that include the necessary interfaces, the zonal node can connect different network types and handle message traffic between them. Within the scope of this project, the S32K3 platform is suitable for implementing the zonal node due to its available communication peripherals, processing capability, and automotive safety features, which are sufficient for the number of connected nodes and the complexity of the communication tasks considered. This article is intended for: System architects evaluating zonal or domain-based vehicle designs Embedded software engineers implementing communication routing logic Engineers evaluating MCU platforms for multi-network automotive applications By reading this series, you will understand why zonal communication components matter, how they fit into modern vehicle architectures, and how the S32K3 platform can support this role.     4 Context In a complete vehicle system, the zonal node sits between the central control system and local hardware. Its main job is to pass, route, or translate messages, not to make application-level decisions. Keeping these roles separate helps the system remain predictable, reliable, and easier to scale. The zonal node may receive messages from central controllers that manage vehicle-wide functions or from local devices such as sensors, actuators, and smaller control modules. It then exchanges this information across different networks in a controlled and time-aware way. Note: CAN and LIN remain important because they are widely used in automotive systems and are well suited to many control tasks. The S32K3 family supports these needs with integrated CAN FD and LIN interfaces and Arm® Cortex®-M7 CPU cores for routing and control tasks. It also includes automotive safety features aligned with ISO 26262 and low-power modes that are useful in some system designs. Together, these features allow the zonal node to handle several communication channels at the same time while keeping the network interfaces clearly separated. High-Level Architecture Diagram Figure 2. Diagram concept for S32K3 Zonal Node Figure 2 shows where the zonal node sits in the system: between the central control side and the local edge nodes, acting as the bridge between networks. Later articles will expand this context in a structured way. The series will first present the overall system, then describe the software and hardware environment that supports the zonal node. It will also cover internal control logic and key communication topics such as CAN-to-CAN routing, LIN-to-CAN routing, and Ethernet-to-CAN communication. Finally, it will discuss common challenges in multi-network routing and zonal integration.     5 References NXP Body Domain and Zonal Controller S32K3 for Zonal Aggregator     6 Conclusion This article provided a high-level introduction to the S32K3-based zonal node as a communication component in modern automotive architectures. It explained what the node does and where it fits in the system, creating a basis for the more detailed topics covered later in the series. Instead of focusing on implementation details, this introductory article explained why zonal nodes are needed and which problems they help address. The next articles in the series will build on this foundation by exploring system structure, configuration, communication routing strategies, and design challenges in greater detail.

    Table of Contents Why embedded development needs a better workflow What Model-Based Design is A simple mental model: from idea to executable model to hardware Why engineers use it: the core advantages Verification along the way: MIL, SIL, PIL, HIL How NXP enables this with Model-Based Design Toolbox (MBDT) What comes next in this article series     1 Why embedded development needs a better workflow Modern embedded systems are no longer isolated functions running on a single controller. In today's vehicles and intelligent machines, applications span sensing, communication, control, safety logic, diagnostics, and multiple processing nodes that must work together as one system. As this complexity grows, traditional workflows based mainly on handwritten code and late-stage hardware testing become difficult to scale, hard to validate early in the development cycle, and slow to iterate. Issues are often discovered late, when integration becomes more costly and harder to manage. Model-Based Design offers an alternative approach designed to address these challenges. It enables earlier validation and a more structured development flow, where verification is not an afterthought, but part of every stage of development.     2 What Model-Based Design is   Model-Based Design is a visual way of programming, where you build your functionality by drawing an engineering diagram, and that diagram can be executed—either as a simulation on your computer or as code running on real hardware. In this approach, models become the central engineering artifact used to design, simulate, verify, and deploy embedded systems. Instead of starting from low-level implementation details, engineers create an executable model of the application behavior, simulate, verify, refine it, and then generate code for the target system. This model-centric workflow makes designs easier to understand, easier to reuse, and less prone to errors. It also enables model-based testing, where test cases can be derived directly from system models and used to verify behavior early in development.     3 A simple mental model: from idea to executable model to hardware A simple way to think about Model-Based Design is this: you describe what the system should do in an executable model, validate that behavior in simulation, and then carry the same design through to the final implementation. In this approach, the model is not just documentation—it becomes an active engineering asset used for design, simulation, verification, and code generation. This creates a direct path from idea to application, where requirements, design, prototyping, testing, and deployment are connected in one continuous workflow.     4 Why engineers use it: the core advantages One of the biggest advantages of Model-Based Design is that it changes where engineering effort is spent. Instead of focusing primarily on how to implement functionality at a low level, engineers can focus on what the system should do—its behavior, control strategy, and response to real-world scenarios. This approach also enables early validation. System behavior can be simulated on a PC before the final hardware is available, allowing issues to be detected earlier and reducing costly rework late in the development cycle. In addition, Model-Based Design enables hardware-independent simulation, where algorithms can be developed and validated before being tied to a specific target platform. This allows teams to explore designs faster and reuse validated functionality across different hardware solutions. As a result, teams benefit from: faster iteration during development improved traceability between design and implementation reduced integration risk more consistent validation across development stages Ultimately, this contributes directly to faster time-to-market, as development cycles are shortened and fewer late-stage issues need to be addressed. Some concrete examples can be found in the following articles: From Virtual Vehicle to All-Electric Off-Road UTV in Less Than a Year Dyson Accelerates New Product Development with System-Level Simulation     5 Verification along the way: MIL, SIL, PIL, HIL A key strength of Model-Based Design is that validation happens continuously throughout development. This is typically organized into several stages: Model-in-the-Loop (MIL): the model is tested against a simulated environment Software-in-the-Loop (SIL): generated code is executed on the host PC and compared to model behavior Processor-in-the-Loop (PIL): code runs on the target MCU to verify functional correctness and performance Hardware-in-the-Loop (HIL): the controller is tested against a real-time or emulated system before final deployment These stages provide a structured validation path, ensuring that issues are detected early and confidence is built progressively before running on final hardware. Model-Based Design also supports reuse and scalability. A validated model can be adapted, parameterized, or reused across multiple systems, reducing development effort and improving consistency.     6 How NXP enables this with Model-Based Design Toolbox (MBDT) To make this workflow practical on real embedded hardware, NXP provides the Model-Based Design Toolbox (or MBDT). This acts as a bridge between the MathWorks' and NXP's software ecosystems, and allows the entire workflow to be done from one environment, as depicted in the diagram above. Concretely, this allows engineers to use MATLAB and Simulink to design, simulate, verify, and automatically generate code that can run directly on NXP microcontrollers and processors. MBDT provides: block libraries for hardware access integration with configuration tools for pins, clocks, and peripherals support for PIL workflows code generation and deployment capabilities profiling and runtime monitoring through tools like FreeMASTER This creates a complete end-to-end flow—from model to validated application running on target hardware. Engineers can explore functionality at a high level, validate behavior through simulation, and deploy with confidence onto real systems.     7 What comes next in this article series In the articles that follow, we will move from this general introduction to concrete, real application examples. We will show how Model-Based Design and NXP tools can be applied across a modern system architecture, covering applications such as battery management, motor control, radar, steering, lighting, and parking sensors. Each example will illustrate how functions can be designed, validated in simulation, and deployed onto the appropriate hardware nodes. The key idea is simple: Model-Based Design helps engineers focus on system behavior while reducing the gap between concept, implementation, and validation. With NXP's Model-Based Design Toolbox, this approach can be carried from the modeling environment all the way to a running application on hardware. MBDT  https://www.nxp.com/mbdt https://mathworks.com/nxp 

  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 Processing Chain - NXP Radar SDK 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)  Processor-in-the-Loop (PIL) 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.

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

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.7.1     The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3 version 1.7.1. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART), and support for the GD3162 Gate Driver based on the S32K396 GD3162 Software. In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 180 examples, covering all the features and functionalities of the toolbox, including new demos for GD3162 Gate Driver applications.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=7846241   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GD3162 GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (6.0.0)   Integrates S32K396 GD3162 v2.0.2 The toolbox enables access to the GD3162 gate driver for S32K396 derivatives from Simulink models, by delivering a library block (Gd3162) that generates code on top of GD3162 components API.   New S32 Configuration Tools version supported (2024.R1.8)😎   Integration with EB tresos v29.0.0   Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB tresos to configure peripherals/pins/clocks   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom project template, it can be used for every model that is being developed.   Such custom projects, addressing specific hardware designs are offered inside the current version of the toolbox to integrate the following EVBs: MCTPTX1AK324 S32K344-WB S32K396-BGA-DC1 MR-CANHUBK344, alongside a set of examples specifically created to target this hardware design and a series of articles (available on NXP Community) demonstrating how to use the toolbox features and functionalities for creating applications for custom boards.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     XS32K3X2CVB-Q172     XS32K3X4EVB-Q257     XS32K3XXEVB-Q172     MR-CANHUBK344             S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289             XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.42 All functions in the Automotive Math and Motor Control Functions Library v1.1.42 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications. S32 Design Studio integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Simulation modes We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) including AUTOSAR SW-C deployment External mode   GD3162 Applications The toolbox provides examples for configuring and accessing the external GD3162 gate driver device via SPI communication to demonstrate Dynamic Gate Strength and DC Link Discharge features, supporting both S32 Configuration Tools and EB tresos. Each of them has a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The examples provided in this release include the following topics: - GD3162 Dynamic Gate Strength - GD3162 DC Link Discharge   Motor Control Applications The toolbox provides examples for 1-shunt and 2-shunt PMSM and BLDC motor control applications, supporting both S32 Configuration Tools and EB  tresos. Each of the examples provides a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The toolbox also demonstrates the integration of the Motor Control Blockset in developing such applications.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b R2025a R2025b   Examples for every peripheral/function supported More than 180 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling GD3162 Gate Driver applications (DC Link Discharge and Dynamic Gate Strength) Motor Control applications (BLDC and PMSM) AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.7.1 is fully integrated with MATLAB® environment.   Target Audience: This release (1.7.1) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

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

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

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

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

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.8.0     The Analog & Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3 version 1.8.0. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K356, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K389, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART). In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 130 examples, covering all the features and functionalities of the toolbox, including new demos for motor control applications.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=7690521   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K356 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388 S32K389 S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (7.0.0)   New S32 Configuration Tools version supported (2025.R1.8)😎   Integration with EB tresos v32.0.0   Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB tresos to configure peripherals/pins/clocks   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom project template, it can be used for every model that is being developed.   Such custom projects, addressing specific hardware designs are offered inside the current version of the toolbox to integrate the following EVBs: S32K312MINI-EVB MCTPTX1AK324 S32K344-WB S32K3-T-BOX S32K396-BGA-DC1 MR-CANHUBK344, alongside a set of examples specifically created to target this hardware design and a series of articles (available on NXP Community) demonstrating how to use the toolbox features and functionalities for creating applications for custom boards.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     S32K312MINI-EVB     MCTPTX1AK324     XS32K3X2CVB-Q172     S32K3-T-BOX     MR-CANHUBK344       XS32K3X4EVB-Q257     XS32K3X4EVB-Q172           S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289      S32K389EVB-Q437            XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.42 All functions in the Automotive Math and Motor Control Functions Library v1.1.42 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   S32 Design Studio integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Simulation modes We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) including AUTOSAR SW-C deployment External mode   Motor Control Applications The toolbox provides examples for 1-shunt and 2-shunt PMSM and BLDC motor control applications, supporting both S32 Configuration Tools and EB  tresos. Each of the examples provides a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The toolbox also demonstrates the integration of the Motor Control Blockset in developing such applications.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2023b R2024a R2024b R2025a R2025b   Examples for every peripheral/function supported More than 130 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling Motor Control applications (BLDC and PMSM) AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and User Manual documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.8.0 is fully integrated with MATLAB® environment.   Target Audience: This release (1.8.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32ZE – version 1.4.0     The Analog & Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32Z/E version 1.4.0. This release supports automatic code generation from MATLAB and Simulink for NXP S32Z/E Automotive Real-Time Processors. This new release supports S32Z2/E2 families and its cores (Real-Time ARM Cortex-R52 cores and DSP/ML processor). It also supports Multicore, 41 Mathematical Operators highly optimized for DSP/ML processor, Processor-in-Loop Simulation mode, RTD components (ADC, PWM, DIO, CAN, UART, GPT, SPI, Application Extension), FreeMASTER, AMMCLib, and execution profiling. The product comes with 40 examples, covering DSP/ML Operators and demonstrating the usage of the peripherals (e.g.: I/O control, timers and scheduling, communication) and multicore concurrent execution.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=7702701   Technical Support: NXP Model-Based Design Toolbox for S32ZE issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: The newly added features are highlighted with bold. Automatic C code generation from MATLAB® for NXP S32Z2/E2 packages: S32E2xx-bga975 S32Z2xx-bga594 S32Z2xx-bga400 GreenBox 3 The toolbox has been tested and validated on the official NXP Evaluation Boards S32E27X-DC S32Z27X-DC GreenBox 3 Rev. B Only S32Z2/E2 chips with DSP/ML option B can use the SPF2 core and associated software Support for the following peripheral components and functions: Application Extension (AE) for S32E: FlexPWM, eTimer, SAR ADC, CTU SPI ADC PWM DIO CAN UART GPT  Multicore support using Concurrent Execution from Simulink Multicore support using Simulink Reference Configurations New Hybrid-Electrical Vehicle (HEV) Example with Virtual Vehicle Composer (VVC) Tool from MathWorks New RTD version supported (2.0.1) New SPF2CE version supported (1.0.0) New AMMCLib version supported (1.1.41) New SPF2 Libraries (MATLAB) version supported (20.4.8) New FreeMASTER Driver version supported (1.4.2) Integration with EB tresos v29.0.0 Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB tresos to configure peripherals/pins/clocks Default Configuration Project Templates targeting all the supported derivatives     Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom project template, it can be used for every model that is being developed. Integrates the Automotive Math and Motor Control Library release 1.1.41 All functions in the Automotive Math and Motor Control Functions Library v1.1.41 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   S32 Design Studio integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Simulation modes We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL)   Multicore support using Concurrent Execution from Simulink     HEV Example using Virtual Vehicle Composer   Support for MATLAB versions We added support for the following MATLAB versions: R2023a R2023b R2024a R2024b R2025a R2025b   More than 40 examples , covering all the peripheral/function supported I/O Control Application Extension (AE) for motor control applications Timers and scheduling Communication (CAN, SPI, UART) Memory handling DSP/ML processor AMMCLib FreeMASTER SIL / PIL Multicore For more details, features, and how to use the new functionalities, please refer to the Release Notes and User Manual documents attached.   MATLAB® Integration:  The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32Z/E Real-Time Processors and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32ZE version 1.4.0 is fully integrated with MATLAB® environment.       Target Audience: This release (1.4.0) is intended for technology demonstration, evaluation purposes, and prototyping S32Z/E Real-Time Processors and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Analog & Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3 – version 1.7.0     The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3 version 1.7.0. This release supports automatic code generation for S32K3 peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3 Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358, S32K364, S32K366, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs, and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, FEE, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART), and support for the GD3162 Gate Driver based on the S32K396 GD3162 Software. In this release, we have also updated the RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 180 examples, covering all the features and functionalities of the toolbox, including new demos for motor control applications.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=7608021   Technical Support: NXP Model-Based Design Toolbox for S32K3 issues will be tracked through the NXP Model-Based Design Tools Community space.   Release Content: Automatic C code generation from MATLAB® for NXP S32K3 derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K364 S32K366 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripheral components and functions: ADC CAN DIO eTPU FEE GD3162 GPT I2C ICU LIN MCL (including DMA support) MEM Memory read/write PWM Profiler Registers read/write SPI UART   New RTD version supported (6.0.0)   Integrates S32K396 GD3162 v2.0.2 The toolbox enables access to the GD3162 gate driver for S32K396 derivatives from Simulink models, by delivering a library block (Gd3162) that generates code on top of GD3162 components API.   New S32 Configuration Tools version supported (2024.R1.8)😎   Integration with EB tresos v29.0.0   Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB tresos to configure peripherals/pins/clocks   Default Configuration Project Templates targeting all the supported S32K3 derivatives The toolbox delivers default configuration projects, available in both S32 Configuration Tools and EB tresos, covering an initial enablement of the on-board peripherals, pins, and clocks, for all the supported S32K3 derivatives. The desired template, which represents the starting point for enabling the hardware configuration of the application, can be selected via a dropdown widget.   Support for creating and using Custom Project Templates The toolbox provides support to use and create custom project templates. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom project template, it can be used for every model that is being developed.   Such custom projects, addressing specific hardware designs are offered inside the current version of the toolbox to integrate the following EVBs: MCTPTX1AK324 S32K344-WB S32K396-BGA-DC1 MR-CANHUBK344, alongside a set of examples specifically created to target this hardware design and a series of articles (available on NXP Community) demonstrating how to use the toolbox features and functionalities for creating applications for custom boards.   The toolbox has been tested and validated on the official NXP Evaluation Boards     S32K31XEVB-Q100     S32K312EVB-Q172     XS32K3X2CVB-Q172     XS32K3X4EVB-Q257     XS32K3XXEVB-Q172     MR-CANHUBK344             S32K3X4EVB-T172      S32K344-WB        XS32K3X8CVB-Q172     S32K388EVB-Q289             XS32K396-BGA-DC     XS32K396-BGA-DC1   Integrates the Automotive Math and Motor Control Library release 1.1.41 All functions in the Automotive Math and Motor Control Functions Library v1.1.41 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   S32 Design Studio integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Simulation modes We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) including AUTOSAR SW-C deployment External mode   GD3162 Applications To demonstrate the integration and support of the GD3162 gate driver IC, we have included a reference Simulink application that configures six GD3162 devices in   a daisy-chain topology using SPI communication. The setup enables sequential initialization, configuration, and status monitoring of each GD3162 device using the S32K396 as a controller MCU.   Motor Control Applications The toolbox provides examples for 1-shunt and 2-shunt PMSM and BLDC motor control applications, supporting both S32 Configuration Tools and EB  tresos. Each of the examples provides a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The toolbox also demonstrates the integration of the Motor Control Blockset in developing such applications.   For demonstrating the S32K3 eTPU Software integration, we have included a PMSM application where the FOC algorithm runs on the main CPU of the S32K396 MCU, while the analog sensing, software resolver, and PWM signals generation are offloaded to the eTPU co-processor.   The motor control applications were developed and validated on the MCSPTE1AK344 and MCSPTR2AK396 Motor Control kits.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a R2024b R2025a   Examples for every peripheral/function supported More than 180 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Memory handling Motor Control applications (BLDC and PMSM) AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3 MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for S32K3 version 1.7.0 is fully integrated with MATLAB® environment.   Target Audience: This release (1.7.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt