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

CLRC663 plus - LPCD Tip & Tricks Prerequisites:  CLRC663 plus Low Power Card Detection 1// Antenna Size  The stronger the coupling between reader and card, the better the detection range.  Ideally, the NFC reader antenna should have a size and form factor similar to that of the target NFC tag antenna. In practice, the reader antenna is typically designed to be slightly larger—by approximately 10% to 20%—to ensure reliable coupling and performance. 2// Antenna Q-factor  Higher Q-factor typically serves higher detection range. The Q-factor should be selected in accordance with the target communication bit rate.(e.g. Q≈30 for 106 kbit/s).  The antenna Q factor is mainly defined by the mechanical design of the antenna itself, as well as by external damping resistors. However, for LPCD-insensitive systems, a zero-ohm damping resistor can be used, and the system should then be evaluated through testing.  3// Target tuning  The CLRC663 should typically be used with the asymmetrical tuning as there is no internal power regulation implemented.  However, in some cases, symmetrical tuning may be beneficial, as it can improve detection range and sensitivity. Care must be taken to ensure that, under varying conditions—such as antenna loading by different NFC tags or the presence of nearby metal, the TVDD current does not exceed the specified maximum limits.   In CLRC663 LPCD operation, detection performance improves with higher TX power. However, this also increases current consumption, so an appropriate trade-off must be determined.   As a starting point, an antenna impedance of approximately Z≈ 50 Ω can be used.   4// Receiver setting (external Rx resistors) Based on the AN11019 (chapter 4.4.1), the peak voltage between RxN and GND (or RxP and GND) shall be in the range of 1.2Vp - 1.7Vp. Generally, higher Rx voltage levels improve detection range. To increase LPCD sensitivity and range, it can be advantageous to operate close to the upper limit of the allowed Rx voltage.   Please note that excessively high RX voltage may lead to immediate false wake-ups. 5//LPCD Settings As a starting point, we recommend using the following settings:   These settings provide robust immunity against false wake-ups and are highly efficient in terms of current consumption. The typical detection range for standard NFC tags is approximately 10 mm to 20 mm or even less in an application where the antenna is placed near a metal environment. Detection performance can be further improved by lowering the threshold settings +0 and -0. If this settings is used, we strongly advice using LPCD_FILTER feature as well. Alternatively, the user can use "high detection range option" + LPCD_FILTER. After using these settings, we recommend running "Endless LPCD" for a while and checking for any false wake-up rates. Note: The LPCD filter feature helps prevent false wake-ups. This is especially important when the threshold is set to +0 and -0. When using thresholds of +0 and −0 it is also recommended to set the "CWMAX" parameter (address 0x2A) to 1b. 5.1// LPCD RF ON time  If the RF on-time is shorter than approximately 20 µs - 30 µs , the primary detuning effect is dominated by the physical design of the NFC tag. For longer RF on-times, the NFC tag becomes energized, and its electrical parameters begin to contribute significantly to the overall detuning. Based on this understanding, a longer RF on-time can help increase LPCD detection range. However, this comes at the cost of higher current consumption. Therefore, it is recommended to compensate by adjusting the RF off-time. See an example below.   5.2// LPCD Charge pump  This function allows the TX power to be increased exclusively during the LPCD RF On time.   This can be beneficial if you want to avoid increasing the power in active mode (e.g., by reducing the tuning impedance) but only increase it during LPCD operation.   By activating the LPCD charge pump, detection performance can be improved, but at the cost of increased current consumption.   If this feature is enabled, it is recommended to verify the LPCD RF ping using an oscilloscope. It may be necessary to increase the RF On time to allow the amplitude to properly settle. Especially for TVDD= 3.3V or lower. 6// Summary Mode  Tuning function Target impedance Q-factor Receiver voltage LPCD Threshold LPCD Filter LPCD Charge -pump RF On time  Standard Asymmetrical  20 Ω - 80 Ω  10 - 30 1.5 Vp +1 and -1 disable disable 10 us High detection range  Asymmetrical /Symmetrical (1) 20 Ω - 50 Ω >25 (2) 1.7 Vp +0 and -0 enable enable/ disable (3)  20 us-100 us Note (1): Symmetrical tuning can only be applied if the TVDD current does not exceed the maximum allowable value after antenna loading caused by a card or metal object. Please ensure that this condition is met. Note (2): If high detection performance is required, the external antenna damping resistors are typically replaced with 0 Ω resistors, resulting in a higher antenna Q-factor. In this case, the user must verify that NFC communication continues to operate reliably. Due to the increased Q-factor, this configuration is typically limited to communication speeds of 106 kbit/s Note (3): Once the charge pump is enabled, the RF On time should be verified and adjusted if necessary. Please also note that the relationship between TX power and detection distance is not linear or unlimited. Beyond a certain point, enabling the charge pump provides only marginal improvements in detection distance.     Please note that the High Detection mode is generally more susceptible to false wake-ups and results in higher current consumption than the standard mode. NFC Frontend Solutions

eIQ ModelRunner on MCUs ModelRunner is a benchmarking tool for running TensorFlow Lite models on NXP microcontrollers. It supports both HTTP and UART communication modes and provides detailed latency profiling for each model layer. The model profiling information is in JSON format and can be uploaded to the upcoming eIQ AI Toolkit and eIQ AI Hub tools for more detailed analysis.  ModelRunner is available on the following MCU devices: FRDM-MCXN947 MCX-N5XX-EVK MCX-N9XX-EVK MIMXRT700-EVK MIMXRT595-EVK MIMXRT685-EVK MIMXRT1060-EVK MIMXRT1170-EVK There are two methods for using ModelRunner: Via an Ethernet connection to the board Via UART using an emulated network connection  - useful for devices without Ethernet like i.MX RT700 The attached guide walks through how to use both methods. A Windows Powershell or Linux prompt should be used for this lab as a normal Windows command prompt will not parse the commands correctly. 

eIQ Neutron NPU Support in Zephyr Zephyr now supports the eIQ Neutron NPU on MCX N and i.MX RT700. This article will describe how to get Zephyr and use the eIQ Neutron NPU libraries and examples.  Some previous experience with eIQ Neutron NPU enablement is assumed, so ensure you're familiar with the eIQ Neutron SDK, converting models for eIQ Neutron NPU, and basic ML concepts by going through the MCX N or i.MX RT700  NPU bare-metal lab guides for VS Code before continuing on below.  Install Software Run the MCUXpresso Installer tool and install three key components: Zephyr Developer Arm GNU Toolchain Zephyr SDK LinkServer Install LinkServer and add LinkServer to the PATH Install VS Code and MCUxpresso VS Code plugin Download Zephyr Open VSCode Go to the MCUXpresso for VSCode plugin and click on Import Repository Go to the Remote tab and select the Zephyr repository. Choose it a directory name and location to download the repository to, and then click on Import. It will take approximately 30 minutes to download the repository. Near the end of the download there will be several prompts in the terminal asking to accept licenses. Type “y” to accept and hit enter. There will be about 10 of these prompts at the end. Open the MCUXpresso Venv Terminal which has a Python virtual environment with all the paths preconfigured that were installed by MCUXpresso Installer. In the terminal that pops up, type “1” to select the default environment. Then navigate to the directory you downloaded Zephyr into Run the following commands to get TensorFlow: west config manifest.project-filter -- +tflite-micro west update Go into the zephyr subdirectory folder cd zephyr Now need to explicitly download the Pull Request (PR) that enables eIQ Neutron. This eventually won’t be necessary when Zephyr 4.5 is released in October, but until then will need to type the following In the command prompt to get it: git remote -v git remote add upstream https://github.com/zephyrproject-rtos/zephyr.git git remote -v   git stash git fetch upstream pull/108834/head:pr-108834 git checkout pr-108834 After this command you should see there’s now a folder at \ \zephyr\samples\boards\nxp\tflm_neutron with example source code. Compile and Run a Zephyr eIQ Neutron NPU example Compile the project with west:  For MCX N: west build -p auto -b frdm_mcxn947/mcxn947/cpu0 samples/boards/nxp/tflm_neutron   For RT700: west build -p auto -b mimxrt700_evk/mimxrt798s/cm33_cpu0 samples/boards/nxp/tflm_neutron Open TeraTerm or other serial terminal program, and connect to the virtual COM port that board enumerated as when you plugged in the USB cable. Use 115200 baud, 1 stop bit, no parity. Flash the resulting code with west flash The serial terminal should show the following: Can debug with west debug  Run your own NPU accelerated ML model in Zephyr Make sure you've gone through the MCX N or i.MX RT700  hands-on labs so you're familiar with the enablement. The same steps for converting a model with the Neutron Converter tool inside eIQ Neutron SDK, updating the eIQ Neutron libraries, modfiying the operator list, and adding a new model are relevant when using Zephyr, but the file locations will be Zephyr specific. Also note that the header file generated by the Neutron Converter tool will need to be updated to match the header of the model.hpp file.  Also note that the README.rst file in the Zephyr Neutron example mentions using eIQ Toolkit but that information is outdated and been superseded by eIQ Neutron SDK.  eIQ Neutron example is at \zephyr\samples\boards\nxp\tflm_neutron Neutron libraries are at \modules\hal\nxp\zephyr\blobs\neutron\ Model data is at \zephyr\samples\boards\nxp\tflm_neutron\src\models\mcxn\model.hpp Labels file is at \zephyr\samples\boards\nxp\tflm_neutron\src\labels.h kTensorArenaSize variable is set in \zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 40) and is set to 60KB by default OpResolver is set in \zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 65) The model is selected in \zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 11) Additional References: Blog post on west which Zephyr uses. Zephyr on FRDM-MCXN947 Zephyr on i.MX RT700 Zephyr TensorFlow Hands-On Training

Automotive Comfort Control Using FRDM-A-S32K344 Microcontrollers 1. Overview This module demonstrates how to implement a vehicle comfort control system using GPIO, PWM, and stepper motor sequencing on NXP S32K3 microcontrollers. The application reads user inputs from push-buttons and translates them into two independent comfort functions: a DC motor that simulates a cabin cooling fan (regulated through PWM) and a stepper motor that simulates an electric window mechanism (driven through GPIO coil sequencing). Both actuators react in real time, mimicking how comfort body-control modules work in modern vehicles. This example is based on the Application Code Hub demonstration for: Vehicle Comfort Control for FRDM-A-S32K344 In this workshop, on-board push-buttons simulate the driver's comfort commands. When the student presses a button, the MCU reads the input through GPIO, decodes the requested action, and drives the associated actuator: a PWM duty cycle is generated for the DC Motor 2 Click (regulating the fan speed), or a full-step coil sequence is generated through GPIO outputs to the H-Bridge Click (moving the NEMA17 stepper motor up or down). Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle comfort control system and the ideas behind HVAC regulation and electric window control. Use on-board push-buttons as simulated driver comfort commands. Read digital inputs using the GPIO peripheral and understand debouncing considerations. Generate PWM signals to regulate DC motor speed (fan simulation). Implement a full-step drive sequence (A → B → C → D) to control a stepper motor. Configure the DC Motor 2 Click and H-Bridge Click boards over the mikroBUS interface. Recognize the actuation data flow: user input → MCU processing → PWM / GPIO actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why comfort functions are relevant in modern automotive body electronics. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Push-buttons (on-board buttons simulate driver comfort commands) Processing: S32K3 MCU (reads GPIO, decodes the command, drives the correct actuator) Output: Dual actuation (DC motor via PWM for the fan, stepper motor via GPIO sequencing for the window) This matches the classic flow of an embedded body-control system: user input → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button that corresponds to a comfort action The GPIO peripheral reads the button state The application decodes the command (fan control or window movement) Depending on the command, the MCU generates either a PWM signal or a stepper coil sequence The DC motor changes speed, or the stepper motor rotates in the requested direction This loop runs continuously to ensure real-time comfort control. Vehicle Comfort Control Application Architecture 4. Key Concepts 4.1 GPIO (General-Purpose Input/Output) The push-buttons on the FRDM-A-S32K344 board are connected to GPIO input pins. The MCU polls (or reads on interrupt) the pin state and interprets a logic transition as a user command. GPIO is also used as output for the stepper motor coil control signals, driving the H-Bridge Click inputs. GPIO handling is the foundation of automotive user-interface processing — used for buttons, switches, ignition detection, and many others. 4.2 PWM — Pulse-Width Modulation and Fan Speed Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A DC motor interprets the average voltage produced by this PWM as a proportional rotational speed. In this demo, the S32K344 generates PWM on a mikroBUS pin that drives the DC Motor 2 Click, which in turn powers the 5 V fan motor. Increasing the duty cycle increases fan speed; decreasing it slows the fan down — a typical pattern used in cabin ventilation and HVAC systems. 4.3 DC Motor Direction and H-Bridge Concept The DC Motor 2 Click integrates an H-Bridge driver that can be configured for forward, reverse, brake, or coast modes. The MCU controls the direction pins and applies PWM on the enable input to regulate speed. This is exactly the same principle used in real automotive fan modules, where a low-side or full-bridge driver is switched at kilohertz frequency to obtain smooth speed control without dissipating power in a series resistor. 4.4 Stepper Motor Full-Step Sequencing A stepper motor like the NEMA17 rotates in fixed angular increments (typically 1.8° per step) when its coils are energized in the correct order. The MCU generates a repeating four-phase pattern (A → B → C → D) on four GPIO pins connected to the H-Bridge Click. Reversing the sequence (D → C → B → A) reverses the direction. The step frequency directly determines rotation speed, and counting the number of steps gives an open-loop position estimate — the exact behavior needed to simulate an electric window moving up or down. 4.5 Push-Buttons as Comfort Commands The on-board buttons are a simplified, safe stand-in for the physical HVAC and window switches found in a real vehicle. The student presses them by hand, the GPIO state changes, the MCU decodes the command, and the corresponding actuator reacts. This isolates the student from real body-electronics wiring while preserving the full software logic. 4.6 Data Flow at a Glance Button press → GPIO input → command decoding → selection of actuator (fan or window) → PWM duty cycle update or stepper coil sequence advance → motor response. This direct chain from the student's finger to the actuator shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the comfort control application and drive the connected peripherals. FRDM-K64 Click Shield FRDM K64 click shieldFRDM K64 click shield mikroBUS expansion board used to connect Click modules to the FRDM platform. DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge driver board used to control DC motor speed and direction via PWM. H-Bridge Click H-Bridge ClickH-Bridge Click Dual H-Bridge driver used to sequence the stepper motor coils. 5 V Fan Motor 5V Fan Motor5V Fan Motor Actuator used to simulate the vehicle cabin cooling fan controlled through PWM. Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Actuator used to simulate the electric window mechanism through step sequencing. USB-C  — Provides power and enables programming and debugging of the system. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate cabin cooling and electric window control. Vehicle Comfort Control Full Setup on FRDM-A-S32K344 Comfort Full SetupComfort Full Setup Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) S32K3 Automotive Software Package Application Code Hub project import Vehicle Comfort Control for FRDM-A-S32K344 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the vehicle comfort control demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable and external 12 V supply Attach FRDM-K64 Click Shield, DC Motor 2 Click and H-Bridge Click Wire the 5 V fan motor and NEMA17 stepper motor Verify wiring before powering the system Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Press the fan control buttons Observe DC motor speed change Press the window up/down buttons Observe stepper motor movement and direction Fan speed and window motion follow user commands in real time 7. Signal Behavior and Control Logic The Vehicle Comfort Control application drives two independent actuators from a single S32K344 MCU: a DC fan motor controlled through a PWM signal for cooling, and a stepper motor controlled through a 4-channel GPIO sequence for electric window movement. User inputs (SW2 and SW3) are read by the MCU, which then generates the appropriate signal type for each actuator. The two diagrams below describe the signal behavior and control logic for each subsystem. 7.1 Cooling System – Fan Speed Control (PWM) Figure: Fan speed control mapping. The MCU generates a PWM signal on the EMIOS channel to drive the DC fan motor through the DC MOTOR 2 Click board. Each SW2 press increments the duty cycle by one step (0 % → 33 % → 67 % → 100 %) and each SW3 press decrements it, so fan speed is directly proportional to duty cycle. Duty Counts represent the raw PWM compare values (period = 20000 counts). When the fan is fully stopped, the TB6593FNG driver is automatically put into low-power sleep mode to prevent wasted current through the windings. 7.2 Window System – Stepper Motor Full-Step Sequencing Direction Step # Coil A (PTA13) Coil B (PTD0) Coil C (PTA3) Coil D (PTC10) Active Pair UP (SW2 pressed) 1 ON OFF ON OFF AC 2 OFF ON ON OFF BC 3 OFF ON OFF ON BD 4 ON OFF OFF ON AD DOWN (SW3 pressed) 1 ON OFF OFF ON AD 2 OFF ON OFF ON BD 3 OFF ON ON OFF BC 4 ON ON OFF OFF AC Table: Stepper motor full-step sequencing for window control. The MCU drives the stepper motor through four GPIO lines connected to the H-Bridge Click board, using dual-coil activation (two coils energised per step) to maximise torque. Pressing SW2 executes the Up sequence AC → BC → BD → AD (window moves up), while SW3 executes the reversed Down sequence AD → BD → BC → AC (window moves down). Each press advances the motor by one full step with a 3 ms delay, and the coil pair remains energised as long as the button is held. When no button is pressed, all coils are de-energised to prevent motor winding overheating during idle periods. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE Fan Does Not Spin Verify PWM configuration and duty cycle Check DC Motor 2 Click wiring and enable pins Ensure the 5 V motor supply is present Stepper Not Moving Verify GPIO output configuration for coil pins Check H-Bridge Click wiring and coil order Confirm the step delay is not too short (motor stalls) Stepper Rotates Wrong Direction Invert the coil sequence in software (A→B→C→D vs D→C→B→A) Swap one coil pair on the H-Bridge output Buttons Not Responding Verify GPIO input configuration and pull-up/pull-down Add software debouncing Check that the correct button pins are mapped 9. Extending the Application The basic implementation can be extended in several ways: Feedback-Based Control Add temperature or Hall-effect sensors for closed-loop fan speed regulation Add end-stop switches or encoders for accurate window position tracking Automatic Comfort Modes Implement predefined climate or ventilation profiles Trigger comfort actions based on sensor thresholds CAN Communication Enable communication with other vehicle ECUs (e.g., HVAC master, door module) Receive comfort commands over the vehicle network Diagnostic Functions Add fault detection for stuck motors, over-current or open loads Expose diagnostic status via LEDs or debug UART Position Memory Store and restore window or fan positions in non-volatile memory Recall the last comfort state after each power-up State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver commands Immediate response to control signals Reliable actuator control for both speed and position In real systems: Redundancy is required for safety-relevant functions (e.g., anti-pinch on windows) Fault detection mechanisms are implemented (over-current, stall, over-temperature) Systems must comply with ISO 26262 (functional safety standard) where applicable Modern comfort modules also implement anti-pinch protection on power windows, ensuring the motor stops or reverses when an obstruction is detected — a safety-critical requirement for real vehicles. 11. Conclusion This module demonstrates how a simple embedded system can implement vehicle comfort control using GPIO inputs, PWM outputs, and stepper motor sequencing on the S32K344 platform. It shows how: Digital user inputs are acquired through GPIO Commands are decoded and processed in real time A DC motor is controlled using PWM for smooth speed regulation A stepper motor is controlled using a full-step coil sequence for precise positioning Result on FRDM-A-S32K344 Comfort ResultComfort Result The course provides a strong foundation for more advanced systems, including feedback-based control, CAN networking, diagnostics, and safety-oriented designs typical of automotive body-control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

To complement solution how to printf float number in MCUXpresso IDE Hi: In previous topics there are some discussions how to print float number in MCUXpresso IDE and SDK. To try them and summarize the final solution: 1.PRINTF the float number to UART console set below macro in project configuration->C/C++ build ->setting PRINTF_FLOAT_ENABLE=1 such code will work. float test1 = 0.15; PRINTF("%f\r\n",test1); 2.Transform float number to string by sprintf() function. there is one error in SDK user manual, " Ensure Redlib: Use floating point version of printf is selected " during project creation does not work. The default C library Redlib doesn't support floating, so it couldn't work with redlib. The correct solution are: (1)Change link library to NewLib, it's full C library and support float  printf. But notice need include in related c file, or else sprintf(float) doesn't work as expected. (2)Change link library to NewLib Nano, it's compact C library , and need click "enable print float" to enable float function, which actually add " -u _printf_float" link symbol. But notice need include in related c file, or else sprintf(float) doesn't work as expected. So the solution surely add flash & RAM consumption in project, but for i.MXRT series it's not problem. Attach is one example for RT1020 EVK. Re: To complement solution how to printf float number in MCUXpresso IDE Thank you! That solved my problem.  Re: To complement solution how to printf float number in MCUXpresso IDE Hi @daweiyou  Thank you so much for your contribution. The information was pretty helpful and it might be helpful for many people. Thank you again. Best Regards. Pablo Avalos.

Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi，pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey

Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi, We are currently testing an application jump from App1 to App2 on the FRDM-S32K344. Our application layout is: App1 Start Address: 0x00400000 App2 Start Address: 0x00500000 For debugging, we are using separate debug configurations with flash memory protection enabled. When debugging App1, the memory protection range is configured as: 0x00500000 to 0x005FFFFF (to protect App2) When debugging App2, the memory protection range is configured as: 0x00400000 to 0x004FFFFF (to protect App1) However, during programming through the debug configuration, we observe that the protected flash region is still being erased, even though the memory protection range has been configured. Could anyone clarify the following? Is the Flash Programmer expected to honor the configured memory protection ranges during erase/program operations? Is there any additional configuration required to prevent the protected flash region from being erased? Has anyone successfully used memory protection to preserve another application while programming only one application on the FRDM-S32K344? Logs and LD files are attached for your ref. we are using on board PE debugger Any guidance or recommendations would be greatly appreciated. Thank you. Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi @Avinpat123  I did quick test in the same version of S32 Design Studio to be sure it is working. I used the same setup – one application forced to 0x40_0000 while 0x50_0000 area is configured to be preserved and second application forced to 0x50_0000 while 0x40_0000 area is configured to be preserved: Here are the logs which shows that this configuration is taken into account: And I can see in the memory that the content is really preserved, so it works as expected. I  saw in your screenshots that you configured the address range but the “Preserve this range” check box is not enabled. Isn’t that the problem? Regards, Lukas Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi @ lukaszadrapa  Thanks for the reply yes as you told check box was the issue now it is working fine

S32K3 ADC 外部チャネルの利用 こんにちは。NXPチーム S32K3 ADCの外部チャネルの使い方 . Re: S32K3 ADC Use of external channels こんにちは、 @VaneBさん これに関して、追加の質問があります。 もし私のデザインにマルチマックスがなくても、例えばセンサ1にADC1_X[0]、センサ2にADC1_X[1]、そしてADC1_Xセンサ3にだけ使いたい場合は、MAピンをGPIO出力ピンなど他の用途で再利用してLEDを駆動することは可能でしょうか? 私のデザインはs32k344をベースにしています Re: S32K3 ADC Use of external channels NPXチームの皆様、こんにちは。 このトピックに関連して、以下の図のようなSCHを実装することが可能かどうか確認していただけますか? サポートありがとうございます。 Re: S32K3 ADC Use of external channels @VaneB ご協力いただき、誠にありがとうございました。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin 各ADCは外部アナログ多重化器の8チャネル中1チャネルを選択するために使う3つの外部デコード信号(MA)を提供し、最大4つのマルチプレクサを設置して32の外部チャネルを接続できます。つまり、これら4つのマルチプレクサは同じMA信号を共有します。 ADCは変換対象の現在のチャネルに基づき、これらの外部アナログ多重化器を制御するよう自動設定します。マスクレジスタのビットに応じて、対応する「X」ピンがサンプリングされ、その結果が「MA」と「X」の組み合わせに対応する場所に格納されます。 当社の開発ボードには外部アナログ多重化装置が設計されていないため、そのような例は実装されていません。 Re: S32K3 ADC Use of external channels こんにちは。ヴェインB あなたのプロンプトによると、RTDで外部チャネルADCを使った例が見つかりません。もし対応するルーティンがあれば、ぜひ送っていただけると嬉しいです。どうもありがとうございます。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin RTDで役立つかもしれないADCの実装例が見つかります。 BR VaneB

MBDT中的CAN总线处理 我正在使用 NXP 的 MBDT for S32K344 来配置 FlexCAN0。我想了解 CAN 消息处理的哪些部分由 NXP 模块/工具箱管理，哪些部分需要由应用程序处理。 仲裁和缓冲区处理是否由驱动程序/工具箱管理？例如：如果我先发送 0x18FEF111，那么 0x18FEEF00 都不会出现在总线上。但如果先发送 0x18FEEF00，则两者都会被发送。当两者同时触发信号时，只会显示其中一个。 那么，在同时发送多个帧时，是否需要为每个消息 ID 分配专用的发送硬件对象？ MBDT 或 SDK 是否处理消息优先级，并在未收到 ACK 时自动重试？ 如果高优先级 ID 失败（例如，没有收到 ACK），是否会阻塞其他消息？我们如何检测并从中恢复？ 为了避免阻塞或消息丢失，模型中是否需要手动管理缓冲区分配或传输时序？ 在 MBDT 中配置多个 Tx 消息 ID 的最佳方法是什么？使用动态缓冲区。 请明确哪些是内部处理的，哪些是我们需要在应用程序中处理的。 示例模型 Re: CAN Bus Handling in MBDT 你好@SorinIBancila ， 我遇到了需要发送的帧数超过可用 HTH 硬件对象数量的情况。由于 S32CT 无法利用 CanIf 发送缓冲实现，您能否推荐一种基于 Simulink 的缓冲解决方案来解决此问题？ 谢谢，此致敬礼！ 桑德什 Re: CAN Bus Handling in MBDT 你好， 32 个 Can Hw 对象数量并非限制。根据你所使用的MCU型号，你还可以进一步提高这个限制。您可以修改 Can Hw Object Count 的数量，但如果您输入的数字过大，S32CT 将报错。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 明白了！如果我需要发送超过 32 条消息，是否应该创建额外的发送硬件对象？另外，在 S32K3 中使用 S32CT，单个 CAN 收发器或控制器下最多可以配置多少个硬件对象？ 想了解在限制条件下，如何以最佳方式构建大型消息集的 HOH。 Re: CAN Bus Handling in MBDT 你好， 你认为一次需要发送多少条信息？ 我已在 S32K358 HVBMS 参考设计上测试了以下场景： 使用单个 TX 硬件对象，并将Can 硬件对象计数设置为 32（以允许缓冲区中最多 32 条消息）。 在 Simulink 中，我向消息缓冲区填充了 32 条消息，随着缓冲区填充的进行，消息优先级也随之增加，以验证仲裁过程。 结果： 正如预期的那样，由于消息缓冲区尚未完全填充，因此发送的第一批消息优先级较低。大约在第 6 条消息时，缓冲区已满，我们可以看到优先级较高的消息会先发送。 由于你想使用单个收发器，因此实际上不可能同时发送所有消息。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 索林，你好 感谢您的意见！ 我想说明在使用动态缓冲区时，在 MBDT 中配置多个 Tx 消息 ID 的最佳方法。就我而言，该控制器用于电动汽车应用，采用基于 J1939 的 CAN 设置，涉及数百个循环消息。 在 S32CT 中为每条消息创建单独的硬件对象似乎既不可扩展也不实用。我希望使用单个 Tx 硬件对象来动态处理多个消息，并通过一个 CAN 接口同时传输它们。 请问针对这种使用场景，推荐的配置或最佳实践是什么？另外，请推荐一些我需要参考的文档，以便了解 MBDT 中配置设置的工作原理和相关函数。 Re: CAN Bus Handling in MBDT 你好， 首先，我想指出的是，S32K3xx 的 MBDT 是基于 S32K3 RTD 的版本。外围设备的配置是在 S32 配置工具中完成的，以便您可以灵活地进行所需的设置。因此，要检查 NXP 的 MBDT S32K3xx 是否支持某个功能，您可以检查外设（在 S32K3 RTD 中）使用的源代码及其在 S32 配置工具中的可用设置。 在工具箱中，您可以在此处找到 FlexCAN 外设的实现： {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 笔记！根据您使用的 MBDT S32K3 版本不同，S32K3 RTD 的名称可能会有所不同。 你问题的答案是基于我的经验，可能并不完全准确。 1、2 和 5：该工具箱不处理任何仲裁，但我不太确定 SDK 中有哪些选项可用于此目的。在你的示例中，你创建了另一个CanHardwareObject并使用它来发送第二条消息，但这种方法可能难以管理。第二个解决方案可能是增加Can Hw 对象计数，以允许缓冲区中存在更多消息。 3：S32K3 的 MBDT 不处理任何消息优先级。据我所知，FlexCAN 控制器负责重试发送消息，直到收到 ACK 为止，同时将消息阻塞在缓冲区中。 4. 检测消息是否已发送的一种方法是使用硬件中断回调中的CanIf_TxConfirmation中断来标记消息已发送。如果指定的 PDU 没有触发信号中断，则表示该消息未发送。此外，还有一个中断（ CAN_ControllerBusOff ）可用，当满足 CAN 总线关闭的条件时，该中断会产生触发信号。在 S32 配置工具中，有一个选项可以从总线关闭状态自动恢复。 如有任何疑问，请随时回复。 此致， 索林·班奇拉

MC33774 デイジーチェーン デュアルループ接続 こんにちは。 現在、MC33665AとMC33774を使用してダブルチェーンループバック構造を形成するAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1はそれぞれMADD0とMADD1として構成されており、すべてのコマンドは現在MADD0経由で送信されています。PORT0とDC1の間だけをデイジーチェーン接続すると、通信は正常です。しかし、PORT1とDC2の間にもデイジーチェーン接続すると、33774が応答フレームで応答できないことがわかりました。これはなぜでしょうか？33665のPORT構成が正しいこと、および33774のSYS_TPL_CFG.RESPCFGが00 SAMEモードに設定されていることは確認済みです。 現在、私はMC33665AとMC33774を組み合わせたデュアルリングループ構成のAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1をそれぞれMADD0とMADD1として設定し、現在すべてのコマンドはMADD0経由で送信されています。 PORT0とDC1の間だけをデイジーチェーン接続した場合、通信は正常に動作します。しかし、PORT1とDC2の間にデイジーチェーン接続も行った後、MC33774にリクエストを送信しても応答しなくなりました。 なぜこのようなことが起こるのでしょうか？ MC33665 PORT の設定を読み返して確認したところ、正しいことが分かりました。また、MC33774 で SYS_TPL_CFG.RESPCFG = 00 (SAME モード) を設定しました。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは。 1. MADD=1の位置からDADDの割り当てを反転させる必要があるかどうかを知りたいです。 2. 現在のSYS_PORT0_CFG構成は、TIMEOUT=0、CADD=1、MADD=0、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1です。 SYS_PORT1_CFG は、TIMEOUT=0、CADD=1、MADD=1、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1 で構成されています。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨によると、2つのMC33665A TPLポートがループバックリングとしてコネクテッドである場合、あなたが見ている挙動を引き起こすいくつかの設定要件があります。 ループバック構成の場合： デバイスアドレス（DADD）は、リングの一方の側からは昇順で、ループバック側からは逆順で割り当てることをお勧めします（あなたの画像にはそれが確認できません）。 2つのポートがループバックとしてコネクテッドされている場合、重複データがMC33665バッファに入るのを防ぐために、どちらか一方のポートはSYS_PORTx_CFG[RX] = 0であるべきです。 さらに、いずれかのポートのSYS_PORTx_CFG[ALLCHAINS]が0である必要があります。両方のループバックポートがALLCHAINSコマンドを受け入れている場合、文書にはこれが信号の競合や通信エラーを引き起こす可能性があると記載されています。 SYS_PORT0_CFGとSYS_PORT1_CFG(特にEN、RX、ALLCHAINS、MADD、CADD)の価値観を共有していただけますか?それは、ループバックポートがAN13910の推奨事項に従って構成されているかどうかを判断するのに役立ちます。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨事項によると、ループバックトポロジでは、DADDの割り当てはMADD=1側から逆にする必要があります。 さらに、現在の設定では、両方のポートでRX=1およびALLCHAINS=1となっています。ループバック接続の場合、重複ルーティングや通信の競合を避けるため、いずれかのポートでRXとALLCHAINSを無効にすることをお勧めします。 RX=0、ALLCHAINS=0のポート(例えばPORT1)を設定して、MC33774が応答フレームを返し始めるか確認していただけますか?

调试 Flash 脚本覆盖“保护内部闪存区域”设置 您好， 我们目前正在测试FRDM-S32K344上从App1到App2的应用程序跳转。 我们的应用程序布局如下： 应用程序1起始地址： 0x00400000 应用程序2起始地址： 0x00500000 为了进行调试，我们使用了启用闪存保护的独立调试配置。 调试App1时，内存保护范围配置如下： 0x00500000 到 0x005FFFFF（用于保护 App2） 调试App2时，内存保护范围配置如下： 0x00400000 到 0x004FFFFF（用于保护 App1） 然而，在通过调试配置进行编程时，我们发现即使已经配置了内存保护范围，受保护的闪存区域仍然会被擦除。 请问有人能解释一下以下问题吗？ Flash Programmer 在擦除/编程操作期间是否应遵守配置的内存保护范围？ 是否需要进行任何额外的配置来防止受保护的闪存区域被擦除？ 有没有人成功地使用内存保护功能，在 FRDM-S32K344 上只编写一个应用程序的同时，保留另一个应用程序？ 日志文件和 LD 文件已附上，供您参考。 我们正在使用板上 PE 调试器 任何指导或建议都将不胜感激。 谢谢！ Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好@Avinpat123 我在相同版本的 S32 Design Studio 中进行了快速测试，以确保它能够正常工作。我使用了相同的设置——一个应用程序被强制使用 0x40_0000 地址，而 0x50_0000 地址区域配置为保留；第二个应用程序被强制使用 0x50_0000 地址，而 0x40_0000 地址区域配置为保留： 以下日志显示此配置已被应用： 而且我可以看到内存中的内容确实被保留了下来，所以它运行正常。 我从你的截图中看到你配置了地址范围，但是“保留此范围”复选框没有启用。问题不就出在这里吗？ 此致， Lukas Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好 @lukaszadrapa 谢谢回复，是的，正如您所说，复选框确实是问题所在，现在一切正常了。

MBDTにおけるCANバス処理 FlexCAN0の設定には、NXPのS32K344用MBDTを使用しています。CANメッセージ処理のどの部分がNXPのブロックやツールボックスで管理され、何がアプリケーションで処理されるべきかを理解したいです。 仲裁やバッファの処理はドライバやツールボックスで管理されていますか?例：最初に0x18FEF111を送信すると、0x18FEEF00はバス上に表示されません。しかし、0x18FEEF00を先に送信すると、両方とも送信されます。両方を同時に送信すると、どちらか一方のみが表示されます。 SO、複数のフレームを同時に送信する際、各メッセージIDに専用のTxハードウェアオブジェクトを割り当てる必要がありますか? MBDTやSDKsはメッセージの優先順位付けを処理し、ACKが届かない場合に自動的に再試行しますか? 優先度の高いIDが失敗した場合（例えば、ACKが返ってこなかった場合）、他のメッセージもブロックされますか？これをどのように検知し、復旧すればよいのでしょうか？ ブロックやメッセージの喪失を避けるために、モデル内でバッファの割り当てや送信タイミングを手動で管理する必要がありますか? MBDTで複数のTxメッセージIDを設定する最適な方法は何ですか？動的バッファを使用する場合。 社内で何が処理されるのか、アプリケーションで何が処理されるのかを明確にしてください。 サンプル・モデル Re: CAN Bus Handling in MBDT こんにちは、 @SorinIBancila さん、 利用可能なHTHハードウェアオブジェクトの数よりも多くのフレームを送信する必要がある状況に遭遇しました。CanIf送信バッファリング実装はS32CTでは活用できないため、この問題に対してsimulinkベースのバッファソリューションをおすすめしてもらえますか? ありがとうございます。 サンデシュ Re: CAN Bus Handling in MBDT こんにちは、 32 CANのハードウェアオブジェクト数は制限ではありません。MCUによってはさらに制限を上げることも可能です。CANオブジェクトカウントの上限を変更できますが、数字を大きくするとS32CTがエラーを出します。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT 理解した！SO、32以上のメッセージを送信する必要がある場合、追加のTx Hardware Objectを作成するべきでしょうか?また、S32CTを使ったS32K3で単一のCANトランシーバまたはコントローラの下で設定できるハードウェアオブジェクトの最大数はどれくらいですか? 制限内に収まるように、大規模なメッセージセットに対してHOH（階層型ヘッダー）を構成する最適な方法を理解したいと考えています。 Re: CAN Bus Handling in MBDT こんにちは、 一度に何件のメッセージを送信する必要があると思いますか？ S32K358 HVBMSリファレンスデザインで以下のシナリオをテストしました: 単一の送信ハードウェアオブジェクトを使い、Can Hw Objectカウント を32に設定します(バッファ内に最大32メッセージを許可するため)。 Simulinkでは、調停プロセスを検証するために、メッセージバッファに32個のメッセージを格納し、バッファにメッセージが格納されるにつれて優先度を上げました。 結果： 予想通り、メッセージバッファが完全に満たされていないため、最初に送信されるメッセージは優先度が低くなります。6番目のメッセージあたりでバッファが埋められ、CANの優先度の高いメッセージが最初に送信されるのがわかります。 単一のトランシーバを使いたい場合、すべてのメッセージを同時に送信することは実際には不可能です。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT こんにちは、ソリンさん。 ご意見ありがとうございます！ 動的バッファを使用する場合に、MBDTで複数の送信メッセージIDを設定する最適な方法を明確にしたいと思いました。私の場合、コントローラはJ1939ベースのCANセットアップでEVアプリケーションに使われており、数百のサイクリックメッセージが関わっています。 S32CTでメッセージごとに個別のハードウェアオブジェクトを作成する方法は、拡張性にも実用性にも欠けるように思われる。単一のTxハードウェアオブジェクトを使って複数のメッセージを動的に処理し、1つのCANインターフェースを通じて同時に送信したいと考えています。 このユースケースで推奨されるセットアップやベストプラクティスについて教えていただけませんか?また、MBDTで使われる設定設定や関連関数の仕組みを理解するために参照しなければならないドキュメントもぜひ教えてください。 Re: CAN Bus Handling in MBDT こんにちは、 まず最初に、S32K3xx用のMBDTはS32K3 RTDをベースに構築されていることを指摘しておきたいと思います。ペリフェラルの設定はS32設定ツールで行い、必要な設定に完全な柔軟性を持たせます。つまり、NXPのMBDT S32K3xxで機能がサポートされているかどうかを確認するには、ペリフェラル(S32K3 RTDで使用されている)のソースコードとS32設定ツールの利用可能な設定を確認できます。 ツールボックスには、FlexCANペリフェラルの実装がこちらにあります: {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 注記！S32K3 RTDの名称は、使用するMBDT S32K3のバージョンによって異なる場合があります。 ご質問への回答は私の経験に基づくものであり、必ずしも完全に正確とは限りません。 1 & 2 & 5:ツールボックスは仲裁を扱っていませんが、SDKでこのマターに関してどんなオプションがあるのかはよくわかりません。あなたの例では、別のCanHardwareObjectを作成してそれを使って 2 番目のメッセージを送信していますが、この方法は管理が難しいかもしれません。2つ目の解決策は、バッファにより多くのメッセージを入れるためにCan Hw Object Countを作成することです。 3：S32K3 用の MBDT はメッセージの優先順位付けを処理しません。私の知る限り、FlexCANコントローラの役割は、ACKが受信されるまでメッセージを再送信しつつ、バッファ内でメッセージをブロックすることです。 4. メッセージが送信されたかどうかを検出する方法の1つは、ハードウェア割り込みコールバックで割り込みCanIf_TxConfirmationを使用して、メッセージが送信されたことをマークすることです。指定されたPDUに対して割り込みが発生しない場合、メッセージは送信されなかったことを意味します。さらに、CANバスオフの条件を満たすとトリガーされる別の割り込み(CAN_ControllerBusOff)が利用可能です。S32設定ツールには、バスオフ状態から自動的に復旧するオプションがあります。 ご質問があれば、遠慮なくご返信ください。 よろしくお願いします、 ソリン・バンシラ

定制 S32G399A 板：双向均无帧交叉选择开关面向 RGMII 总线 板：基于 S32G399A 的定制模块，源自 S32G-VNP-RDB3。PFE_MAC1 通过 RGMII (PE_02–PE_13) 连接到 NXP SJA1110A 交换机端口 2，配置为 DSA CPU 端口（树内 sja1105 驱动程序，内核 6.x BSP43.0）。 拓扑结构： - PFE_MAC0：通过 SerDes1 通道 1 的 SGMII，模式 1 - PFE_MAC1：RGMII 到 SJA1110A 端口 2（DSA CPU 端口）——即所讨论的端口 - PFE_MAC2：通过 SerDes0 通道 1 进行 SGMII 传输 S32G MAC地址配置如下： +---------+--------------+------------------+ | | 第 0 道 | 第 1 道 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完整的 U-启动 硬件配置： hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii 端口 2（交换机侧）的 DTS： port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1（MAC 端）的 DTS： &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) 链路状态 — 已确认已启动，并且在 Linux/驱动程序级别配置正确： 启动时 dmesg： [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed 实时 DTB 确认内核与源 DTS 匹配： # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip 输出： 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link 所有SJA1110 DSA从端口均已正确枚举。这证实了 sja1105 DSA 驱动程序已成功绑定。 将 pfe1 作为 CPU 端口/DSA 主设备，并解析静态配置，未出现错误。 时钟树： TX 和 RX RGMII 时钟均已启用并连接到正确的使用者： # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id 因此，pfe1 状态为 UP、LOWER_UP，已正确绑定到 SJA1110 作为 DSA 主设备，并以 RGMII 模式运行。 两个时钟都已启用——这排除了 pfe1 宕机、未绑定或配置错误的可能性。 Linux/驱动程序级别。目前尚不清楚的具体问题是，帧是否真的会跨越 PFE_MAC1 和 SJA1110 端口 2 之间的物理 RGMII 引脚。 问题： 尽管总线两侧的所有设备都已独立启动，但 PFE_MAC1 和 SJA1110 端口 2 之间的 RGMII 总线似乎没有任何流量双向通过： 测试 1 — S32G -> 切换方向 设置： ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 测试 2 — 切换 -> S32G 方向 设置伙伴板是一个独立的基于 SJA1105 交换机的板。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] 端口 9 接收到 9 个实际帧；交换矩阵将全部 9 个帧转发到端口 2——但是 pfe1处未收到任何信息。 因此，SJA1110 自身的交换矩阵计数器显示所有 9 个帧都已成功从端口 9 转发到端口 2 的出口。 但是，在本次测试中，S32G 上运行 tcpdump -i pfe1 -e -nn 命令显示没有收到任何数据。 因此，S32G 端的 DSA/软件层认为它正在发送（情况 1）。交换机的内部结构认为它正在向 CPU 端口发送数据（情况 2）。双方都无法确认对方是否真的通过物理 RGMII 总线收到了任何信息。与这条总线相邻的每一层都是独立运行的；这条总线本身在任何方向上都没有确认的成功穿越记录。 目前已排除的可能性： - pfeng_mode / hwconfig (xpcs_mode) — 已确认正确；EMAC1 模式为 RGMII (0x9)，而非 SGMII（之前由于 SerDes1 上的 xpcs_mode=both 强制 PFE_MAC1 的 XPCS 为 SGMII，因此错误地配置为 SGMII；已更正为 xpcs_mode=0，因为 PFE_MAC0 单独只需要 XPCS0）。 - PFE_MAC1 TX/RX 时钟使能 — 已在 clk_summary 中确认以正确的频率 (125MHz) 使能 - DSA 标记和 CPU 端口绑定——已确认工作正常（端口网络设备存在，帧在 DSA 标头中被标记了正确的目标端口） - SJA1110 内部交换矩阵/转发 — 已确认在另外两个端口（9 和 2）之间使用真实外部流量正常工作 - BASE-T1 链路伙伴 — 已确认将真实帧传递到交换机（端口 9 n_rxfrm 从真实的线路流量中递增） 尚未排除的可能性/悬而未决的问题： - 在 MAC 端和交换机端均无内部延迟（rx/tx-internal-delay-ps=0，使用纯“rgmii”而非“rgmii-id”）的情况下，1000 Mbps RGMII 是否兼容，且不考虑板载走线长度带来的延迟——尚未尝试将链路速率强制降至 100 Mbps 进行时序裕量测试。 1. 在 1000 Mbps RGMII 模式下，两端的 rx/tx-internal-delay-ps=0 是否预期可以工作，或者除非 PCB 明确考虑了延迟补偿，否则这种组合通常需要延迟补偿吗？ 2. 我是否遗漏了其他配置？ 如有需要，我很乐意提供完整的寄存器转储文件。在用逻辑分析仪探测 PE_02-13 总线之前，请提供一些建议（由于电路板布局的限制，探针的访问受到限制，因此目前不太方便）。 谢谢。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z @db16122，我把原理图的相关部分附在这里。连接流程如下： 我们使用s32g3_pfe_mac1_connections.png中所示的 S32G3 芯片上的 PE_02 到 PE_13 作为 PFE_MAC1。它们连接到板对板连接器（如图Board_to_board_connector.png所示），该连接器将这些信号路由到具有开关的另一块板。交换机连接如图SJA1110_A.png和SJA1110_B.png 所示。 所以连接方式是：PE_xx 引脚 -> 板连接器 -> 开关 (SJA1110) 如有任何疑问，请随时联系我。我也提交了一份支持工单（ #00990408 ），内容与上述相同。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好， pcentauri92 感谢您的回复。 请提供与您的 ETH 相关的原理图，特别是 PFE_MCA1 和 SJA1110 部分的原理图。 您可以创建内部支持系统案例。@Joey ，请在信息描述中提供您的原理图信息。请访问此网站： https://support.nxp.com BR 乔伊 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z ， 谢谢你的回复。 这里提到的模块是一个定制设计，它使用了 S32G399A 芯片和 NXP SJA1110A 以太网交换机。我们以 S32G-VNP-RDB3 开发平台为基础进行设计，但对基础设计做了一些改动。使用 RGMII 的 PFE_MAC1 就是其中一项更改。 我还附上了 dts 文件覆盖，其中我们更改了 PFE_MAC1 模式和引脚复用。 PFE_MAC1 模式配置： /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 引脚复用： /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 如果您还需要其他信息，请告诉我。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 是否有关于PFE_MAC1和SJA1110端口2之间RGMII总线的硬件原理图可以分享？ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好， pcentauri92 感谢您提供的详细信息 据我了解，当您在开发板上使用 PFE_MAC1 RGMAII 和 SJA1110A 的端口 2 时，通信似乎存在问题。是这样吗？ S32G-VNP-RDB3 的默认配置是 PFE_MAC0/1 以 SGMII 模式运行并连接到 SJA1110。在你的开发板上，为什么考虑使用 RGMII 模式？建议修改相应的软件配置。 BR 乔伊

カスタムS32G399Aボード:スイッチ面RGMIIバスをクロスフレームなしでいずれの方向にも接続しません 基板： S32G-VNP-RDB3をベースにしたカスタムS32G399Aモジュール。PFE_MAC1 RGMII(PE_02–PE_13)を介してNXPのSJA1110Aスイッチポート2にコネクテッド、DSA CPUポートとして設定されていました(in-tree sja1105ドライバ、カーネル6.x BSP43.0)。 トポロジー： - PFE_MAC0: SerDes1 レーン 1 経由の SGMII、モード 1 - PFE_MAC1: RGMII から SJA1110A ポート 2 (DSA CPU ポート) — 問題のポート - PFE_MAC2: SerDes0レーン1経由のSGMII S32G MACは以下のように構成されています。 +---------+--------------+------------------+ | | レーン0 | レーン1 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完全なU-Bootハードウェア構成: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii port@2用DTS(スイッチ側): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1 (MAC側) の DTS: &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1(pfe1)リンク状態 — Linux/ドライバーレベルで確認・正しく設定: 起動時のdmesg: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTBは、カーネルがソースDTSと一致することを確認します。 # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a の出力: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link SJA1110 DSAスレーブポートはすべて正しく列挙されました。これにより、sja1105のDSAドライバが正常にバインドされていることが確認されました pfe1をCPUポート/DSAマスターとして設定し、静的設定を誤りなく解析しました。 クロックツリー： TXおよびRXのRGMIIクロックが両方とも有効で、正しいコンシューマーに接続されています。 # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id SO pfe1はUP、LOWER_UP、DSAマスターとして正しくSJA1110バインドされ、RGMIIモードで動作しています 両方のクロックが有効になっている場合 — これによりPFE1がダウン、アンバウンド、または誤った設定で Linux/ドライバレベル。未解決の問題は、フレームが実際に PFE_MAC1とSJA1110ポート2間の物理的なRGMIIピン。 問題： PFE_MAC1とSJA1110ポート2間のRGMIIバスでは、バスの両側の機器がすべて独立して稼働しているにもかかわらず、どちらの方向にもトラフィックが流れていないようです。 テスト1 — S32G ->スイッチ方向 セットアップ: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 テスト2 — スイッチ-> S32G方向 セットアップパートナーボードは別のスイッチベースのSJA1105ボードです。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] ポート9は9つの実際のフレームを受信しました。ファブリックは9つすべてをポート2に転送しましたが、 pfe1には何も届きませんでした。 SO、SJA1110自身のファブリックカウンターでは、ポート9からポート2の出口へ9フレームすべてが正常に転送されたことが示されています。 しかし、このテスト中にS32Gでtcpdump -i pfe1 -e -nnを実行すると、何も受信されなかったことが示されます。 つまり、S32G側のDSA/ソフトウェア層は送信していると認識しています(CASE 1)。スイッチの内部ファブリックはCPUポートに向かって送信していると認識しています(CASE 2)。どちらの側も、相手側が物理的なRGMIIバスを介して実際に何かを受信したという確証は得ていない。このバスに隣接する各層は個別に機能します。バス自体は、どちらの方向にも正常に通過したことが確認されていません。 これまでに除外されたこと: - pfeng_mode / hwconfig (xpcs_mode) — 正確であることが確認されています。EMAC1モードはRGMII(0x9)であり、SGMIIではありません(以前はSerDes1でxpcs_mode=両方がPFE_MAC1のXPCSSをSGMIIに強制的に入ったためSGMIIとして誤って設定されていました。PFE_MAC0単独でXPCS0が必要なため、xpcs_mode=0に修正します) - PFE_MAC1 TX/RXクロックのイネーブルメント — clk_summaryで正しいレート(125MHz)で有効化が確認されています - DSAタグ付けおよびCPUポートバインディング — 動作確認済み(netdevのポートが存在し、フレームにDSAヘッダーで正しい宛先ポートがタグ付けされる) - SJA1110内部ファブリック/転送 — 実際の外部トラフィックを用いて他の2つのポート(9と2)間で動作が確認されました - BASE-T1リンクパートナー — 実際のフレームをスイッチに渡すことを確認しました(ポート9 n_rxfrm実際のワイヤートラフィックからのインクリメント) まだ排除されていないこと/未解決の疑問: - MAC側とスイッチ側の両方で内部遅延ゼロ(rx/tx-internal-delay-ps=0、単に「rgmii」ではなく「rgmii-id」)の1000 Mbps RGMIIがボードトレース長による遅延なしに互換性があるかどうか — タイミングマージンテストとしてリンクを100 Mbpsに強制的に落とす試みはまだしていません 1. 1000 Mbps RGMII において、両端で rx/tx-internal-delay-ps=0 は正常に動作すると想定されますか？それとも、PCB が明示的に遅延を考慮していない限り、この組み合わせでは通常、遅延補償が必要になりますか？ 2. 他に何か設定漏れはありますか？ 必要であれば、完全なレジスタダンプを提供いたします。PE_02-13バスをロジックアナライザで探査する前に、何かアドバイスをいただけるとありがたいです(基板レイアウトのためプローブへのアクセスが限られているため、現状はあまり便利ではありません)。 ありがとう。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん、@db16122 さん。回路図の関連部分をここに添付します。接続の流れは以下のとおりです。 PFE_MAC1には、s32g3_pfe_mac1_connections.pngに示されているS32G3チップ上のPE_02からPE_13を使用します。基板間コネクタ( Board_to_board_connectorに示されています)。png)を使い、これらの信号をスイッチを持つ別のボードにルーティングします。スイッチ接続は SJA1110_Aで示されています。png および SJA1110_B.png。 接続はPE_xxピン - >基板コネクタ - >スイッチ(SJA1110) ご質問があればお知らせください。同じ詳細でサポートチケット( #00990408)も提出しました。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 ご返信よろしくお願いします。 貴社のETHに関する回路図、特にPFE_MCA1およびSJA1110セクションの回路図をご提供ください。 内部サポートシステムのケースを作成することもできます。情報の説明欄に、 @Joey さん、回路図の情報を提供してください。こちらのウェブサイトを参照してください： https://support.nxp.com BR ジョーイ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん。 ご回答ありがとうございます。 ここで扱っているモジュールは、S32G399AチップとNXP SJA1110Aイーサネットスイッチを組み合わせたカスタム設計です。このデザインはS32G-VNP-RDB3の開発プラットフォームを基にしましたが、ベースデザインからかなりの変更を加えました。RGMIIを使用するPFE_MAC1は、そうした変更点の1つです。 また、PFE_MAC1モードとピン多重化を変更するdtsファイルのオーバーライドも添付します。 PFE_MAC1モードの設定： /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1ピンマルチプレクサ: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 他に何か情報が必要な場合はお知らせください。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction PFE_MAC1とSJA1110ポート2間のRGMIIバスに関するハードウェア側の回路図を共有していただけませんか？ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 詳細な情報を提供していただきありがとうございます。 私の理解では、開発ボード上でRGMAIIとポート2を使うPFE_MAC1通信に問題があるようですSJA1110A。それは正しいですか？ S32G-VNP-RDB3のデフォルト構成は、PFE_MAC0/1がSGMIIモードで動作し、SJA1110にコネクテッドです。開発ボードでRGMIIモードを使うことを考えたのはなぜですか?対応するソフトウェア構成を変更することが推奨されます。 BR ジョーイ

MC33774 Daisy Chain Dual Loop Connection HI. 我当前使用MC33665A+MC33774的AFE采样系统组成双链回环的结构，配置MC33665A的PORT0和PORT1分别为MADD0和MADD1，当前发送所有指令均由MADD0发送。当我只连接PORT0到DC1之间的菊花链时，我的通讯都是正常的，但是当我把PORT1和DC2之间的菊花链也连接后，我再去请求33774发现33774无法回复响应帧，这是为什么？我回读确认过33665的PORT端口配置没有错误，并且将33774中的SYS_TPL_CFG.RESPCFG设置为00 SAME模式。 I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1.我想知道从MADD=1的位置反向分配DADD是必须的吗？ 2.我当前的SYS_PORT0_CFG配置为TIMEOUT=0,CADD=1,MADD=0,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 SYS_PORT1_CFG配置为TIMEOUT=0,CADD=1,MADD=1,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 Re: MC33774 Daisy Chain Dual Loop Connection 你好， 根据 AN13910 TPL 环回建议，当两个 MC33665A TPL 端口连接成环回环时，存在一些配置要求，可能会导致您看到的行为。 对于环回配置： 我们建议从环的一侧按升序分配设备地址 (DADD)，从环回侧按相反的顺序分配设备地址 (DADD)（我在你的图片中没有看到这一点）。 如果两个端口连接为环回，则其中一个端口应设置 SYS_PORTx_CFG[RX] = 0，以避免重复数据进入 MC33665 缓冲区。 此外，其中一个端口的 SYS_PORTx_CFG[ALLCHAINS] 应为 0。文档指出，如果两个环回端口都接受 ALLCHAINS 命令，则可能导致信号冲突和通信错误。 请问能否提供 SYS_PORT0_CFG 和 SYS_PORT1_CFG 的值（特别是 EN、RX、ALLCHAINS、MADD 和 CADD）？这将有助于确定环回端口是否按照 AN13910 建议进行配置。 Re: MC33774 Daisy Chain Dual Loop Connection 你好， 根据 AN13910 TPL 环回建议，在环回拓扑中，DADD 分配应与 MADD=1 侧相反。 此外，您当前的配置在两个端口上都设置了 RX=1 和 ALLCHAINS=1。对于环回连接，我们建议禁用其中一个端口上的 RX 和 ALLCHAINS，以避免重复路由和通信冲突。 请尝试将一个端口的 RX=0 和 ALLCHAINS=0 配置为（例如，PORT1），并验证 MC33774 是否开始返回响应帧？

「内部フラッシュメモリ領域」設定を上書きするDebug Flashスクリプト こんにちは、 現在、FRDM-S32K344上でApp1からApp2へのアプリケーションジャンプをテスト中です。 私たちのアプリケーションレイアウトは以下の通りです: アプリ1の開始アドレス: 0x00400000 アプリ2の開始アドレス: 0x00500000 デバッグには、フラッシュメモリ保護を有効にした個別のデバッグ構成を使用しています。 App1のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00500000～0x005FFFFF（App2を保護するため） App2のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00400000～0x004FFFFF（App1を保護するため） しかし、デバッグ構成によるプログラミング中に、メモリ保護範囲が設定されているにもかかわらず、保護対象のフラッシュ領域が消去されていることが確認されました。 どなたか次の点をCANしてもらえますか? フラッシュプログラマは、消去／書き込み操作中に、設定されたメモリ保護範囲を尊重することが求められますか？ 保護されたフラッシュ領域が消去されないようにするために、追加の設定が必要ですか？ FRDM-S32K344上で1つのアプリケーションだけをプログラムしながら、メモリ保護を使って別のアプリケーションを保存することに成功した方はいらっしゃいますか? ログファイルとLDファイルを参考資料として添付しました。 私たちは搭載のPEデバッガを使用しています 何かご助言やご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings こんにちは、@Avinpat123さん 同じバージョンのS32 Design Studioで動作しているか素早くテストしました。私も同じ設定を使いました。1つのアプリケーションは0x50_0000領域が保持されるように設定されている間に強制的に0x40_0000し、もう1つのアプリケーションは0x50_0000を強制され、0x40_0000領域は保存されるように設定されています: この設定が考慮されていることを示すログを以下に示します。 メモリを見ると、内容が本当に保存されているのがわかり、SO、期待通りに動作します。 スクリーンショットを確認したところ、アドレス範囲は設定されているようですが、「この範囲を保持する」チェックボックスが有効になっていません。問題はそこではないでしょうか？ よろしくお願いいたします。 ルーカス Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings こんにちは、@lukaszadrapa ご返信ありがとうございます。おっしゃる通り、チェックボックスが問題でした。今は正常に動作しています。

MC33774 Daisy Chain Dual Loop Connection HI. I'm currently using an AFE sampling system with MC33665A and MC33774 to form a double-chain loopback structure. The MC33665A's PORT0 and PORT1 are configured as MADD0 and MADD1 respectively, and all commands are currently sent via MADD0. When I only connect the daisy chain between PORT0 and DC1, my communication is normal. However, when I also connect the daisy chain between PORT1 and DC2, I find that the 33774 cannot reply with a response frame. Why is this? I have confirmed that the PORT configuration of the 33665 is correct and that SYS_TPL_CFG.RESPCFG in the 33774 is set to 00 SAME mode. I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1. I want to know if it is necessary to reverse the allocation of DADD from the position where MADD=1? 2. My current SYS_PORT0_CFG configuration is TIMEOUT=0, CADD=1, MADD=0, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 SYS_PORT1_CFG is configured with TIMEOUT=0, CADD=1, MADD=1, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 Re: MC33774 Daisy Chain Dual Loop Connection Hello, According to the AN13910 TPL Loopback Recommendation, when two MC33665A TPL ports are connected as a loopback ring, there are several configuration requirements that may cause the behavior you are seeing. For a loopback configuration: We recommend assigning device addresses (DADD) in ascending order from one side of the ring and in reverse order from the loopback side (I do not see this in your image). If two ports are connected as loopback, one of the ports should have SYS_PORTx_CFG[RX] = 0 to avoid duplicate data entering the MC33665 buffer. In addition, one of the ports should have SYS_PORTx_CFG[ALLCHAINS] = 0. If both loopback ports accept ALLCHAINS commands, document states that this can cause signal conflicts and communication errors. Could you please share the values of SYS_PORT0_CFG and SYS_PORT1_CFG (especially EN, RX, ALLCHAINS, MADD, and CADD)? That would help determine whether the loopback ports are configured according to the AN13910 recommendations. Re: MC33774 Daisy Chain Dual Loop Connection Hello, According to AN13910 TPL Loopback Recommendation, the DADD assignment should be reversed from the MADD=1 side in a loopback topology. In addition, your current configuration has RX=1 and ALLCHAINS=1 on both ports. For a loopback connection, we recommend disabling RX and ALLCHAINS on one of the ports to avoid duplicate routing and communication conflicts.  Could you please try configuring one port with RX=0 and ALLCHAINS=0 (for example, PORT1) and verify whether the MC33774 starts returning response frames?

S32K3 ADC 使用外部通道 你好。恩智浦团队 如何使用S32K3 ADC的外部通道 . Re: S32K3 ADC Use of external channels 嗨@VaneB 我还有后续问题。 如果我的设计没有多路复用器，但我只想使用例如 ADC1_X[0] 连接传感器 1，ADC1_X[1] 连接传感器 2，ADC1_X[2] 连接传感器 3，我可以将 MA 引脚重复使用于其他用途吗，例如用作 GPIO 输出引脚来驱动 LED？ 我的设计基于s32k344 Re: S32K3 ADC Use of external channels NPX团队，您好！ 关于这个话题，请问是否可以实现如下图所示的SCH？ 非常感谢您的支持。 Re: S32K3 ADC Use of external channels @VaneB 非常感谢您的帮助。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 每个 ADC 提供 3 个外部解码信号 (MA)，用于从外部模拟多路复用器的 8 个通道中选择 1 个通道，最多可以有 4 个这样的多路复用器来连接 32 个外部通道，这意味着这 4 个多路复用器共享相同的 MA 信号。 ADC 根据当前选择的转换通道，自动设置 MA 来控制这些外部模拟多路复用器。根据掩码寄存器位，对相应的“X”引脚进行采样，并将结果存储在“MA”和“X”组合的匹配位置中。 由于我们的开发板上没有设计外部模拟多路复用器，因此没有实现这样的示例。 Re: S32K3 ADC Use of external channels 你好。VaneB 根据您的提示，我找不到在RTD中使用外部通道ADC的例子。如果你有相应的日常安排，希望你能发给我。非常感谢。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 您可以在 RTD 中找到一些可能对您有用的 ADC 实现示例。 BR VaneB

S32K3 ADC Use of external channels Hello.  NXP Team How to use the external channel of S32K3 ADC . Re: S32K3 ADC Use of external channels Hi @VaneB I have a followup to this. If my design DOES NOT have a MUX but I want to use only for example ADC1_X[0] to sensor1, ADC1_X[1] to sensor2 and ADC1_X[2] sensor 3, can i reuse the MA pins for other purpose like GPIO output pins to drive an LED? My design is based on s32k344 Re: S32K3 ADC Use of external channels Hi NPX Team,  Related with this topic, may you please confirm if  is it possible to implement a SCH like the following diagram? Many thanks for your support. Re: S32K3 ADC Use of external channels @VaneB  Thank you very much for your help. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  Each ADC provides 3 external decode signals (MA) to be used to select 1 channel out of 8 in the external analog multiplexers, and there can be maximum 4 of such multiplexers to connect 32 external channels, it means that these 4 multiplexers sharing the same MA signals. The ADC automatically sets the MA to control these external analog multiplexers, based on the current channel selected for conversion. Depending on the Mask Register bits, the corresponding “X” pin is sampled, and the result is stored in the matching location for the “MA” & “X” combination. Since no external analog multiplexers have been designed on our development board, such an example has not been implemented. Re: S32K3 ADC Use of external channels hello.VaneB According to your prompt, I can't find an example of using external channel ADC in RTD. If you have a corresponding routine, I hope you can send it to me. Thank you very much. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  You can find examples of ADC implementation that may be useful to you in the RTD. B.R. VaneB