恩智浦基于模型的设计工具知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

NXP Model-Based Design Tools Knowledge Base

讨论

排序依据:
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for LAX – version 1.2.0 RTM   The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for LAX version 1.2.0 RTM. This release supports automatic code generation for ARM Cortex-A53 and NXP LAX Accelerator cores from MATLAB for NXP S32R45 Automotive Microprocessors. This release adds support for RSDK 1.2.0, improves to code generation and Radar processing demo, and adds support for new trigonometric LAX kernels. The product comes with 60 examples, covering the supported RSDK LAX Kernels by MATLAB API and demonstrating the programming of the LAX accelerator from MATLAB environment.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983168   Technical Support: NXP Model-Based Design Toolbox for LAX issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content: Automatic C code generation from MATLAB® for NXP S32R45: ARM Cortex-A53 NXP LAX Accelerator Support Linux application build and run NXP Auto Linux BSP 37.0 for S32R45 Includes MATLAB API for additional RSDK LAX Kernels highly optimized for LAX accelerator add, sub, mul, div, times, cT, inv abs, abs2, sqrtAbs ¸conj, norm, norm2 diag, eye, zeros, ones, find, sort cospi, sinpi, tanpi, cispi, sincpi acospi, asinpi, atanpi, atan2pi Improved code generation and reduced memory usage Support for Radar SDK version 1.2.0 Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a More than 60 examples showcasing the supported functionalities: Cholesky Gauss-Newton Eigen (new) Kalman Filter Linear Regression Navier-Stokes QR Factorization (updated) MUSIC DoA (updated) Radar processing demo (updated) Range FFT, Doppler FFT, and Non-Coherent Combining offloaded to NXP SPT accelerator MUSIC DoA offloaded to NXP LAX accelerator     For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® experience by allowing customers to evaluate and use NXP LAX Accelerator from NXP’s S32R45 MPU and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for LAX version 1.2.0 is fully integrated with MATLAB® environment.       Target Audience: This release (1.2.0 RTM) is intended for technology demonstration, evaluation purposes, and prototyping on NXP S32R45 MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt    
查看全文
Wanna see & play something cool ?  You can see it live in June during Mathworks Expo:  - Munich, Germany on June 27th  - China on June 20th an 27th If you want more details - leave a comment below Check our video showing the demo:  Video Link : 7851 
查看全文
BLDC OpenLoop Voltage Control example for MPC574xP(Panther)+MotorGD Features: - Commutation based on HALL sensor transitions - Voltage read via SW1(++) and SW2(--) - Voltage can be read from POT if VoltageReqSource=0 - Motor can rotate CW (default) or CCW via SW1/SW2 Copyright (c) 2017 NXP version 1.0.1 Model Based Design ToolBox
查看全文
This video shows the main differences between basic and advanced modes for peripheral configuration
查看全文
Having fun with MBDT for MPC57xx 3.1.0 and MPC5744P for Xmas tree by controlling the lights and sounds
查看全文
This video highlights the main features added in the version 4.1.0 of the NXP Model-Based Design Toolbox for S32K1xx Series
查看全文
Get to know NXP Model-Based Design Toolbox™—a connection between MathWorks and NXP ecosystems that allows rapid prototyping of complex embedded designs on NXP microcontrollers. In this presentation, @Irina_Costachescu and @mariuslucianand  will highlight the main features of the NXP Model-Based Design Toolbox. They will demonstrate how to design a BMS application, covering the main development phases from an idea to a running on target prototype. Register here: https://www.matlabexpo.com/online/2022.html 
查看全文
Announcing the introduction of the Model Based Development Toolbox for MATLAB/Simulink MBD supporting MagniV S12ZVC.  The model based development toolbox is a comprehensive collection of tools that plug into the MATLAB®/Simulink® model-based design environment to support rapid application development with NXP® MCUs. OVERVIEW The model based development toolbox offers support for motor control application development, enabling control engineers and embedded developers to help shorten project life cycles. The model based development toolbox includes: Integrated Simulink®-embedded target supporting NXP MCUs for direct rapid prototyping and processor-in-the-loop (PIL) development workflows Peripheral device interface blocks and drivers Bit-accurate simulation results in the Simulink simulation environment The model based development toolbox generates all the code required to start up the MCU and run the application code, while supporting builds with multiple compilers. TARGET APPLICATIONS Aerospace and defense Automotive control design Embedded system development Industrial automation Machinery real-time systems FEATURES Built-in support for direct code download to the target MCU through the RAppID Boot Loader utility Complimentary license Built-in support for NXP FreeMASTER—a real-time debug monitor and data visualization tool interface. It provides visibility into the target MCU for algorithm calibration and tuning, making it ideal for advanced control systems, with: Monitor signals in real time on the embedded target Data logging Signal capture Parameter tuning Simulink blocks supporting: ADC CAN Custom Initialization DAC Data Memory Read/Write Digital I/O FreeMASTER Data Recorder I2C Profiler PWM SCI SPI TIM PRODUCT REQUIREMENT MATLAB® (32-Bit or 64-Bit)* Simulink MATLAB coder Simulink coder Embedded coder Support available via the NXP community at: https://community.nxp.com/community/mbdt Download the tool at www.nxp.com/mctoolbox
查看全文
Speed up development time with NXP Model-Based Design Toolboxes
查看全文
This short video shows how a NXP CUP Car can be controlled via an application developed with Model Based Design Toolbox for S32K microprocessors
查看全文
Short unedited video - showing the Model Based Design at work on our custom demo platform created with the scope of supporting various scenarios testing.
查看全文
A short - 1 minute - Motor Control Class introduction that highlight the main topics and objectives of the training series NOTE: Chinese viewers can watch the video on YOUKU using this link. 注意:中国观众可以使用此链接观看YOUKU上的视频
查看全文
Introduction   The following article shows a basic configuration for S32K3 that allows the MCU to transition from RUN mode to a Standby mode.   Prerequisite software   The following software tools were used to develop and deploy the application onto the S32K3 board. MATLAB® R2023b or later Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ® Support Package for ARM ® Cortex ® -M Processors S32K3 MBDT Toolbox Version 1.8.0 FreeMASTER Run-Time Debugging Tool   Prerequisite hardware   The application is developed for the following hardware*: X-RD-K344BMU (MCU: S32K344-Q257) Debug probe (used to deploy the example and to connect the FreeMASTER application to the board) 12V power supply Jumper Wire   Configuration project   In this chapter, I show most important settings that must be to allow the MCU to enter standby mode and to be able to wake up and switch to RUN mode again. For more details, please download the files attached and consult the configuration project. Pins configuration Two pins must be configured for this application: Signal wkpu,14  (of WKPU peripheral) to the PTB17. Direction: Input Pull Select: Pullup Pullup Enable: Enabled Signal gpio, 65 (of SIUL2 peripheral) to the PTC1. Direction: Output     Figure 1. Configuration Pins tab - Dio_Pins_MBDT Functional Group   Clocks configuration A new Functional Group must be created for the Standby Mode. This can be done from the Clocks tab (as shown in the image below).   Figure 2. Configuration Clock tab - Create new Functional Group   Peripherals configuration Dio component   Figure 3. Configuration Dio Component - DioGeneral     Figure 4.  Configuration Dio Component - DioChannel Wkpu_DioChannel     Figure 5.  Configuration Dio Component - DioChannel Green_Led_DioChannel   Port configuration The Port configuration must match the settings configured in the Pins tab (check Pins Configuration chapter).   Figure 6. Configuration Port component - PortPin Wkpu_PortPin     Figure 7. Configuration Port component - PortPin Green_Led_PortPin   Mcu configuration A new McuModeSettingConf must be created. It is going to be used to switch to STANDBY mode.   Figure 8. Configuration Mcu component - McuModuleConfiguration -> McuModeSettingConf   A new McuClockSettingConfig must be created. The MCU will use to this clock tree when it is in standby. All the settings in this newly created McuClockSettingConfig must match the settings made in Clocks tab.     Figure 9. Configuration Mcu component - McuModuleConfiguration -> McuClockSettingsConfig   Make sure that for the new McuClockSettingsConfig, in the configuration tab, the Functional Group created in Figure 2 is selected.     Figure 10. Configuration Mcu component - McuModuleConfiguration -> McuClockSettingsConfig -> Configuration     ICU configuration     Figure 11. Configuration Icu component - IcuConfigSet -> IcuChannels   Note! The first 4 Hardware Channel are internally routed. For the evaluation board that I used, the PTB17 corresponds to the WAKE_14. In the configuration project, the hardware channel must be set to CH18 (to offset the first 4 internally routed hardware channel).     Figure 12. Offset internally routed hardware channels     Figure 13. Configuration Icu component - IcuConfigSet -> IcuWkpu -> IcuWkpuChannels     Figure 14. Configuration Icu component - IcuConfigSet -> IcuHwInterruptConfigList   Model configuration   The Simulink model used to switch from RUN mode to STANDBY mode can be seen in the picture below. It can also be found in the achieve attached to this article. The application executes the following tasks at each steps: Toggle the LED to visually tell if the board is running or in standby mode Increment a variable Check if the enter_standby variable is set to 1. If true, the sequence to enter standby mode is executed.   Figure 15. Simulink Model S32K3_Standby_GPIO_Wkpu     Figure 16. Enter Standby mode routine     Figure 17. Custom code to enter standby mode   Validation   To validate the application, the FreeMASTER tool is used to connect to the board and initiate the sequence to enter standby mode. To connect the board, I used the debug probe.   Figure 18. Connect FreeMASTER tool to the board using debug probe   If everything is properly configured, the FreeMASTER should now be connected to the board. In the Variable Watch, the value of the counter variable is increased each second.  To enter standby mode, the value of the enter_standby variable must be set to 1. If the sequence to enter standby mode is correctly executed, the value of the counter shouldn't be updated anymore and the LED should stop blinking. Also, the board is disconnected from the FreeMASTER board. To exit standby mode, use the jumper wire to connect the PTB17 to a GND pin. The LED should start blinking.   Conclusion   In this article, I presented a basic implementation that allows the S32K344 to enter standby mode. The configuration presented here doesn't maximize the power savings, as the user should take care of putting the pins in a floating state, disable all unnecessary clocks and many more. For further details, please consult the S32K3 reference manual.   This application was based on the examples found in this article: S32K3 Low Power Management AN and demos. Kudos @Shuang!
查看全文
Introduction The following article shows a basic configuration and model for S32K396BMS-EVB that configures the SPI to communicate with the MC33CD1030 MSDI IC mounted on the evaluation board.   Prerequisite software The following software tools were used to develop and deploy the application onto the S32K396BMS-EVB board. MATLAB® R2024b or later Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ® Support Package for ARM ® Cortex ® -M Processors S32K3 MBDT Toolbox Version 1.4.0 BMS MBDT Toolbox Version 1.2.0 FreeMASTER Run-Time Debugging Tool   Prerequisite hardware The application is developed for the following hardware*: S32K396BMS-EVB Debug probe (used to deploy the example and to connect the FreeMASTER application to the board) 12V power supply   Configuration project In this chapter, I show most important settings that must be to allow the MCU to enter standby mode and to be able to wake up and switch to RUN mode again. For more details, please download the files attached and consult the configuration project.   Pins configuration   For the CD1030, only the SPI pins must be configured; LPSPI3 PCS1: PTF18 (OUTPUT) LPSPI3 CLOCK: PTF13 (OUTPUT) LPSPI3 SIN: PTF12 (INPUT) LPSPI3 SOUT: PTF15 (OUTPUT)   Figure 1. Configuration Pins tab - LPSPI pins   Peripherals configuration Platform component The interrupt must be configured for the LPSPi3. To configure it, please go to PLATFORM -> Interrupt Controller and add a new entry into the table, as below. Figure 2. Configuration Platform Component - Enable LPSPI3 interrupt   MCU Component The peripheral clock must be enabled and it can be done from the MCU component -> McuModuleConfiguration -> McuModeSettingsConf. Figure 3. Configuration MCU Component - Enable LPSPI3 peripheral clock   SPI Component The MCU communicates with MC33CD1030 over the LPSPI3. First step is to configure the Spi -> SpiGeneral -> SpiPhyUnit Figure 4. Configuration SPI Component - SpiPhyUnit (LPSPI3)   Then, the Spi->SpiDriver must be configured. Important! The frame size of the SPI messages: It must be 32-bit wide and MSB. Figure 5. Configuration SPI Component - SpiChannel   Figure 6. Configuration SPI Component - SpiExternalDevice   Figure 7. Configuration SPI Component - SpiJob   Figure 8. Configuration SPI Component - SpiSequence   Model configuraiton The Simulink model used to communicate with the MC33CD1030 can be seend in the picture below. It can also be found in the achieve attached to this article. The initialization of the model sets the AsyncMode to interrupt. Figure 9. Simulink Model - Initialization subsystem   The application executes the following tasks at each step: Set up the External Buffer for the LPSPI3 SpiChannel_CD1030. The input for the block must be an array of 4 uint8 elements (in total 4 bytes - 32bit). The control word is the last element, while the first 3 elements are the configure words. The Dest Data output is a data story memory configured as uint8 with the size equal to 4.  Send the command to the MC33CD1030 IC and receive the previous result in CD1030_RecvData_SG data store Increment a variable to check that the application is running   Figure 10. Simulink Model - Full Overview   Validation To validate the application, the FreeMASTER tool is used to connect to the board and initiate the sequence to enter standby mode. To connect the board, you can use the LPUART1 (J6 connector), baud rate 115200. If everything is properly configured, in the FreeMASTER you should see the following in the Variable Watch: The SPI_SetAsyncMode_Status, CD1030_SetupEB_Status and SPI_Transmit_Status should all be 0. The CD1030_RecvData_SG (BIN) and CD1030_RecvData_SG (HEX) should display the content of the CD1030's register 0x3E Read switch status registers SG. The step_counter should increment at each step execution. Figure 11. FreeMASTER Project - Variable Watch   To test that the CD1030 is working, I connect the J10_6 (SG0 - KEY_ON_DIN) to either GND or VCC and we can see that the last bit of the register changes.  Figure 12. FreeMASTER Project - J10_6 connected to GND  Figure 13. FreeMASTER Project - J10_6 connected to VCC   Conclusion   In this article, I presented a basic implementation that allows the S32K396 communicate with the MC33CD1030 IC over the SPI. For further details, please consult the MC33CD1030 reference manual.
查看全文
Table of Contents 1. Introduction 2. Requirements 2.1 Software Required 2.2 Hardware Required 3. NXP Account Login 4. Installation 4.1 PEmicro Driver Installation 4.2 FreeMASTER Installation 4.3 MATLAB® Installation 4.4 MATLAB® Add-Ons Installation 4.5 MBDT for S32K3 v1.8.0 Installation 5. Running a Demo from the MBDT Examples for S32K3 6. Running a Motor Control Demo using MBDT 7. Conclusion 1. Introduction This article aims to help new users prepare and install the necessary software and hardware to use the FRDM Automotive S32K312 with the latest  Model-Based Design Toolbox for S32K3 version 1.8.0. Note: These steps can also be followed with any NXP Evaluation Board from the supported list referenced in the toolbox documentation. S32K312MINI‑EVB Renamed to FRDM‑A‑S32K312: Now part of the FRDM Automotive Ecosystem under its new name, the board keeps the same hardware and adds full ecosystem compatibility for flexible, scalable development.     2. Requirements   2.1 Software Required MATLAB® R2023b or later, with the following Add-ons: AUTOSAR Blockset Embedded Coder Support Package for ARM Cortex-M Processors Motor Control Blockset NXP_Support_Package_S32K3 Stateflow NXP Model-Based Design Toolbox for S32K3 version 1.8.0 FreeMASTER Run-Time Debugging Tool PEmicro Hardware Interface Drivers   2.2 Hardware Required FRDM-A-S32K312 Development Board MCSPTE1AK344 Motor Control Kit, which includes: Sunrise motor  DEVKIT-MOTORGD  12V power supply USB Type-C cable   3. NXP Account Login Open Software Licensing: Support, make sure you are logged into your NXP Account, and select: Click on My NXP Account. Select Software Licensing and Support. Then click on View accounts: These steps will ensure that you are properly authenticated with your NXP Account before proceeding with step 4.5 MBDT for S32K3 v1.8.0 Installation. Keep the page open for the login to persist.   4. Installation Note: Before proceeding, make sure you have full access to your PC or Laptop. Some installers require local admin rights. Contact your IT department to assist you with installation.   4.1 PEmicro Driver Installation After downloading the PEmicro Hardware Interface Drivers: Open the installer package and select the default Destination Folder: Click on Install and then wait for it to finish successfully. Connect the USB cable to your PC and the FRDM Automotive S32K312 board: Open Device Manager to check OpenSDA and the COM port number. OpenSDA - CDC Serial Port → note this COM port number: Note: The COM port number may differ on your system.   4.2 FreeMASTER Installation Download the  FreeMASTER Run-Time Debugging Tool:   Open the installer FMASTERSW32.exe Click Next, then select all available products: Use the default installation path: C:\NXP\FreeMASTER 3.2 Wait for the installation to complete.   4.3 MATLAB® Installation First, check whether MATLAB® R2023b or later is already installed. If so, you can skip this section. For this tutorial, MATLAB® R2025b is downloaded from MathWorks®: Download the matlab_R2025b_Windows.exe (246 MB) file. A MathWorks® Account login is required. After signing in, select the installation directory; the default is C:\Program Files\MATLAB\R2025b For minimum requirements, install the following products: MATLAB® Simulink® AUTOSAR Blockset Embedded Coder MATLAB® Coder Motor Control Blockset Simulink® Coder Stateflow By default, Select All is enabled during install: Wait for the installation to finish. After installation, open MATLAB® and change the default Add-ons path to a shorter path such as C:\MathWorks .   4.4 MATLAB® Add-Ons Installation Open Add-On Explorer and install: Embedded Coder Support Package for ARM Cortex-M Processors NXP Support Package for S32K3 (NXP_Support_Package_S32K3)   4.5 MBDT for S32K3 v1.8.0 Installation After installing the support package, run the following command in MATLAB®: sp_s32k3.nxp.setup(); Select version 1.8.0; the installer will check prerequisites: If any toolboxes are missing, install them before continuing. Click Download to proceed. The Download button opens the Software Terms and Conditions dialog; if the page is not loading properly, follow the steps in 3. NXP Account Login. After reading, click I Agree. Download the SW32_MBDT_S32K3_1.8.0_D2512.mltbx file (approx. 1.6 GB): Once the download completes, browse to the location of the SW32_MBDT_S32K3_1.8.0_D2512.zip file: Click Install to proceed and accept the license agreement. After a few minutes, the dialog will display: Installation successfully completed! Click Next. Select an option such as Open S32K3 Root Folder. MATLAB®'s current folder will change to the root of the toolbox. Click Finish to close the installer. The current folder in MATLAB® is now C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3 :     5. Running a Demo from the MBDT Examples for S32K3 Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\demos\s32k3xx_uart_leds_s32ct Open the model s32k3xx_uart_leds_s32ct.mdl . Click on Hardware Settings: Go to Hardware Board Settings → Hardware → Select Configuration Project Template: For the FRDM-A-S32K312 select Custom: S32K312MINI-EVB S32 Config Tool. A Warning Dialog will appear; click OK. Wait for the configuration update to complete. Click on Apply and close the Configuration Parameters window. Press Build, Deploy & Start (CTRL+B) to generate the code: After the build completes successfully, the executable is downloaded to the board. Open a terminal application and connect to the board's COM port at 115200 baud: Pressing r, g, or b on the keyboard toggles the corresponding RGB LED on the board.   6. Running a Motor Control Demo using MBDT Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\mc\PMSM Open the folder s32k312_mc_pmsm_2sh_s32ct : Open the model s32k312_mc_pmsm_2sh_s32ct.mdl : Press Build, Deploy & Start (CTRL+B) to generate the code. After the executable file is downloaded to the board: Disconnect the FRDM-A-S32K312 board from the PC. Insert the DEVKIT-MOTORGD on top of the FRDM-A-S32K312, ensuring proper pin alignment. Plug in the 12V power supply to the DEVKIT-MOTORGD. Reconnect the USB Type-C cable to the FRDM-A-S32K312.  The RGB LED and User Buttons are on the top side, the Reset Button is on the left side, while the 12V power, Motor Phases, and USB Type-C are on the right side.    Open FreeMASTER s32k312_mc_pmsm_2sh_s32ct.pmpx : Press GO to connect at 115200 baud. In the App Control tab, press On and set Speed Required to 1000 RPM: Apply a small mechanical load to the motor (friction force to the motor shaft) and observe the iABC currents. Here is a short video with the steps above explained:   7. Conclusion These steps conclude the Getting Started with FRDM Automotive S32K312 using the Model-Based Design Toolbox guide. For more details, refer to: s32k312_mc_pmsm_2sh_s32ct_example_readme.html The corresponding example_readme.html for the selected model. Thank you for your time, Stefan V.
查看全文
    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 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement.     3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation.     4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent.   Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate.     5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors     6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.
查看全文
    1 Table of Contents • 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 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.
查看全文