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

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

Streams and Transcode Video with Gstreamer This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below: Bio_TICFSL_0-1784751985670.jpeg This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false You can check the results with the 1080p@24fps.

MCXN547: 利用可能な拡張Flex PWMインスタンスはいくつありますか？ リファレンス・マニュアルには、PWMモジュールの2つのインスタンス(PWM0とPWM1)がMCXN547で提供されていると記載されています。しかし、ヘッダーファイル（MCXN547_cm33_core0_COMMON.h）では、PWM0のベースアドレスは含まれていますが、PWM1のベースアドレスは含まれていません。 私はMCXN547VKLTという部品を使用しており、PWM出力にはピン17（ポート2_3）を使用する予定です。データシートMCXN547、ポート2_3はALT5 - PWM1_B2機能として設定可能とされています。しかし、MCUXpresso IDEのピン設定ツールを使うと、ALT5 - PWM1_B2機能のためにPin17(ポート2_3)を選択するオプションがありません。 そこで、MCXN547VKLTが2つのEnhanced Flex PWMインスタンスをサポートしているかどうかを確認したいです。 クロック|タイマー MCX N Re: MCXN547: How many Enhanced Flex PWM instances are available? こんにちは、 @JawaharA さん。 投稿ありがとうございます。 MCXN547VKLT FlexPWMモジュールは1つ(FlexPWM0)しか持っていないことは確認できます。 リファレンス・マニュアルとピンマックステーブルは、いくつかのMCX Nシリーズデバイス(N94/N54/N53/N52/N24)に共通しているため、すべてのデバイスバリアントに存在しないペリフェラルに関連する信号が含まれている場合があります。 デバイス固有の機能の利用可否については、データシートの表4（機能比較）を参照してください。この表に基づくと、FlexPWM1はMCXN547VKLTでは利用できません。 Celeste_Liu_0-1784629787830.png したがって、P2_3は共通ピンマルチプレクサテーブルではPWM1_B2として記載されていますが、MCXN547VKLTではこの機能はサポートされていないため、MCUXpresso Config Toolsでは利用できません。 お役に立てば幸いです。他に質問がありましたら、お気軽にお知らせください。 BR セレステ

Simulinkに統合されるNXP MBDTツールボックスを使用してOSを開発することは実現可能でしょうか？ こんにちは、チームのみなさん。 私の目的は、MATLAB/Simulink、Embedded Coder、NXP MBDTを用いて、NXP S32G3向けの完全なベアメタルオペレーティングシステム/ソフトウェアプラットフォームを開発する実現可能性を評価することです。 目標は、Simulinkで完全なソフトウェアスタックを開発し、Embedded Coderを使ってCコードを生成し、生成されたコードを外部オペレーティングシステムやRTOS、AUTOSAR BSWに依存せずに直接S32G3 Gold Boxにデプロイすることです。 特に、NXP MBDTを用いて、Cortex-AコアとCortex-Mコアの両方をS32G3上で実装し、生成されたソフトウェアがシステムの初期化、スケジューリング、割り込み管理、メモリ管理、ハードウェア抽象化、周辺機器初期化、IPCメカニズム、その他オペレーティングシステムで通常提供されるサービスとして技術的に実装できるかどうかを理解したいです。 Boot ROMはハードウェア上に常駐しており、アプリケーションより先に実行されると理解しています。私の意図としては、ハードウェアの起動プロセス以降のすべての処理を、可能な限りNXP MBDTワークフローを通じてSimulinkで生成されたコードを使用して実装することです。 したがって、私の主な質問は次のとおりです。 1. NXP Model-Based Design ToolboxとMATLAB/Simulink、Embedded Coderを組み合わせて、Cortex-AおよびCortex-Mの両方を対象としたS32G3向けのベアメタルソフトウェアプラットフォーム(OS風フレームワーク)を開発することは技術的に実現可能か?MBDTのワークフローに制限がある場合、どの部分が手書きのCやアセンブリを必要とするのかを明確に教えていただけますか? MBDTはNXPによって開発されたものだと理解しています。しかし、もしこの質問にNXP MBDTチームがより適切に回答できる場合は、適切な連絡先やサポートチャネルをご案内していただけるとありがたいです。 ご指導ありがとうございました。 Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink こんにちは、 @charan032001 投稿ありがとうございます。 別のスレッドで言及され、返信もあったのに気づきました。 NXPの製品にご関心いただきありがとうございます。 BR チェイン

Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink? Hi team, My objective is to evaluate the feasibility of developing a complete bare-metal operating system/software platform for the NXP S32G3 using MATLAB/Simulink, Embedded Coder, and the NXP MBDT. The goal is to develop the complete software stack in Simulink, generate C code using Embedded Coder, and deploy the generated code directly onto the S32G3 Gold Box without relying on an external operating system, RTOS, or AUTOSAR BSW. In particular, I would like to understand whether, using the NXP MBDT, it is technically feasible to implement software for both the Cortex-A cores and the Cortex-M core on the S32G3, with the generated software handling system initialization, scheduling, interrupt management, memory management, hardware abstraction, peripheral initialization, IPC mechanisms, and other services typically provided by an operating system. I understand that the Boot ROM is hardware-resident and executes before the application. My intention is for everything after the hardware boot process to be implemented, as much as possible, using Simulink-generated code through the NXP MBDT workflow. Therefore, my primary question is: 1. Is it technically feasible, using the NXP Model-Based Design Toolbox together with MATLAB/Simulink and Embedded Coder, to develop an entire bare-metal software platform (OS-like framework) for the S32G3 targeting both the Cortex-A and Cortex-M cores? If there are any limitations within the MBDT workflow, could you please clarify what portions would still require handwritten C or assembly? I understand that MBDT is developed by NXP. However, if this question is better addressed by the NXP MBDT team, I would appreciate it if you could kindly direct me to the appropriate contact or support channel. Thank you for your guidance. Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink Hello, @charan032001  Thanks for your post. I noticed it is mentioned via another thread and it had been replied. Thanks for your interest on NXP's product. BR Chenyin

使用NXP MBDT工具箱开发操作系统并将其集成到Simulink中是否可行？ 大家好， 我的目标是评估使用 MATLAB/Simulink、Embedded Coder 和 NXP MBDT 为 NXP S32G3 开发完整的裸机操作系统/软件平台的可行性。 目标是在 Simulink 中开发完整的软件栈，使用 Embedded Coder 生成 C 代码，并将生成的代码直接部署到 S32G3 Gold Box 上，而无需依赖外部操作系统、RTOS 或 AUTOSAR BSW。 具体来说，我想了解使用 NXP MBDT 在技术上是否可行，能否在 S32G3 上为 Cortex-A 内核和 Cortex-M 内核实现软件，生成的软件能够处理系统初始化、调度、中断管理、内存管理、硬件抽象、外设初始化、IPC 机制以及操作系统通常提供的其他服务。 我了解到启动 ROM 是硬件驻留的，并且在应用程序之前执行。我的目标是尽可能地使用 NXP MBDT 工作流程，通过 Simulink 生成的代码来实现硬件启动过程之后的所有操作。 因此，我的主要问题是： 1. 使用 NXP 基于模型的设计工具箱以及 MATLAB/Simulink 和 Embedded Coder，为 S32G3 开发一个完整的裸机软件平台（类似操作系统的框架），同时面向 Cortex-A 和 Cortex-M 内核，在技术上是否可行？如果 MBDT 工作流程存在任何限制，能否请您说明哪些部分仍然需要手写 C 代码或汇编代码？ 据我了解，MBDT是由NXP公司开发的。但是，如果这个问题更适合由 NXP MBDT 团队解答，请您指点我到合适的联系方式或支持渠道。 感谢您的指导。 Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink 你好， @charan032001 感谢你的帖子。 我注意到另一个帖子也提到了这件事，而且已经有人回复了。 感谢您对恩智浦产品的关注。 BR 陈银

MCXN547: How many Enhanced Flex PWM instances are available? The reference manual mentions 2 instances of PWM modules (PWM0 and PWM1) are available in MCXN547. However, in the header files (MCXN547_cm33_core0_COMMON.h), base addresses for PWM0 is included and not for PWM1.  I am using MCXN547VKLT part and I was planning to use Pin 17 (Port 2_3) for PWM output. MCXN547 datasheet indicates Port 2_3 can be configured as ALT5 - PWM1_B2 function. However, if I use the Pin config tool in MCUXpresso IDE, there is no option to select Pin17 (Port 2_3) for ALT5 - PWM1_B2 function.  Hence, I would like to get confirmation, whether MCXN547VKLT supports 2 instances of Enhanced Flex PWMs.  Clock|Timers MCXN Re: MCXN547: How many Enhanced Flex PWM instances are available? Hello @JawaharA , Thanks for your post. I can confirm that MCXN547VKLT only has one FlexPWM module (FlexPWM0). The Reference Manual and pinmux tables are common to several MCX N series devices (N94/N54/N53/N52/N24), so they may contain signals associated with peripherals that are not present on every device variant. For device-specific feature availability, please refer to Table 4 (Feature Comparison) in the Data Sheet. Based on this table, FlexPWM1 is not available on MCXN547VKLT. Celeste_Liu_0-1784629787830.png Therefore, although P2_3 is listed as PWM1_B2 in the common pinmux table, the function is not supported on MCXN547VKLT, which is why it is not available in MCUXpresso Config Tools. Hope it helps. Please let me know if you have any further questions. BR Celeste

MCXN547：有多少个增强型 Flex PWM 实例可用？ 参考手册提到 MCXN547 中有 2 个 PWM 模块实例（PWM0 和 PWM1）。然而，在头文件（MCXN547_cm33_core0_COMMON.h）中，PWM0 的基地址已包含在内，但 PWM1 的基地址未包含在内。 我正在使用 MCXN547VKLT 器件，并计划使用引脚 17（端口 2_3）作为 PWM 输出。MCXN547 数据手册表明端口 2_3 可以配置为 ALT5 - PWM1_B2 功能。但是，如果我使用 MCUXpresso IDE 中的引脚配置工具，则没有选项可以选择引脚 17（端口 2_3）作为 ALT5 - PWM1_B2 功能。 因此，我想确认一下，MCXN547VKLT 是否支持 2 个增强型 Flex PWM 实例。 时钟|计时器 MCX N Re: MCXN547: How many Enhanced Flex PWM instances are available? 你好@JawaharA ， 感谢你的帖子。 我可以确认 MCXN547VKLT 只有一个 FlexPWM 模块 (FlexPWM0)。 参考手册和引脚复用表是几个 MCX N 系列设备（N94/N54/N53/N52/N24）通用的，因此它们可能包含与某些设备变体上不存在的外围设备相关的信号。 有关设备特定功能的可用性，请参阅数据表中的表 4（功能比较）。根据此表可知，MCXN547VKLT 上没有 FlexPWM1。 Celeste_Liu_0-1784629787830.png 因此，尽管 P2_3 在通用引脚复用表中被列为 PWM1_B2，但 MCXN547VKLT 不支持该功能，因此 MCUXpresso 配置工具中没有该功能。 希望对您有所帮助。如果您还有其他问题，请告诉我。 BR 塞莱斯特

内部 DCDC DCDC_ANA_SENSE 和 VOUT_DCDC_1V8/DCDC_ANA 存在问题 尊敬的NXP支持团队： 在使用 MX RT1172 定制板时，在捕获DCDC_ANA_SENSE波形时，我们发现初始上升到 1.9V，然后稳定在 1.51V。 请问这是什么原因造成的？我附上了波形图和原理图供您参考。 deeporbit_0-1784609948051.png deeporbit_1-1784609973813.jpeg 期待您的回音。 此致， 深的 Re: Issue with internal DCDC DCDC_ANA_SENSE and VOUT_DCDC_1V8/DCDC_ANA 嗨@deeporbit ， 非常感谢您对我们产品的关注以及对我们社区的使用。 根据提供的波形，VOUT_DCDC_1V8（DCDC_ANA_SENSE）的稳态电压约为1.51V，这与预期行为不符。在 MIMXRT1170-EVKB 上，我进行了测试，发现 DCDC_1V8_OUT 电源轨稳定在约 1.8 V。 我建议您检查以下内容： 1：确认 DCDC_ANA_SENSE 已正确连接到 VOUT_DCDC_1V8，并检查 0Ω 反馈电阻 R166 是否已正确安装和焊接。 2：检查是否有任何外部 1.8V 稳压器、外设、电平转换器或其他功率域连接到 VDD_1V8 / VOUT_DCDC_1V8 电源轨，并且可能对该电源轨进行拉动或反向驱动。 3：检查连接到 DCDC_ANA / VOUT_DCDC_1V8 的总负载。DCDC_ANA 的负载不得超过其规定的输出能力 150 mA。 mayliu1_1-1784626389774.png 4：如果可能，隔离下游 1.8 V 负载，再次测量 VOUT_DCDC_1V8。如果隔离后电源轨电压恢复到 1.8 V 左右，则问题可能与负载过大或外部电路连接到 1.8 V 电源轨有关。 此致， 5月

Issue with internal DCDC DCDC_ANA_SENSE and VOUT_DCDC_1V8/DCDC_ANA Dear NXP support team, While working with custom board with MX RT1172, while capturing waveforms of DCDC_ANA_SENSE, we found initial ramp to 1.9V then it stabilises at 1.51V. Could you tell why this is happening, I have attached waveforms and schematic for your reference. deeporbit_0-1784609948051.png deeporbit_1-1784609973813.jpeg Looking forward to hearing from you. Regards, Deep Re: Issue with internal DCDC DCDC_ANA_SENSE and VOUT_DCDC_1V8/DCDC_ANA Hi @deeporbit , Thank you so much for your interest in our products and for using our community. Based on the waveform provided, the steady-state voltage of VOUT_DCDC_1V8 ( DCDC_ANA_SENSE) is approximately 1.51 V, which does not match the expected behavior. On the MIMXRT1170-EVKB, I test and found the DCDC_1V8_OUT rail regulates at approximately 1.8 V. I would recommend checking the following: 1： Confirm that DCDC_ANA_SENSE is correctly connected to VOUT_DCDC_1V8 , and check whether the 0-Ω feedback resistor R166 is properly populated and soldered. 2： Check whether any external 1.8 V regulator, peripheral, level shifter, or other power domain is connected to the VDD_1V8 / VOUT_DCDC_1V8 rail and may be pulling or back-driving the rail. 3： Check the total load connected to DCDC_ANA / VOUT_DCDC_1V8 . The load on DCDC_ANA must not exceed its specified output capability of 150 mA. mayliu1_1-1784626389774.png 4: If possible, isolate the downstream 1.8 V loads and measure VOUT_DCDC_1V8 again. If the rail returns to around 1.8 V after isolation, the issue is likely related to excessive load or an external circuit connected to the 1.8 V rail.  Best regards, May

内部DCDC DCDC_ANA_SENSEおよびVOUT_DCDC_1V8/DCDC_ANAに関する問題 親愛なるNXPサポートチームの皆様、 MX RT1172を搭載したカスタムボードで作業中に、 DCDC_ANA_SENSEの波形をキャプチャしたところ、最初に1.9Vまで上昇し、その後1.51Vで安定することがわかりました。 なぜこうなるのか教えてもらえますか?参考のために波形と回路図を添付しました。 deeporbit_0-1784609948051.png deeporbit_1-1784609973813.jpeg あなたからの返信を楽しみにしています。 よろしくお願いいたします。 深い Re: Issue with internal DCDC DCDC_ANA_SENSE and VOUT_DCDC_1V8/DCDC_ANA こんにちは、 @deeporbit さん。 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 提供された波形に基づくと、VOUT_DCDC_1V8 (DCDC_ANA_SENSE) の定常状態電圧は約 1.51 V であり、これは期待される動作と一致しません。MIMXRT1170-EVKBでテストしたところ、DCDC_1V8_OUTレールは約1.8Vに安定化することが分かりました。 以下の点を確認することをお勧めします。 1: DCDC_ANA_SENSEが正しくVOUT_DCDC_1V8に接続されているか確認し、0 Ωフィードバック抵抗R166が正しく埋め込まれてはんだ付けされているか確認してください。 2: 外部の1.8Vレギュレーター、ペリフェラル、レベルシフター、その他の電源領域がVDD_1V8/VOUT_DCDC_1V8レールに接続されていて、レールを引き寄せたり逆動させたりしている可能性があるか確認してください。 3: DCDC_ANA / VOUT_DCDC_1V8に接続された総負荷を確認してください。DCDC_ANAにかかる負荷は、規定の出力能力である150mAを超えてはならない。 mayliu1_1-1784626389774.png 4: 可能であれば、下流の 1.8 V 負荷を分離し、VOUT_DCDC_1V8 を再度測定します。レールが絶縁後に約1.8Vに戻る場合、問題は過剰な負荷か1.8Vレールに接続された外部回路に関連している可能性が高いです。 よろしくお願いします、 5月

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

MCXW72のデバッグ認証応答 MCXW72のデバッグポートのロックを解除しようとしています。MCUXpressoのSecure Provisioning Toolでロック解除は正常に動作しますが、Debug Credential(DC)、DCK秘密鍵、デバイスから受け取ったDACに基づいて自分のアプリケーションを使ってポートのロック解除を試みています。 この分野のドキュメントは非常に不明瞭で(場合によっては誤りもあります)。 私の理解では、DARは以下の要素で構成されています。 DAR = DC + AB + UUID (DACより) + 署名 (リファレンス・マニュアルの図50ではUUIDとABフィールドの順序が誤っています。) OpenSSLを使って署名を計算したいのですが、どのデータを署名すべきか正確には判断できません。 a) DC + CV（DACから） b) DC + AB + CV (DACから) c) DC + AB + UUID (DACから) + CV (DACから) それとも全く別の何か？ ドキュメントには署名がDARをチャレンジベクトル(CV)に結合すると記載されていますが、ハッシュ化と署名すべき正確なバイトシーケンスは明確に指定されていません。DAR署名を生成するために使われる正確なデータを教えていただけますか? MCXA セキュリティ（EdgeLock | セキュアブート | OTP） Re: Debug authentication Response for MCXW72 こんにちは、 @Surdej Secure Provisioning ToolはSecure Provisioning SDKの上に構築されています。詳細は https://spsdk.readthedocs.io/en/latest/ これはオープンソースなので、そこで答えが見つかります。

[S32K3] [RTD 7.0.1]BCTUモジュールにおける3つの課題 RTDコードバージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206のBCTUモジュールに3つの問題が見つかりました。詳細な問題点は以下のとおりです。   問題 1:ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの 1558 行目で、現在のコードではビットごとの OR 代入を使用しています: BctuBasePtr->FIFOERR |= FifoWatermarkMask;これを直接代入に変更する必要があります: BctuBasePtr->FIFOERR = FifoWatermarkMask;   問題2：ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの567行目と568行目に、既存のコードに誤ったビットシフト演算が含まれています。元のコードは以下のとおりです。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << インデックス) : 0U; これらの2行は、以下のように正しいシフトロジックに修正する必要があります。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (インデックス * 2u)) : 0U;   問題3: MCAL/SDKコード生成ツールとBCTUモジュールの静的ソースコードの間に型の整合性の問題があります。MCAL で生成されたコード ( Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m 、2397行目）では、ヘッダーファイルとCファイルの両方で定義されている配列は、一律にuint32型を採用しています。SDK生成コードでは、ヘッダーファイルとCファイルの型定義が一貫していません。eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.hの配列型は(249行目)は、BctuFifoDmaRawDataオプションが有効になっているかどうかに応じてuint16とuint32を切り替え、対応する配列はeclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.cの対応する配列です（317行目）はuint32型に固定されています。静的コード ( Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 、1629行目）では、送信長（2バイトまたは4バイト）はBctuFifoDmaRawData構成に基づいて動的に決定されます。BctuFifoDmaRawDataオプションのチェックを外すと、以下の異常な問題がすべて発生します。 1.SDKプロジェクトの場合:ヘッダーファイルとCファイルの配列型が不一致で、直接コン パイル失敗を引き起こします。 2. MCALプロジェクトの場合:コンパイルは成功しますが、固定されたuint32配列定義のため メモリ容量の半分が無駄になります。さらに、各uint32データユニットには2つのADC結果が含まれているため、データ解析時にuint16の高値と低値を手動で分割する必要があります。 上記の3つのバグは、公式バージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206に存在します。NXPのソフトウェアエンジニアが次回RTDリリースでこれらのBCTUモジュールの欠陥を修正できることを期待しています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft あなたの質問は社内フォーラムにエスカレーションされており、設計チームからの確認を待っています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft ご意見ありがとうございます。 ソフトウェアチームと私はこれらの問題を確認しましたが、確かにバグです。 これらの問題は社内でエスカレーションしており、今後のアップデートで修正する予定です。

[S32K3] [RTD 7.0.1]BCTU模块中的三个问题 我在 RTD 代码版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中发现了 BCTU 模块的三个问题。具体问题如下：   问题 1：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 的第 1558 行，当前代码使用按位或赋值： BctuBasePtr->FIFOERR |= FifoWatermarkMask;应修改为直接赋值： BctuBasePtr->FIFOERR = FifoWatermarkMask;   问题 2：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c的第 567 行和第 568 行中，现有代码包含不正确的位移操作。原始代码如下所示： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << 索引) : 0U; 这两行代码应按如下方式修改为正确的换行逻辑： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << （索引 * 2u）） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (索引 * 2u)) : 0U;   问题 3： MCAL/SDK 代码生成工具与 BCTU 模块的静态源代码之间存在类型不一致对齐问题。在 MCAL 生成的代码（ Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m中，第 2397 行），头文件和 C 文件中定义的数组统一采用uint32类型。在 SDK 生成的代码中，头文件和 C 文件中的类型定义不一致： eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h中的数组类型（第 249 行）根据BctuFifoDmaRawData选项是否启用，在uint16和uint32之间切换，而eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c中的相应数组（第 317 行）固定为uint32类型。在静态代码（ Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c中，第 1629 行），传输长度（2 字节或 4 字节）是根据BctuFifoDmaRawData配置动态确定的。当取消选中BctuFifoDmaRawData选项时，会出现以下所有异常问题： 1.对于 SDK 项目：头文件和 C 文件之间数组类型不匹配会导致直接编译失败。 2. 对于 MCAL 项目：虽然编译可以成功，但固定的 uint32 数组定义导致一半的内存空间被浪费。此外，每个 uint32 数据单元包含两个 ADC 结果，需要在数据解析期间手动拆分高 uint16 值和低 uint16 值。 以上三个错误存在于官方版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中。我们希望恩智浦软件工程师能在下一个 RTD 版本中修复这些 BCTU 模块缺陷。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 您的问题已提交至内部论坛，正在等待设计团队的确认。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 感谢您的反馈。 软件团队和我已经确认了这些问题，它们确实是软件漏洞。 我们已将这些问题上报内部，并将在未来的更新中修复它们。

i.MX8M Plus - Dedicated I2C for Display and Camera Hi Team, Just wanted to confirm if there is any Dedicated I2C for Display and Camera. (like I2C2 for Display and I2C4 for Camera) or there is no restriction on configuring can i use any I2C for Display and camera interfaces? Re: i.MX8M Plus - Dedicated I2C for Display and Camera You can use any available I2C controller for display-related or camera-related devices on i.MX8M Plus. There is no dedicated "camera I2C" or "display I2C" inside the SoC. The choice is determined by your hardware design and device-tree configuration.

MFS2323BMBA5EP OTP構成の競合:SPIとI2Cモードの識別 NXPのエンジニアおよびコミュニティの専門家の皆様へ 現在、以下の方法で開発中です MFS2323BMBA5EP セーフティ SBCで、設定ファイルとデータシートレポートの間でOTPの工場出荷時設定に関する大きな矛盾に直面しました。この点についてご説明いただけると大変ありがたいです。 設定の競合： 1. 証拠 .cfg ファイル： 私の FS2320_BA5_CONFIG_Rev_A.cfg ファイルには、直接レジスタ値があります。 0x30 : 0x00 FS23データシート（表229）によると、 OTP_MAIN_SYS_I2C_CFG😞 ビット4（ SPI_EN_OTP ） ： 0 手段 I2Cは有効、SPIは無効です。 1 SPIが有効になっていることを意味します。 ビット3~0 ( I2CDEVADDR_OTP ) : 0000 意味する I2Cスレーブアドレスは 0x20 。 これは明らかに、このチップが工場出荷時に構成されていることを示唆しています。 I2Cモード。 2. 構成レポートPDFからの証拠： しかし、私の R_MFS2323BMBA5_Rev_A_test.pdf 文書、 表2. デバイスのOTP設定、レポートには明示的に記載されています。 SPI有効化：SPIピンが有効になっています。 これはハードウェアピンがロックされていることを示唆しています SPIモード。 私の実際のハードウェアテスト結果： MCU(S32K344)をSPIマスターとして設定し、このPMICと通信させたとき: MISOピンは一定のままです 0.3V （内部プルダウン抵抗が弱い高インピーダンス状態を示しており、スレーブ側がラインを駆動していないことを意味します。） PMIC側のSCKピンは、実際には独自にクロック信号を出力していた。 チップがOTPエミュレーションモードに固定されているか、I2Cスレーブとして設定されている可能性があり、それが原因でSPI通信が完全に失敗しているのではないかと考えています。 私の具体的な質問： 確認いただけますか MFS2323BMBA5EPの実際の工場出荷時OTP設定ですか?それはSPIですか、それともI2Cですか?  の間に対立が生じたとき。cfg registerファイル(0x30 : 0x00)とPDF設定レポート、どちらが絶対的なハードウェアの真実と考えられるべきでしょうか?PDFレポートにドキュメントの誤りが含まれている可能性はありますか? （添付しました） FS2320_BA5_CONFIG_Rev_A.cfg そして R_MFS2323BMBA5_Rev_A_test.pdf （参考としてこの投稿を参照してください）。 ご協力ありがとうございます！ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification はい、ありがとうございます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification どちらの会社にお勤めですか？現在、お客様はご自身のメールアドレスを使用されていますが、これは優先度の低い（経営幹部レベルの）顧客とみなされます。 これには、回路図とCRCドライバに関連する一連の事項を確認する必要があります。 会社のメールアドレスを使ってチケットを送信することをお勧めします。 家 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 現状では不可能です。デバッグモードで通信しています。344ピンのSCK波形とMOSI波形を個別にテストしたところ、書き込んだデータは送信できました。しかし、FS23のSCKピンも信号を送信しているため、この2つを接続すると、MCUから送信されたSCK信号がFS23によってローにプルダウンされてしまいます。FS23に送信する応答はすべて0です。CRCも設定済みです。 紫色の線は、上部の信号以降のSCK信号を表しています。 黄色はデータ信号を示します。 定格電圧は5Vです。 送信されたデータは {0x02, 0x00, 0x00, CRC} です SCK波形を通常の波形として無理やり解釈すると、データが正しいことがわかります。最初のビットは2で、その後に00とCRCが続きます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification SPIを使用して正常に通信できますか？ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification FS23とS32K344がSPIで通信している際に、FS23のSCK信号も送信されている可能性はありますか？というのも、FS23とのSPI通信を設定しない場合、FS23のSCKピンをキャプチャしようとしても波形が取得できないからです。S32K344と通信している場合にのみ、FS23とS32K344の両方のSCKピンから信号が送信され、SCKピンとCSピンの波形が全く同じになります。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification guoweisun_0-1784603079866.png GUI経由で.cfgファイルをMirrorにアップロードしました。このレジスタはSPIモードを示します。

システムマネージャーのドライバーコードPCAL6524 システムマネージャーのドライバーコードを教えていただけますかPCAL6524HEAZ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 ビンソン様、 公式のMCUXpresso SDKsやSystem マネージャ ドライバは知りません。 fsl_pcal6524.cfsl_pcal6524.h fやPCAL6524HEAZ。NXP Linux BSPは、標準のLinux GPIOエクスパンダードライバーを通じて、PCA6524デバイスツリー互換文字列を使ってデバイスをサポートしています。i.MX95 19x19 EVK は、I²C GPIO エキスパンダーとして PCAL6524 を使用する公開サンプルです。https ://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   敬具、 ヨゼフ

i.MX8M Plus - ディスプレイとカメラ専用のI2Cポート チームの皆さん、こんにちは。 ディスプレイとカメラ専用のI2Cポートがあるかどうか確認したかっただけです。 (例えばディスプレイ用のI2C2やカメラ用のI2C4のような)設定に制限はありませんか?ディスプレイとカメラのインターフェースに任意のI2Cを使えますか? Re: i.MX8M Plus - Dedicated I2C for Display and Camera i.MX8M Plusでは、ディスプレイ関連やカメラ関連デバイス用に利用可能な任意のI2Cコントローラーを使用できます。SoC内部には、専用の「カメラI2C」や「ディスプレイI2C」は搭載されていません。選択はハードウェア設計とデバイスツリー構成によって決まります。