1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion   2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail.   3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target.   Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application.   4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface.   Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces.   Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100   Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization   5 References Developing a Parking Sensor System with Model-Based Design Toolbox 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 NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool   6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.

    1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion     2 Introduction This article belongs to the Front and Rear Lights series and describes the software and hardware environment used throughout the project. Before looking into signal routing, control logic, or integration aspects, it is important to first understand the tools and platforms that support the development and execution of the front and rear lights application. This article introduces the software components used to develop, configure, and deploy the application, together with the hardware platforms used to demonstrate the lighting functionality. This information provides the foundation needed for the remaining articles in the series. Model-Based Design sits at the center of the workflow. MathWorks tools handle the modeling of the front and rear lighting control logic, the definition of the CAN communication interfaces, and validation across simulation stages. NXP tools then deploy those models to the S32K3 target platform, wiring the generated application to real-time peripherals, LED driver hardware, and lighting feedback signals.     3 Required Software 3.1. Vehicle Network Toolbox Within this workflow, Vehicle Network Toolbox plays a central role in defining, simulating, and validating the CAN interfaces of the front and rear lights module. It brings DBC-driven message definitions directly into Simulink, allowing communication behavior to be tested alongside the control logic long before integration. Every command received from the central controller and every status message sent back to the network is modeled using the exact structure defined in the DBC files, keeping the application perfectly aligned with the vehicle-level specification. Vehicle Network Toolbox is available as an add-on in MATLAB/Simulink, adding support for CAN communication and DBC-based message definitions.     Figure 1 - Vehicle Network Toolbox 3.2. Stateflow Stateflow is used to model the control logic of both lighting modules, translating the CAN commands received from the central controller into concrete lighting actions. Each function is represented as a state machine, where transitions are triggered by incoming signals and internal conditions. This approach keeps the logic structured and readable: activation, deactivation, mode switching, and fault handling are all captured in the same diagram. Stateflow is available as an add-on that can be installed directly from within MATLAB/Simulink, extending the environment with state machine modeling capabilities.   Figure 2 - Stateflow 3.3. NXP Model-Based Design Toolbox for S32K3 NXP Model-Based Design Toolbox for S32K3 is the link between the Simulink model and the S32K3 microcontroller. It takes care of generating the code, building it, and running it on the target, turning the lighting model into a real embedded application. Through its peripheral blocks, the model can directly use the resources needed by the front and rear lights modules, such as DIO, CAN, and UART without leaving the Simulink environment. It also connects to the NXP configuration tools and supports FreeMASTER for real-time monitoring, which makes it easy to check how the lighting logic actually behaves on the hardware.   Figure 3 - Development flow diagram     4 Required Hardware 4.1. FRDM Automotive S32K312 Development Board (FRDM-A-S32K312) The front and rear lights application runs on the FRDM Automotive S32K312 Development Board, a development platform based on the NXP S32K312 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the lighting application and exchange messages with the central controller through the CAN network. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating body electronics use cases and lighting control scenarios.   Figure 4 - FRDM Automotive S32K312 Development Board 4.2. CAN analyzer Emulates the central controller when the node is not yet integrated with the full system. It injects the CAN commands defined in the DBC files (turn signals, headlight modes, hazard, brake indication, etc.) and captures the status messages sent back by the module, enabling the CAN interface and control logic to be validated in a controlled and repeatable way. 4.3. Addressable LED Strip The physical lighting output is represented by an addressable LED strip, in which each LED can be controlled individually. This makes it possible to reproduce all the relevant lighting functions on a single strip - turn signals, hazard lights, headlight modes, and brake indication - by assigning different LEDs or groups of LEDs to each function. The result is a clear visual representation of the module's behavior, making it easy to demonstrate how the control logic reacts to incoming CAN commands.     5 References Model-Based Design Toolbox (MBDT) MATLAB® and Simulink® Documentation S32K3 Microcontrollers FRDM Automotive S32K312 Development Board (FRDM-A-S32K312)     6 Conclusion This article described the software and hardware enablement required for the front and rear lights modules. The software environment combines MathWorks modeling and vehicle network capabilities with NXP target support, while the hardware environment brings together the FRDM Automotive S32K312 Development Board, a CAN analyzer, and an addressable LED strip. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the lighting application. The next article will focus on the architecture and model description of the front and rear lights modules, including the control logic, CAN interfaces, and overall application structure.

    1 Table of Contents • Introduction • Open the generated project in S32 Design Studio • Debug the generated application in S32 Design Studio • Debug the code generated from the Simulink model • Conclusion 2 Introduction This article explains how to take a project generated with the Model-Based Design Toolbox (MBDT) in Simulink and open, build, and debug it in S32 Design Studio. It focuses on the transition from model execution in Simulink to target-level debugging and validation on S32 hardware.     3 Open the generated project in S32 Design Studio MBDT generates code from Simulink models and exports it as an S32 Design Studio-compatible project. After a successful model build, the generated <modelName>_Config folder contains the files required by the IDE. The project can then be opened directly from Simulink or imported into S32 Design Studio for further configuration, building, and debugging on S32 hardware. Before opening or debugging the project in S32 Design Studio, build the Simulink model. The build process generates the code and project structure required for IDE integration. You can open the generated project either directly from Simulink or manually from within S32 Design Studio. Use the Simulink option when you want to launch the generated project immediately after configuration. Use the IDE import option when you want to manage the project manually from an S32 Design Studio workspace. Open the project from Simulink To open the project from Simulink, open the model Hardware Settings from the Hardware tab or press Ctrl + E. Then go to Hardware Implementation → Hardware board settings → Target hardware resources → S32 Design Studio Project and select Open. Figure 1. S32 Design Studio project settings in Simulink A dialog appears and prompts you to select the S32 Design Studio installation path. Figure 2. S32 Design Studio installation path selection To select the S32 Design Studio installation path later, or to change it during toolbox usage, click Browse in the S32 Design Studio location field under the Tools Paths group. Figure 3. S32 Design Studio path changing The generated project opens in S32 Design Studio and is ready to build, configure, or debug. Figure 4. Generated project opened in S32 Design Studio Open the project inside the IDE To import the project manually into S32 Design Studio, follow these steps: Inside the IDE, select File → Import → Existing Projects into Workspace. Figure 5. Importing an existing project into the workspace Browse for the <modelName>_Config folder in Select root directory. Before clicking Finish, make sure that Copy projects into workspace is disabled. If the project is copied into the S32 Design Studio workspace, the build process will fail. Figure 6. Directory selection for the generated project     4 Debug the generated application in S32 Design Studio To build and debug the project in S32 Design Studio, select the project and click Debug. S32 Design Studio builds the project and automatically switches to the Debug perspective. Note: Ensure that the target hardware board is connected before starting the debug session. Figure 7. Starting the debug session Figure 8. Debug perspective in S32 Design Studio After the debugger launches and the application is loaded on the target, you can use the following actions to control program execution and inspect the generated code: The Breakpoint action sets a breakpoint when you double-click in the left margin of a .c file:   Figure 9. Breakpoint set in the generated source file The Step Over (F6) action executes the current line while remaining in the same function: Figure 10. Step Over action in the Debug toolbar The Step Into (F5) action enters a called function: Figure 11. Step Into action in the Debug toolbar The Step Return (F7) action runs to the end of the current function: Figure 12. Step Return action in the Debug toolbar The Resume (F8) action runs until the next breakpoint: Figure 13. Resume action in the Debug toolbar Figure 14. Breakpoint reached after pressing Resume action The Suspend (F9) action pauses execution at the current instruction: Figure 15. Suspend action in the Debug toolbar Figure 16. Function paused after pressing Suspend action The Terminate (Ctrl + F2) action stops the debug session and disconnects from the target: Figure 17. Terminate action in the Debug toolbar The Disconnect action leaves the target running while detaching the debugger: Figure 18. Disconnect action in the Debug toolbar     5 Debug the code generated from the Simulink model The code generated by the Simulink model can be found in the <modelName>_step() function. To enter this function, set a breakpoint before the function call, run the application until the breakpoint is reached, and then select Step Into. Alternatively, Ctrl + Click the function name to open the function and place a breakpoint inside it. Figure 19. modelName_step function In this function, you will also find the generated code for the blocks placed inside the Simulink model. Figure 20. Generated step function in the source code To monitor variable values, hover over a variable to see its current value: Figure 21. Variable value displayed on hover Alternatively, add the variable to the Expressions view by selecting Add new expression, entering the variable name, and pressing Enter. Figure 22. Add new expression in Expressions view Figure 23. Variable added to Expressions view Upon running the code, if the value changes, it will be highlighted. Figure 24. Variable value highlighted during debug The names of the variables in the generated code are the same as the names they have in the Simulink model, making it easier to debug the generated code. Figure 25. Variable name in Simulink model and generated code   6 Conclusion After identifying the generated function and monitoring key variables, you can validate how the Simulink model behavior maps to the generated application running on the target hardware. For more tutorials on installing, activating, and using S32 Design Studio, see the S32 Design Studio tutorials on the community page: S32 Design Studio Knowledge Base.

    1 Table of Contents • Overview • Executive Summary - What is .MLTBX • Context - Where to obtain the .mltbx file • Method 1 - Manual Installation (.mltbx) • Method 2 - Install via NXP Support Package • Method 3 - Automotive Software Package Manager • Conclusion     2 Overview NXP provides a range of MATLAB ® Toolboxes distributed as .mltbx packages to support modeling, simulation, configuration, and code generation for NXP microcontrollers and processors. These toolboxes integrate directly with the MathWorks environment and enable faster development workflows by extending MATLAB/Simulink with NXP-specific blocks, drivers, and examples. The scope of this article is to guide users through the process of installing an NXP .mltbx toolbox obtained from the official NXP website. It explains the prerequisites, where to download the toolbox, and how to install and verify it within MATLAB. The instructions are intended for engineers and developers who have basic familiarity with MATLAB but may be new to installing third-party toolboxes distributed outside of MathWorks Add-Ons. By following this guide, readers will be able to correctly install the NXP toolbox, ensure it is recognized by MATLAB, and prepare their environment for subsequent development and evaluation tasks.     3 Executive Summary - What is .MLTBX An .mltbx file is a MATLAB Toolbox package used to distribute and install MATLAB or Simulink extensions. It is a self-contained archive created by MathWorks that can include functions, Simulink blocks, documentation, examples, and setup scripts. When opened in MATLAB, an .mltbx file is installed using the Add-On Manager, which automatically places the toolbox in the default add-ons folder, and registers the toolbox within the environment. This format allows third-party vendors - such as NXP - to safely deliver toolboxes outside of the MathWorks Add-On Explorer while preserving a standard installation experience. In short, a .mltbx file is the official and recommended way to package, install, update, and uninstall MATLAB toolboxes.     4 Context - Where to obtain the .mltbx file There are multiple ways to get the .mltbx file, as shown below: Manual download and install - from NXP site (.mltbx file) Installation via MATLAB - Add-Ons / toolbox flow (NXP Support Package) Installation via Automotive Software Package Manager - bundle installer All methods are valid and can be used depending on your setup and preferences. The Automotive Software Package Manager approach installs bundles and generates an installer that walks through the steps automatically. Prerequisites Before installing the toolbox, ensure the following: MATLAB is installed on your machine You have access to the toolbox download source Note: The .mltbx file cannot be used without MATLAB. The toolbox is only available for Windows and may require additional prerequisites such as: Embedded Coder MATLAB Coder Simulink Coder     5 Method 1 - Manual Installation (.mltbx) The manual installation flow is simple, once prerequisites are met. Manually download the .mltbx file from the NXP site and install it. Typical install behavior: Open MATLAB → run or double-click the .mltbx file → install → toolbox is added automatically. Installed toolboxes are placed under MATLAB Add-Ons directories and appear in the Add-On Explorer. Step 1 - Select the toolbox family As a first step, on the NXP site, select "Automotive SW - Model-Based Design Toolbox".     Step 2 - Select the target software In our example, we are selecting "Automotive SW - S32K3 Software".   Step 3 - Select the S32K3 Model-Based Design Toolbox Select "Automotive SW - S32K3 - Model-Based Design Toolbox".   Step 4 - Choose Product Information Select the Product Information: "Model-Based Design Toolbox S32K3 1.8.0".   Step 5 - Accept Software Terms and Conditions The Software Terms and Conditions will appear - select "I Agree".   Step 6 - Download the .mltbx file After the terms and conditions agreement, you can download the .mltbx file.   When downloading, save the file under the .zip extension, as shown below.   Step 7 - Reveal file extensions in Windows To see and change the file extension, follow the next steps: Press the three dots visible below:   Select "Options". Deselect "Hide extensions for known file types".   Press Apply and OK. After this update, the file will be visible with its extension.   Step 8 - Change the file extension to .mltbx Change the file extension from .zip to .mltbx :   A pop-up will appear - press "Yes":   View after changing the file from .zip to .mltbx:   Step 9 - Install the toolbox in MATLAB Double-click the .mltbx file and accept the License Agreement.   The installation process will start and it will take a few moments to be finalized.  Installation Finalized     Toolbox registered in MATLAB Add-On Manager        6 Method 2 - Install via NXP Support Package The NXP Support Package add-on is a guided installer that: Checks and validates all installation prerequisites Directs users to the page where the required .mltbx package can be downloaded Allows users to select the .mltbx package to install Provides the option to open relevant documentation resources Step 1 - Open MATLAB Launch MATLAB.   Step 2 - Navigate to Add-Ons Go to: Add-Ons → Get Add-Ons.     Step 3 - Install the toolbox Load the toolbox file or follow your internal download process. Note: Direct download via Add-On Explorer may not always be available, depending on licensing and setup.     7 Method 3 - Automotive Software Package Manager This method uses the Automotive Software Package Manager, which installs bundles and generates an installer that walks through the steps automatically. Step 1 - Access Package Manager Use the Automotive Software Package Manager.   Step 2 - Select required components Choose: Target platform - e.g. S32K3 Required tools - e.g. FreeMASTER, Model-Based Design Toolbox   Step 3 - Generate installer The tool generates a bundle installer.   Step 4 - Run installer Run the generated installer. Follow the step-by-step instructions.     8 Conclusion Installing an NXP .mltbx toolbox is straightforward once the MATLAB prerequisites are in place. Depending on your workflow, you can choose the manual .mltbx installation, the guided NXP Support Package, or the Automotive Software Package Manager bundle installer - all three methods produce a properly registered toolbox inside MATLAB. With the toolbox installed and verified, your environment is ready to start developing, simulating, and generating code for NXP microcontrollers and processors. Stay tuned for the next article, where we will dive into using the newly installed toolbox to build your first Model-Based Design project.

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