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 How to MBDT Dio Port/Pins 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 • Pins Configuration • Configure Port Component • Conclusion • References 2 Introduction Before a microcontroller can interact with external hardware, its pins must be configured correctly. Whether you want to read a button state, drive an LED, communicate with a sensor, or use a peripheral, the first step is to configure the corresponding pins. 3 Pins Configuration First, identify the pin you want to use. In this example, we will use the following pin: RGBLED0_RED PTA29 GPIO29 Note: When working in S32 Configuration Tools, the pin MSCR value (third line) is not required. However, it will be needed later if you also configure the same pins in EB tresos. Configure the pins according to their intended use: input, output, or input/output. To begin, open the Pins Tool by clicking the Pins button in the upper-right corner. In the Pins Tool, the pins are organized into Functional Groups. In the default projects provided with the Model-Based Design Toolbox, these groups are arranged based on the peripheral to which the pins are routed. For this step, focus on the Pins tab in the upper-left area of the window. Search for the pin you want to configure; in this example, PTA29. If the desired functionality is already routed to a different pin, first disable that routing by clearing the corresponding selection before assigning it to PTA29. Next, update the identifier and label as needed, then enable the routing by selecting the checkbox on the left. This opens the routing selection dialog. Select SIUL2:gpio,29 , as it matches the intended functionality. A second dialog then prompts you to select the pin direction.   In this example, the LED is configured as Input/Output, matching the configuration used by the example project. Depending on the intended use of the pin, a different direction may be required — for example, a push button is typically configured as an input. Additional examples can be found in the default projects provided with the Model-Based Design Toolbox. 4 Configure Port Component The Port component must reflect the same pin configuration defined in the Pins Tool. After returning to the Peripherals Tool, the Port component may be highlighted in red because the pin configuration was modified in the Pins Tool and has not yet been updated in the Port component.   In the default Model-Based Design Toolbox projects, PortPins are grouped into PortContainers according to their associated peripheral, such as Dio_Pins or Can_Pins . Locate the Dio_Pins PortContainer and update the PortPin entries so that they match the values configured in the Pins Tool. The pin will already contain the MSCR value inherited from the Pins configuration. Update the pin name as desired so it can be easily identified in the model, then repeat the process for each additional pin. The PortPin Id uniquely identifies each PortPin entry. The identifier must remain unique across all PortContainers. Note: If a duplicate PortPin Id value is used, the configuration will report an error. Assign a unique PortPin Id value to each configured pin. For example, a configuration containing 40 pins can use identifiers within the range described by the tool configuration. 5 Conclusion Once the pin configuration is complete and the Port component has been updated accordingly, you can continue with the configuration of the software components that will use those pins. 6 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344

  1 Table of Contents • Introduction • Component Configuration  • Conclusion • References 2 Introduction Before configuring the DIO component, make sure that the pins you intend to use have already been configured in both the Pins Tool and the Port component. If not, refer to the previous articles on pins and port configuration. 3 Component Configuration In order to configure the Dio peripheral, press on the Dio component on the left side of the screen for the Dio Configuration tab to be opened. There, press on the Dio Config tab. Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. Register half DioPort value AL 0 AH 1 BL 2 BH 3 CL 4 CH 5 DL 6 DH 7 EL 8 EH 9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_RED pin is assigned to PTA29. From that we can conclude that, since 29 is higher than 15 (the 16th value of AL, since the first value is 0), the PTA29 pin must be assigned to the AH register. To reiterate, the PTA0–PTA15 pins belong to the AL register while the PTA16–PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too: PTB, PTC, PTD, PTE. Note: When computing the channel Id for pins in the upper half of a port (e.g. PTA16–PTA31), subtract 16 from the pin number. To create a new channel, select the appropriate DioPort and click the + button next to DioChannel. A new channel entry will be created. Fill in the required channel information according to the pin that was previously configured in the Pins Tool and Port component.   Repeat this process for each newly configured pin, ensuring that the channel is added under the correct DioPort. 4 Conclusion After configuring the required DioChannels, save the configuration and regenerate the code. The configured DIO channels can then be used by the application to access the corresponding digital inputs and outputs. 5 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344

  1 Table of Contents • Introduction • Required Software • Required Hardware • Communication and Board-Specific Setup • References • Conclusion   2 Introduction The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible. Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series. This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system.   Figure 1. Position of the Main Node within the system architecture.   3 Required Software The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis. 3.1 Modeling and Application Development The Main Node application is developed as a Simulink model. MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved. The software environment used for this project includes: MATLAB R2024a or newer Simulink Simulink Coder Embedded Coder MATLAB Coder Stateflow These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware. 3.2 Network Definition and Validation Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network. Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system. The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes. Required tools: Vehicle Network Toolbox CANdb++ 3.1 or newer 3.3 Target Support and Code Generation The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package. The toolbox provides: Main target platform support Peripheral integration blocks Build integration Deployment support FreeMASTER integration Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code. 3.4 Build and Configuration Environment After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board. In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow. Together, these tools ensure that the generated software and the target configuration remain aligned throughout development. 3.5 Runtime Monitoring and Validation Once deployed, the Main Node can be observed through two complementary mechanisms. FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network. These tools are used throughout development and validation activities to verify both application behavior and network communication.   Figure 2. Development workflow used by the Main Node application.   4 Required Hardware Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution. 4.1 S32N55 Board The Main Node application executes on an S32N55 board selected for the central application role. Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways. The board provides: CAN FD communication interfaces UART communication interfaces Debug and deployment connectivity I2C peripherals Processing resources required by the Main Node application The Main Node target board is the primary hardware platform referenced throughout this article series. 4.2 Host PC The host PC provides the environment used to interact with the full setup. Depending on the activity being performed, it may host: MATLAB and Simulink RoadRunner simulation environments FreeMASTER Lite CAN analysis software The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER. 4.3 CAN Analyzer A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways. Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled.   5 Communication and Board-Specific Setup Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup. 5.1 Communication Topology The Main Node does not communicate directly with every vehicle-domain node. Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes. This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently. 5.2 CAN Transceiver Initialization One hardware-specific detail of the target board concerns the external CAN transceiver. Note: Before CAN communication becomes available, the transceiver must first be switched from standby mode into normal operation. This transition is not controlled directly through a dedicated GPIO. Instead, it is performed through an I2C-connected port expander located on the board. As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication.   Figure 3. CAN transceiver enable sequence on the target board. 5.3 FreeMASTER Telemetry Interface In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite. This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time.   6 References Model-Based Design Toolbox (MBDT) Community NXP S32N Vehicle Super-Integration Processors MathWorks Vehicle Network Toolbox NXP FreeMASTER Run-Time Debugging Tool   7 Conclusion This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network. Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board. The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.

  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 • 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 Software & Hardware Environment for Parking Sensor System 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 Table of Contents • Introduction • Black-Box Overview • Simulink Model Overview • Inputs • Algorithm • Outputs • References • Conclusion     2 Introduction This article explains the internal behavior of the Zone Node by opening the component "black box" and describing how information flows through the application. The objective is to provide a functional understanding of the model, starting from the incoming inputs, continuing through the internal processing logic, and concluding with the generated outputs. The Zone Node acts as an intermediary between the Central Controller and the Edge Nodes located within a vehicle zone. While previous articles introduced the component and the development environment, this article focuses on the application's behavior and the responsibilities performed by the embedded software. This article focuses on the functional behavior of the Zone Node and explains how information flows through the component. Detailed aspects such as CAN routing implementation, LIN scheduling mechanisms, peripheral configuration, and communication stack integration will be covered in dedicated articles later in the series.     3 Black-Box Overview From a system perspective, the Zone Node behaves as a communication gateway and data aggregation component. It receives information from different communication networks, processes that information according to predefined routing rules, and forwards the resulting data to other parts of the system. At a high level, the component can be represented as: Figure 1. Black-Box Overview The Zone Node does not implement vehicle-level control strategies. Functions such as braking decisions, steering calculations, or vehicle state management remain the responsibility of higher-level controllers. Instead, the Zone Node focuses on: Receiving messages from the Central Controller Receiving messages from Edge Nodes Acquiring data from local LIN-connected devices Routing information between networks Aggregating and forwarding data Providing monitoring and diagnostic information The result is a reusable communication component that can be deployed in different vehicle zones while maintaining the same overall behavior.     4 Simulink Model Overview The Zone Node functionality is implemented as a Simulink model organized around communication, routing, scheduling, and diagnostic subsystems. From a model perspective, the application can be divided into four logical areas: Input handling Routing and processing Communication scheduling Outputs and diagnostics Figure 2. Main Simulink Application The input layer receives information from CAN and LIN communication interfaces and makes it available to the application logic. The processing layer evaluates incoming messages and determines how they should be handled. The scheduling layer manages periodic communication activities, while the output layer is responsible for forwarding messages and generating diagnostic information. This separation helps keep the model modular and makes it easier to extend the application with additional communication paths or Edge nodes without changing the core routing behavior.     5 Inputs The Zone Node receives information from three main categories of inputs. 5.1 CAN Network Inputs CAN communication represents the primary source of information processed by the Zone Node. Messages can originate from: Central Controller Lighting modules Steering modules Motor control modules Other Edge Nodes within the zone Typical examples include: Vehicle commands Status reports Diagnostic information Fault indications Actuation requests The exact set of messages depends on the specific Edge Nodes connected to the zone. 5.2 LIN Device Inputs The Zone Node also acquires information from LIN-connected devices. In the reference implementation, LIN communication is used to retrieve parking sensor information. The Zone Node periodically requests data from the LIN device and receives measurement values in response. Examples include: Front parking distances Rear parking distances Other LIN-based sensor information From the perspective of the Zone Node, LIN data behaves similarly to any other external input source. 5.3 Configuration Inputs Before normal operation begins, the Zone Node initializes its communication interfaces and loads the required configuration information. Examples include: CAN interface configuration LIN interface configuration Communication schedules Routing rules These parameters define how the application interacts with the surrounding networks.     6 Algorithm Internally, the Zone Node performs three main processing activities. 6.1 Message Reception The first step consists of collecting incoming communication data. Whenever a message arrives, the application captures: Communication source Message identifier Data payload Message length This information becomes available to the routing and aggregation logic. Figure 3. CAN Reception Pipeline 6.1.1 Model Representation of Message Reception Within the Simulink model, message reception is implemented using communication interface blocks and dedicated processing subsystems that capture incoming network events and make the received information available to the rest of the application. Figure 4. CAN Reception Main Flow Figure 5. CAN Reception Subsystem At a high level, the reception subsystem performs three actions: Detects incoming communication events Stores the received information Makes the information available to the routing logic This allows the routing algorithm to operate independently from the physical communication interface. 6.2 Message Routing Message routing represents the primary responsibility of the Zone Node. The routing logic determines the origin of each incoming message and forwards it to the appropriate communication interface. The behavior can be simplified as: Figure 6. Bidirectional CAN Routing Messages received from the Central Controller are forwarded toward the Edge Nodes, while messages originating from Edge Nodes are routed back toward the Central Controller. The routing mechanism remains independent of the actual application payload, allowing the same software architecture to support different message sets and vehicle functions. 6.2.1 Model Representation of Routing Logic The routing functionality is implemented as a dedicated subsystem responsible for deciding where each received message should be forwarded. Figure 7. Message Routing Main Flow Figure 8. Message Routing Subsystem The routing subsystem evaluates the origin of the received message and selects the appropriate destination interface. At this level, the application does not interpret individual signal meanings; it simply ensures that information reaches the correct communication network. This approach keeps the routing layer independent from application-specific functionality and allows the same architecture to be reused across different deployments. 6.3 LIN Scheduling and Data Acquisition In parallel with CAN routing, the Zone Node periodically acquires data from LIN-connected devices. The sequence follows a simple request-response model: Figure 9. LIN Parking Acquisition Cycle This mechanism allows information originating on a LIN network to become available to the rest of the vehicle through CAN communication. 6.3.1 Model Representation of LIN Scheduling Periodic LIN communication is implemented using a dedicated scheduling subsystem. Figure 10. LIN Scheduling Main Flow The scheduler periodically requests data from LIN-connected devices, waits for a response, and updates the application data used by the rest of the system. Depending on the communication requirements, the scheduler may manage one or more request-response sequences while maintaining a deterministic execution pattern. 6.4 High-Level Data Flow The internal data flow implemented by the Zone Node can be summarized as follows: Figure 11. Zone Node Data Flow     7 Outputs The Zone Node produces several categories of outputs that are consumed by different parts of the vehicle architecture and by development tools used during validation and debugging. 7.1 Routed CAN Messages The primary outputs of the Zone Node are CAN messages forwarded between communication networks. Examples include: Commands sent from the Central Controller to Edge Nodes Status information returned from Edge Nodes Diagnostic messages Fault reports Configuration updates By routing these messages between communication domains, the Zone Node maintains communication between the central controller and the devices located within its assigned vehicle zone. 7.2 Aggregated Device Data In addition to forwarding CAN traffic, the Zone Node generates CAN messages containing information acquired from locally connected devices. One example is parking sensor data collected through a LIN interface and republished on CAN. This allows the Central Controller to access the information without requiring direct interaction with the LIN-connected device. The process can be summarized as: Figure 12. LIN-to-CAN Data Path This approach creates a unified communication interface while hiding the complexity of the underlying network topology. 7.3 Diagnostic Outputs The Zone Node generates diagnostic information that is useful during development, system integration, and troubleshooting activities. Examples include: Communication counters Status variables Network activity indicators Communication statistics Device data used for monitoring purposes These outputs provide insight into the current behavior of the application and can be accessed through development tools such as FreeMASTER. 7.4 Visual Indicators In addition to communication outputs, the Zone Node drives visual indicators available on the evaluation hardware. The on-board LEDs provide immediate feedback regarding: Message reception activity Message transmission activity LIN communication activity Application execution status Although these indicators are not used by the vehicle itself, they simplify application bring-up and validation by providing a quick visual confirmation that the software is operating correctly. 7.5 Output Destinations The outputs generated by the Zone Node are consumed by several different system components. Central Controller Receives: Status information from Edge Nodes Aggregated sensor data Diagnostic information generated within the zone Edge Nodes Receive: Commands originating from the Central Controller Configuration and control messages forwarded through the Zone Node Local Devices Receive: Periodic requests issued by the Zone Node Communication messages required to acquire local measurements Development Tools Receive: Monitoring variables Communication statistics Diagnostic information used for debugging and validation 7.6 High-Level Output Flow Figure 13. System Topology This output structure allows the Zone Node to act as a communication intermediary while simultaneously providing visibility into the behavior of the system during development and validation.     8 References NXP Model-Based Design Toolbox (MBDT) S32K3 Microcontroller Documentation S32K344-WB Evaluation Board Documentation     9 Conclusion This article described the internal behavior of the Zone Node by examining its inputs, processing logic, and outputs. By presenting the component as a functional black box, it explained how information is received, routed, aggregated, and distributed throughout the system without focusing on implementation-specific details. The next articles in the series will build upon this foundation by examining individual communication paths in more detail, including CAN-to-CAN routing, LIN-to-CAN routing, and the techniques used to validate and troubleshoot communication behavior.

      1 Table of Contents • Introduction • Software Environment • Hardware Environment • References • Conclusion     2 Introduction Turning a vehicle concept into an interactive Virtual Vehicle requires more than a standalone simulation model. It requires a connected software and hardware environment that can define the vehicle architecture, simulate the powertrain and vehicle dynamics, place the vehicle in realistic driving scenarios, visualize the behavior in 3D, and allow user interaction through driver-in-the-loop inputs. This article continues the Virtual Vehicle system series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks tools and host-side hardware resources that make the virtual vehicle demonstrator possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to configure the vehicle architecture with Virtual Vehicle Composer, model the powertrain and vehicle dynamics, define and execute driving scenarios, create 3D road environments, exchange CAN-based signals, and analyze simulation results. The same environment also supports interactive execution, where driver inputs from a steering wheel and pedals can influence the virtual vehicle behavior during scenario playback.     3 Software Environment The software environment provides the modeling, simulation, scenario definition, visualization, communication, and analysis capabilities required by the Virtual Vehicle system. Each MathWorks tool contributes a specific part of the workflow, from vehicle architecture definition and plant modeling to 3D scenario execution and CAN-based interaction with external systems. 3.1 MATLAB and Simulink R2025b MATLAB and Simulink form the central engineering environment for the Virtual Vehicle. Figure 1. MATLAB MATLAB provides the scripting, data management, parameterization, and analysis capabilities required to configure simulations, process logged signals, and evaluate test results. Figure 2. Simulink Simulink provides the model-based design environment in which the virtual vehicle, control logic, communication interfaces, and test harnesses are assembled. The system-level model can connect plant models, vehicle dynamics, driver inputs, scenario interfaces, and network communication blocks into a single executable simulation. 3.2 Virtual Vehicle Composer Figure 3. Virtual Vehicle Composer Virtual Vehicle Composer is the configuration and assembly environment used to create the Virtual Vehicle model. It allows the user to define the vehicle class, select the powertrain architecture, choose the vehicle dynamics fidelity, configure components, specify test scenarios, select logged signals, build the vehicle model, run the configured tests, and analyze the results. In this Virtual Vehicle system, Virtual Vehicle Composer acts as the entry point for building a consistent vehicle model. It assembles the selected architecture from predefined and customizable components and prepares the model for closed-loop simulation in Simulink. The app also supports repeatable test execution. The same virtual vehicle can be operated across selected scenarios, while relevant signals are logged for review. This makes it suitable for early design studies, component comparison, control validation, and system-level behavior analysis before moving to hardware integration. 3.3 Powertrain Blockset Figure 4. Powertrain Blockset Powertrain Blockset provides the vehicle powertrain modeling foundation for the Virtual Vehicle model. It includes reference applications and component libraries for conventional, hybrid, and battery-electric propulsion systems. In this system, Powertrain Blockset supports the definition of the propulsion architecture, energy storage, electric motors, drivetrain elements, tires, driver models, and supervisory control behavior. It also provides workflows that help configure, resize, calibrate, and analyze the selected powertrain components. The generated vehicle model can be used for performance analysis, energy management studies, range evaluation, component sizing, control parameter optimization, and hardware-in-the-loop preparation. Because the models are open, project-specific subsystems can be integrated into the generated architecture when needed. 3.4 Vehicle Dynamics Blockset Figure 5. Vehicle Dynamics Blockset Vehicle Dynamics Blockset provides the vehicle motion and handling foundation for the Virtual Vehicle. It includes reference applications and component libraries for propulsion, steering, suspension, vehicle body, brakes, tires, driver models, and supervisory controllers. For the Virtual Vehicle system, the blockset enables different levels of vehicle dynamics fidelity depending on the simulation objective. Longitudinal dynamics can be used for drive-cycle and energy studies, while combined longitudinal, lateral, and vertical dynamics can be used for handling, chassis behavior, and more complex driving scenarios. The blockset also supports 3D visualization workflows, allowing the virtual vehicle behavior to be observed in a realistic environment. This helps connect numerical simulation results with intuitive visual feedback during ride, handling, ADAS, and driver-in-the-loop demonstrations. 3.5 Automated Driving Toolbox Figure 6. Automated Driving Toolbox Automated Driving Toolbox supports the definition, simulation, and analysis of driving scenarios used to exercise the Virtual Vehicle. It provides capabilities for creating road layouts, actors, trajectories, sensor-related contexts, and repeatable test cases. In this setup, the toolbox is used to create controlled and repeatable traffic situations around the ego vehicle. These scenarios can be used to evaluate how the virtual vehicle behaves in predefined maneuvers, traffic interactions, lane-following conditions, or other driving situations relevant to the demonstration. By combining scenario definition with the vehicle model, the Virtual Vehicle can be validated in a structured way. Instead of testing only isolated model behavior, the complete system can be exercised against realistic road and traffic conditions. 3.6 Vehicle Network Toolbox Figure 7. Vehicle Network Toolbox Library Vehicle Network Toolbox brings vehicle network communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding messages over in-vehicle network protocols such as CAN, CAN FD, J1939, and XCP. In the Virtual Vehicle, the toolbox is used to exchange selected vehicle signals with external systems or hardware components. CAN messages can be packed and unpacked using database-driven definitions, allowing the model to follow the same signal structure expected by the vehicle-level architecture. This makes communication behavior visible and testable during simulation. Commands, feedback, status information, and selected virtual vehicle signals can be validated before deployment or integration with physical controllers, reducing late-stage integration risk. 3.7 RoadRunner Figure 8. RoadRunner RoadRunner provides the 3D scene creation environment used by the Virtual Vehicle system. It enables the design of detailed road networks, intersections, lane markings, traffic signs, buildings, terrain, and other environmental assets required for realistic driving simulation. In this workflow, RoadRunner supplies the visual and spatial context in which the virtual vehicle operates. The generated scenes can represent controlled proving-ground layouts, urban intersections, highway segments, or demonstration environments used for scenario execution. When combined with Simulink and the vehicle model, RoadRunner helps transform the simulation from a signal-level model into an interactive visual experience. This is especially useful for driver-in-the-loop demonstrations, ADAS workflows, and stakeholder-facing presentations. 3.8 Simulink 3D Animation Figure 9. Simulink 3D Animation Library Simulink 3D Animation connects Simulink models and MATLAB algorithms to a 3D simulation environment, enabling dynamic systems to be visualized in photorealistic scenes. In the Virtual Vehicle system, it provides the visualization and interaction layer used to observe vehicle behavior in a 3D environment during simulation. The toolbox can use prebuilt scenes or imported scenes created in RoadRunner, and it allows vehicles, objects, lighting, weather effects, and sensor-related elements to be controlled during simulation. This makes it suitable for connecting the Virtual Vehicle model to visually rich driving environments. For driver-in-the-loop operation, Simulink 3D Animation also supports interactive navigation and manual control through hardware devices. This allows steering wheel and pedal inputs to influence the simulated vehicle while the resulting motion is visualized in the 3D scene. 3.9 Stateflow Figure 10. Stateflow Library Stateflow provides the graphical environment for modeling state machines, decision logic, and event-driven behavior inside the Virtual Vehicle system. It is used when vehicle behavior must depend on operating modes, transitions, conditions, timers, or fault states. Within the Virtual Vehicle model, Stateflow can support supervisory control, mode management, scenario state handling, driver input interpretation, startup and shutdown sequencing, or fallback behavior. This helps separate discrete decision logic from continuous plant and controller behavior. Using Stateflow keeps the system behavior easier to understand, review, and validate. Complex conditions can be represented explicitly as states and transitions, which improves traceability during simulation and debugging.     4 Hardware Environment The hardware environment provides the execution platform, user input interface, and visualization resources required to operate the Virtual Vehicle system interactively. The main components are the GPU-accelerated PC and the Xbox-compatible steering wheel and pedal controller. 4.1 PC with GPU Acceleration The PC is the main host platform for the Virtual Vehicle system. It runs MATLAB, Simulink, Virtual Vehicle Composer, RoadRunner-related workflows, and the supporting toolboxes used to model, simulate, visualize, and analyze the vehicle behavior. GPU acceleration is important because the system includes visually rich 3D scenes and interactive simulation workflows. The graphics hardware helps render the driving environment smoothly, maintain responsive visualization, and support a more realistic driver-in-the-loop experience. In this setup, the PC also acts as the integration point between the simulation model, the 3D environment, the input devices, and any external communication interfaces. This makes it the central execution and orchestration node of the Virtual Vehicle demonstration. 4.2 Xbox-Compatible Wheel Controller Xbox-Compatible Wheel Controller The Xbox-compatible wheel controller provides the physical driver input interface for the Virtual Vehicle system. It allows the user to control steering, acceleration, and braking through a steering wheel and pedal set instead of using keyboard-based commands. This input device makes the simulation suitable for driver-in-the-loop demonstrations. User actions can be mapped into the Simulink model and used to influence the virtual vehicle response during scenario execution. The wheel controller improves the realism and accessibility of the demonstration. It allows engineers and stakeholders to experience the virtual vehicle behavior interactively, making it easier to evaluate the relationship between driver input, vehicle response, and 3D scene feedback.     5 References The following resources provide useful background for the technologies referenced in this article: MathWorks MATLAB and Simulink documentation MathWorks Virtual Vehicle Composer documentation MathWorks Powertrain Blockset documentation MathWorks Vehicle Dynamics Blockset documentation MathWorks Automated Driving Toolbox documentation MathWorks Vehicle Network Toolbox documentation MathWorks RoadRunner documentation MathWorks Simulink 3D Animation documentation MathWorks Stateflow documentation     6 Conclusion This section described the software and hardware enablement required for the Virtual Vehicle system. The software environment combines MATLAB and Simulink with Virtual Vehicle Composer, Powertrain Blockset, Vehicle Dynamics Blockset, Automated Driving Toolbox, Vehicle Network Toolbox, RoadRunner, Simulink 3D Animation, and Stateflow to support vehicle configuration, system-level modeling, scenario execution, 3D visualization, communication, and analysis. The hardware environment combines a GPU-accelerated PC with a steering wheel and pedal controller to support interactive driver-in-the-loop execution. Together, these elements provide the foundation for building, operating, visualizing, and validating the virtual vehicle before integration with physical controllers or target hardware.

  1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Modern vehicle development increasingly relies on digital validation before physical prototypes are available. Simulation enables rapid testing and iteration, but engineering teams also need to demonstrate how virtual behavior maps to real hardware. In the Hello World demonstrator, this connection is handled by the Main Node application running on the NXP S32N55. The Main Node acts as the central execution point of the demonstrator, transforming vehicle information generated inside MATLAB ® and Simulink ® into decisions and actions that can be observed on physical hardware. By combining Model-Based Design, CAN communication, and centralized decision making, the system creates a bidirectional link between the virtual vehicle and the physical demonstrator. This article explains how the Main Node converts simulation inputs into coordinated vehicle behavior while maintaining synchronization between the digital and physical domains.     3 Overview As introduced in the previous article, the S32N55 functions as the communication hub of the demonstrator, aggregating information from distributed modules and distributing commands throughout the system. Beyond communication, however, the Main Node also serves as the decision-making layer responsible for interpreting vehicle state and translating it into actionable control signals. Developed using the NXP Model-Based Design Toolbox (MBDT), the application is entirely modeled in Simulink and deployed directly onto the target hardware. This workflow enables engineers to focus on vehicle functionality and system behavior while leveraging automated code generation and integrated CAN communication support. The Main Node receives data from simulated and physical sources, maintains a coherent vehicle-state view, runs vehicle-level control logic, and sends commands to the actuator nodes that make up the demonstrator. This centralized architecture reflects the direction of modern software-defined vehicle platforms, where coordination moves from isolated ECUs toward higher-level compute nodes. Figure 1. Main Node overview showing how the S32N55 coordinates simulation inputs, vehicle-state processing, and commands to distributed hardware modules.     4 Context The Main Node is positioned between the virtual vehicle environment and the physical hardware modules that form the demonstrator. Driver inputs generated through the Driver-in-the-Loop simulation environment are transmitted over CAN and received by the S32N55, where they are processed alongside feedback arriving from multiple distributed nodes. Commands such as vehicle speed, steering angle, gear selection, braking requests, and lighting controls enter the Main Node from the simulation environment. These inputs are then evaluated by the application and translated into CAN messages that drive the corresponding hardware modules. This architecture enables the physical demonstrator to mirror the behavior of the virtual vehicle. When the simulated vehicle accelerates, the speed command is interpreted by the Main Node and forwarded to the motor control subsystem. Steering-wheel movements are translated into steering-angle commands for the steering module, while lighting commands activate headlights, fog lights, hazard lights, and turn indicators on the physical hardware. Figure 2. System context illustrating the Main Node as the bridge between the virtual vehicle environment and the physical demonstrator hardware. The Main Node can be driven either by the Driver-in-the-Loop simulation or by the External Control model. In both cases, the command source publishes the same DBC-defined CAN frames, so the S32N55 receives speed, steering, brake, gear, and lighting commands through the same interface. This allows the same deployed application to be exercised from two sources without changing the Main Node software. This approach is especially useful during integration, demonstrations, and incremental validation. Engineers can exercise the Main Node and the downstream actuator modules even when the complete virtual environment is not active, while still preserving the exact communication contract used by the full system. As a result, the application can be validated against two different input sources without changing the deployed software on the board. Rather than acting as a simple gateway, the Main Node continuously evaluates received information and executes vehicle-level decisions. One example is the processing of motor feedback data, where information from multiple motors is combined to derive a representative vehicle speed used throughout the system. Centralizing this functionality simplifies system coordination while ensuring consistency across all connected modules. Gear selection is handled as part of this centralized decision layer. The incoming gear command is interpreted as a driving mode that affects how the requested speed is applied: Park and Neutral block motion commands, Reverse changes the sign of the velocity reference, and Drive or Sport propagate the requested speed as a forward-driving command. This keeps speed-control behavior aligned with the selected driving mode while preserving the same driver-input signal set. The target-speed command is computed from the requested speed reference, the selected gear mode, the reported vehicle speed, and the effective brake command. Motor feedback is fused into a representative reported speed, which provides the actual-speed reference used during braking decisions. Under normal driving conditions, the requested target speed passes through the gearbox-aware logic and is converted into the motor-speed command sent over CAN. When braking is active, the Main Node bases the outgoing command on the detected speed and brake value, reducing the command until the vehicle is considered stopped. The Main Node also hosts the demonstrator's automated emergency braking functionality. Parking sensor nodes continuously report obstacle distances over CAN. The application evaluates these measurements and determines whether an object has entered a predefined safety zone. When this condition is met, the braking command issued by the driver can be overridden and replaced with an emergency braking request generated by the system. Figure 3. Parking sensors in action detecting nearby obstacles and providing distance feedback used by the Main Node to support emergency braking decisions. An important aspect of this implementation is that the braking behavior is reflected across both domains. The physical hardware responds to the braking request, while the simulation environment can receive corresponding vehicle-state updates through the same CAN-based loop. This closed-loop behavior demonstrates bidirectional interaction between simulation and embedded execution, allowing safety-related functionality to be validated in a realistic environment before a full vehicle prototype is available. Figure 4. Closed-loop emergency braking flow showing how parking sensor feedback can trigger an automated braking request across both the physical and simulated domains. CAN communication is the key enabler of this architecture. Every subsystem communicates through DBC-defined interfaces, allowing functionality to be distributed across multiple independent nodes while preserving a consistent and scalable communication framework. The shared DBC approach ensures that signal definitions remain synchronized across all parts of the demonstrator. To support this workflow, MathWorks Vehicle Network Toolbox ™ provides direct integration between MATLAB ® , Simulink ® , and CAN communication interfaces. DBC files can be used directly throughout the development process, simplifying signal management and ensuring consistency across the virtual vehicle, the Main Node, and all peripheral modules. As the demonstrator grows to include additional functionality, the same network definition can be reused across all participating systems, reducing integration effort and helping accelerate development. Note: The combination of NXP Model-Based Design Toolbox and MathWorks Vehicle Network Toolbox creates a workflow in which vehicle behavior, communication interfaces, and deployed software remain aligned from modeling through system integration. Figure 5. CAN and DBC workflow showing how shared signal definitions keep the virtual vehicle, Main Node, and distributed hardware modules synchronized.     5 References NXP Model-Based Design Toolbox (MBDT) NXP S32N Vehicle Super-Integration Processors Vehicle Network Toolbox ™ NXP Model-Based Design Toolbox Community     6 Conclusion The Main Node demonstrates how a centralized compute platform can act as more than a communication gateway. Running on the NXP S32N55, it combines signal aggregation, decision making, and command distribution into a single application that coordinates the entire demonstrator. By transforming simulation-generated inputs into physical vehicle behavior and feeding real-world information back into the virtual environment, the Main Node creates a practical closed-loop development platform. Together, NXP Model-Based Design Toolbox, MathWorks Vehicle Network Toolbox, and CAN-based communication enable rapid iteration, simplified integration, and efficient validation of vehicle functionality across simulated and physical domains.

      1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion     2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles.     3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer.     4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 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 routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series.     5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board     6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.

    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 • Overview • Context • FreeMASTER Blocks • Generated ELF File • References • Conclusion     2 Overview This article introduces the FreeMASTER blocks available in NXP Model-Based Design Toolbox (MBDT) and explains how they are used within a Simulink model to prepare an application for FreeMASTER integration. The primary focus is the FreeMASTER Config block, which enables the FreeMASTER Driver in the generated application and allows users to configure the communication interface and runtime parameters required by FreeMASTER. The article also introduces the FreeMASTER Recorder block, which can be used to add data-recording capabilities to the application. Why is this Important? Before FreeMASTER can communicate with an embedded application, the FreeMASTER Driver should be enabled and configured in the embedded application. The FreeMASTER blocks provided by MBDT simplify this integration process by allowing all required settings to be configured directly within the Simulink environment. This article is intended for: Simulink users working with NXP Model-Based Design Toolbox Developers integrating FreeMASTER into embedded applications Engineers interested in runtime monitoring and debugging Users preparing an application for future interaction with FreeMASTER By reading this article, you will understand how FreeMASTER support is enabled within a Simulink model and how the generated application is prepared for runtime communication and data access. You will also learn how the code-generation process produces an ELF file containing symbolic information corresponding to application variables, which is later used by FreeMASTER to access, monitor, and visualize application data.     3 Context Dedicated Simulink blocks integrate FreeMASTER into a Model-Based Design Toolbox project by automatically generating the software infrastructure required by the application. The overall workflow is illustrated below: Figure 1. FreeMASTER workflow In this workflow, the FreeMASTER blocks serve as the interface between the Simulink model and the FreeMASTER Driver that will be included in the generated application.     4 FreeMASTER Blocks FreeMASTER blocks can be found in the MBDT library under: S32K3xx Core, System, Peripherals and Utilities → Utility Blocks Figure 2. FreeMASTER Simulink Library Three blocks are available for FreeMASTER integration: FreeMASTER Config block FreeMASTER Poll block FreeMASTER Recorder block 4.1 FreeMASTER Config Block The FreeMASTER Config block is responsible for enabling and configuring the FreeMASTER Driver within the generated application. It inserts the software infrastructure required for communication between the embedded target and the FreeMASTER desktop tool and serves as the foundation for integrating FreeMASTER functionality into a Simulink model. Figure 3. FreeMASTER Config block This block provides a configuration interface divided into two sections: communication settings and runtime settings. 4.1.1 General Tab The General tab contains communication-related parameters: Connection Type – selects the communication interface used by FreeMASTER. Instance – specifies the peripheral instance assigned to FreeMASTER communication. Baudrate – defines the communication speed. ISR Priority – sets the interrupt priority associated with FreeMASTER communication. Figure 4. FreeMASTER General tab During configuration, a dedicated communication peripheral is assigned to the FreeMASTER Driver. In the example shown, communication is performed through LPUART6 operating at 115200 bps. Note: The peripheral assigned to FreeMASTER should not be reused simultaneously for other communication purposes. During initialization, the FreeMASTER Driver assumes control of the communication resources associated with the selected peripheral. 4.1.2 FreeMASTER Configuration Tab The FreeMASTER Configuration tab contains runtime-related settings: Mode – defines the FreeMASTER operating mode. Number of Scopes – specifies the number of available scope instances. Max Variables – defines the maximum number of variables handled by a scope. Automatic Buffer Size – automatically calculates communication buffer size. FIFO Receiver Queue Size – configures the receive queue used by the communication driver. Figure 5. FreeMASTER Configuration tab Together, these settings determine how the FreeMASTER Driver operates within the generated application. 4.2 FreeMASTER Recorder Block In addition to the configuration block, MBDT provides a FreeMASTER Recorder block that enables support for FreeMASTER recording functionality. Figure 6. FreeMASTER Recorder block Unlike the Config block, which is primarily focused on communication setup and driver integration, the Recorder block is designed for high-speed monitoring and visualization of application variables. It configures data acquisition resources that can be accessed later through the FreeMASTER desktop application, enabling detailed analysis of system behavior. The Recorder block is typically placed in application execution paths where rapidly changing signals need to be captured periodically. To support this, it uses an on-board memory buffer to store acquired samples, allowing high-frequency data to be recorded without requiring immediate transfer to the host PC. The buffered data can then be retrieved and displayed in FreeMASTER for waveform visualization, performance evaluation, and post-run analysis. The block provides the following configuration parameters: Id – unique identifier of the recorder instance. Name – user-defined recorder name. Buffer Size – amount of memory allocated for storing captured samples. Timebase – time reference used during recording operations. Figure 7. FreeMASTER Recorder block parameters The Recorder block is optional and can be used whenever runtime data recording capabilities are required. 4.3 FreeMASTER Poll Block MBDT also provides a FreeMASTER Poll block, which allows the application to explicitly call the FreeMASTER polling function within the Simulink model. Figure 8. FreeMASTER Poll block The Poll block does not require any configuration parameters. Its purpose is to provide a configurable location within the application where FreeMASTER communication handling and command processing can be executed. Figure 9. FreeMASTER Poll block mask The role of the Poll block depends on the operating mode selected in the FreeMASTER Config block. When the FreeMASTER Driver is configured in Poll Mode, the Poll block is responsible for both communication handling and command processing. When the Driver operates in Short Interrupt Mode, communication is handled by interrupts, while command processing is performed through the Poll block. Note: For both Poll Mode and Short Interrupt Mode, the Poll block is required and should be placed in an execution path that runs periodically, such as the application's main step function, to ensure timely processing of FreeMASTER requests. When the FreeMASTER Driver is configured in Long Interrupt Mode, communication handling and command processing are performed entirely by the driver interrupt routines. In this configuration, the Poll block is not required, and its execution has no effect on FreeMASTER operation. The Poll block complements the FreeMASTER Config and FreeMASTER Recorder blocks by providing a configurable mechanism for communication processing when required by the selected FreeMASTER operating mode.     5 Generated ELF File Once the FreeMASTER blocks have been added and configured, the model can be built using the standard code-generation workflow provided by Embedded Coder and MBDT. In addition to the application code generated from the Simulink model, the build process also produces an ELF (Executable and Linkable Format) file. When debug information is enabled during the build process, the ELF file contains symbolic information about application variables, functions, and memory locations stored in the DWARF debug sections. Otherwise, this information may be removed, preventing the FreeMASTER desktop tool from extracting the symbols required for variable access and monitoring. The ELF file is later loaded by the FreeMASTER desktop tool, allowing variables to be identified automatically without requiring manual memory address entry. This enables features such as variable monitoring, runtime configuration, data visualization, and recording. Note: Generating a valid ELF file with debug information is an important preparation step before attempting to establish communication with the target application.     6 References Introduction to FreeMASTER FreeMASTER Driver and Documentation Package – The FreeMASTER Driver and its accompanying documentation are delivered as part of the MBDT installation. After installing the toolbox, they can be found in the root installation directory: NXP_MBDToolbox_S32K3\FreeMASTER\     7 Conclusion This article introduced the FreeMASTER Configuration blocks provided by NXP Model-Based Design Toolbox and explained their role in preparing a Simulink model for FreeMASTER integration. By configuring the block appropriately, developers can include the required FreeMASTER support in the generated application and produce an ELF file suitable for runtime access to application data. The next article in this series will demonstrate how to use the generated application and ELF file to establish a connection between the target device and the FreeMASTER desktop application.

  1 Introduction After introducing the Dual-Motor EV Traction platform and the Software & Hardware environment behind it, this article moves one step closer to the running application. It looks inside the Motor Control System and explains how the Simulink model is structured to control two PMSM motors using the NXP S32K396 MCU as the target hardware. The goal is to provide a clear architectural view of the application before diving into simulation, validation, or deployment details. We will follow the main signal paths, from vehicle-level CAN commands and inverter feedback to FOC execution, PWM generation, ADC measurement, and communication back to the vehicle network. The focus remains intentionally architectural. Instead of covering controller tuning, peripheral configuration, or low-level implementation, this article highlights the building blocks that make the dual-motor application understandable as a complete embedded control system. This article is organized around five architectural views: the application overview, the system interfaces, the CAN communication path, the Simulink model structure, and the peripheral-to-data-flow mapping. Together, these views explain how the dual-motor application receives commands, measures feedback, executes control, drives the inverters, and reports diagnostic information back to the vehicle network.   2 Table of Contents • Introduction • Application Overview • System Inputs and Outputs • Vehicle-Level Communication • Simulink Application Architecture • Peripheral Mapping • Data Flow • Conclusion • References   3 Application Overview The Motor Control System is implemented on the NXP S32K396 microcontroller and runs as a single-core embedded application. The ECU controls two PMSMs, each connected to its own three-phase inverter stage. From a control perspective, the application contains two Field-Oriented Control implementations. Each FOC instance is responsible for one motor and executes independently, based on its own sensing path, control states, and output generation. Both control loops are scheduled from independent interrupt sources and are triggered every 100 microseconds. This execution period supports the fast current-control layer required by traction inverter applications, while the single-core implementation requires both motor-control paths to complete within the available timing budget.   Figure 3-1. Overall Simulink Application At vehicle level, the Motor Control System behaves as a actuating end node. It receives enable and speed commands from the Central Node over CAN and sends back monitoring and diagnostic information at a slower periodic rate. The Motor Control System exchanges CAN data with the vehicle network through the South Zone Controller. 3.1. Control Strategy At the heart of the application is the Field-Oriented Control algorithm, which provides the control structure required to drive each PMSM efficiently and independently. In this architecture, FOC transforms the three-phase motor behavior into a control problem handled in a rotating reference frame, where torque-producing and flux-producing current components are regulated separately. The control strategy is built around speed control. The requested speed comes from the vehicle-level command interface, while the estimated rotor speed is provided by the sensorless observer. The speed controller compares these values and generates the current reference needed to reach the commanded operating point. For each motor, the FOC structure combines an outer speed loop with inner current-control loops. The current PI controllers regulate the direct-axis and quadrature-axis currents in the rotating reference frame, allowing the application to control the electrical behavior of the motor in a deterministic and decoupled way. Sensorless operation is achieved using an Extended EMF Observer. This observer estimates the rotor position and speed from the measured electrical quantities, removing the need for a physical position sensor in the control loop. The estimated position is then used by the Park and inverse Park transformations that connect the stationary and rotating reference frames. The feedback path is based on phase-current reconstruction using the dual-shunt measurement method. The reconstructed phase currents are processed through the Clarke and Park transformations, while the DC bus voltage feedback is used to keep the control and modulation stages aware of the available inverter supply. The two FOC implementations follow the same control structure, but each one operates on its own motor-specific inputs, states, and outputs. This separation allows Motor 1 and Motor 2 to be controlled independently, even though both algorithms execute on the same S32K396 device. Because the control loops are executed every 100 microseconds, the FOC layer must remain compact and deterministic. The model architecture therefore separates the fast control path from slower communication and monitoring tasks, ensuring that current regulation and PWM update remain the highest-priority activities in the application.   Figure 3-2. Sensorless Field-Oriented Control diagram 4 System Inputs and Outputs The application interface can be viewed through two categories of signals. The first category contains vehicle-level commands exchanged over CAN. These signals define how the traction application is started, stopped, and commanded from the rest of the vehicle. The second category contains real-time electrical feedback and actuation signals exchanged with the inverter hardware.   Figure 4-1. Split the Simulink model to Inputs, Outputs and Application layers 4.1. Inputs The main vehicle-level inputs are received from the Central Node over CAN through the South Zone Controller. The command message contains the CCS_EnableMotors signal, used to engage or disengage the motors, and the CCS_SetSpeed signal, used to provide the desired speed reference for the control application.   Figure 4-2. CAN Message Unpack block for receiving the command signals   These CAN inputs are not part of the fast current-control loop, but they directly influence its behavior. Once decoded, the enable command defines whether the control logic is allowed to drive the inverters, while the speed reference becomes the target followed by the outer speed controller. The hardware feedback inputs are acquired from the inverter stages through ADC measurements. For each motor, two phase currents are measured using the dual-shunt method, while the third phase current is reconstructed in software using Kirchhoff’s Current Law. The DC bus voltage is measured for each inverter so the control, modulation, and monitoring logic remain aware of the available supply voltage.   Figure 4-3. Gathering analog quantities via ADC Block   4.2. Outputs The primary real-time outputs are the PWM commands used to actuate the inverter phases for both motors. The FOC algorithm computes the voltage commands required by each PMSM, and these commands are translated into duty cycles for the three-phase inverter. Because each inverter leg requires a high-side and a low-side control signal, the application ultimately drives six PWM signals per motor. These signals are generated from the MCU timing path and routed to the gate-driver stage that controls the external power switches.   Figure 4-4. PWM Actuation Subsystem   In addition to the PWM outputs, the application sends CAN data to the South Zone Controller every 0.1 seconds. These messages are intended for diagnostics, monitoring, and vehicle-level observability. The transmitted CAN data includes the estimated speed of each motor, the fault status reported by each control channel, the measured DC bus voltage for each inverter, the current operating state of each motor-control instance and many more. The following table highlights the output data sent over CAN bus:   Name Description Unit MC_BusVoltageM1 DC Bus Voltage measured by inverter for Motor 1 V MC_BusVoltageM2 DC Bus Voltage measured by inverter for Motor 2 V MC_FaultStatusM1 Fault status reported by Motor 1 true/false MC_FaultStatusM2 Fault status reported by Motor 2 true/false MC_PhACurrentM1 Phase A current – Motor 1 A MC_PhACurrentM2 Phase A current – Motor 2 A MC_PhBCurrentM1 Phase B current – Motor 1 A MC_PhBCurrentM2 Phase B current – Motor 2 A MC_PhCCurrentM1 Phase C current – Motor 1 A MC_PhCCurrentM2 Phase C current – Motor 2 A MC_SpeedEstM1 Motor 1 estimated speed rpm MC_SpeedEstM2 Motor 2 estimated speed rpm MC_SpeedRefM1 Motor 1 desired speed rpm MC_SpeedRefM2 Motor 2 desired speed rpm MCS_StateM1 Motor 1 state. It can be Stand By, Running, Fault - MCS_StateM2 Motor 2 state. It can be Stand By, Running, Fault - MCS_PhAVoltageM1 Phase A Voltage – Motor 1 V MCS_PhAVoltageM2 Phase A Voltage – Motor 2 V MCS_PhBVoltageM1 Phase B Voltage – Motor 1 V MCS_PhBVoltageM2 Phase B Voltage – Motor 2 V MCS_PhCVoltageM1 Phase C Voltage – Motor 1 V MCS_PhCVoltageM2 Phase C Voltage – Motor 2 V   Figure 3-5. Example for CAN Pack Message   5 Vehicle-Level Communication The Motor Control System is part of a distributed EV control architecture. It does not operate as an isolated controller. Instead, it receives high-level commands from the vehicle network and reports measured and estimated values back to the rest of the system. The communication path is organized around the CAN interface between the Central Node, the South Zone Controller, and the Motor Control System Node. Commands such as motor enable and desired speed are received through this path, while feedback messages such as estimated speed, DC bus voltage, phase-current information, and fault status are sent back through the same zonal communication route. CAN receive handling is interrupt-driven. When a command frame is received, the application decodes the enable and speed request signals and updates the internal command variables used by the Simulink control model. This keeps the command interface responsive without placing CAN processing inside the 100 microsecond FOC interrupt.   Figure 4-1. CAN Receive Interrupt block   CAN transmit handling is periodic. A PIT interrupt schedules outgoing monitoring messages every 0.1 seconds. This separates network reporting from the real-time control path and ensures that diagnostics transmission does not disturb the deterministic execution of the motor-control interrupts.   Figure 4-2. Periodic Interrupt for transmitting CAN messages   The CAN database defines the mapping between application variables and network messages. For example, the enable and speed command are grouped in dedicated message, while fault information, estimated speed, DC bus voltage, and phase-current feedback are exposed through dedicated monitoring messages. More information about the CAN database created for organizing the CAN messages and signals will be presented in a dedicated article.   6 Simulink Application Architecture The Simulink model is organized around a dual-control structure. Each motor channel contains the algorithmic blocks required to transform measured currents, estimate rotor position and speed, regulate the control loops, and generate voltage commands for PWM modulation. Although both channels implement the same FOC strategy, they are treated as separate execution paths. This separation makes it easier to scale from a single-motor setup to a dual-motor configuration and to validate each channel independently before running both motors together. 6.1. Real-Time Control Layer The real-time control layer is executed inside the BCTU-triggered interrupt flow. The BCTU is synchronized with the PWM timing generated by eMIOS, so the ADC conversions are requested at the correct moment within the switching period. Once the required current measurements are available, the interrupt allows the control algorithm to run using a coherent feedback set.   Figure 5-1. FOC Implementation   Inside this layer, the application reconstructs the three-phase current set, executes the Clarke and Park transformations, estimates rotor position and speed through the Extended EMF Observer, runs the speed and current PI controllers, and generates the voltage commands required by the modulation stage. The voltage commands are then translated into PWM duty cycles. eMIOS provides the base PWM generation, while the LCU forms the complementary high-side and low-side signals needed by the inverter legs. LCU also adds the necessary dead-time in complementary PWM signals to avoid the DC source damage. TRGMUX routes the required trigger signals between these peripherals, maintaining alignment between actuation and measurement.   Figure 5-2. Fast Loop Subsystem   The same execution concept is applied to the second motor channel. The two FOC instances run on the same S32K396 core, so the application depends on the MCU processing capability and on a carefully scheduled interrupt structure to complete both control paths within the available timing budget. 6.2. Communication and Monitoring Layer The communication and monitoring layer connects the fast control application with the vehicle network. It receives the enable and speed commands from CAN, prepares diagnostic information, and schedules outgoing status messages. This layer runs at a lower rate than the FOC loops. It is intended for command exchange, observability, and integration with the Central Node through the South Zone Controller. 6.3. Hardware Abstraction and Peripheral Layer The hardware abstraction and peripheral layer connects the generated Simulink application to the physical resources of the S32K396 MCU. Its purpose is to keep the control algorithm separated from the low-level hardware access, while still allowing the model to read measurements, update PWM outputs, handle interrupts, and exchange data over communication interfaces. In practice, this layer contains the target-specific blocks used for ADC acquisition, PWM generation, and CAN communication. These blocks provide the interface between the algorithmic part of the model and the peripherals configured on the MCU. This layer also makes the model easier to understand and maintain. The FOC subsystems can remain focused on control behavior, while the peripheral layer handles how signals enter and leave the MCU. As a result, the same architectural structure can be reused when moving between simulation, generated code, and target execution. The NXP Model-Based Design Toolbox provides the Simulink blocks that expose these S32K396 peripherals at model level. This allows engineers to configure and connect hardware-facing functions directly in Simulink, while the generated embedded code uses the corresponding target drivers and configuration.   7 Peripheral Mapping The peripheral mapping is centered on the synchronization between measurement, control execution, actuation, gate-driver communication, and vehicle-level CAN communication. Each peripheral has a specific role in this chain, and together they allow the generated Simulink application to interact deterministically with the inverter hardware. SAR-ADC is used to measure the analog quantities required by the control algorithm. These measurements include the phase-current feedback acquired from the inverter stages and the DC bus voltage used by the modulation and monitoring logic. BCTU (Body Cross Triggering Unit) performs the triggering of the ADC conversions. Instead of sampling the analog signals at an arbitrary moment, BCTU waits for the synchronization event coming from the PWM timing path and then starts the SARADC conversions at the correct point in the switching period. eMIOS (Enhanced Multiple Input Output System) generates the three phase PWM signals for each motor channel. These PWM signals represent the base timing generated from the duty cycles computed by the FOC algorithm. LCU (Logic Control Unit) takes the three PWM signals generated by eMIOS and creates the six PWM outputs required by the inverter. For each motor phase, it generates the complementary high-side and low-side control signals with dead-time insertion used to drive the corresponding inverter leg. TRGMUX provides the internal routing between peripherals. It connects the three PWM outputs from eMIOS to the LCU inputs and also routes the synchronization signal between eMIOS and BCTU. This routing keeps the actuation path and the measurement path aligned. LPSPI is used as the communication layer between the S32K396 controller and the MC33937 gate driver. Through this interface, the application can configure and exchange diagnostic information with the gate-driver device, complementing the direct PWM actuation path. FlexCAN provides the CAN communication controller used by the Motor Control System. It enables reception of command messages from the South Zone Controller and transmission of monitoring and diagnostic data back to the vehicle network. In this mapping, the fast motor-control path is formed by eMIOS, TRGMUX, BCTU, SARADC, and LCU, while LPSPI supports gate-driver interaction and FlexCAN supports vehicle-level communication. This separation helps keep the time-critical control loop independent from slower configuration, diagnostics, and network tasks.   Figure 6-1. Peripherals Mapping Overview   PIT (Periodic Interrupt Timer) peripheral is used for slower periodic activity, such as CAN diagnostics transmission every 0.1 seconds. CAN receive interrupts are used for incoming command messages from the South Zone Controller.   8 Data Flow The data flow starts at the vehicle network and at the analog feedback interface. CAN provides the high-level operating commands, while the inverter sensing path provides the real-time electrical feedback required by the FOC loops. When a CAN command is received, the enable and speed references are decoded and stored as application-level command variables. These signals are then consumed by the motor-control logic during the next control execution. In parallel, synchronized ADC conversions provide the latest phase-current and DC bus voltage values. The control algorithm reconstructs the motor currents, estimates rotor position and speed, transforms the feedback into the rotating reference frame, and computes the required voltage commands. The voltage commands are converted into PWM duty cycles and applied to the inverter actuation path. The resulting gate-drive signals control the external power stage, which drives the PMSM phases. At a slower rate, selected internal variables are packed into CAN monitoring frames. These values allow the South Zone Controller and Central Node to observe the Motor Control System state without interfering with the fast control-loop execution.   9 Conclusion This article described the architectural overview of the Dual-Motor EV Control System application. It presented the main Simulink model structure, the system inputs and outputs, the vehicle-level CAN communication path, the peripheral mapping, and the data flow between command reception, sensing, control, actuation, and monitoring. The architecture is built around two independent FOC control paths running on the S32K396 in a single-core configuration. Each motor channel receives synchronized analog feedback, executes its control algorithm every 100 microseconds, and generates the PWM outputs required by its inverter stage. By combining Model-Based design with target-specific peripheral integration, the application provides a scalable foundation for validating dual-motor traction behavior in simulation and on real hardware. The next article can build on this architecture by focusing on Model-in-the-Loop development and controller validation before deployment.   10 References Developing a Dual-Motor EV Control System with Model-Based Design Toolbox Software & Hardware Enablement for the Dual-Motor EV Control System Sensorless FOC with Motor Control Blockset Extended EMF Observer – Motor Control Blockset NXP Model-Based Design Toolbox for S32K3 NXP S32K396 microcontroller documentation AN14481: MCSPTR2AK396 3-phase PMSM Motor Control Kit with S32K396 Application Note

1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.

1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model.   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX

1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior.   Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation

  1 Introduction Turning a motor control concept into a running dual-motor traction real system requires more than a control algorithm. It requires a connected software and hardware environment that can take the design from simulation to generated code, from target deployment to real-time calibration, and finally to validation on physical motors. This article continues the Motor Control System series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks and NXP tools, software components, MCU resources, and power-stage building blocks that make the Dual-Motor EV traction system possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to model the field-oriented control algorithms, define the CAN communication interfaces, and support validation across simulation stages. NXP tools then bring those models onto the S32K396 target platform, connecting the generated application to real-time peripherals, gate-driver hardware, and motor feedback signals. Together, these elements form the development backbone of the dual-motor application: a path that starts with definition of the control strategy and ends with validation on real hardware. 2 Table of Contents • Software • Hardware • References • Conclusion 3 Software The software environment provides the modeling, simulation, communication, code generation, and deployment capabilities required by the Motor Control System. Each tool contributes a specific part of the development flow. 3.1. Motor Control Blockset Motor Control Blockset is the control-algorithm engine behind the traction application. It provides a ready-to-use environment for designing, simulating, and deploying motor control algorithms, while also supporting optimized C code generation from Simulink. In this Motor Control System, the MCB models the Field-Oriented Control strategy for Permanent Magnet Synchronous Motors. It supports the main control-loop blocks. These include Clarke and Park transforms, current and speed regulation, Space Vector Modulation, and position or speed feedback processing. The same model can run across desktop simulation and real-time validation. This keeps the controller consistent from early algorithm work to target execution. It also aligns the design across Model-in-the-Loop, Software-in-the-Loop, Processor-in-the-Loop, and hardware deployment stages. For more information, see the Motor Control Blockset documentation in the References chapter. 3.2. Vehicle Network Toolbox Vehicle Network Toolbox brings CAN communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding CAN messages. This makes network behavior visible and testable before deployment. In the Motor Control System, CAN exchanges commands, feedback, and status information. It links the ECU with the surrounding vehicle architecture. The toolbox helps define the signal interface, pack and unpack CAN frames, simulate bus traffic, and validate communication behavior before target execution. Communication is not treated as a late integration step. CAN interaction can be simulated and verified together with the control model. This reduces integration risk and makes ECU behavior easier to validate end to end. For more information, see the Vehicle Network Toolbox documentation in the References chapter. 3.3. NXP Model-Based Design Toolbox for S32K3 NXP Model-Based Design Toolbox for S32K3 connects the Simulink model to the NXP S32K3 target environment. It provides the embedded target support required to generate, build, download, and run applications on NXP microcontrollers. The toolbox provides peripheral blocks for hardware access. These include interfaces for ADC, PWM, CAN, SPI, UART, timers, interrupts, and other target resources used by motor control applications. For the Motor Control System, the toolbox enables the generated application to run on top of the S32K3 software stack. It also supports configuration flows based on NXP tools, real-time data visualization with FreeMASTER, and integration with optimized libraries such as AMMCLib. NXP Model-Based Design Toolbox for S32K3 is used as part of the enablement environment for the S32K3 complex applications. It provides the bridge between the model and the production-oriented embedded implementation. 4 Hardware The hardware environment provides the real-time execution platform and the power stage interface required to control the motors. The key hardware components are the NXP S32K396 microcontroller and the NXP MC33937 three-phase FET pre-driver. 4.1. The NXP S32K396 Microcontroller The NXP S32K396 is the main processing device used by the Motor Control System. It belongs to the S32K39 family of electrification microcontrollers and is optimized for traction inverter, torque vectoring, and smart actuation applications. The device combines real-time compute, motor control acceleration, advanced analog acquisition, high-resolution actuation, safety mechanisms, security services, and automotive networking in a single MCU platform. At the compute level, the S32K396 provides Arm Cortex-M7 processing resources running up to 320 MHz. The architecture supports safety-oriented execution through lockstep and split-lock configurations. This enables separation between safety-critical motor control tasks and additional monitoring or communication functions. For motor control, the device includes a dedicated motor control coprocessor called eTPU (Enhanced Time Processing Unit) and a programmable CoolFlux DSP. These resources can offload timing-critical functions from the main CPU. They support fast current-loop execution, resolver processing, PWM generation, analog sensing, and other functions required by high-performance FOC applications. The smart timer and I/O subsystem is also important for traction control. The S32K396 includes eFlexPWM modules with NanoEdge capability, eMIOS channels, Logic Control Units, and Body Cross-Triggering Units. These blocks help synchronize PWM generation, ADC triggering, fault handling, and real-time control events. The analog subsystem supports the feedback path of the inverter. It includes multiple SAR ADCs, Sigma-Delta ADCs, analog comparators, and sine wave generators. These resources are used to acquire phase currents, DC bus voltage, phase voltages, temperature signals, and position-related feedback. The communication subsystem enables integration with the vehicle network and external devices. The S32K396 provides CAN FD, Ethernet with TSN support, LIN/UART, SPI, I2C, QSPI, FlexIO, and Zipwire interfaces. In this Motor Control System, CAN is used for vehicle-level command and status exchange. Figure 4-1. S32K396 Block Diagram In the Motor Control System, the S32K396 executes the real-time control loops, reads current and voltage feedback, processes rotor position or speed information, generates PWM signals, and exchanges data with the vehicle network over CAN. The same platform can support one six-phase motor or two three-phase motors. This makes it suitable for the dual rear-motor architecture used throughout this article series. 4.2. The NXP MC33937 Three-Phase FET Pre-Driver The NXP MC33937 is the three-phase Field Effect Transistor pre-driver used between the microcontroller and the inverter power switches. It is designed for three-phase motor control and similar automotive actuation applications. The device contains three high-side FET pre-drivers and three low-side FET pre-drivers. Together, these six gate-drive channels control the external MOSFET bridge used by the three-phase inverter. The MC33937 interfaces with the S32K396 through six direct input control signals. These signals provide the fast phase control path from the PWM outputs of the microcontroller to the gate-driver stage. The device also includes an SPI interface. SPI is used for device setup, configuration, diagnostics, and safe control features. Reset, enable, and interrupt pins provide additional control and fault signaling between the pre-driver and the MCU. The MC33937 supports an extended operating range from 6 V to 58 V and is fully specified from 8 V to 40 V. This makes it suitable for 12 V and 24 V automotive systems, as well as higher-voltage transient operating conditions. The MC33937 also provides protection and monitoring features needed in motor control applications. These include undervoltage detection, overcurrent comparison, desaturation comparison, temperature limitation, phase voltage comparison, and protection against reverse charge injection from the external FETs. The device accepts both 3.3 V and 5 V logic-level inputs and provides 5 V logic-level outputs. This simplifies the connection with automotive microcontrollers and allows the pre-driver to fit into different control board designs. Figure 4-2. MC33937 Block Diagram In the Motor Control System, the MC33937 forms the actuation bridge between the PWM signals generated by the S32K396 and the three-phase inverter that drives each PMSM. It converts logic-level control commands into the gate-drive signals required by the external power stage. 4.3. NXP Evaluation Boards The Motor Control System hardware is built from modular NXP evaluation boards. This allows the same S32K396 control platform to be connected to one or two low-voltage three-phase inverter stages. Figure 4-3. NXP S32K396-BGA-DC1 The S32K396-BGA-DC1 evaluation board is the main controller board. It contains the S32K396 microcontroller in MAPBGA 289 package, an onboard debugger, communication interfaces, and the connectors required to access the real-time control signals. It is optimized for electrification applications such as traction drive and torque vectoring. The S32X-MB board is used as an I/O extension board. It is not a standalone development board. It must be used together with a compatible S32K39/37 evaluation board. In this setup, it expands the number of accessible peripherals and provides an additional motor control connector. Figure 4-4. S32X-MB Board The MCSPTR2AK396 kit provides the low-voltage motor control power stage used in the demo. From this kit, the demo uses the three-phase low-voltage pre-driver board and the PMSM motor. The power stage is based on the MC33937A pre-driver and is designed for BLDC or PMSM control. Figure 4-5. 3-Phase Low Voltage Motor Control Kit The kit also provides useful motor control interfaces. These include the three-phase motor output, Hall or encoder interface, resolver interface, DC bus sensing, phase voltage sensing, and protection feedback. These signals are required to close the control loop on the target hardware. 4.4. Dual-Motor Hardware Connections For the dual-motor hardware set-up, the S32K396-BGA-DC1 board provides the main MCU resources. The first three-phase motor control channel is connected through the primary motor control connector. The second channel is routed through the S32X-MB extension board. Each motor channel uses one low-voltage three-phase pre-driver and one PMSM motor. The PWM signals generated by the S32K396 are routed to the MC33937A gate-driver stage. The pre-driver then controls the external MOSFET bridge of the inverter. The feedback path is routed back from each power stage to the MCU. This includes phase current feedback, DC bus voltage, phase voltage, and position or speed feedback from the selected sensor interface. These signals are sampled and synchronized with the PWM events. The S32K396 therefore controls two independent three-phase inverter stages. Each motor has its own PWM outputs, sensing path, position feedback, and protection signals. The control software coordinates both channels and exchanges the resulting status information over CAN. This hardware arrangement can also be viewed as a scalable topology. The same MCU platform can be used for two independent three-phase motors or for one six-phase motor, depending on how the PWM outputs, sensing resources, and power stages are mapped. By connecting the software workflow with the hardware execution path, this enablement layer shows how a model-based motor control concept can be taken from algorithm design to a running dual-motor traction demonstrator on NXP silicon.   5 References Motor Control Blockset Documentation Vehicle Network Toolbox Documentation NXP Model-Based Design Toolbox for S32K3 S32K39-37-36 Microcontrollers for Electrification Applications MC33937: 3-Phase Field Effect Transistor Pre-Driver S32K396-BGA-DC1 Evaluation Board MCSPTR2AK396 BLDC/PMSM Motor Control Development Kit S32X-MB I/O Extension Evaluation Board 6 Conclusion This article described the software and hardware enablement required for the Motor Control System. The software environment combines MathWorks motor control and vehicle network capabilities with NXP target support. The hardware environment combines the S32K396 microcontroller with the MC33937 pre-driver and the inverter stage. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the dual-motor control application. The next article will focus on the architecture and model description of the Motor Control System, including the main control layers, signal interfaces, and application structure.

  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.

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