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

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 learned 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? FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Lights Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Logic Control (Main model overview) Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control What is next? S32 Design Studio - export Note: This index is updated as new articles are published.

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. 

Vision ML with the FRDM-MCXN947 The MCX N microcontroller family includes an eIQ Neutron N1-16 NPU for accelerating neural network models. The FRDM-MCXN947 development board can be combined with a camera and LCD screen to showcase running TinyML vision models on a microcontroller.   MCX N Camera Hardware Setup: The following hardware is used: MCX N FRDM Development Board - FRDM-MCXN947 OV7670 camera (with optional wide-angle lens) NXP LCD-PAR-S035  There are three small modifications needed for the FRDM-MCXN947 board for camera support. Without this modification the camera colors will be incorrect and tinted red.   Change SJ16, SJ26, and SJ27 found on the back of the Rev B board to connect pin 3 (the dashed side) so that it looks like the following:          Then connect the camera and LCD to the FRDM-MCXN947: Plug in the OV7670 camera into J11. It should line up with the orange box.                            Connect the LCD-PAR-S035 LCD into J12. It should be flush with the bottom so that the top 2 rows of pins are left hanging off the edge. Also note that on some LCD-PAR-S035 boards those top two rows of pins are not installed.          It should look like the following when complete           Also as the camera and Ethernet pins are shared, if you need to use the Ethernet+Camera at the same time please see this NXP Community post. MCX N Vision ML Examples: The NXP Application Code Hub contains several vision AI/ML examples: Face Detect Face Detect with Zephyr Multiple Person Detection  CIFAR10 Fashion MNIST There are also Multimedia Processing Pipeline (MPP) examples inside the MCX N MCUXpresso SDK that demonstrate more examples of using vision AI/ML on MCX N. These examples are only available for VSCode/GCC in the Repository-Layout SDK package. Note: It is recommended to use MCUXpresso SDK 25.09 for these examples. The MPP issues in the 25.12 and 26.03 MCUXpresso SDK releases should be fixed in the upcoming MCUXpresso SDK 26.06.  MCX N ML Vision Lab: The attached eIQ Neutron NPU for MCX N Lab Guide - Face Detect.pdf lab document walks through the steps to download an example Face Detect ML project from the NXP Application Code Hub and use the eIQ Neutron Converter tool to convert a model. It also describes how to update the eIQ and Neutron software libraries in an older MCUXpresso SDK project to work with the latest eIQ Neutron SDK libraries. It is recommended to go through the general MCX N NPU Lab Guide first and then do the attached Face Detect lab second.  The lab is also included below: 1  Lab Overview This document will demonstrate the acceleration provided by the eIQ Neutron NPU using the Multiple Face Detection demo for the FRDM-MCXN947 found on the NXP App Code Hub. The demo will run with the non-NPU optimized model and then the performance can be compared to the NPU optimized version of that same model. It also demonstrates how the NPU optimized version of the face detect model was generated. This lab is written for MCUXPresso IDE but the same basic steps can be used for VSCode or GCC. This lab will also cover how to update the Neutron NPU libraries in the project, as the original Face Detect example uses an older Neutron library version. It is highly recommended to complete the eIQ Neutron NPU for MCX N Lab Guide before starting this lab. 2  Software and Hardware Installation This section will cover the hardware and software needed for this lab. 2.1 Hardware The following hardware is required for this lab: MCX N FRDM Development Board - FRDM-MCXN947 OV7670 camera (with optional wide-angle lens) NXP LCD-PAR-S035 2.2 NXP Software Installation          Install MCUXpresso IDE v25.6 or later. Download the latest eIQ Neutron SDK Download and unzip the latest MCUXpresso SDK for FRDM-MCXN947 using MCUXpresso SDK builder Search for the FRDM-MCXN947 board Then click on Others On the SDK builder page, make sure to select the “eIQ” middleware and that the MCUXpresso IDE toolchain is selected. Then click on Build SDK.   Then click on the Download button and accept the license agreement to download the zip file. 3   Face Detection Example 3.1 Download Face Detect Demo from App Code Hub The code for this lab can be found on the NXP Application Code Hub hosted on Github, and we can use MCUXpresso IDE to directly import the Face Detection example from App Code Hub. Drag-and-drop the FRDM-MCXN947 SDK zip file into the Installed SDKs window, located on a tab at the bottom of the screen named “Installed SDKs”. You will get the following pop-up, so hit OK. Once imported, the Installed SDK tab will look something like this:  In the Quickstart Panel found in the lower left corner, click on Import from Application Code Hub.. In the dialog box that pops up there are many filters available to filter for different devices and types of demos. But since the name of the demo we are interested in is already known, the search box will be faster. Select the AI/ML category and then type in “face detection” and then click on the “Multiple face detection on mcxn947” demo. Make sure you don’t accidently click on the “Multiple Person Detection” demo. On the popup that comes up, click on GitHub link at the top. At that point the Next button at the bottom will become clickable so click on that. The next screen displays the possible branches. In this case there is only main so just click on the Next button at the bottom to go with the default. The next dialog box determines the location on your computer where the code will be downloaded to. You can leave it at the default location if desired or click on Browse to pick your own location. Then click on Next. The next screen will download the code and ask about importing the project. Click on Next to go with the default Import existing Eclipse projects option. Then finally on the last screen click on Finish to import the project into your MCUXPresso IDE workspace. You may get the following warning due to the project being made on an older version of the SDK. Then hit OK to accept the using the newest version.  15. It should look like the following when done: 3.2 Convert Model The demo is already using a model that was converted to take advantage of the eIQ Neutron NPU. This purpose of this section of the lab is to teach new NXP users how that model was converted. Unzip the eIQ Neutron SDK package in a directory of your choosing.   Optionally add \eIQ_NeutronSDK_ \bin to your executable path so that the neutron-converter utility can be directly called from the command line. Back in MCUXpresso IDE, find the location of the original non-converted model used for this demo by right clicking on the face_detect.tflite file in source/model/ and going to Utilities->Open directory browser here. Copy the directory location as it will be used in the next step Open a Windows Command prompt and navigate to the directory where the model was at from the previous step             Use the Neutron Converter to convert the Face Detection model: neutron-converter --input face_detect.tflite --output face_npu.tflite --target mcxn94x 3.3 Update eIQ Neutron Libraries The Face Detect ACH example uses an older version of the eIQ Neutron libraries, and so it needs to be updated to match the Neutron libraries in newest eIQ Neutron SDK since the model was converted with that version of the Neutron Converter tool. In the frdmmcxn947_multi_face_detection project, right click on the eiq folder and go to Utilities->Open directory browser here Overwrite the Neutron files from the eIQ Neutron SDK folder into your project to update the Neutron libraries to the latest version: File Name Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\mcxn94x\board\ eiq\neutron\mcxn\cm33 libNeutronFirmware.a target\mcxn94x\board\ eiq\neutron\mcxn\cm33 NeutronDriver.h target\mcxn94x\driver\include\ eiq\neutron\driver\include NeutronErrors.h target\mcxn94x\common\include\ eiq\neutron\common\include After the new Neutron libraries are copied over, clean the project to ensure the new libraries will be used 3.4 Board modifcations There are some hardware modifications to the MCX FRDM board required for this demo since the camera pins are muxed with the Ethernet pins and the Ethernet functionality is the default. The board version can be determined by scanning the QR code on the back of the MCX FRDM board with your phone. Most people will have Rev B boards. Rev A: Remove the R157, R158, and R159 resistors from the back of the Rev A board so that it looks like the following: Rev B: Change SJ16, SJ26, and SJ27 found on the back of the Rev B board to connect pin 3 (the dashed side) so that it looks like the following: 3.5 Connect the camera and LCD Plug in the OV7670 camera into J11. It should line up with the orange box. Connect the LCD-PAR-S035 LCD into J12. Note that some older LCD-PAR-S035 LCDs may have an extra set of pins soldered on, and in that case the extra 2 rows of pins should be hanging off the edge like in the photo below.             It should look like the following when complete 3.6 Run Models Now open up model_data.s by double clicking on it, and then modify line 43 to point to the original (non NPU converted) model file named face_detect.tflite. This particular project uses the .tflite file directly. Build the project by clicking on the Build icon in the Quickstart Panel Then download and run the project by clicking on the Debug icon in the Quickstart Panel You should see the demo working with an inference time of 817ms printed on the LCD display. Note: The default camera on the OV7670 is not very wide angle so you have to hold it fairly far back. There are wide-angle lenses that can be purchased to make it easier to demonstrate. Note: After POR there may be some glitching on the camera due to the fact the camera is expecting 2.8V but the board is at 3.3V and the initial HSYNC signal was missed. Press the reset button (SW1) and it should fix any camera issue.  Now let’s use the Neutron optimized model by opening model_data.s again and this time selecting the NPU converted model face_npu.tflite Recompile and reprogram the board. You’ll see it is significantly faster with a 22ms inference time, a 37x improvement! 4  Conclusion This lab demonstrated how the eIQ Neutron NPU on MCX N devices can significantly decrease inference time on quantized models and the steps to generate a NPU optimized model using the command line tools. Also explore the other App Code Hub ML examples available online. FRDM-Training MCXN NPU|ML

How to Update eIQ Projects with the Latest eIQ Neutron SDK Libraries eIQ Neutron SDK is a new software package that includes the Neutron Converter tool and eIQ Neutron libraries to run Neutron converted neural network models on devices that have an eIQ Neutron NPU like MCX N, i.MX RT700, or i.MX95 Previously the Neutron Converter tool was part of eIQ Toolkit. However going forward, new versions of the Neutron Converter tool will be released as part of the eIQ Neutron SDK. This change will allow for more frequent updates to provide better performance and additional operator support. MCUXpresso SDK and Linux BSP use Neutron libraries as part of the eIQ examples included in those software releases. However to use the latest Neutron Converter, an eIQ project will need to be updated to use the latest Neutron software libraries. This post walks through where to place the updated Neutron libraries and header files.  If the version of the Neutron Converter tool that was used to convert a model does not match the Neutron libraries used by the eIQ project, then during inference you will see the following error(s) printed on the serial terminal and may get incorrect results: Microcode version mismatch Or Internal Neutron NPU driver error 281b in model prepare Or Incompatible Neutron NPU microcode and driver versions The version of the Neutron Converter tool that was used to convert a model can be found by either viewing the converted model in Netron or by looking at the generated header file:   Here is a table showing where you can find the matching version of the Neutron Converter tool for the default Neutron libraries found in different versions of MCUXpresso SDK: MCUXpresso SDK Default Neutron Library Version in MCUXpresso SDK Default Compatible Neutron Converter Can Be Found In 24.12 1.2.0+0x6f710a6d eIQ Toolkit 1.17 25.03 1.2.0+0X1b86b19d eIQ Toolkit 1.17 25.06 2.0.2 eIQ Toolkit 1.17 25.09 2.1.3 eIQ Toolkit 1.17 25.12 2.2.2 eIQ Neutron SDK 2.2.2 26.03 3.0.0 eIQ Neutron SDK 3.0.0 26.06 3.1.1 eIQ Neutron SDK 3.1.1 Manually Update SDK Libraries To Use Latest Version eIQ Neutron SDK 3.1.3 It is highly recommend to always use the latest Neutron Converter tool and to update the libraries in your eIQ project to match the latest Neutron Converter tool. The libraries can be updated by overwriting the original files. You may wish to make a backup first though as the default eIQ examples in that SDK will use models that were converted to match those original Neutron libraries. The Neutron file structure in eIQ Neutron SDK and MCUXpresso SDK are now the same so that the entire Neutron folder can be overwritten directly.  Updating Neutron Libraries in MCUXpresso SDK 25.12 and later: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\neutron\common\include\ Note: The target\imxrt700\driver\include\NeutronEnvConfig.h and the libraries in target\imxrt700\cmodel are used by the ExecuTorch inference engine and so are not needed for TFLM eIQ projects.  Note: In MCUXpresso SDK 26.03 there are two sets of Neutron libraries in imported projects. It's the files in the /middleware/eiq folder that need to be updated.  Updating Neutron Libraries in MCUXpresso SDK 25.09 or before: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\common\include\ Updating Neutron Libraries for MCUXpresso SDK 2.16 or before: Replace the entire middleware\eiq directory from MCUXpresso SDK 26.03 into your project, and then the Neutron libraries can be updated per the instructions above. In these older MCUXpresso SDK releases there were additional eIQ changes beyond just the four files above, so the easiest method to update those older projects is just to replace the entire eIQ middleware directory.  Updating Neutron Libraries for i.MX devices: To update the neutron runtime on a target device, upload the files to their designated directories, as follows: File Target Directory NeutronFirmware.elf /lib/firmware libNeutronDriver.so /lib/ libneutron_delegate.so /lib/

Vision AI/ML with i.MX RT700 The i.MX RT700 microcontroller family includes an eIQ Neutron N3-64 NPU for accelerating neural network models. The i.MX RT700 EVK can be combined with a camera and LCD screen to showcase running TinyML vision models on a microcontroller.  i.MX RT700 Camera Hardware Setup: The following hardware is used: i.MX RT700 EVK RK055HDMIPI4MA0 LCD panel Camera Options: USB Camera with USB A to micro-B converter OV7670 parallel camera (with optional wide-angle lens) The USB camera should be attached to the i.MX RT700 EVK on USB OTG port J40. The parallel camera interface is available on J53 and uses FlexIO with eDMA to read in the camera data. AN14836 describes the details. Note that the links in that app note for the demo software do not work but the demo code is in the process of being posted on NXP’s Application Code Hub.  When inserting the parallel camera align it to the left most side, as shown in the image below: Directions for attaching the LCD panel to the J52 connector on the underside of the i.MX RT700 EVK can be found on this Community post.  Note that there are multiple names used for the LCD panel and all these part numbers refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG i.MX RT700 Vision ML Examples: There are two vision AI/ML examples for i.MX RT700 available today: Object Detection (part of AN14718) Hand Gesture Recognition Both of these examples use a USB camera.  i.MX RT700 Vision MPP Examples:  The Media Processing Pipeline (MPP) interference examples in i.MX RT700 MCUXpresso SDK 26.06 and later support both parallel and USB camera interfaces. These SDK examples are only available for command line GCC and VS Code MCUXpresso SDK layouts. They are not available for MCUXpresso IDE, IAR, or Keil.  A parallel camera is used by default in the RT700 MPP projects. A USB camera can be enabled by adding a USE_USB_CAMERA declaration in the project's CMakeLists.txt file by adding the following macro: mcux_add_macro(     CC "-DUSE_USB_CAMERA"     CX "-DUSE_USB_CAMERA" ) However it's important to note that the camera_usb_final_fr_app_view project is setup to use USB camera by default, but it only works with a very specific HM2131 camera. All other MPP demos can work with most generic USB cameras. 

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 Vehicle Comfort Control Using FRDM-A-S32K344 Microcontrollers Overview This article demonstrates the implementation of a vehicle comfort control system using the FRDM-A-S32K344 development platform. The application showcases how embedded peripherals can be used to control multiple vehicle comfort functions, including cabin cooling and electric window operation. The demo operates a DC motor and a stepper motor based on user inputs while providing real-time control through PWM generation and GPIO outputs. The project highlights the interaction between user inputs, control logic, PWM motor control, and stepper motor sequencing commonly found in automotive body electronics and comfort modules. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Vehicle Comfort Control on FRDM-A-S32K344  Learning Objectives This project demonstrates: GPIO-based input handling PWM motor control Direction control techniques Stepper motor sequencing Real-time actuator control Automotive comfort system concepts Multi-actuator control using S32K3 peripherals The example provides a practical introduction to automotive body-control applications involving cooling and window-control systems. System Architecture The application follows a command-and-control architecture:   Plain Text     User Inputs ↓ GPIO Interface ↓ Vehicle Comfort Control Logic ↓ PWM + GPIO Outputs ↓ DC Motor + Stepper Motor Architecture Diagram (Insert Vehicle Comfort Control Architecture Diagram) Figure Caption Figure 1. Vehicle comfort control system architecture. User button inputs are processed by the S32K344 microcontroller. The application determines the desired comfort function and generates either PWM-controlled outputs for the cooling fan or GPIO sequencing signals for the stepper motor representing window movement.  Control Principle The demo operates two independent comfort functions: Cooling System Control A DC motor represents a vehicle cooling fan. The MCU generates PWM signals that regulate: Fan activation Fan speed Cooling-system behavior PWM control allows smooth speed adjustments while minimizing power losses. Window Control System A stepper motor represents an electric window mechanism. The MCU controls the motor through a full-step coil sequencing algorithm. This allows: Upward movement Downward movement Direction control Precise positioning The behavior emulates typical automotive power-window systems. User Input Processing The system uses push-button inputs connected to the FRDM-A-S32K344 board. The button states are continuously monitored through GPIO inputs. Based on the detected command, the application executes the corresponding comfort function. Possible actions include: Increasing fan activity Decreasing fan activity Moving the window upward Moving the window downward The control logic translates user commands into actuator actions in real time. DC Motor Control The DC Motor 2 Click board is used to drive a 5V fan motor. PWM output generated by the S32K344 controls: Motor activation Speed variation As the PWM duty cycle changes, the fan speed changes accordingly. This illustrates a common cooling-system implementation used throughout the automotive industry. Stepper Motor Control The H-Bridge Click board controls a NEMA17 stepper motor using a full-step drive sequence. The MCU energizes the motor coils in a predefined pattern:   Plain Text     A → B → C → D   This enables: Controlled rotation Direction changes Window position simulation The process demonstrates how automotive ECUs control electromechanical comfort systems. Control Behavior The control logic can be represented as a command-response system. Example behavior: User Action System Response Fan Command PWM duty cycle adjusted Window Up Stepper advances forward Window Down Stepper advances reverse No Command Actuators remain idle Control Behavior Diagram (Insert Comfort Control Behavior Diagram) Figure Caption Figure 2. Vehicle comfort control behavior. User commands are translated into specific actuator actions. PWM signals regulate fan speed, while GPIO-driven step sequences determine stepper motor direction and movement. Hardware Setup Required Hardware FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 FRDM K64 Click Shield FRDM K64 click shieldFRDM K64 click shield DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge Click H-Bridge ClickH-Bridge Click 5V Fan Motor 5V Fan Motor5V Fan Motor Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Full setup: Comfort Full SetupComfort Full Setup This configuration enables simultaneous control of both rotational-speed and positional actuators. Software Environment The example was developed using: S32 Design Studio S32K3 Real-Time Drivers (RTD) Application Code Hub framework The software demonstrates practical usage of GPIO and PWM drivers for actuator control. Implementation Guide Step 1: Import the Project Open S32 Design Studio Import project from Application Code Hub Search for Vehicle Comfort Control example Expected result: Project appears in workspace Step 2: Build the Application Compile the project Check for errors Expected result: Successful build Step 3: Connect Hardware Install: FRDM K64 Click Shield DC Motor 2 Click H-Bridge Click Fan motor NEMA17 stepper motor Verify all wiring before powering the system. Step 4: Flash and Run Program the MCU Start execution Expected result: Application runs continuously Step 5: Functional Validation After startup: Press the control buttons Observe fan operation Observe stepper motor movement Expected result: The system immediately responds to user commands. Comfort System Examples The demonstrated functions correspond to common automotive applications. Cooling Regulation The DC motor represents: Cabin ventilation systems HVAC airflow control Cooling fan operation Electric Window Control The stepper motor represents: Window up/down movement Position control Direction control These systems are examples of comfort-oriented body electronics within modern vehicles. Possible Extensions The application can be enhanced with: Feedback-Based Control Add sensors to provide closed-loop position or speed control. Automatic Comfort Modes Implement predefined comfort profiles. CAN Communication Enable communication with other vehicle ECUs. Diagnostic Functions Add fault detection and actuator monitoring. Position Memory Store and restore window or comfort positions. Conclusion This vehicle comfort control demonstration shows how the S32K344 platform can integrate user inputs, GPIO processing, PWM generation, and electromechanical actuator control into a complete embedded automotive application. By controlling both a DC motor and a stepper motor, the project illustrates the implementation of cooling-system regulation and electric-window operation, providing a practical example of automotive comfort-module design on the S32K3 platform. Comfort ResultComfort Result 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.

IMX8MPセカンダリイメージブート IMG_CNTN_SET1_OFFSETセカンダリイメージブート（RM 6.1.6.2）は、i.MX8MP上のECSPI（"SPI") NORブートで動作しますか、それともFlexSPI NOR（およびSD/eMMC）のみで動作しますか？表6-28では、「SPI」と「FlexSPI NOR」が別々のブートデバイスとして記載されており、セカンダリオフセットの有効値は「FlexSPI NORブートの場合」にのみ記載されています。 Re: IMX8MP secondary image boot こんにちは、 あなたの理解は間違っています。IMG_CNTN_SET1_OFFSETセカンダリイメージブートはSPIデバイスでも動作しますが、オフセットが異なります。 FlexSPI の有効な値は、0、1、2、3、4、5、6、および 7 です。 SPI の場合、ヒューズ値が 10 より大きい場合、セカンダリ ブートは無効になります。n = ヒューズ値が より大きい場合 10. • n == 0: オフセット = 4MB • n == 2: オフセット = 1MB • その他 & n <= 10 : オフセット = 1MB*2^n

IMX8MP secondary image boot Does IMG_CNTN_SET1_OFFSET secondary image boot (RM 6.1.6.2) work for ECSPI ("SPI") NOR boot on i.MX8MP, or only for FlexSPI NOR (and SD/eMMC)? Table 6-28 lists "SPI" and "FlexSPI NOR" as separate boot devices, and the secondary-offset valid values are stated only "for FlexSPI NOR boot." Re: IMX8MP secondary image boot Hello, Your understanding is wrong, the IMG_CNTN_SET1_OFFSET secondary image boot also work for SPI devices, only with a different offset: For FlexSPI = the valid values are: 0, 1, 2, 3, 4, 5, 6, and 7 For SPI = Secondary boot is disabled if fuse value is bigger than 10, n = fuse value bigger than 10. • n == 0: Offset = 4MB • n == 2: Offset = 1MB • Others & n <= 10 : Offset = 1MB*2^n

The plugin configuration dialog failed The prompt appears after I finish configuring the CAN Communication: “The plugin configuration dialog failed. Try to specify the connect string manually.” Re: The plugin configuration dialog failed Hello, until this issue is solved, please see a workaround discussed here. Regards, Michal Re: The plugin configuration dialog failed Hello the version 3.2.7 has been released. This version fixes the CAN plug-in dependency issue discussed in this thread. Regards, Michal

How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hello to everyone on the NXP support team. I am currently working on a project using the S32K314, RTD 7.0.0, and FreeRTOS. I am trying to implement the measurement of the voltage of an external device connected to the MCU, the internal temperature (TEMPSENSE) of the MCU, the internal voltage (ANAMUX) of the MCU, and the bandgap voltage using the MCAL's ADC module. Looking at the measurement results, the voltage of the external device and the bandgap voltage seem to be measured correctly, but the values of the internal temperature and internal voltage of the MCU are different from what I expected. Expected value: MCU internal voltage (VDD_HV_A): 8192 (2.5V, 14-bit resolution) Actual measured value: Approximately 6800–7100 (2.07–2.13V, 14-bit resolution) The MCU power supply voltage is 5.0V. The ADC hardware unit is set to ADC0, and the ADC measurement target is configured as follows: Ch8: MCU internal temperature (TEMPSENSE) Ch9: MCU Internal Voltage (ANAMUX) Chapter 10: Band Gap MCU input voltage = 5.0V ADC initialization code: void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADC data acquisition (all periodic tasks) void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } } I believe the ADC values for the ADC0 group can be updated using `Adc_ReadGroup`, but I think you need to use `Adc_TempSenseGetTemp` and `Adc_TempSenseCalculateTemp` to check the MCU's internal temperature. Please let me know if I've overlooked any settings. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for your quick response. I have already reviewed the sample code you provided and believe I have incorporated it into my code. I interpreted the table you provided as a table of register settings for each clock supplied to the ADC block. However, I was unable to determine which of the ADC settings in MCAL they correspond to. Since I am unable to provide the source code, I am attaching an image of the ADC settings. Please let me know which settings I should change. If there are any other settings screens you need, please let me know. AdcHwUnit> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko I didn't see the complete ADC configuration in the information you provided, so please double-check that the ADC clock matches the datasheet requirements. If possible, you can share your test project with me, and I'll check it for you. by the way, take a look at the demo in the link below: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for your advice. Following your advice, I changed the settings as shown below to set the TEMPSENSE sampling time to 1.2 usec.　 160MHz = 0.00625usec 1.2usec/0.00625usec = 192 I created a task with a 1-second cycle in FreeRTOS and acquired the ADC values for the MCU voltage (VDD_HV_A) and MCU temperature (TEMPSENSE) every second (collecting 30 seconds’ worth of data). For the MCU voltage, I used the bandgap voltage and converted it to mV using the following compensation formula. (The bandgap voltage showed almost no fluctuation, with a value of around 3975 (approximately 1.2 V) obtained.) AdcCorrection = (1200(mV) * Adc_VCC_HV_A) / Adc_bandgap Mcu Voltage = AdcCorrection * 2  (2 is the voltage division ratio of VDD_HV_A) Additionally, the McuTemp data comes from `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)`. Even taking into account the ADC conversion error of +/- 5.0%, I believe the variation is too large. Are there any suggested solutions?   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko From the configuration screenshots and code you provided, I don't see any obvious errors. However, it's important to note that the temperature sensor's sampling time must be greater than 1.2µs; otherwise, it will affect the sampling accuracy. Therefore, I suggest you double check the sampling time before testing. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 The image for ADC_Config>AdcHwUnit was compressed, resulting in a loss of resolution, so I am re-uploading it. <#1> <#2> <#3> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for attaching the documentation. Since I am currently measuring channels 32–63, I understand that this corresponds to Sampling Duration 1. Thank you for your prompt response. The issue has been resolved.　 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko You can directly read the raw data from the temperature channel to observe whether there are fluctuations. If the fluctuations are large, you can continue to try increasing the sampling time. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, I interpreted the information in Table 317 as follows. When fmc = 160 MHz: ・ Set the prescaler for calibration to 4 ・ Set the prescaler for normal ADC conversion to 2 ・ Set “ADC High Speed” to Disable The data obtained by applying these settings is shown in the table below. Although averaging reduced the variation, I feel that the variation in the MCU’s internal temperature is still quite significant. The table below shows the MCU temperature data converted from ADC values to °C. (To convert the ADC values to °C, I divided the ADC values by 16.) A variation of 2.55 degrees over a 16-point average is extremely large. I understand that the MCU temperature fluctuates depending on the processing load, but is it normal for it to change this much instantaneously? When measuring the internal temperature of the MCU, is averaging the correct approach?　 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for you reply. As shown in the figure below, the values stabilized after I increased the Sampling Duration 1/Duration 2 values. I thought the default setting was Sampling Duration 0, but how can I switch between Sampling Duration 0, 1, and 2? (Based on the prescale setting, since the ADC clock is 80 MHz, the duration equivalent to 1.2 μs is 96.)

How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 NXPサポートチームの皆様、こんにちは。  現在、S32K314、RTD 7.0.0、およびFreeRTOSを使用したプロジェクトに取り組んでいます。MCALのADCモジュールを使用して、MCUに接続された外部デバイスの電圧、MCUの内部温度（TEMPSENSE）、MCUの内部電圧（ANAMUX）、およびバンドギャップ電圧の測定を実装しようとしています。測定結果を見ると、外部デバイスの電圧とバンドギャップ電圧は正しく測定されているようですが、MCUの内部温度と内部電圧の値は予想と異なっています。 期待値： MCU内部電圧（VDD_HV_A）： 8192（2.5V、14ビット分解能） 実測値： 約6800～7100（2.07～2.13V、14ビット分解能） MCUの電源電圧は5.0Vです。ADCハードウェアユニットはADC0に設定され、ADC測定対象は以下のように構成されます。  Ch8：MCU内部温度（TEMPSENSE）  Ch9：MCU内部電圧（ANAMUX）  第10章：バンドギャップ  MCU入力電圧 = 5.0V ADC初期化コード： void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADCデータ取得（すべての周期的なタスク） void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } }  ADC0グループのADC値は`Adc_ReadGroup`を使用して更新できると思いますが、MCUの内部温度については`Adc_TempSenseGetTemp`と`Adc_TempSenseCalculateTemp`を使用する必要があると思います。もし私が見落としている設定があれば教えてください。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 迅速なご対応ありがとうございます。 ご提供いただいたサンプルコードは既に確認済みで、私のコードに組み込んだと考えています。 ご提供いただいた表は、ADCブロックに供給される各クロックに対するレジスタ設定の表であると解釈しました。しかし、それらがMCALのどのADC設定に対応しているのかを特定することはできませんでした。 ソースコードを提供できないため、ADC設定の画像を添付します。どの設定を変更すればよいか教えてください。 他に何か必要な設定画面があれば、お知らせください。 AdcHwUnit> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 提供された情報にはADCの完全な構成が見当たらなかったので、ADCクロックがデータシートの要件に合っているか再確認してください。 可能であれば、テストプロジェクトを共有していただければ、私が確認します。 ちなみに、下記のリンクからデモをご覧ください。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 アドバイスありがとうございます。 ご助言に従い、TEMPSENSEのサンプリング時間を1.2マイクロ秒に設定するように、以下のように設定を変更しました。 160MHz = 0.00625マイクロ秒 1.2マイクロ秒/0.00625マイクロ秒= 192 FreeRTOSで1秒サイクルのタスクを作成し、MCU電圧(VDD_HV_A)とMCU温度(TEMPSENSE)のADC値を毎秒取得しました(30秒分のデータ収集)。 MCU電圧についてはバンドギャップ電圧を使い、以下の補償式でmVに変換しました。 （バンドギャップ電圧はほとんど変動せず、約3975（約1.2V）の値が得られた。） Adc補正 = (1200(mV) * Adc_VCC_HV_A) / Adc_バンドギャップ Mcu電圧 = アドコレーション × 2(2は電圧分割比VDD_HV_A) さらに、 McuTempデータは `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)` から取得されます。 ADC変換誤差が±5.0%であることを考慮しても、このばらつきは大きすぎると思います。何か解決策の提案はありますか？   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 ご提供いただいた設定画面のスクリーンショットとコードを見る限り、明らかなエラーは見当たりません。ただし、温度センサのサンプリング時間は1.2μsを超えなければならないことに注意が必要です。そうでなければ、サンプリングの精度に影響します。したがって、テストを行う前にサンプリング時間を再度確認することをお勧めします。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 ADC_Config>AdcHwUnitの画像が圧縮されて解像度が低下したため、再アップロードします。 <#1> <#2> <#3> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 温度チャネルから生データを直接読み取って、変動があるかどうかを観察できます。変動が大きい場合は、サンプリング時間を延ばし続けるCAN。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ご返信ありがとうございます。 下図に示すように、サンプリング期間1/期間2の値を増加させた後、値は安定しました。デフォルト設定はサンプリング持続時間0だと思っていましたが、サンプリング持続時間0、1、2の切り替えはどうすればいいのでしょうか? （プリスケール設定に基づくと、ADCクロックは80MHzなので、1.2μsに相当する期間は96となる。） Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ドキュメントを添付してくださりありがとうございます。現在チャネル32から63を測定しているので、これはサンプリング持続時間1に対応していると理解しています。 迅速なご対応ありがとうございます。問題は解決しました。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 私は表317の情報を以下のように解釈しました。 fmc = 160 MHz の場合: ・キャリブレーション用のプリスケーラを4に設定する ・通常のADC変換のプリスケーラを2に設定する ・「ADC高速」を無効に設定する これらの設定を適用して得られたデータは、以下の表に示されています。 平均化することでばらつきは減りましたが、MCU内部温度の変動は依然としてかなり大きいと感じます。 以下の表は、ADC値から°Cに変換したMCU温度データを示しています。 （ADC値を摂氏に変換するために、ADC値を16で割りました。） 16点平均で2.55度の変動は極めて大きい。MCUの温度はプロセッシング負荷によって変動することは理解していますが、これほど瞬時に大きく変わるのは普通のことですか? MCUの内部温度を測定する際に、平均を取るのが正しいアプローチでしょうか?

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.

S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hi We are working on Secure Debug authentication for the S32N55 platform and have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. We are now trying to extend this to the CRS domain (HSE_DEBUG_DOMAIN_APP = 0x1B) and have the following questions: --- [Q1] Is ADKP usable for CRS domain Secure Debug authentication? After provisioning ADKP via HSE_OTP_FOEM_ADKP_ATTR_ID, is it possible to use the same ADKP for CRS domain (APP) Secure Debug authentication via HSE_DEBUG_CMD_APP_CHALLENGE? --- [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? Per the RM description of hseOwnerDebugKeyMapConfig_t: "This service is called for each installed device owner individually from an owning MU. HSE FW assumes the owner identity based on the MU this service request is sent to." Our current implementation calls SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) only through FSS MU (MU0), mapping aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP. - Is a separate SetOwnerDebugKeyMap() call required through the CRS MU for CRS domain authentication? - If so, which MU number should be used for the CRS domain on S32N55? --- [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? The RM states: "Only the numOfAuthorizationRefEntries and numOfAuthenticationRefEntries are logged, rest of the entries are ignored." This implies the key mapping is volatile and not stored in NVM. Does this mean SetOwnerDebugKeyMap() must be called on every boot (after SU rights are granted) for both FSS and CRS domains? --- [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? --- [Q5] Response size and packet structure for APP_CHALLENGE Per hseDebugAuthorizeProofProvCmd_t byte map, the packet structure is always 32 bytes (2 packets x 8 words). HSE_CR_APP_RESPONSE_SIZE = 16U vs HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U. For APP_CHALLENGE, should the host send: - 16 bytes of AES-encrypted response + 16 bytes of zero padding = 32 bytes total? - Or only 16 bytes? Currently, after sending FLAG_START + DebugSignalMap(4 bytes) + Response(16 bytes) + FLAG_END, HSE2 does not respond and T32 hangs waiting indefinitely. When we send 32 bytes (16-byte response + 16-byte zero padding), we observe the same hang. --- For reference: - Sherpa_Cdd_AllocateChannel() always allocates MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302), called with SU rights - crs_auth.cmm: DEBUG_TARGET=0x1B, OID=0xFF*16, keyRef=0x00 - AUTH_MODE_REQ passes successfully (HSE_DEBUG_WAITING_RESPONSE_TO_CHG received) - Challenge received: 32 bytes - After sending Response, no ACK (0x4A4A4A4A) received from HSE2 Please see the attached CMM script and log for reference. Thank you in advance. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your suggestion. As requested, I have created a new post to track the CRS (APP domain) Secure Debug authentication issue: [S32N55 HSE2 — CRS (APP Domain) Secure Debug Authentication via hseDebugCardCmd_t] (Please search the title above in NXP Community) This issue is currently blocking our customer delivery schedule. Could you please review the new post at your earliest convenience? The CMM script (crs_auth.cmm) and log file are attached in the new post. Thank you very much for your urgent support. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your response.  We have additional questions regarding hseDebugCardCmd_t implementation for CRS (APP) domain Secure Debug authentication on S32N55. --- [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? Our device is configured in single-owner scenario where Fss_Firmware_au8Oid[] = {0xFF * 16}. Should the ownerId field in hseDebugCardCmd_t also be set to 0xFF * 16? Or does it need to match a specific value provisioned during Device Owner installation? --- [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? Per RM: "For APP based options, debug signals are enabled and authorized only through the debug cards authentication (see hseDebugCardCmd_t)(field is ignored)." Our current flow: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG received 3. APP_CHALLENGE → rx_challenge (32 bytes received) 4. hseDebugCardCmd_t sent directly (skipping hseDebugAuthorizeProofProvCmd_t) 5. HSE2 stops responding (T32 hangs at FLAG_END of CARD_REQUEST) Should hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) be sent BEFORE hseDebugCardCmd_t? Or should hseDebugCardCmd_t be sent directly after rx_challenge without ProofProv? --- [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? We are using: authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes]) authLen = 16 Is this the correct computation? Or should the CMAC input include additional fields (OID, domain map, etc.)? --- [Q4] What is the correct packet structure for hseDebugCardCmd_t? Based on the RM byte map, our current implementation: Packet 1 (32 bytes): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC) Packet 2 (32 bytes): enabledDebugDomainMap(bit27=0x08000000) + padding(28B) Packet 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) Is this structure correct? HSE2 stops responding after receiving the OID field (0xFF bytes). --- Could you please let me know your email?  I will send you cmm file for crs auth. BRs. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your post. Pleased to hear that the Secure Debug authentication for the S32N55 platform have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. I will continue to help check with the details for your new issues, sorry that I did not see the attached CMM script and log for reference, would you mind uploading them again to share with us? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. There are already 6 questions existed in this post, and may take a relative long time to investigate, in order for improving the efficiency,  for additional questions, I suggest creating a new post to track. And as you mentioned, there would be scripts/logs attached for checking, but I do not see in your post, may I know if they would be uploaded again? BR Chenyin

RT1064 I2C 通信异常，频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常，但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看，这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS：将该设备的 I2C 驱动程序移植到另一台 1064 设备上，测试模块 A，在 400k 功耗下未发现问题。 原因可能是什么？ 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2：模块 A 在 100kHz 下的逻辑分析仪波形 图3：模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察，该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足，而不是模块 A 本身的异常。 即使上升时间在规格范围内，在 RT1064 上，我们仍然建议检查 LPI2C 主侧 400 kHz 配置，特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1，因为 RT1064 上的主同步延迟不仅受上升时间的影响，还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置，并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符： I2C模块时钟源 目标波特率：400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息：昨天在定位方面取得了一些进展： 我们的硬件扩容计划如下： 主板：RT1064--- ADUM1251 3.3V 至 5 V 子板：ADUM1251-模块A 5V转3.3V 经验证，在硬件链路的两层中添加 ADUM1251 后，模块 A 的通信出现异常。但移除 ADUM1251 后，通信在 400k 处恢复正常。造成这种情况的原因可能是什么？ PS：我们的硬件工程师认为 ADUM1251 只会增加通信延迟，不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好，@mayliu1 我们的产品即将发布，我们已经调查这个问题好几天了。如果您能尽快回复，我们将不胜感激！ Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形，上升时间符合要求，在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备，并测试了模块 A，没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑： 1.如果时钟在拉伸后恢复异常，还有哪些其他原因可能导致这种情况？ 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置？我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求，我们是否就不需要考虑这些寄存器设置了？ Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题，而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上，LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出，上升时间越大，同步延迟就越高。（参见第 47.3.1.4 章）时序参数） 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置，使其延迟保持在最小 SCL 低/高周期以下，RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此，如果模块 A 使总线边沿稍微变慢或改变有效负载，则总线可能在 400 kHz 时发生故障，但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率，但应根据 I2C 规范仔细验证自动生成的定时参数，特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险，建议使用经过验证的时钟源，例如 48 MHz，如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数？ PS：显然是由于自动接口分配造成的

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

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 配置工具中，有一个选项可以从总线关闭状态自动恢复。 如有任何疑问，请随时回复。 此致， 索林·班奇拉