General Tip of the day Tip of the day  Licensing MBDT license missing error  Toolbox functionality Registers, Linkers not displaying options  Profiler/Execution S32k144 Simulation Time and Profiler  Peripherals How to put MCU into sleep? Apps Motor Control

General Installer and Setup  How to install the license of MBDT for S32K3?  How to setup the S32K344 toolbox and EVB?  How to export the generated code to S32DS3.4? Export generated projects in MBDT for s32k3XX  Programming methods MBDT for S32k3 using P&E Multilink Custom code usage SENT Protocol Support in S32K3 MBDT Custom project usage How to use custom project configuration Sequential reset S32K344-Q172 sequential reset SIL / PIL / External Mode External mode External mode example wouldn't compile after update  S32K3X4EVB-Q257 with MBDT PIL Example: Not able to run Simple PIL S32CT example Peripherals ADC How to add a new ADC channel using the external configuration tool  SPI How to send 32 bit frames  DIO S32K3x4-Q172P_with_MBDT_Blink_Project DIO and PWM configuration issues ICU PWM Duty cycle measurement PWM PWM raising edge and falling edge detection Interrupt based PWM generation CAN FreeMASTER over CAN connection issue  Apps Motor Control SPI configuration MODEL based design tool box- 32 bit instruction (SIMULINK) 

This page summarizes all Model-Based Design Toolbox topics related to the S32K3 Product Family. How to: Standby mode on S32K3 using NXP MBDT How to: MSDI MC33CD1030 on S32K396BMS-EVB using NXP MBDT 

This page summarizes all Model-Based Design Toolbox videos related to i.MX RT Product Family

Having fun with MBDT for MPC57xx 3.1.0 and MPC5744P for Xmas tree by controlling the lights and sounds

This video shows how to program the GPIO with Model Based Design Toolbox to obtain the speed reference for the BLDC speed closed loop control system.   We discuss about: - How to implement a simple program to read data from the GPIO - How to test in real time with FreeMaster - How to transform GPI pulses into a speed reference data that represents the rpm. - How to implement from scratch a Simulink model to cover the GPIO functionality NOTE: Chinese viewers can watch the video on YOUKU using this link. 注意：中国观众可以使用此链接观看YOUKU上的视频

  1. Introduction 1.1 A New Control Option For NXP Cup Race Car    NXP Cup car development kit is usually based on NXP's Freedom KL25Z board for motors control and image evaluation. However the control of the race car can be done with multiple NXP solutions.    In this article, a solution based on S32K144EVB board will be presented along with a programming approach based on MATLAB/Simulink Model-Based Design Toolbox for S32K. Additionally another tool provided by NXP - FreeMASTER - will be used to debug in real time the application.     As S32K144 pinout is not compatible with the default Landzo board pinout, an additional board to route the pins to the desired destination has been built. Complete details on the mapping of the pins are provided in the tutorial.   This article is structured as a tutorial detailing all the steps and providing all the source code to enable one to use this solution. However the control application is done very simple - on purpose - and uses just 10% of the speed to prove the concept.  Table 1. Freedom KL25Z vs. S32K144 features Freedom KL25Z Board Features S32K144 Board Features 32-bit ARM Cortex-M0+ core, up to 48 MHz operation 32-bit ARM Cortex-M4F core,  up to 112 MHz operation Voltage range: 1.71 to 3.6 V Voltage range: 2.7 V to 5.5 V • Up to 128 KB program flash memory • Up to 16 KB SRAM • Up to 512KB program flash memory • Up to 64 KB SRAM • Clock generation module with FLL and PLL for system and CPU clock generation • 4 MHz and 32 kHz internal reference clock • System oscillator supporting external crystal or resonator • Low-power 1kHz RC oscillator for RTC and COP watchdog •  4 - 40 MHz fast external oscillator (SOSC) with up to 50 MHz DC external square input clock in external clock mode •  48 MHz Fast Internal RC oscillator (FIRC) •  8 MHz Slow Internal RC oscillator (SIRC) •  128 kHz Low Power Oscillator (LPO) • 16-bit SAR ADC • 12-bit DAC • Analog comparator (CMP) containing a 6-bit DAC and programmable reference input  • Up to two 12-bit Analog-to-Digital Converter (ADC) with up to 32 channel analog inputs per module • One Analog Comparator (CMP) with internal 8-bit Digital to Analog Converter (DAC) •  Low-power hardware touch sensor interface (TSI) •  Up to 66 general-purpose input/output (GPIO) •   Non-Maskable Interrupt (NMI) •   Up to 156 GPIO pins with interrupt functionality • Two 8-bit Serial Peripheral Interfaces (SPI) • USB dual-role controller with built-in FS/LS transceiver • USB voltage regulator • Two I2C modules • One low-power UART and two standard UART modules   • Up to three Low Power Universal Asynchronous Receiver/Transmitter (LPUART/LIN) modules with DMA support and low power availability • Up to three Low Power Serial Peripheral Interface (LPSPI) modules • Up to two Low Power Inter-Integrated Circuit (LPI2C) modules • Up to three FlexCAN modules • FlexIO module for emulation of communication protocols and peripherals (UART, I2C, SPI, I2S, LIN, PWM, etc) • Six channel Timer/PWM (TPM) • Two 2-channel Timer/PWM modules • 2 – channel Periodic interrupt timers • 16-bit low-power timer (LPTMR) • Real time clock • Up to eight independent 16-bit FlexTimers (FTM) modules • One 16-bit Low Power Timer (LPTMR) with flexible wake up control • Two Programmable Delay Blocks (PDB) with flexible trigger system • One 32-bit Low Power Interrupt Timer (LPIT) with 4 channels • 32-bit Real Time Counter (RTC) • 4-channel DMA controller, supporting up to 63 request sources • 16 channel DMA with up to 63 request sources 1.2 Resources Model-Based Design Toolbox – Tool used to create complex applications and program the S32K144 MCU directly from the MATLAB/Simulink environment. This tool allows automatic code generation for S32K144 peripherals based on configuration of the Simulink model done by the user. S32K144-Q100 Evaluation Board – Evaluation board from the S32K14x family used for quick application prototyping and demonstration. NXP Cup Development Kit – Information about the hardware components of the development kit and instructions regarding the car assembling. Software which is helpful for the project design is also presented. FreeMaster Debugging Tool – Real-time data monitor tool which shows in both graphical mode (as a scope for example) and text mode the evolution of variables in time. It is suitable to monitor application behavior in real time during execution of the code.  TSL1401 Datasheet – Information regarding the camera configuration. Excel Spreadsheet (attached at the end of the document) with routing information to map pins from Landzo to S32K144 board. 2. Hardware Setup    After assembling all the hardware modules as indicated in the development kit the car will look like in the next image. It should be mentioned that for the S32K144 EVB to system board connection an S32K adapter board was created. Fig 1. Hardware setup 2.1  Hardware Modules    The hardware modules of this application and the way the peripherals of the S32K144 MCU are communicating with those is summarized in the Fig. 2. To understand more about the control of the motors, please check chapters 3.4.4 and 3.4.5. For learning how to debug the application using the Freemaster software, take a look at the chapter 4 where a detailed description is presented. A similar indication is given also for the camera information collecting. Chapter 3.4.1 and 3.4.2 provide a close-up image of the operations that need to be done in order to make the car “see”. Fig 2. System block diagram 2.2  Hardware Validation Steps    After connecting all the hardware modules, connect a USB cable to the PC. Connect other end of USB cable to mini-B port on FRDM-KEA at J7. When powered through USB, LEDs D2 and D3 should light green like in the picture below. Also, once the S32K144 board is recognized, it should appear as a mass storage device in your PC with the name EVB-S32K144.        Fig 3. LEDs to validate the correct setup 3. Model-Based Design Application 3.1  Application Description    The Model-Based Design approach consists of a visual way of programming, which is based on blocks. A block implements a certain functionality, such as adding two numbers. In case of the NXP's Model-Based Design Toolbox which is specifically developed for the S32K14x family, a block implements a functionality of a MCU peripheral, such as turning on the green led on the board. Each block has a different functionality and for a complex application, multiple components should be used together so they can provide the best solution for the problem proposed. For example, if you want to toggle the green led at every 10 seconds, you are going to add a new block to your design, one that can count those 10 seconds and then trigger an action when the count is over, which is toggling the led. Connection between the blocks should be made accordingly to your application system model. When building the model, the code that stands behind the blocks and implements the connection logic between them is automatically generated and downloaded on the embedded target. Doing so, code errors are certainly eliminated, and a faster design process is accomplished.    For using the Model-Based Design Toolbox for S32K, the MATLAB programming platform should be installed on the PC you are working on. Make sure that you respect all the System Requirements that you can find on the following link (Model Based Design Toolbox). Follow the installation steps from the Install and Configuration Steps and now you are ready to develop your own model-based design application.           3.2  Application Scheme    The generated code from the Simulink model is downloaded on the S32K144 MCU. A mapping between hardware and software for this application is illustrated in the figure below: Fig 4. Hardware to software mapping    The hardware components are controlled by the application through the peripheral functions of the S32K144 MCU. This board is connected to the other hardware modules by using an adapter board. In the link NXP Cup Development Kit there are information regarding how to connect the camera, servo and motors modules on the System and Driver Boards. Thus, the software generated signals are transmitted to the modules that need to be configured and controlled (camera, servo, motors). Fig 5. Application Scheme    When you open the Simulink model, this structure shown in Fig. 6 will be displayed. The functionalities are grouped in areas, which area containing a small description of what it is computed inside it. There are blocks and connections between them like mentioned before. Based on the image given by the camera, the steering and the speed of the car should be controlled. More details about how each of the subsystems works are provided in the following chapters. Fig 6. Simulink top level system 3.3 Application Logic    The application logic is described by the following block diagram. The signal from the camera is converted and the data is stored in an array. Based on the elements of the array (description of the image in front of the car), an algorithm will compute how much does the car have to steer its front wheels. This is expressed in a duty cycle value of a signal, signal which will be directly transmitted to the servo module. A constant speed, 10% of the maximum reachable of the car, it is also given as a duty cycle of the signal which will control the two rear motors. Fig 7. Application logic diagram   3.4 Simulink Model Components 3.4.1 Camera Configuration                 The camera module has a major importance in the project, because it is used to scan and process the track in front of the car. Firstly, for the main purpose of the application: control the car and maintain its position on the desired direction, the camera module should be configured so it can receive the analog signal properly. After the camera receives the analog signal, the application converts it into 128 digital values on the basis of which control decisions will be taken. There are 128 digital values for a conversion because the line scan camera module consists of a linear sensor array of 128 pixels and an adjustable lens. As specified in the datasheet, for the camera module configuration, two signals must be generated, a clock and a serial input (CLK and SI). Fig 8. Waveforms for camera configuration    To validate the functionality of this module, you should open the FreeMaster and check that the camera is working properly. Open the .pmp file and watch the conv variable evolving on the recorder. Put a white paper in front of your camera and then move an object in front of it. Every time the camera spots a dark color, its graphical evolution presents easy observable dips like in the picture below (blue graphic).                                                                                      Fig 9. Dips caused by dark objects CLK Signal    For the CLK signal generation, a FTM (FlexTimer) block is used. This block generates a PWM signal with a duty cycle given as an input (DTC – Dutcy Cycle Camera). The duty cycle has to be 0.5 (50%) as specified in the datasheet. The PWM signal is then passed to the corresponding pin of the camera module through the S32K144 board.    Check the Landzo_car pins to S32K144EVB file for the mapping and connections.     The frequency of the clock signal was chosen considering the imposed value range in the datasheet. (fclock between 5 and 2000 kHz).       Fig 10. Generating the CLK signal      When configuring the FTM block, the following block parameters will be available:                    Fig 11. FTM block parameters    The FTM functionality has 4 different modules, each of them with 8 channels grouped in pairs (for each channel an output pin can be selected). After checking the Landzo_car pins to S32K144EVB file for the corresponding pin of the camera CLK, the choice of the FTM module and the pair should be done (FTM0_CH1 means that the pin is connected to the FTM0 module, pair 0-1). It should also be mentioned that the camera module is connected on the CCD1 interface of the System Board in the hardware setup of this application. Another linear interface CCD2 is available for user usage, as specified in the description of the development kit. The frequency of the signal can also be set from the editbox in the Frequency Settings groupbox. An initial duty cycle value equal to 0.5 was set according to the datasheet.    There are two operation modes for each pair of channels and they can be chosen from the popup box next to the pair selection. These modes are called independent and complementary. Let’s give them a short description.    By setting channel n in the Complementary mode, the output for the channel n+1 will be the inverse of the channel n output and the block will have only one input. In the Independent mode, the channels have independent outputs, each one depending on the duty cycle given as an input on that channel (2 inputs for the block in this case). The CLK signal of the camera is transmitted to a single pin of the hardware module, so there is no need for two channels to be configured. Only one is enough to output the desired waveform (in complementary mode, only the first channel of a pair will be set; ex: channel 0, channel 2, channel 4, channel 6). That is why the Complementary option is chosen in this case. The input will be the 50% duty cycle on the basis of which the CLK signal will be generated. The channel 7 will now be the inverse of the channel 6 but in the next picture it can be observed that the channel 7 does not have a pin to output the signal to, because the inverted CLK signal is not needed in the current application.                   Fig 12. FTM output signals SI Signal      The SI signal’s period must provide enough time for 129 CLK cycles, as the timing requires (datasheet). 129 CLK cycles are needed with the purpose of acquiring 128 samples of the analog signal received by the camera. In order to meet all the specified conditions for a normal operation mode, the algorithm to create the CLK and SI waveforms as required uses two Periodic Interrupt Timers (PIT) blocks. Fig 13. PIT blocks    An interrupt represents a signal transmitted to the processor by hardware or software indicating an important event that needs immediate attention. The processor responds to this signal by suspending its current activities, saving its state and executing a function called an interrupt handler to deal with the event. The interruption is temporary, and, after the interrupt handler finishes, the processor resumes its normal activities.    A PIT block is used to trigger an interrupt handler to execute at every timeout of a counter. The Function-Call Subsystems linked to the PIT blocks represent the actions inside the interrupt handler. The interrupt handler will be triggered every Period(us). For the first PIT, it will be triggered every 20000us and for the second one every 100us. This means that every time the counter reaches the value specified in the block configuration parameters, the Function-Call Subsystem is triggered, the actions inside of it executed and the counter reinitialized. Fig 14. PIT block parameters    The PIT functionality has 4 channels, and they are implemented based on independent counters. The channel 0 is not available for user usage because it is configured to trigger the execution of the entire model at every period of time specified in the model configuration parameters.    The last checkbox from the block parameters is used to start the counter immediately after the application initialization, without waiting for other events.    Considering all the information mentioned above, the timing of creating the waveforms as required involves the following actions:      at every 100µs (CLK signal’s period) the next things happen: Fig 15. Actions in the 100us interrupt           C variable, which counts the clock cycles, is incremented; If C >=2, the SI signal is turned from high to low. (value 2 was chosen to keep the SI signal high for the convenient amount of time as specified by the tw, tsu, th and ts parameters. Their values can be found in the datasheet)                    Fig 16. Timing for camera configuration    A GPIO (General Purpose Input/Output) block is used for this and its role is to send the value given as an input to the selected pin which can be selected from the dropdown menu available in the block configuration parameters). Fig 17. Setting SI signal LOW Fig 18. GPIO block parameters A conversion is started and if C < 128, the converted values (analog-digital conversion of the received signal from the camera) are stored in an array of 128 elements (Store the converted values into an array subsystem is triggered) and into the conv array. Conv variable is used for the debugging process which will be later detailed.          at every 20ms (SI signal’s period) the next things happen:        SI signal is turned from low to high using the same GPIO functionality;       The clock cycles counter C is reinitialized;             Based on the values of the array (high values for white, low values for dark) and on their indexes, the duty cycle (DTS – Duty Cycle Servo) which controls the              Servo is computed (it controls the car to turn left or right with a certain angle); Fig 19. Actions in the 20ms interrupt 3.4.2 Camera Reading    After the camera module is configured (SI and CLK signals generated as specified), the data acquisition can be started. The signal given by the camera is converted into digital values which are stored in an array. The conversion implies the usage of the ADC (Analog to Digital Converter) functionality. Taking this into consideration, a configuration block for the ADC should be added to the Simulink model.         Fig 20. ADC configuration block    The ADC of the S32K144 has two modules (ADC0, ADC1) each of them with up to 16 external analog input channels and up to 12-bit conversion resolution. The camera module is connected to the CCD 1 linear interface of the System Board. The Landzo_car pins to S32K144EVB file specifies that the pin of the camera module which receives the analog signal is ADC1_CH10, so the ADC 1 module should be configured. A 12-bit conversion resolution was chosen for improving the accuracy of the sampled data.     An analog to digital conversion should happen every 100us as specified in the Timing section, because 128 samples of the input signal need to be acquired (every time the C variable is incremented, a value should be stored in the conversion array). Fig 21. Start of conversion    Considering the facts mentioned in the previous paragraph, every time the subsystem of the PIT block is triggered, the conversion is started (an ADC Start block is used) and if C < 128 the sampled data is stored into the array that will consist the information on which basis the servo control decision will be taken. Variable C is the index of the array elements and each result of the conversion represents the value of an element. Following this algorithm, the Y array is created and it is going to be used in the next chapter where the algorithm which computes how much the car should steer, based on the image of the track in front of it, is described. For putting the values into the array an assignment block is used. Fig 22. Storing conversion values to Y array     3.4.3 Camera To Steering Algorithm    The algorithm presents a basic approach and uses an if-else logic. Before giving it a short description, a couple of things should be mentioned.   Considering the reference voltage of the ADC module of the microcontroller which is 5V and the 12 bit resolution of the conversion, the resolution on a quantum is 5 / 4095. But the camera is powered by a voltage approximately equal to 3.4V, thus resulting a value which varies around 3.4 / ( 5/4095) = 2785. This value is the maximum that the ADC can provide when the camera spots white in front of it. The light conditions in the room represent a major factor that contributes to variations of this value.   The Servo of this kit needs a 20ms period PWM signal with the pulses duration equal to 600µs for a neutral position of the wheels, 400µs for the wheels turned maximum left, and 800µs maximum right. This results in the following values for the duty cycle (0.03 - the car goes forward, 0.02 – the car turns maximum right, 0.04 – the car turns maximum left). The 0.02 value should be replaced by 0.023 in order to obtain a proper operation mode due to the servo’s construction particularities.      The array with the converted values (Y) is iterated. If a dark value is found (the difference between ‘maximum white’ and the value of the current element is bigger than a threshold), the duty cycle is computed to determine how much right or how much left the front wheels should turn. If a dark value is spotted in the first half of the array, the car should turn right, or left if found in the other. But the camera gives the image from right to left so the turning ways are opposite (left if a dark value is spotted in the first half of the array, right for the second one).    After determining the way of the steering, left or right, the DTS is computed proportionally with the index of the array where a dark value is found. If a value representing a dark color is spotted at the beginning or at the ending of the array, it means that the what needs to be avoided is not exactly in front of the car, but more to one side of it, so a steering with a small angle should be effective in order to keep the car on the runway. On the other hand, if a small value is found more to the middle of the array, a wider angle of steering should be computed in order to ensure the avoidance of the dark color and the car moving off the track.     Fig 23. Matlab function for computing the DTS 3.4.4 Set The Servo    The DTS is then passed to another FTM_PWM_Config block to generate the signal needed to control the Servo.       Fig 24. FTM block for controlling the servo      In order to do so, the block should be configured with the following parameters, which have the same signification as mentioned in chapter 3.4.1:                 Fig 25. FTM block parameters    According to the hardware connections from the S32K adapter board and the current setup, only one Servomotor is used, and this is the STEERINGPWM1 mentioned in the file with the mapping between the Landzo car pins and the S32K144 board. The allocated peripheral for this module is the FTM0_CH1, which means that the module 0 should be chosen from the configuration parameters together with the 0-1 pair of channels. To control the servo, only one signal is needed, so there is no need to use 2 channels. The complementary mode could have been used here, like in the camera CLK signal configuration, but doing so, only the configuration of channel 0 would have been possible and channel 1 is requested for the application. By choosing the independent mode, a duty cycle input will be available for the both channels of the pair, and because only channel 1 is needed for the control of this module, an input equal to 0 will be given to the other one. The frequency is set to 50Hz considering the motor construction particularities and a duty cycle equal to 0.03 (wheels not steered) is set as an initial value.     Fig 26. FTM output signals 3.4.5 Set The Motors    For the two rear motors, the same principle applies. The duty cycle (DT) is configured by default at the 0.1 value which will cause the car to move along the track with 10% of its maximum speed.     The frequency of the PWM signal that controls the motors is 5000Hz. This value is in the range specified in the datasheet of the motor drivers mentioned in the schematics.                 Fig 27. FTM block for controlling the traction motors     For the control of a single motor, two signals are needed. The schematics of the Motor Driver board indicate that for the control of each motor two integrated circuits are used (BTN7960). They form an H bridge which looks as in the picture below.                 Fig 28. H bridge    To make the motor spin, the potential difference of the points the motor is connected between must be different from 0. It can be observed that each integrated circuit needs an input signal. The pins that give the input signals to the circuits are corresponding to the output channels of the FTM block. Let’s take for example the 1st rear motor. It is controlled by a FTM Config block which outputs on the following channels.                     Fig 29. FTM output signals    By setting and keeping channel 3 of the FTM Config block channels to 0, an input equal to 0 will be transmitted to one of the BTN modules as an input on the IN pin (for example, to the right one). This will trigger the right lower transistor to act like a closed switch. The transistor above it will remain opened, so the voltage of the OUT point will be 0V. The channel 2 corresponds to the other integrated circuit, and a positive input will be received by this one on the IN pin (left side of the picture). Now, the left upper transistor will act like a closed switch, and the one below will remain open, making the OUT point’s potential to represent a positive value (depending on the duty cycle given as an input to the FTM block). Thus, a potential difference is created and the motor will start spinning. 3.4.6 Configuration Block    In addition to all these, the model needs also a configuration block which is used to configure the target MCU, the compiler, the system clock frequency, etc. A configuration block is needed in all the models because it ensures the communication with the target. Fig 30. Model configuration block    The operation frequency can be chosen from the MCU tab of the block parameters window. For this model, it was set at 80Hz. The board model, the SRAM and the clock frequency can also be set from the MCU tab. Fig 31. Configuration block MCU tab    If you want to change the compiler and also the optimization levels, click the Build Toolchain tab and take a look at the available options presented in the picture below. From this tab you can also choose the target memory for the model which can be FLASH or SRAM.                   Fig 32. Configuration block Build Toolchain tab    The application is downloaded on the target through OpenSDA. OpenSDA is an open standard serial and debug adapter. It bridges serial and debug communications between a USB host and an embedded target processor. Make sure that the Download Code after Build option is checked in order to see your application running on the target.                   Fig 33. Configuration block Target Connection tab    For additional information about the blocks used in this model, right-click on them and choose the ‘Help’ option available in the menu. 4. How To Debug The Application Using FreeMaster    In order to use FreeMaster for debugging and managing the information from your application, a FreeMaster configuration block must be used in the Simulink model. Fig 34. FreeMaster configuration block    The block parameters should be configured as in the following picture: Fig 35. FreeMaster configuration block parameters    The interface field specifies the communication interface between the application and the FreeMaster. LPUART1 is chosen in this example because it is directly connected to the OpenSDA. OpenSDA is an open standard serial and debug adapter. It bridges serial and debug communications between a USB host and an embedded target processor.    The BaudRate represents the speed of data transmission between the application and the FreeMaster and it is expressed in kbps. The receive data pin and the transmit data pin should be always configured to PTC6, respectively PTC7 (for the LPUART1 interface) because these pins are connected to the OpenSDA Receive and Transmit pins, as specified in the HMI Mapping.       Fig 36. OpenSDA to LPUART1 connection    By clicking the Show Advanced Options checkbox, multiple settings are available and their functionalities are all specified in the Help file which will open after clicking the Help button in the Block Parameters tab.    The variables that need to be observed changing over time must be declared Volatile. The variables already added to the FreeMaster project are declared using the Data Store Memory block.                 Fig 37. Global Variables    The Volatile option can be chosen from the Block Parameters Tab. After double clicking the Data Store Memory block, click the Signal Attributes tab and in the Code Generation groupbox, set the Storage Class option to Volatile (Custom), as in the picture below.  Fig 38. Data store memory block parameters    For calling the FreeMaster data acquisition each time a subsystem is triggered, a FreeMaster Recorder Call block should be added in the subsystem where the variables that you want to record are computed. Thus, a recorder block is placed in the subsystem which is triggered at 100us for recording the evolution of C and conv variables. Fig 39. FreeMaster recorder call    To check the functionality of the FreeMASTER, open the .pmp file with the same name as the Simulink model and click on the red STOP button in order to initialize the communication with the S32K144 evaluation board. Fig 40. Start/Stop FreeMaster communication    If errors appear, click on the Project menu and open the Options window. Make sure that the port value is the same as the one on which your S32K144 is connected (you can check the COM number of the evaluation board in the Device Manager window). Make sure also that the Speed is the same as the baud rate of the FreeMaster Config block.       Fig 41. FreeMaster communication setup    Click on the MAP Files tab and ensure that the default symbol file is the .elf file from the folder that is created when you build your Simulink model. It should be called (your_model_name.elf).           Fig 42. FreeMaster .elf file    Once the connection is set and the app working, you will observe how the values of the variables in the Variable Watch are changing.    Click on the Recorder option from the left side of the window in order to see the graphical evolution of the variables.    You can add or remove variables from the watch by right-clicking inside the Variable Watch area and choosing the Watch Properties options.    Right clicking on the Recorder will provide a Properties option as well. Use that for selecting the variables that you want to display and for many other options.           Fig 43. FreeMaster recorder properties 5. Autonomous Intelligent Car Demonstration And Hints For Improvement 5.1 Demo    If you want to make sure that everything works as it is supposed to before actually putting the car on the track, you can use the FreeMaster tool to visualize the evolution of the variables of your project. Considering every setup was made as specified, here is what you should expect to see. Fig 44. Variable Watch    The two rear motors duty cycle and also the one for the camera CLK signal should have constant values all the time (0.1 respectively 0.5). The DTS should vary its values between 0.023 and 0.04 as mentioned in the Camera to Steer algorithm chapter. C variable must be incremented every 100us and reset every 20ms, this meaning that when it reaches 200, it should be set back at 0. This evolution can also be graphically observed by using the recorder option. Conv variable and Y array represent the conversion result and all the bottoms of the conv graphical evolution represent the existence of a dark color in the visual field of the car.    A demonstration video with the car following the track for a lap is attached to the current content.   5.2 Improvement Areas    The application proposed uses a basic if-else algorithm in order to compute the steering of the front wheels based on the track in front of the car. A proof of the concept that the vehicle can be controlled and kept on the path using a S32K144 board and a Model Based Design approach is realized in the presented solution. Major improvements regarding the lap time could be achieved by developing a way to control also the car speed which now is at a constant value. Many other hardware and software solutions can be designed and implemented with the purpose of obtaining the fastest autonomous self driving car for the NXP Cup. NXP CUP - LINE FOLLOWER WITH MODEL-BASED DESIGN TOOLBOX FOR S32K MICROPROCESSOR

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

1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. Figure 5. Embedded Coder. Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.

    1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion     2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.     3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller.   The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior.     4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads     5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator       6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT)     7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.

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

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

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

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

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

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

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

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

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

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