NXPモデルベース・デザイン・ツールナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

NXP Model-Based Design Tools Knowledge Base

ディスカッション

ソート順:
Hello all, sharing the latest version of S12ZVM Power Dissipation Calculator started by Carlos Vazquez and Anita Maliverney. With this excel sheet is possible estimate the power dissipated for any MCU of S12ZVM family, considering: supply voltages, digital modules, gate drive unit, charge pump, communication transceivers, etc.   Updated static and dynamic consumption current of S12ZVMC256, S12ZVM32 and S12ZVMB. Regards.
記事全体を表示
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
記事全体を表示
This video highlights the main features added in the version 4.1.0 of the NXP Model-Based Design Toolbox for S32K1xx Series
記事全体を表示
Having fun with MBDT for MPC57xx 3.1.0 and MPC5744P for Xmas tree by controlling the lights and sounds
記事全体を表示
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
記事全体を表示
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   SorinIBancila_0-1768495197748.png   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). SorinIBancila_1-1768495588172.png   Figure 2. Configuration Clock tab - Create new Functional Group   Peripherals configuration Dio component SorinIBancila_2-1768495758362.png   Figure 3. Configuration Dio Component - DioGeneral   SorinIBancila_3-1768495793846.png   Figure 4.  Configuration Dio Component - DioChannel Wkpu_DioChannel   SorinIBancila_4-1768495810080.png   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). SorinIBancila_5-1768496114620.png   Figure 6. Configuration Port component - PortPin Wkpu_PortPin   SorinIBancila_6-1768496160497.png   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. SorinIBancila_0-1768496372309.png   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.   SorinIBancila_1-1768496567805.png   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.   SorinIBancila_3-1768496798654.png   Figure 10. Configuration Mcu component - McuModuleConfiguration -> McuClockSettingsConfig -> Configuration     ICU configuration   SorinIBancila_4-1768496907799.png   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).   SorinIBancila_7-1768497314930.png   Figure 12. Offset internally routed hardware channels   SorinIBancila_5-1768496989125.png   Figure 13. Configuration Icu component - IcuConfigSet -> IcuWkpu -> IcuWkpuChannels   SorinIBancila_6-1768497048517.png   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. SorinIBancila_9-1768497588515.png   Figure 15. Simulink Model S32K3_Standby_GPIO_Wkpu   SorinIBancila_11-1768497753974.png   Figure 16. Enter Standby mode routine   SorinIBancila_12-1768497853446.png   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. SorinIBancila_14-1768498313050.png   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!
記事全体を表示
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上的视频
記事全体を表示
Short unedited video - showing the Model Based Design at work on our custom demo platform created with the scope of supporting various scenarios testing.
記事全体を表示
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. FRDM-A-S32K312-Details.png     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. stefanvlad_4-1766413667183.png Then click on View accounts: stefanvlad_5-1766413890382.png 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: stefanvlad_1-1766419738640.png Click on Install and then wait for it to finish successfully. Connect the USB cable to your PC and the FRDM Automotive S32K312 board: FRDM-A-S32K312-Connect.png Open Device Manager to check OpenSDA and the COM port number. OpenSDA - CDC Serial Port → note this COM port number: stefanvlad_2-1766420223283.png Note: The COM port number may differ on your system.   4.2 FreeMASTER Installation Download the  FreeMASTER Run-Time Debugging Tool: stefanvlad_3-1766420635579.png   Open the installer FMASTERSW32.exe Click Next, then select all available products: stefanvlad_3-1766483372281.png Use the default installation path: C:\NXP\FreeMASTER 3.2 stefanvlad_5-1766483553297.png 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®: stefanvlad_1-1765986670126.png Download the matlab_R2025b_Windows.exe (246 MB) file. A MathWorks® Account login is required. stefanvlad_0-1765989175448.png 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: stefanvlad_1-1765989395916.png Wait for the installation to finish. stefanvlad_0-1765990977949.png After installation, open MATLAB® and change the default Add-ons path to a shorter path such as C:\MathWorks . stefanvlad_0-1766410047823.png   4.4 MATLAB® Add-Ons Installation Open Add-On Explorer and install: Embedded Coder Support Package for ARM Cortex-M Processors stefanvlad_0-1766412311420.png NXP Support Package for S32K3 (NXP_Support_Package_S32K3) stefanvlad_0-1766411567825.png   4.5 MBDT for S32K3 v1.8.0 Installation After installing the support package, run the following command in MATLAB®: sp_s32k3.nxp.setup(); stefanvlad_0-1766413223525.png Select version 1.8.0; the installer will check prerequisites: stefanvlad_1-1766413310659.png If any toolboxes are missing, install them before continuing. Click Download to proceed. stefanvlad_2-1766413441318.png 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. stefanvlad_6-1766414096051.png After reading, click I Agree. Download the SW32_MBDT_S32K3_1.8.0_D2512.mltbx file (approx. 1.6 GB): stefanvlad_7-1766414190914.png Once the download completes, browse to the location of the SW32_MBDT_S32K3_1.8.0_D2512.zip file: stefanvlad_0-1766414656239.png Click Install to proceed and accept the license agreement. stefanvlad_1-1766414793231.png After a few minutes, the dialog will display: Installation successfully completed! Click Next. stefanvlad_0-1766415122676.png Select an option such as Open S32K3 Root Folder. stefanvlad_1-1766415182502.png MATLAB®'s current folder will change to the root of the toolbox. stefanvlad_2-1766415288611.png Click Finish to close the installer. The current folder in MATLAB® is now C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3 : stefanvlad_3-1766415419643.png     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 . stefanvlad_4-1766415657531.png Click on Hardware Settings: stefanvlad_0-1766419685798.png Go to Hardware Board Settings → Hardware → Select Configuration Project Template: stefanvlad_0-1766421790798.png For the FRDM-A-S32K312 select Custom: S32K312MINI-EVB S32 Config Tool. A Warning Dialog will appear; click OK. stefanvlad_2-1766421922797.png Wait for the configuration update to complete. stefanvlad_3-1766421986052.png Click on Apply and close the Configuration Parameters window. Press Build, Deploy & Start (CTRL+B) to generate the code: stefanvlad_4-1766422124406.png After the build completes successfully, the executable is downloaded to the board. stefanvlad_0-1766482772353.png Open a terminal application and connect to the board's COM port at 115200 baud: stefanvlad_1-1766483002529.png 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 : stefanvlad_0-1766489966607.png Open the model s32k312_mc_pmsm_2sh_s32ct.mdl : stefanvlad_1-1766494271242.png 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.  K312_MC_KIT.png 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.  K312_MC_KIT_TOP_A.JPG   Open FreeMASTER s32k312_mc_pmsm_2sh_s32ct.pmpx : stefanvlad_4-1766495406118.png Press GO to connect at 115200 baud. In the App Control tab, press On and set Speed Required to 1000 RPM: stefanvlad_5-1766495532076.png Apply a small mechanical load to the motor (friction force to the motor shaft) and observe the iABC currents. stefanvlad_6-1766495622758.png 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.
記事全体を表示
    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.   SorinIBancila_1-1784019970441.png   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. SorinIBancila_3-1784020100200.png   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 SorinIBancila_2-1784020020513.png       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.
記事全体を表示
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)   SorinIBancila_0-1777471509980.png 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. SorinIBancila_1-1777471606813.png 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. SorinIBancila_2-1777471646182.png 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 SorinIBancila_3-1777471737967.png 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. SorinIBancila_4-1777471790174.png Figure 5. Configuration SPI Component - SpiChannel   SorinIBancila_5-1777471818464.png Figure 6. Configuration SPI Component - SpiExternalDevice   SorinIBancila_6-1777471857095.png Figure 7. Configuration SPI Component - SpiJob   SorinIBancila_7-1777471913175.png 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. SorinIBancila_1-1777472543316.png 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 SorinIBancila_0-1777473333102.png   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. SorinIBancila_1-1777473443463.png 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. SorinIBancila_2-1777473882992.png  Figure 12. FreeMASTER Project - J10_6 connected to GND SorinIBancila_3-1777473915113.png  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.
記事全体を表示
  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. NXP Model-Based Design Toolbox One Pager 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. [02.16]NXP AutoWorks Tools Suite 26.jpg Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Front & Rear Lights System Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control Architecture (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Other Guides Getting Started with FRDM-A-S32K312 using Model-Based Design  A1: Interacting with Digital Inputs Outputs on MR-CANHUBK344 A2: Sending data via UART and monitoring signals with FreeMASTER A3: Controlling LED intensity with ADC and PWM A4: Communicating over the CAN Bus   Note: This index is updated as new articles are published.
記事全体を表示
1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model. Automated Driving - Bird's-Eye Plot.png   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation S32R45 Radar MPU Block Diagram.png   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX
記事全体を表示
      1 Table of Contents • Introduction • Overview • Context • 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. dragostoma_0-1782905205237.png 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 dragostoma_1-1782905238932.png 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.
記事全体を表示
1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. iulianbulancea_0-1784543595345.png Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. iulianbulancea_0-1784543663487.png Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) iulianbulancea_0-1784543716938.png Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: iulianbulancea_1-1784543746920.png Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. iulianbulancea_2-1784543782860.png Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. iulianbulancea_3-1784543808220.png Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. iulianbulancea_4-1784543832714.png Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.
記事全体を表示