Compilation Error on imx-95-FRDM unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/xen/gntdev.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/xen/evtchn.h: Cannot open: No such file or directory Re: Compilation Error on imx-95-FRDM Hi @Asadeds  What is your BSP version? I checked it on my Imx95 FRDM and there are no problems. pengyong_zhang_0-1786413970033.png B.R

ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi, i tried to run the adt7420 sample demo with frdm_mcxw board, but the print message is "sensor: device not ready.“ after i flashed the image into the target . the hardware setup like below picture for reference  anliu114036_0-1786010612902.png i think the hardware wiring is ok which i followed below description. anliu114036_1-1786010728607.png and you can find the overlay file which i added the board folder like below anliu114036_2-1786010818065.png i also attached the build log file which can help get more information from it.  can you check it and help solve the issue Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hello, hope you are doing well.   From the image you shared, it looks like you are working with a KW47-LOC board, could you please confirm this is the right device? Which Zephyr repo and version you are working with? As you may know, the KW47-LOC board is not directly supported on Zephyr, only the frdm-mcxw72 is. That said, since the chips are compatible, you can work with the frdm-mcxw72 examples and modify the overlay file to adapt it to the KW47-LOC board pins. Checking your overlay configuration, the KW47-LOC board only supports the LPI2C1 module, so you will have to enable the lpi2c1 node in your overlay instead. For the SCL and SDA pins, these are defined in frdm_mcxw72-pinctrl.dtsi as PTB4 and PTB5 for I2C1, I would recommend keeping those since they match the KW47-LOC pins. In order for J2 pin 6 to connect to the target MCU pin PTB4, place J24 2-3 shorted.   Refer to UM12114 for the MikroBUS I2C pinout: Pin 2: INT (Hardware interrupt) on WUU0_P12/PTC7 Pin 5: SCL (I2C clock) on I2C1_SCL Pin 6: SDA (I2C data) on I2C1_SDA   Please also confirm that you have the following configurations enabled in your prj.conf file: CONFIG_I2C=y CONFIG_SENSOR=y CONFIG_ADT7420=y   Best regards, Ana Sofia. Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi Ana Thanks for your support.  Yes, I did work with a KW47-LOC board and try to run the frdm-mcxw72 examples on this board, the Zephyr repo version is v4.4.1. After change the overlay file from I2C0 into I2C1,  it looks the ADT7420 device initialize is ok, but this sensor is still can't read out the right temperature , you can see  below print message from the serial monitor.  anliu114036_0-1786427779708.png here is the latest overlay file and prj.conf file content. anliu114036_1-1786427965565.png anliu114036_3-1786428011874.png Best regards Liu Wei

iMX8 Nano Kernel updation from 5.15 to 6.18 Hi  While porting the kernel from 5.15 to 6.18 for the A53 core. facing an issue with rpmsg.  # dmesg -T | grep -Ei 'rpmsg|rproc' [Tue Oct 8 15:42:28 2024] imx rpmsg driver is registered. [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: error -ENOENT: Failed to enable clock [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: probe with driver imx-rproc failed with error -2 [Tue Oct 8 15:42:29 2024] remoteproc remoteproc0: releasing imx-rproc I am getting this error.When i searched this error online i was asked to add dummy clock in the dts as below  imx8mn-cm7 {     compatible = "fsl,imx8mn-cm7";     rsc-da = <0xb8000000>;     clocks = <&clk IMX8MN_CLK_DUMMY>;     mbox-names = "tx", "rx", "rxdb";     mboxes = <μ 0 1                                    μ 1 1                                    μ 3 1>;     memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;     status = "okay";   } Could u please let me is this the only the change required. What is the reason for this change. Regards Yadunath R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 No — I would not treat clocks = <&clk IMX8MN_CLK_DUMMY>; as the only required change. It may be enough to get past the immediate -ENOENT: Failed to enable clock probe failure, but for i.MX8M Nano the important requirement is that the Cortex-M7 root clock must remain enabled when Linux loads/starts the M7 firmware. Reason: The imx-rproc node is expected to have a clock entry; AN5317 shows the i.MX8M remoteproc DTS node with compatible = "fsl,imx8mn-cm7" and a clocks = <...> property, plus mailbox and memory-region entries. Your error means the kernel 6.18 imx-rproc driver tried to get/enable the clock from that node and the clock lookup failed with -ENOENT , so probe aborted before remoteproc0 stayed registered. NXP’s AMP guidance says: “For i.MX 8M platforms, the root clock for M7/M4 must be kept always enabled by Linux to load the firmware code and start Cortex M7/M4.” It also says NXP Linux BSP keeps this root clock enabled when the M core is started from U-Boot; otherwise, if the M core is first started from Linux boot, drivers/clk/imx/clk-composite-8m.c must be updated to skip gate registration for the M core clock. So the change has two possible meanings: Dummy clock as compatibility workaround If kernel 6.18 imx-rproc requires a clocks property but the real M7 clock is intentionally not controlled through common clock framework, adding IMX8MN_CLK_DUMMY can satisfy the driver’s clock handle requirement and avoid -ENOENT . Real clock-control fix If Linux is actually responsible for loading/starting the M7, a dummy clock alone may hide the probe error but not guarantee the M7 clock is enabled. In that case you must ensure the M7/M4 root clock is kept on, either by the NXP BSP clock-driver handling or by the clk-composite-8m.c change described in AN5317. Also verify the rest of the remoteproc/rpmsg DTS, not only the clock line: imx8mn-cm7 {         compatible = "fsl,imx8mn-cm7";         rsc-da = <...>;         clocks = <&clk IMX8MN_CLK_DUMMY>;   /* or the correct M7 clock used by your BSP */         mbox-names = "tx", "rx", "rxdb";         mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;         memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;         status = "okay"; }; The memory-region list is important because AN5317 states that this property must contain the memory sections used by the firmware ELF so remoteproc can reload it from sysfs. Recommended check path: If you start M7 from U-Boot , use the NXP flow such as prepare_mcore / bootaux , then boot Linux; AN5317 says this is the path where the BSP keeps the M core root clock enabled. If you start M7 from Linux remoteproc , confirm your 6.18 clock driver includes the NXP handling to keep the M core root clock always enabled; otherwise the dummy clock may only fix probe, not runtime start/load. Compare your DTS against the NXP imx8mn-*-rpmsg.dts for the same BSP release, especially clocks , mboxes , rsc-da , and reserved-memory layout. The dummy clock explains the immediate -ENOENT probe failure, but the real design requirement is to keep the i.MX8MN M7 root clock enabled; whether DTS alone is sufficient depends on whether your 6.18 BSP clock driver already preserves that clock.

ddr_stress_tester cannot work on some DDRs I have been using  ddr_stress_tester tools for many years, this year, I found the tool cannot work well on some newer manufacturing process DDRs, (20nm or 25nm DDRs),  we found that the binary will hang when I select cpu frequency. For example, winbond  w631gu6rb and ISSI IS43TR166640C-125JBLI-TR. by the way  CPU model is mx6solo/dl i.MX6DL Re: ddr_stress_tester cannot work on some DDRs The symptom is more likely tied to the DDR initialization/MMDC setup or board-level margin than to the DDR die process node itself. I could not find an NXP-documented issue that says the i.MX6Solo/DL ddr_stress_tester hangs specifically because the DDR3 is 20 nm/25 nm, nor anything specific to Winbond W631GU6RB or ISSI IS43TR166640C after checking NXP library/community paths by part number, process node, and “CPU frequency” hang wording. What I would check first: Use the i.MX6/7 DDR Tool flow, not an old fixed script The i.MX6/7 DDR tools are intended to generate and test a custom DRAM initialization based on the actual device configuration — density, chip-selects, bus width, board layout/swizzling, etc. — and they explicitly cover i.MX6DL/S devices. If you changed DDR vendors or DDR geometry/timing, regenerate the .inc initialization script using the DRAM Register Programming Aid / DDR tool flow; NXP notes that scripts “may need to be modified for your custom board and memory.” Do not assume old calibration values still apply The stress tool performs write leveling, DQS gating, read/write delay calibration, and stress testing on i.MX6 boards. If it hangs right after selecting frequency, the DDR may already be marginal before calibration can complete. NXP community guidance for similar i.MX6 DDR stress hangs points to incorrect MMDC parameters, power brownout, board noise, or layout issues. Check DDR voltage/mode and frequency selection i.MX6Solo/DualLite DDR pads support LPDDR2 and DDR3/DDR3L modes. For DDR3/DDR3L I/O supply, the i.MX6Solo/DL datasheet excerpt gives OVDD as 1.425–1.575 V for DDR3 and 1.283–1.45 V for DDR3L . The i.MX6 DDR stress tool supports DDR stress testing between 135 MHz and 672 MHz ; select a conservative DDR frequency first, then work upward after calibration passes. Review refresh timing There is an i.MX6 case where low-frequency hang was resolved by correcting MMDC0_MDREF , changing tREFI from 3.9 µs to 7.8 µs . NXP documentation also points to MMDCx_MDREF as the register controlling DDR refresh behavior, and notes that some DDR3 devices require temperature-dependent refresh changes, e.g. 64 ms refresh period at ≤85 °C and 32 ms above 85 °C. Eliminate known tool-environment hang causes If running from U-Boot, disable splash screen / IPU or any DMA that may still access DRAM; NXP notes that active IPU/splash access can make the system hang during the DDR stress flow. Check whether the watchdog fuse/configuration is enabled; NXP notes that on i.MX6Solo the watchdog can reset the device while DDR_Stress_Tester is doing calibration or stress test. If you are using the JTAG version, one reported i.MX6 case stopped after DDR frequency selection, and the guidance was to check JTAG mode/connection and use simple SDK DDR tests plus signal/power probing. My recommendation: regenerate the DDR init script for each new DDR part, start with a lower MMDC/DDR frequency, verify MDREF /timing values against the DDR datasheet, then rerun calibration. If it still hangs at CPU/DDR frequency selection, scope DDR power rails and clocks during that transition and compare MMDC register values between the old working DDR and the new Winbond/ISSI parts. The issue should be treated as an i.MX6Solo/DL DDR initialization and margin problem first; I did not find evidence that NXP identifies 20 nm/25 nm DDR3 process itself as a ddr_stress_tester incompatibility.

S32K358 SEMA42 demo 你好！我要使用 SEMA42 模块中的 Gate 寄存器，去写其 GTFSM 字段。需要在 mcal 中去进行使能 SEMA42 操作，目的为在使用的过程中保证对 GTFSM 字段可以正常写入与读取。请帮忙提供一份使用SEMA42的核间通信的demo给我，谢谢！

Battery Management System - SW & HW Environment Battery Management System Software and Hardware Environment 0 Table of Contents •Introduction •Software •Hardware •References •Conclusion 1 Introduction This article presents a comprehensive overview of the hardware and software components required to design and implement a high-voltage Battery Management System (BMS). It focuses on solutions based on NXP hardware platforms, combined with the integrated development ecosystems provided by NXP and MathWorks. The objective is to highlight how these technologies work together to streamline system development, deployment, and validation. 2 Software The software environment provides the modeling, simulation, communication, code generation, and deployment capabilities required by the Battery Management System. 2.1 Deep Learning Toolbox SorinIBancila_0-1786527787490.png Deep Learning Toolbox brings artificial intelligence into the model-based workflow. It provides MATLAB functions, apps, and Simulink blocks for designing, training, simulating, and analyzing deep neural networks. This makes AI-based behavior easier to develop, understand, and validate before deployment. In the Battery Management System, deep learning can support battery state estimation, fault detection, and operating-condition classification. The toolbox can create and evaluate neural networks, import pretrained models from PyTorch, TensorFlow, and ONNX, and integrate trained networks into Simulink for system-level simulation. Artificial intelligence is not treated as a separate development activity. Neural network behavior can be simulated and verified together with the battery control model. Networks can also be optimized through quantization, projection, or pruning, and prepared for embedded deployment through automatic code generation. This reduces integration risk and makes AI-based BMS functions easier to validate within the complete system. For more information, see the Deep Learning Toolbox documentation in the References chapter. 2.2 Vehicle Network Toolbox SorinIBancila_1-1786527804953.png Vehicle Network Toolbox brings CAN communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding CAN messages, making network behavior visible and testable before deployment. In the Battery Management System, commands, feedback, and status information are exchanged over CAN, linking the ECU with the surrounding vehicle architecture. The toolbox helps define signal interfaces, pack and unpack CAN messages, simulate bus traffic, and validate communication before target execution. Communication is not treated as a late integration step. CAN interaction can be simulated and verified together with the control model. This reduces integration risk and makes ECU behavior easier to validate end to end. For more information, see the Vehicle Network Toolbox documentation in the References chapter. 2.3 NXP Model-Based Design Toolbox for BMS SorinIBancila_2-1786527835753.png The NXP Model-Based Design Toolbox for BMS extends the NXP Model-Based Design Toolbox for S32K3 with BMS support. It enables configuration and integration of the MC33775A, MC33774A, MC33772C, MC33665A, and MC33664. The S32K3 toolbox includes peripheral blocks that provide access to key microcontroller resources such as ADC, PWM, CAN, SPI, UART, timers, and interrupts. These interfaces facilitate communication between the S32K3 microcontroller and the supported BMS integrated circuits. Together, the toolboxes support the development and deployment of BMS applications on the S32K3 platform, leveraging the underlying S32K3 and BMS software stack. The workflow also integrates with NXP configuration tools and supports real-time monitoring and visualization through FreeMASTER, simplifying application development, validation, and debugging. 3 Hardware The central hardware platform is the 800 V Battery Management System Reference Design using ETPL. The kit contains: RD-K358BMU - Battery Management Unit RD33774CNTEVB - Cell Monitoring Unit RD772BJBTPL8EVB - Battery Junction Box BATT-18EMULATOR - 18-cell battery pack emulator SorinIBancila_3-1786527864628.png 3.1 RD-K358BMU The RD-K358BMU is an NXP reference Battery Management Unit (BMU) designed for evaluation, development, and rapid prototyping of 800 V high-voltage Battery Management System (HVBMS) hardware and software. It provides a representative automotive-grade BMU platform built around the S32K358 microcontroller, enabling developers to evaluate battery-management architectures, safety concepts, communication interfaces, diagnostics, and control strategies in a realistic system environment. The board integrates several NXP components, including the S32K358, FS26, MC33665A, HB2000, TJA1145A, PCA2131, NBP8 and MC12XS6. Together, these components provide the processing, power management, communication, sensing, actuation, diagnostics, and safety capabilities required in a high-voltage BMS application. SorinIBancila_4-1786527890248.png 3.2 Cell Monitoring Unit: MC33774A The RD33774CNT3EVB is a centralized Cell Monitoring Unit (CMU) reference design intended for the development and evaluation of 800 V high-voltage Battery Management System (HVBMS) applications. It uses Electrical Transport Protocol Link (ETPL) communication to connect with the broader BMS architecture and support reliable data exchange within the battery system. The board includes three MC33774 Analog Front End (AFE) devices arranged in a daisy-chain configuration. These AFEs are responsible for measuring and monitoring battery cell parameters, helping developers evaluate cell supervision, diagnostics, and communication strategies in a centralized BMS topology.   SorinIBancila_5-1786527906947.png 3.3 Battery Junction Box: MC33772C The RD772BJBTPL8EVB is a Battery Junction Box (BJB) reference design developed for 800 V high-voltage Battery Management System (HVBMS) applications. It leverages Electrical Transport Protocol Link (ETPL) communication to ensure robust and isolated data exchange within the battery system. The board features two MC33772C battery sensor ICs configured to deliver redundant measurements of voltage and current, improving diagnostic coverage and supporting functional safety requirements. It also performs isolation measurements, which are essential for monitoring insulation integrity and detecting potential fault conditions in high-voltage environments. SorinIBancila_6-1786527924913.png 3.4 18-Cell Battery Pack Emulator The BATT-18EMULATOR board is designed to emulate a multi-cell battery pack and is easily interfaced with MC33774 battery cell controller evaluation boards. It enables quick evaluation of NXP Battery Cell Controller (BCC) ICs and supports software development by providing a controlled and flexible test environment. The board allows users to intuitively adjust the voltage of each of the 18 emulated cells, as well as the voltage levels on selected analog inputs typically used for temperature sensing. This capability makes it particularly useful for validating measurement accuracy, system behavior, and control algorithms without requiring a physical battery pack. Additionally, the BATT-18EMULATOR provides three independent outputs, allowing up to three BCC ICs to be connected simultaneously to a single emulator board. 4 References Deep Learning Toolbox Documentation Vehicle Network Toolbox Documentation NXP Model-Based Design Toolbox 800 V Battery Management System Reference Designs Using ETPL 5 Conclusion This article described the software and hardware environment required for the Battery Management System. The software combines MathWorks model-based design capabilities with NXP BMS and S32K3 platform support. The hardware integrates the S32K3 with NXP battery-cell controllers, communication interfaces, and associated BMS devices. Together, these elements provide the foundation for battery monitoring, communication, algorithm development, code generation, deployment, and validation. Next article: BMS architecture and model description, including the main software components, communication interfaces, data flow, and overall application structure.

First Steps with the Automotive MCU S32K – Development Environment Setup Guide: How to Install S32DS and RTD (Japanese Blog) What is this article about? NXP provides the S32 Design Studio ( S32DS) software development IDE environment for S32 microcontrollers and processors , as well as the Real-time Driver (RTD) software required to operate the MCU, free of charge. This article explains how to install the S32DS development environment and the RTD. * What is a Real-Time Driver ? This is NXP's proprietary driver set that integrates an " AUTOSAR- compliant MCAL(Microcontroller Abstraction Layer)" and a " non-AUTOSAR-compliant conventional SDK(Software Development Kit)" into a single unit. This time, we'll use the S32K3 , an automotive MCU that is versatile and has a wide range of options, as an example. S32DS is an environment that can be used with other NXP automotive MCUs as well. Overview of the S32K3 microcontroller's software First, let's get a rough understanding of the S32K3's software configuration . You don't need to understand the details at this point. YukoKinto_0-1786451878336.png This article will only cover a portion of the following: S32 Design Studio (S32DS) Real-Time Driver (RTD) What should I install? (Checklist) S32 Design Studio (※A common development environment for the S32 series) S32K3 Real-Time Drivers (RTD for S32K3) 1. Install S32 Design Studio S32 Design Studio is a free integrated development environment (IDE) that supports Power Architecture ® ( e200 core) and Arm ® -based automotive high-reliability microcontrollers /processors. S32DS IDE is a simple development tool with no code size limitations, based on open-source software such as Eclipse IDE , the GNU Compiler Collection (GCC) , and the GNU Debugger (GDB), and can be used for editing, compiling, and debugging designs. Download and install Download the IDE installer from the download site for S32 Design Studio for S32 Platform: ide/s32-design-studio-for-s32-platform:S32DS-S32PLATFORM" target="_blank" rel="noopener"> nxp.com Go to the S32DS download site and click the " Download " button. YukoKinto_1-1780932606377.png The page will scroll down, so please click " Download " below. YukoKinto_2-1780932606422.png Click on S32 Design Studio IDE. YukoKinto_3-1780932606478.png Click on the latest version, and if there are no issues, agree to the terms of service. YukoKinto_4-1780932606560.png There are versions for Linux and Windows, so please click the one that matches your operating system. YukoKinto_5-1780932606659.png Once the download is complete, launch the installer and follow the on-screen instructions to complete the installation. The process isn't particularly difficult, but if you're unsure, the following video provides detailed instructions, so please watch it while you proceed with the installation. Recommended ▶ gallerypage/video-id/6366101833112" target="_blank" rel="noopener">Video S32DS3.6_install_activation_use.mp4 - NXP Community 2. Install the S32K3 Real-Time Driver. Real-Time Drivers (RTDs) are a set of software components developed by NXP to accelerate the development of embedded applications running on S32 automotive MCUs . They provide a standardized, high-performance interface to hardware peripherals, enabling developers to create reliable and scalable automotive software systems.   Download and install Go to the download site for RTD xp.jp/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD" target="_blank" rel="noopener"> and click the " Download " button. YukoKinto_6-1780932606715.png The page will scroll down, so please click the " Download " button for the S32K3 Standard Software below. Please note that this Standard Software is free software and tools available for use. YukoKinto_7-1780932606765.png This time, we'll select an RTD for the S32K3. YukoKinto_8-1780932606833.png Click on the one that says“ Qualified as RFP Release” (RFP = Release For Production). YukoKinto_9-1780932606979.png I agree to the terms of service and will proceed. Next, click on the Updatesite for S32 Design Studio and download it . spoiler (Highlight for reading) * What is Updatesite? Simply downloading the RTD file doesn't mean you can use it with S32DS; you only have the "zip package" on hand. Only by installing the downloaded Update Site ( ..._DesignStudio_updatesite.zip ) into S32DS will the RTD be registered in the IDE. This allows you to select the RTD in the new project wizard and automatically generate the RTD code using "Update Code" based on the settings configured in the S32 Configuration Tool . *If you do not add this, RTD will not appear as an option when creating a new project. *Note that if the RTD is already bundled with the S32DS version, this procedure is unnecessary and you can use it as is. *What is Updatesite? Even after downloading RTD, you only have the "zip package" on hand and cannot use it with S32DS. Only by installing the downloaded Update Site (..._DesignStudio_updatesite.zip) into S32DS will RTD be registered in the IDE, allowing you to select RTD in the new project wizard and automatically generate RTD code using "Update Code" based on settings configured in the S32 Configuration Tool. *Without this, RTD will not appear as an option when creating a new project. *Note that this step is unnecessary for versions of S32DS that already bundle RTD and can be used immediately. YukoKinto_10-1780932607141.png   Open the Real-Time Driver on the S32DS and install RTD. Now let's actually open S32DS. Once you open S32DS, click on " S32DS Extension and Updates ". YukoKinto_11-1780932607291.png Verify that the S32K3 Development Package is installed. YukoKinto_0-1782821499671.png Click " Add Updates Site " in the bottom right corner and add the Real-time Driver you downloaded earlier. YukoKinto_12-1780932607553.png Once the addition is complete, the Real-Time Driver will appear on the left side. This time, click on "S32K3XX Real-Time Driver…" to start the installation. If you look at the bottom right, you can confirm that the installation has started. As the installation progresses, you will be prompted to restart the S32DS, so follow the instructions. YukoKinto_13-1780932607635.png After restarting, the RTD installation is complete! If you open " S32DS Project From Example " in the lower left, you can see the S32K3XX Real-Time Driver that you just installed . YukoKinto_14-1780932607787.png The following video also provides detailed instructions, so please try installing while watching the video. Recommended ▶ S32 Design Studio 3.6: How to Download RTD | NXP Semiconductors At this point, the installation of the S32 Design Studio IDE and the S32K3 Real-Time Driver is complete. Great job! In the next article, we will actually run the drivers and sample applications included in the RTD. =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but when making an inquiry, please refer to " 8 %E3% 81 %AE% E6 %8A% 80 %E8% A1 %93% E8 %B3% AA %E5% 95 %8F-% E5 %95% 8F %E3% 81 %84% E5 %90% 88 %E3% 82 %8F% E3 %81% 9B %E6% %B9% %B3% E6 %E6% 97 %A5% E6 %9C% AC %E8% AA %9E% E3 %83% 96 %E3% 83 %AD% E3 %82% B0/ba-p/2153299" target="_blank" rel="noopener" data-hyperlinktype="0" > How to ask technical questions to NXP ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may ask your representative directly. ) This article provides a detailed explanation of how to install the S32 Design Studio (S32DS) development environment and the Real-Time Driver for NXP automotive MCUs, in a level of detail that even those new to S32K can easily follow. This example uses the S32K3 automotive MCU, but the same procedure can be used to set up the environment for other automotive MCUs. (Working time: 20 minutes) General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads Japanese Blog

让我们使用 S32K – RTD（首款车规级 MCU）运行一个 LED 闪烁应用程序（日本博客） 这篇文章是关于什么的？ 在上一篇文章中，我们安装了S32 设计工作室（以下简称S32DS ）和实时驱动程序（以下简称RTD），以执行使用 S32 MCU 进行评估和开发所需的必要准备步骤。 汽车级MCU S32K入门指南——开发环境搭建指南：安装S32DS和RTD（日语博客） 这一次，我们将迈出下一步，实际打开一个 RTD 示例项目，并通过生成代码、构建和调试来体验 S32K3 开发的“第一步” 。 本文目标：调试 S32K3 FRDM 板上的 RTD 示例 ， 并使 LED 闪烁（预计时间：15 分钟） 准备 硬件： FRDM-A-S32K344 USB Type-C 数据线（※FRDM-A-S32K344 随附） 在本文中， 我们将使用 FRDM Automotive 的 新型 开发板 FRDM-A-S32K344 ，该开发板采用 S32K3 微控制器。S32K344 是 一款 1x LockStep Arm Cortex-M7 微控制器， 广泛应用于 电机控制 和车身控制 等领域。 软件： S32DS（IDE 开发环境） RTD（S32K3软件） 请事先确保已安装上一篇文章中介绍的 S32DS和RTD 。 步骤 1：打开 RTD 样品 启动 S32DS 并创建一个新项目。然后，按照以下步骤打开 RTD 示例。 打开左下角的“ S32DS 项目示例”，然后点击“ S32K3XX 实时驱动程序… ”查看ADC 、 CAN 、 GPT 、 I2C 、 PWM 等示例。 YukoKinto_13-1780933148603.png 这次，我们以“ Dio 示例”为例。 点击“Dio 示例”，然后 选择“ Dio_Example_S32K344 ”。 示例的详细信息会显示在右侧，请检查内容并 点击“完成”。 YukoKinto_14-1780933148676.png 在左侧的“项目资源管理器”中导航到 main.c ，然后单击打开源代码。 YukoKinto_15-1780933148992.png 您会在右下角和代码中看到几个“警告”，但这些警告并不表示源代码本身存在错误，而是表示S32DS没有正确找到与 RTD 相关的头文件。 YukoKinto_16-1780933149223.png 步骤 2：解决警告 要解决此警告，请先单击屏幕左侧项目资源管理器中的“example_Dio.mex” 。 “example_Dio.mex”是一个存储MCU设置（例如，DIO = 数字I/O）、引脚/时钟/外设设置和代码生成设置的文件。 YukoKinto_17-1780933149559.png 配置工具界面将会出现。点击顶部中央的“更新代码”按钮，即可更新代码并解决错误。更新完成后，右下角“问题”部分中的警告信息将会消失。 YukoKinto_18-1780933149981.png   步骤 3：构建 点击下方按钮返回上一屏幕。 YukoKinto_19-1780933150450.png 在项目资源管理器的“生成”部分，您可以查看每个软件及其各自的标题。 YukoKinto_20-1780933150921.png 最后，点击屏幕左上角的构建按钮。屏幕右下角应该会显示“构建完成”的消息，确认没有错误后，就表示之前提到的警告问题已经解决。 YukoKinto_21-1780933151268.png 到目前为止，我们已经确认可以打开 RTD 示例项目，从 .mex 文件生成代码，并成功完成构建。 第四步：调试 使用随附的USB Type-C 数据线将 FRDM-A-S32K344 连接到您的电脑。连接成功后，板上的 LED 指示灯将亮起。 FRDM-K3.png   返回 S32DS 屏幕，点击屏幕顶部中央的调试图标（虫子图标）开始调试。点击后，屏幕上会显示一条消息，提示您启动 PE Micro 调试器，请允许其启动，并按照屏幕上的说明进行调试。 PE Micro是一款用于调试的调试驱动程序（工具）。S32DS使用名为 PE Micro的调试器将开发板连接到PC。 在当前环境下， S32DS （ IDE ）➡ PE Micro（调试工具） ➡ FRDM-A-S32K344 这是我们沟通的渠道。 YukoKinto_23-1780933151944.png 调试后，如果控制台中出现“目标已复位”和“ DAP 已成功上电”等日志，并且调试视图中显示线程信息（线程 #1），则表示与目标板的连接和程序传输已成功完成。   步骤五：点亮LED灯 现在，让我们在 FRDM-A-S32K344 板上实际检查一下。 点击屏幕中央工具栏中的播放图标 ▶ “恢复/运行” 以开始执行程序。 请注意，每个示例程序都在 main() 函数的开头设置了一个断点，以便于调试。 YukoKinto_24-1780933152481.png 如果您能确认 LED 灯 亮起 几秒钟 （下图黄色圆圈中的 LED 灯），则此调试成功。 在这个示例代码中， 我们被指示“ while (count++ < 10) ”。 初始计数为0 每次循环迭代，计数都会增加count++。 仅当计数小于 10 时才有效 换句话说，LED 最多亮 10次才能完成操作，所以LED 只亮几秒钟然后停止是正常的。 YukoKinto_25-1780933153221.png 到目前为止，我们已经体验了从构建和调试 RTD 示例项目到验证其在实际电路板上的运行（打开和关闭 LED）的整个过程。 最后 这一系列步骤代表了使用 S32K3 的基本开发步骤。 代码生成 → 构建 → 调试 → 测试功能 通过在电路板上实际观察其运行情况，你就能更直观地了解软件如何控制硬件。 根据这些基本步骤，尝试开发你自己的应用程序。 =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。） 在本文中，我们将使用 S32K3 实时驱动程序中的一个 LED 闪烁示例项目，通过生成、构建和调试代码来体验 S32K3 开发的“第一步”。 本文目标：调试S32K3 FRDM 板上的RTD示例并使其 LED闪烁。 （预计时间：15分钟） 通用微控制器 S32设计工作室 S32K SW | 下载 日本博客

Let's run an LED blinking application using the S32K – RTD, the first automotive-grade MCU (Japanese blog) What is this article about? In the previous article, we installed S32 Design Studio (hereinafter S32DS ) and Real-Time Driver (hereinafter RTD) to perform the necessary preliminary steps for evaluating and developing with the S32 MCU. First Steps with the Automotive MCU S32K – Development Environment Setup Guide: Installing S32DS and RTD (Japanese Blog) This time, as the next step, we will actually open an RTD sample project and experience the " first step " of S32K3 development by generating code, building, and debugging . Goal of this article: Debug a sample from RTD on an S32K3 FRDM board and make an LED blink (estimated time: 15 minutes) Preparation Hardware: FRDM-A-S32K344 USB Type-C cable (※Included with FRDM-A-S32K344) In this article, we will be using the new FRDM Automotive board, the FRDM-A-S32K344 , which uses the S32K3. The S32K344 is a 1x LockStep Arm Cortex-M7 microcontroller and is used in a wide range of applications, including motor control and body control . software: S32DS (IDE development environment) RTD (Software for S32K3) Beforehand, please make sure that S32DS and RTD, which were introduced in the previous article , are installed. Step 1: Open the RTD sample Launch S32DS and create a new project. Then, follow these steps to open the RTD sample. Open " S32DS Project from Example " in the lower left corner, and click " S32K3XX Real-Time Drivers… " to see examples of ADC , CAN , GPT , I2C , PWM, etc. YukoKinto_13-1780933148603.png This time, let's use " Dio Example " as an example. Click on "Dio Example," and then select " Dio_Example_S32K344 " from there. The details of the example are displayed on the right, so check the contents and click "Finish." YukoKinto_14-1780933148676.png Navigate to main.c in the "Project Explorer" on the left and click to open the source code. YukoKinto_15-1780933148992.png You will see several "Warnings" in the bottom right and on the code, but these warnings do not indicate errors in the source code itself, but rather that S32DS is not correctly finding where to look for RTD-related header files. YukoKinto_16-1780933149223.png Step 2: Resolving the Warning To resolve the warning, first click on "example_Dio.mex" in the Project Explorer on the left side of the screen. "example_Dio.mex" is a file that stores MCU settings (e.g., DIO = Digital I/O), Pins/Clock/Peripheral settings, and code generation settings. YukoKinto_17-1780933149559.png The Configuration Tool screen will appear. Click "Update Code" at the top center to update the code and resolve the error. Once the update is complete, the warning message will disappear from the "Problem" section at the bottom right. YukoKinto_18-1780933149981.png   Step 3: Build Click the button below to return to the previous screen. YukoKinto_19-1780933150450.png In the " generate " section of Project Explorer, you can view each software and its respective headers. YukoKinto_20-1780933150921.png Finally, click the build button in the upper left corner of the screen. You should also see a "Build Finished" message in the lower right corner of the screen, and confirm that there are no errors, which means the warning mentioned earlier has been resolved. YukoKinto_21-1780933151268.png Up to this point, we have confirmed that we can open the RTD sample project, generate code from the .mex file, and complete the build successfully. Step 4: Debugging Connect the FRDM-A-S32K344 to your PC using the included USB Type-C cable . The LED on the board will light up when the connection is successful. FRDM-K3.png   Return to the S32DS screen and click the debug icon (bug logo) at the top center of the screen to start debugging. After clicking, a message will appear asking you to launch the PE Micro debugger, so allow it to launch and follow the on-screen instructions to proceed with debugging. PE Micro is a debug driver (tool) used by the S32DS to connect the board to the PC. In the current environment, S32DS ( IDE ) ➡ PE Micro ( Debugging Tool ) ➡ FRDM-A-S32K344 This is the route through which we are communicating. YukoKinto_23-1780933151944.png After debugging, if logs such as " Target has been RESET " and " DAP successfully powered up " appear in the Console, and thread information ( Thread #1 ) is displayed in the Debug view, then the connection to the target board and program transfer have been completed successfully.   Step 5: Light up the LED Now, let's actually check it on the FRDM-A-S32K344 board. Click the play icon ▶ “Resume/Run” in the toolbar in the center of the screen to start the program execution. Please note that each sample program has a breakpoint placed at the beginning of the main() function to facilitate debugging. YukoKinto_24-1780933152481.png If you can confirm that the LED lights up for a few seconds (the LED circled in yellow in the diagram below), then this debugging was successful. In this example code, we are instructed to " while (count++ < 10) ". Start with count = 0 The count increases by count++ with each loop iteration. It only works while count < 10 In other words, the LED lights up a maximum of 10 times to complete the operation, so it's normal for the LED to light up for only a few seconds and then stop . YukoKinto_25-1780933153221.png Up to this point, we have been able to experience the entire process from building and debugging the RTD sample project to verifying its operation on the actual board ( turning the LEDs on and off). Finally This series of steps represents the basic development steps using the S32K3. Code generation → Build → Debug → Test functionality By actually seeing it in action on the board, you were able to gain a more intuitive understanding of how software controls hardware. Based on these basic steps, try developing your own application. =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) In this article, we will use a sample LED blinking project within the S32K3 Real-Time Driver to experience the " first steps " of S32K3 development by generating, building, and debugging code. Goal of this article: Debug a sample in RTD on an S32K3 FRDM board and blink an LED. (Estimated time: 15 minutes) General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads Japanese Blog

初めての車載向けMCU S32K – RTDを使用してLED点滅のアプリケーションを動かしてみよう (日本語ブログ) この記事は？ 前回の記事では、S32 Design Studio（以下S32DS）とReal-Time Driver（以下RTD）のインストールを行い、S32 MCUの評価、開発に必要な下準備を行いました。 初めての車載向けMCU S32K – 開発環境構築ガイド：S32DSとRTDのインストール（日本語ブログ） 今回はその次のステップとして、実際にRTDのサンプルプロジェクトを開き、コード生成、ビルド、デバッグを行うことで、S32K3開発の「最初の一歩」を体験してみます。 この記事のゴール：S32K3 FRDMボード上でRTD内のサンプルをデバッグし、LEDを点滅させる （所要時間：15分） 事前準備 ハードウェア： FRDM-A-S32K344 USB Type-Cケーブル (※FRDM-A-S32K344に付属しています。) 今回の記事では、S32K3の新しいFRDM Automotiveボード、FRDM-A-S32K344を使います。S32K344は、１ｘLockStep Arm Cortex-M7 マイクロコントローラで、モーター制御、ボディ制御等、幅広いアプリケーションで採用されています。 ソフトウェア： S32DS (IDE開発環境) RTD (S32K3用ソフトウェア) 事前に、前回の記事、で紹介したS32DSとRTDがインストールされていることを確認してください。 ステップ１：RTDサンプルを開く S32DSを起動し、新しいプロジェクトを作成しましょう。その後、以下の手順に沿って、RTDサンプルを開きます。 左下の「S32DS Project from Example」を開き、「S32K3XX Real-Time Drivers…」をクリックすると、ADC、CAN、GPT、I2C、PWM…etc.等のサンプルが確認できます。 YukoKinto_13-1780933148603.png 今回は、例として「Dio Example」を使ってみましょう。「Dio Example」をクリックし、その中からさらに「Dio_Example_S32K344」を選択。右側に、Exampleの詳細が記載されているため、中身を確認し、「Finish」をクリック。 YukoKinto_14-1780933148676.png 左の「Project Explorer」でmain.cへと移動し、クリックすると、ソースコードを開くことができる。 YukoKinto_15-1780933148992.png 右下およびコード上にいくつかの「Warning」が表示されますが、この警告は、ソースコードそのもののミスではなく、S32DSがRTD関連のヘッダファイルを探す場所を正しく見つけられていない場合に表示されます。 YukoKinto_16-1780933149223.png ステップ２：Warningの解消 Warningを解消するために、まずは画面左のProject Explorerから、「example_Dio.mex」をクリックします。「example_Dio.mex」は、MCUの設定（例：DIO = Digital I/O）、Pins / Clock / Peripheral設定、コード生成設定情報を保存しているファイルです。 YukoKinto_17-1780933149559.png Configuration Toolの画面が表示されるので、中央上の「Update Code」をクリックし、エラーを解消するためにコードを更新します。アップデートが完了すると、右下の「Problem」セクションからWarningメッセージが消えます。 YukoKinto_18-1780933149981.png   ステップ３：ビルド 以下のボタンをクリックし、元の画面に戻ります。 YukoKinto_19-1780933150450.png Project Explorerの「generate」のセクションで、各ソフトウェアとそれぞれのヘッダーを確認することができます。 YukoKinto_20-1780933150921.png 最後に、画面左上のビルドボタンをクリックします。画面右下に「Build Finished」のコメントともにエラーが無いことも確認できるので、先ほどのWarningも解消されたことが確認できます。 YukoKinto_21-1780933151268.png ここまでで、RTDサンプルプロジェクトを開き、.mexファイルからコードを生成し、ビルドが正常に完了するところまで確認できました。 ステップ４：デバッグ FRDM-A-S32K344を付属のUSB Type-Cケーブルを使って、お使いのPCにつないでください。正常につながると、ボード上のLEDが光った状態になります。 FRDM-K3.png   S32DSの画面に戻り、画面中央上のデバッグアイコン（虫のロゴ）をクリックし、デバッグを開始しましょう。クリックすると、デバッガのPE Microを起動させるメッセージが出てくるので、起動を許可し、画面の指示に沿ってデバッグを進めてください。 PE Micro は、デバッグ用の接続ドライバ（ツール）で、S32DSがPCとボードをつなぐために、PE Microというデバッガを使っています。 現在の環境では、 S32DS（IDE）➡ PE Micro(デバッグツール) ➡ FRDM-A-S32K344 という経路で通信しています。 YukoKinto_23-1780933151944.png そして、デバッグ実行後、Consoleに「Target has been RESET」「DAP successfully powered up」などのログが表示され、さらにDebugビューにスレッド情報（Thread #1）が表示されていれば、ターゲットボードへの接続およびプログラム転送は正常に完了しています。   ステップ５：LEDを光らせる では、実際にFRDM-A-S32K344ボード上で確認しましょう。 画面中央のツールバーにある再生マーク ▶ “Resume/Run”をクリックすると、プログラム実行がスタートします。 尚、各サンプルプログラムはデバッグを行いやすいように、main()の先頭にブレイクポイントを貼っています。 YukoKinto_24-1780933152481.png 「数秒だけLEDが光る」（下図の黄色で囲ったLED）動作が確認できれば、今回のデバッグは成功です。 今回のDim Exampleのコードでは、“while (count++ < 10)”と指示されており、 count = 0 でスタート ループ1回ごとに count++ で増える count < 10 の間だけ動く つまり、最大10回LEDが光って動作が完了する、という中身になっているため、LEDが数秒だけ動作して止まるのが正常な挙動です。 YukoKinto_25-1780933153221.png ここまでで、RTDサンプルプロジェクトのビルドからデバッグ、そして実機ボード上での動作確認（LEDの点灯・消灯）までを一通り体験することができました。 さいごに 今回の一連の流れは、S32K3を用いた開発の基本ステップとなります。 コード生成 → ビルド → デバッグ → 動作確認 実際にボード上で動作を確認することで、ソフトウェアがハードウェアを制御していることをより直感的に理解できたのではないでしょうか。 この基本ステップをベースに、ご自身のアプリケーション開発へと発展させてみてください。 =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 今回の記事では、S32K3 Real-Time Driver内のLED点滅のサンプルプロジェクトを用いて、コード生成、ビルド、デバッグを行うことで、S32K3開発の「最初の一歩」を体験します。 この記事のゴール：S32K3 FRDMボード上でRTD内のサンプルをデバッグし、LEDを点滅させる （所要時間：15分） General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads 日本語ブログ

汽车级MCU S32K入门指南——开发环境搭建指南：如何安装S32DS和RTD（日语博客） 这篇文章是关于什么的？ 恩智浦 半导体 (NXP) 为 S32 微控制器和 处理器 免费 提供 S32 设计 工作室 ( S32DS) 软件开发集成开发环境 (IDE)，以及 运行 MCU 所需的 实时驱动程序 (RTD) 软件。本文将介绍如何安装 S32DS 开发环境和 RTD。 什么是 实时驱动程序 ？ 这是 NXP 的 专有驱动程序集 ，它将“ 符合 AUTOSAR 标准的 MCAL （微控制器抽象层）”和“ 不符合 AUTOSAR 标准的常规 SDK （软件开发工具包）” 集成到一个单元中 。 这次，我们将以功能全面、选项丰富的 汽车级 MCU S32K3 为例进行说明。S32DS 环境也可以与 NXP的其他汽车级 MCU配合使用。 S32K3微控制器软件概述 首先，让我们大致了解一下S32K3的软件配置。 你现在不需要了解细节。 YukoKinto_0-1786451878336.png 本文仅涵盖以下内容的一部分： S32 设计工作室 (S32DS) 实时驾驶员 (RTD) 我应该安装哪些软件？（清单） S32 设计工作室（※S32 系列的通用开发环境） S32K3 实时驱动程序（S32K3 的 RTD） 1.安装S32 设计工作室 S32 Design Studio是一个免费的集成开发环境 (IDE)，支持基于 Power Architecture ® ( e200内核) 和Arm ®的汽车高可靠性微控制器/处理器。 S32DS IDE 是一款简单的开发工具，没有代码大小限制，它基于 Eclipse IDE 、 GNU编译器集合(GCC)和GNU调试器(GDB) 等开源软件，可用于编辑、编译和调试设计。 下载并安装 从下载站点下载适用于 S32 平台的 S32 Design Studio IDE安装程序：ide/s32-design-studio-for-s32-platform:S32DS-S32PLATFORM" target="_blank" rel="noopener"> nxp.com 前往 S32DS 下载网站，然后点击“下载”按钮。 YukoKinto_1-1780932606377.png 页面会向下滚动，请点击下面的“下载”按钮。 YukoKinto_2-1780932606422.png 点击 S32 设计工作室 IDE。 YukoKinto_3-1780932606478.png 点击最新版本，如果没有问题，请同意服务条款。 YukoKinto_4-1780932606560.png 有Linux 和Windows 版本，请点击与您的操作系统匹配的版本。 YukoKinto_5-1780932606659.png 下载完成后，启动安装程序，并按照屏幕上的说明完成安装。 这个过程并不特别难，但如果您不确定，以下视频提供了详细的说明，请在安装过程中观看。 推荐▶ gallerypage/video-id/6366101833112" target="_blank" rel="noopener">视频 S32DS3.6_install_activation_use.mp4 - NXP 社区 2.安装S32K3 实时驱动程序。 实时驱动程序 (RTD) 是恩智浦半导体开发的一组软件组件，旨在加速在 S32 汽车 MCU 上运行的嵌入式应用程序的开发。它们为硬件外设提供标准化的高性能接口，使开发人员能够创建可靠且可扩展的汽车软件系统。   下载并安装 前往RTD的下载站点xp.jp/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD" target="_blank" rel="noopener"> 并点击“下载”按钮。 YukoKinto_6-1780932606715.png 页面将向下滚动，请点击下方“ 下载”按钮 下载 S32K3 标准软件。 请注意，此标准软件为免费软件和工具。 YukoKinto_7-1780932606765.png 这次，我们将为 S32K3 选择 RTD。 YukoKinto_8-1780932606833.png 点击标有“符合 RFP 发布条件”的选项（RFP =发布用于生产）。 YukoKinto_9-1780932606979.png 我同意服务条款，并将继续操作。 接下来，点击 S32 Design Studio的更新站点并下载。 剧透 （高亮显示以便阅读） Updatesite是什么？ 仅仅下载 RTD 文件并不意味着您可以将其与 S32DS 一起使用；您手中只有“zip 压缩包”。只有将下载的更新站点 ( ..._DesignStudio_updatesite.zip ) 安装到 S32DS 中，RTD 才能在 IDE 中注册。这样，您就可以在新建项目向导中选择 RTD ，并根据 S32 配置工具中配置的设置，使用“更新代码”自动生成 RTD 代码。 *如果不添加此项，创建新项目时 RTD 将不会显示为选项。 *请注意，如果 RTD 已与 S32DS 版本捆绑在一起，则此步骤是不必要的，您可以直接使用它。 Updatesite是什么？ 即使下载了 RTD，您也只能获得“zip 压缩包”，而无法将其与 S32DS 一起使用。只有将下载的更新站点 (..._DesignStudio_updatesite.zip) 安装到 S32DS 中，RTD 才能在 IDE 中注册，从而允许您在新建项目向导中选择 RTD，并根据 S32 配置工具中配置的设置，使用“更新代码”自动生成 RTD 代码。*否则，创建新项目时将不会显示 RTD 选项。*请注意，对于已捆绑 RTD 并可直接使用的 S32DS 版本，此步骤是不必要的。 YukoKinto_10-1780932607141.png   在 S32DS上打开实时驱动程序并安装 RTD。 现在让我们打开 S32DS。 打开 S32DS 后 ， 点击“ S32DS 扩展和更新”。 YukoKinto_11-1780932607291.png 确认已安装 S32K3 开发包。 YukoKinto_0-1782821499671.png 点击右下角的“添加更新站点”，然后添加您之前下载的实时驱动程序。 YukoKinto_12-1780932607553.png 添加完成后，实时驱动程序将显示在左侧。这次，点击“S32K3XX 实时驱动程序…”开始安装。 查看右下角，即可确认安装已开始。安装过程中，系统会提示您重启 S32DS，请按照提示操作。 YukoKinto_13-1780932607635.png 重启后，RTD安装完成！ 如果您在左下角打开“ S32DS 项目示例”，您可以看到您刚刚安装的S32K3XX 实时驱动程序。 YukoKinto_14-1780932607787.png 以下视频也提供了详细的安装说明，请边观看视频边尝试安装。 推荐▶ S32 设计工作室 3.6：如何下载 RTD | 恩智浦半导体 至此，S32 设计工作室 IDE和S32K3实时驱动程序的安装已完成。干得好！ 下一篇文章中，我们将实际运行 RTD 中包含的驱动程序和示例应用程序。 =========================​ 我们目前无法回复此帖子“评论”部分留下的评论。 由此给您带来的不便，我们深表歉意。如有任何疑问，请参考“ 8 %E3% 81 %AE% E6 %8A% 80 %E8% A1 %93% E8 %B3% AA %E5% 95 %8F-% E5 %95% 8F %E3% 81 %84% E5 %90% 88 %E3% 82 %8F% E3 %81% %E6% %B9% %B3% E6 %E6% 97 %A5% E6 %9C% AC %E8% AA %9E% E3 %83% 96 %E3% 83 %AD% E3 %82% B0/ba-p/2153299” target="_blank" rel="noopener" data-hyperlinktype="0" >如何向NXP提出技术问题（日语博客） ” ） “ 。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接咨询您的代表。 ） 本文详细介绍 了如何安装 S32 设计工作室 (S32DS) 开发环境和 NXP 汽车 MCU 的实时驱动程序 ， 即使是 S32K 新手 也能轻松理解。 本示例使用 S32K3 汽车 MCU，但相同的步骤也可用于设置其他汽车 MCU 的环境。 （操作时间：20分钟） 通用微控制器 S32设计工作室 S32K SW | 下载 日本博客

初めての車載向けMCU S32K – 開発環境構築ガイド：S32DSとRTDのインストール方法（日本語ブログ） この記事は？ NXPでは、S32 マイコン・プロセッサ用ソフトウェア開発IDE環境「S32 Design Studio (S32DS)」と、MCUを動かすために必要なソフトウェア*Real-time Driver(RTD)を無料で提供されています。この記事では、開発環境S32DSとRTDのインストール方法について解説します。 *Real-Time Driverとは？ 「AUTOSAR準拠のMCAL（マイコン抽象化レイヤ）」と「AUTOSAR非準拠の従来のSDK（ソフトウェア開発キット）」を1つに統合したNXP独自のドライバセットです。 今回は、汎用的かつラインナップも豊富なS32K3という車載MCUを例にします。S32DSは、他のNXP車載MCUでも使用できる環境です。 S32K3マイコン の Software 全体像 最初に、S32K3 のソフトウェア構成を “ざっくり” 把握しておきましょう。  この時点で細かい理解は必要ありません。 YukoKinto_0-1786451878336.png 本記事で扱う範囲は、以下の一部だけです。 S32 Design Studio (S32DS) Real-Time Driver (RTD) 何をインストールすればいい？（チェックリスト） S32 Design Studio (※S32シリーズで共通の開発環境) S32K3 Real-Time Drivers (※S32K3向けRTD) １．S32 Design Studioをインストール S32 Design Studioは、Power Architecture®（e200コア）およびArm®ベースの車載向け高信頼性マイクロコントローラ/プロセッサに対応する統合開発環境(IDE)であり、無償で提供されています。 S32DS IDEは、Eclipse IDE、GNUコンパイラ・コレクション (GCC)、GNU デバッガ (GDB) などのオープンソース・ソフトウェアをベースにした、コード・サイズに制限のないシンプルな開発ツールであり、設計の編集、コンパイル、デバッグに利用できます。 ダウンロードとインストール IDEのインストーラをide/s32-design-studio-for-s32-platform:S32DS-S32PLATFORM" target="_blank" rel="noopener">S32 Design Studio for S32 Platformのダウンロードサイトからダウンロードします。このダウンロードにはnxp.com S32DS のダウンロードサイトへ行き、「ダウンロード」ボタンを押します。 YukoKinto_1-1780932606377.png ページがスクロールされるので、以下の「ダウンロード」を押します。 YukoKinto_2-1780932606422.png S32 Design Studio IDEをクリックします。 YukoKinto_3-1780932606478.png 最新バージョンをクリックし、問題がなければ利用規約に同意します。 YukoKinto_4-1780932606560.png Linux用とWindows用があるので、ご自身のOSに応じてクリックください。 YukoKinto_5-1780932606659.png ダウンロードが完了したら、インストーラーを起動し、表示される手順に従ってインストールを完了させます。 そこまで難しい内容はございませんが、もし不安な方は、以下のビデオにて、細かい手順が案内されているので、ビデオを見ながら平行してインストールを進めてみてください。 おすすめ ▶ gallerypage/video-id/6366101833112" target="_blank" rel="noopener">Video S32DS3.6_install_activation_use.mp4 - NXP Community ２．S32K3 Real-Time Driverをインストール リアル・タイム・ドライバ(RTD)は、S32車載MCU上で動作する組込みアプリケーションの開発を加速するためにNXPが開発した一連のソフトウェア・コンポーネントです。ハードウェア・ペリフェラルに対する標準化された高性能インターフェースを提供し、開発者が信頼性と拡張性に優れた車載ソフトウェア・システムを開発できるようにします。   ダウンロードとインストール RTD xp.jp/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD" target="_blank" rel="noopener">のダウンロードサイトへ行き、「ダウンロード」ボタンを押します。 YukoKinto_6-1780932606715.png ページがスクロールされるので、以下のS32K3 Standard Softwareの「ダウンロード」ボタンを押します。尚、このStandard Softwareとは、無償でご利用いただけるソフトウェア、ツールです。 YukoKinto_7-1780932606765.png 今回はS32K3向けのRTDを選択します。 YukoKinto_8-1780932606833.png  “Qualified as RFP Release”(RFP＝Release For Production)となっているものをクリック。 YukoKinto_9-1780932606979.png 利用規約に同意して、進めます。 続いて、S32 Design StudioのUpdatesiteをクリックし、ダウンロードします。 スポイラ （読むためにハイライト） *Updatesiteとは？ RTDをダウンロードした状態は、まだ「zipで配布されたパッケージ」を手元に持っているだけで、S32DSからは使えません。ダウンロードしたUpdate Site（ ..._DesignStudio_updatesite.zip ）をS32DSに追加インストールすることで、はじめてRTDがIDEに登録され、新規プロジェクトウィザードでRTDを選択したり、S32 Configuration Toolで設定した内容を「Update Code」でRTDのコードとして自動生成できるようになります。 ※これを追加しないと、新規プロジェクト作成時にRTDが選択肢に表示されません。 ※なお、RTDがあらかじめS32DSにバンドルされているバージョンでは、この手順は不要でそのまま使えます。 *Updatesiteとは？ RTDをダウンロードした状態は、まだ「zipで配布されたパッケージ」を手元に持っているだけで、S32DSからは使えません。ダウンロードしたUpdate Site（..._DesignStudio_updatesite.zip）をS32DSに追加インストールすることで、はじめてRTDがIDEに登録され、新規プロジェクトウィザードでRTDを選択したり、S32 Configuration Toolで設定した内容を「Update Code」でRTDのコードとして自動生成できるようになります。※これを追加しないと、新規プロジェクト作成時にRTDが選択肢に表示されません。※なお、RTDがあらかじめS32DSにバンドルされているバージョンでは、この手順は不要でそのまま使えます。 YukoKinto_10-1780932607141.png   S32DSでReal-Time Driverを開き、RTDをインストール では実際にS32DSを開いてみましょう。 S32DSを開いたら「S32DS Extension and Updates」をクリック。 YukoKinto_11-1780932607291.png S32K3のDevelopment Packageがインストール済であることを確認。 YukoKinto_0-1782821499671.png 右下の「Add Updates Site」をクリックし、先ほどダウンロードしたReal-time Driverを追加します。 YukoKinto_12-1780932607553.png 追加が完了すると、左側にReal-Time Driverが出てくるので、今回は「S32K3XX Real-Time Driver…」をクリックし、インストールを開始する。 右下を見ると、インストールが開始されたことを確認できます。インストールが進むと、S32DSを再起動するよう求められるので、指示に沿って進めます。 YukoKinto_13-1780932607635.png 再起動を行い、RTDのインストールが完了！ 左下の「S32DS Project From Example」を開くと、先ほどインストールしたS32K3XX Real-Time Driverが確認できます。 YukoKinto_14-1780932607787.png 以下のビデオにも、細かい手順が案内されているので、ビデオを見ながら平行してインストールを進めてみてください。 おすすめ ▶　S32 Design Studio 3.6: How to Download RTD | NXP Semiconductors ここまでで、S32 Design Studio IDEとS32K3のReal-Time Driverのインストールが完了しました。お疲れ様でした。 次の記事で、実際にRTDに含まれるドライバーとサンプル・アプリケーションを動かしてみます。 =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「8%E3%81%AE%E6%8A%80%E8%A1%93%E8%B3%AA%E5%95%8F-%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B%E6%96%B9%E6%B3%95-%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%96%E3%83%AD%E3%82%B0/ba-p/2153299" target="_blank" rel="noopener" data-hyperlinktype="0">NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。）​ 本記事では、NXP車載MCU用の開発環境S32 Design Studio (S32DS)、及びReal-Time Driverのインストール方法を、初めて S32K に触る方でも迷わず進められる粒度で丁寧に解説します。 今回はS32K3という車載MCUを例にしますが、他の車載MCUでも同じ手順で環境を構築できます。 （作業時間：20分） General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads 日本語ブログ

S32K312 POR_WDG is what, how to use. Hi HXP, S32K312 POR_WDG is what, how to use. li3_0-1712841547675.png Re: S32K312 POR_WDG is what, how to use. Hi @li3, 1. Please refer to the DCF clients file attached to the reference manual. Julin_AragnM_0-1713218415262.png 2. The Watchdog timer has a configurable threshold, if the chip does not exit the reset sequence within this time, the POR_WDG initiates a power-on-reset. You can monitor the WDG status from the DCMROPPn register.  3. This register only captures the status of the functional reset sequence process when POR_WDG overflows. Since the POR_WDG is part of the DCF client safety function, you can also look into the Safety Manual for S32K3 in "Secure Files" from the S32K3 Auto General-Purpose MCUs, documentation. Best regards, Julián Re: S32K312 POR_WDG is what, how to use. Hi NXP,     Please help me answer the following three questions.     1.I can't find the control register for reset monitor. I don't know how to turn on or off the reset monitoring function of POR_WDG. Please tell me the location of the register. li3_0-1712973586290.png     2. How does the reset monitoring function detect that the system is stuck in the reset sequence? Does it detect registers that have not been successfully reset?     3.The reset monitoring function indicates that after POR_WDG times out, the system deadlock position can be captured in DCM's DCMROPPn register. Can these states only let us know the system deadlock position after POR_WDG times out? Or is it the state of DCM's DCMROPPn register that determines the POR_WDG timeout? li3_1-1712973946770.png li3_2-1712974028398.png Best regards, Li 3. Re: S32K312 POR_WDG is what, how to use. Hi @li3, This is in case of functional reset event: Julin_AragnM_0-1712958688520.png Best regards, Julián Re: S32K312 POR_WDG is what, how to use. Hi NXP, What is the Reset monitoring control register? Is it to monitor whether Reset can succeed? li3_0-1712893068068.png Best regards, Li 3. Re: S32K312 POR_WDG is what, how to use. Hi @li3, The Power-on Reset Watchdog is a module for added monitoring to the chip. If the chip is stuck in reset or standby for a determined time, the watchdog generates a power-on reset to recover it.  Best regards, Julián

关于S32k144的pwm频率会周期变化的问题 我现在在开发nxp的s32k144遇到一个问题，我使用eb配置工具，我配置好了FTM0的四个通道输出，并且再代码中调用了PWM_Init();setdutycycle（8129）；我在配置中选择的是中心对齐模式，不启动死区，也不和别的通道绑定，并且周期设置的是0.00125，每个通道都是独立模式，得到的是250us，占空比20%的方波，这显然不对，我希望是25%才对，所以我后面换了一下占空比为setdutycycle（16339），但是这个得到的结果是波形不对，通道变成了由150us周期66占空比的方波和100us周期为50占空比的方波交替出现，请问这是为什么？这是我的实际波形； 事实上可以看出我这里有两个问题：1、为什么我的pwm占空比设置会有偏差；2、为什么我的pwm周期在不断地变化？ Re: 关于S32k144的pwm频率会周期变化的问题 Hi 请告诉我你测试的是哪个版本的Real-Time Drivers for S32K1还是之前哪个版本的AUTOSAR MCAL for S32K1 devices? 请注意，MPC5xxx 和 S32K1xx 器件的 MCAL 已停止支持。如需进一步支持，需经市场团队批准，请联系您的恩智浦销售人员寻求帮助。 Best Regards, Robin Re: 关于S32k144的pwm频率会周期变化的问题 我不清楚你使用的哪个版本软件，但需要注意设置Loading Point，参考以下两个讨论： Changing FTM_PWM period and duty cycle S32K116 PWM输出问题

I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error Hi NXP Team, We are trying to flash an i.MX93 board using a .wic image file provided by our team. We have two i.MX93 boards with the same hardware revision (SCH-96411 REV_B2). On one board, we are able to successfully flash the .wic image. However, when attempting to flash the same image on the second board, we encounter an error. We have tested both: emmc_all (for eMMC flashing) sd_all (using an SD card) In both cases, the same issue occurs on the second board. We would appreciate your support in troubleshooting and resolving this issue. Please let us know if you need any additional logs, error messages, or board information. Providing both uuu command and debugProviding both uuu command and debugProviding both uuu command and debugProviding both uuu command and debug uuu supported listuuu supported listuuu supported listuuu supported list i.mx93 usb identifiedi.mx93 usb identifiedi.mx93 usb identifiedi.mx93 usb identified Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error Hi, Thank you for your interest in NXP Semiconductor products, It's good to have schematic identification, I would recommend confirming i.MX 93 top marking though. Confirm that they share TOP marking. Please download latest prebuilt image release from Linux. Finally, you are trying to flash both of them in serial download and do they have any fuses blown? Regards Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error Hi Please find the attached images. We noticed some changes in the IC part numbers. We also tried flashing the SD card externally and then inserting it into the i.MX93 board, but we are still encountering the same issue. Additionally, we would like to bring to your attention that an image is already present in the eMMC, and the board is able to boot successfully from it. However, when we attempt to flash a new image, we encounter errors. Please find the attached debug logs below. One observation is that the preloaded image that came with the board is showing U-Boot SPL 2025.04, whereas the image we are attempting to use shows U-Boot SPL 2024.04. We downloaded the latest Linux 6.18.20_2.0.0 (i.MX93 EVK, FRDM) release. However, we could only find the 14x14 EVK WIC image and were unable to locate an 11x11 FRDM WIC image package. Could you please confirm whether the 14x14 image is the correct one to use for our board, or if there is a separate 11x11 FRDM image available? SD Card Boot: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok eMMC Boot: U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot Trying to boot from BOOTROM Boot Stage: Primary boot image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from 0x57800 by ROM_API NOTICE: TRDC init done NOTICE: BL31: v2.12.0(release):lf-6.18.2-1.0.0 NOTICE: BL31: Built : 07:53:18, Feb 10 2026 /****************************************************/ Regarding the fuse being blown, could you please let us know how we can verify whether the fuses have been programmed or blown on the board? Thank you. Issue board - imx93Issue board - imx93Issue board - imx93 Working board - imx93Working board - imx93Working board - imx93 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error I've got similar issues and per my understanding, the Chinese manufacturer who is behind FRDM series changed DDR RAM IC. This requires re-training DDR and update to u-boot, which was done for the board software, committed to nxp's u-boot repo, but the BSPs, Yocto layers and binary images on web site wasn't updated. Basically newer boards work with built-in u-boot only, everything your developers build with BSPs (and u-boot from 2024) will not even start due to invalid ddr configuration. You could confirm this issue by booting from board's u-boot, stop it using keyboard and then manually load your custom linux kernel and DT from the SD card.

How to integrate the BLE and Classic Bluetooth for dual-mode operation Hi Team, I am using: MCU: i.MX RT1176 EVKB WiFi/Bluetooth module: Murata IW416 I want to add the BLE wireless_uart_cm7 service into the handsfree_ag_cm7 application so that the application supports both: - Bluetooth Classic (HFP AG) - BLE GATT (Wireless UART) In BT_features.h, I noticed that: #ifndef CFG_CLASSIC #define BT_LE #endif Since CFG_CLASSIC is defined in the project preprocessor, BT_LE is never defined. What is the recommended method to build a dual-mode (Classic + BLE) application using the EdgeFast Bluetooth stack? Should CFG_CLASSIC be removed, or is there another project configuration or build option intended for dual-mode applications? Is there any examples or application notes demonstrating how to merge handsfree_ag_cm7 with wireless_uart_cm7? MCXA Re: How to integrate the BLE and Classic Bluetooth for dual-mode operation Dear @Karthick_KL , Your integration direction is correct. Since HFP AG is the main application, `handsfree_ag_cm7` should remain the base project, and the BLE Wireless UART GATT service should be added into this project. `CFG_CLASSIC` should not be removed, because it is required by the Bluetooth Classic HFP AG profile. The issue is more likely caused by the sample project feature selection logic in `BT_features.h`: #ifndef CFG_CLASSIC #define BT_LE #endif This logic makes `BT_LE` enabled only for non-Classic example projects. It is suitable for single-feature SDK examples, but it is not sufficient for a custom dual-mode application. For a dual-mode application, the project should keep the Classic/HFP AG configuration enabled and explicitly enable the BLE host/GATT configuration as well. In other words, the dual-mode project should build both the Classic path and the LE path. A possible direction is to introduce a project-level dual-mode or BLE macro, for example `CFG_BLE` or `CFG_DUAL_MODE`, and update the feature selection so that `BT_LE` can be enabled even when `CFG_CLASSIC` is also defined. For example: #if defined(CFG_BLE) || defined(CFG_DUAL_MODE) || !defined(CFG_CLASSIC) #define BT_LE #endif Then merge only the Wireless UART BLE service, advertising data, GATT callbacks, and BLE connection handling into the `handsfree_ag_cm7` application. The Bluetooth stack initialization should remain single-instance, and the HFP AG Classic path should remain unchanged. We are not aware of a ready-to-use public SDK example or application note that directly merges `handsfree_ag_cm7` with `wireless_uart_cm7`. The available public examples demonstrate `handsfree_ag` and `wireless_uart` separately, so this should be treated as a custom dual-mode application integration. Thanks! Regards, Weidong Hi , Thank you for your reply to my previous post. Follow... Hi @weidong_sun, Thank you for your reply to my previous post. Following your suggestion, I integrated both BLE and Bluetooth Classic by modifying the macro in BT_features.h #if defined(CFG_BLE) || defined(CFG_DUAL_MODE) || !defined(CFG_CLASSIC) #define BT_LE #endif And I have added the stack for both classic and ble. Now it is working correctly. Karthick_KL_0-1786113084956.png I have now integrated Wi-Fi with the BT/BLE application using the evkbmimxrt1170_wifi_wpa_supplicant_cm7 example. The Wi-Fi is used to establish a Wi-Fi Direct (P2P) connection, while audio is streamed over the HFP interface. However, I am facing an issue with Wi-Fi Direct connection during audio streaming. If I establish the Wi-Fi Direct connection before starting HFP audio streaming, the connection is successful. But if I attempt to establish the Wi-Fi Direct connection while HFP audio is streaming, the Wi-Fi Direct connection fails. The terminal output is shown below: p2p_connect start ok! P2P-GO-NEG-SUCCESS role=client freq=5240 ht40=0 peer_dev=72:1a:2e:a3:f8:17 peer_iface=72:1a:2e:a3:f8:17 wps_method=PBC wf3: WPS-PBC-ACTIVE wf3: SME: Trying to authenticate with 72:1a:2e:a3:f8:17 (SSID='DIRECT-69-Realme Narzo N55' freq=5240 MHz) wf3: Trying to associate with 72:1a:2e:a3:f8:17 (SSID='DIRECT-69-Realme Narzo N55' freq=5240 MHz) wf3: Associated with 72:1a:2e:a3:f8:17 wf3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wf3: CTRL-EVENT-EAP-STARTED EAP authentication started wf3: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=14122 method=1 wf3: CTRL-EVENT-EAP-METHOD EAP vendor 14122 method 1 (WSC) selected P2P-GROUP-FORMATION-FAILURE wf3: CTRL-EVENT-DISCONNECTED bssid=72:1a:2e:a3:f8:17 reason=3 locally_generated=1 wf3: CTRL-EVENT-DSCP-POLICY clear_all P2P-GROUP-REMOVED wf3 client reason=FORMATION_FAILED I would like to know if there is a way to resolve this coexistence issue without completely disabling Bluetooth or is there any other configuration I need to do to handle this issue? Thank you!   Re: Hi , Thank you for your reply to my previous post. Follow... Dear @Karthick_KL , Thank you for the detailed information. Based on the behavior you described, this appears to be related to the Wi-Fi/Bluetooth coexistence policy rather than a Bluetooth Classic/BLE integration issue. In the coexistence algorithm, HFP audio (SCO/eSCO) traffic is assigned a very high priority to maintain voice quality. As a result, if a Wi-Fi Direct (P2P) connection attempt is initiated while HFP audio streaming is already active, the P2P group formation procedure may fail during the authentication/WPS phase. This observation is consistent with your test results: P2P Connection --> HFP Audio Streaming : OK HFP Audio Streaming --> P2P Connection : May Fail   Therefore, the recommended sequence is to establish the Wi-Fi Direct (P2P) connection first and then start the HFP audio connection/streaming. Based on the current logs, the observed authentication/group formation failure during active HFP audio streaming is an expected coexistence behavior rather than a Bluetooth stack issue. Thanks! Regards, Weidong Re: Hi , Thank you for your reply to my previous post. Follow... Hello @weidong_sun Thank you for your detailed explanation and support. It was very helpful.

#S32K388 S32K388 LPI2C will stop when debug mode is entered When using lpi2c, I encountered a situation where the program got stuck in debug mode. However, when I disconnected the PE connection and restarted the program, it worked properly. The program got stuck in debug mode during runtime. do { /* Master send data */ Lpi2c_Ip_MasterSend(Instance); ElapsedTicks += OsIf_GetElapsed(&CurrentTicks, I2C_TIMEOUT_TYPE); }while ((Lpi2c_Ip_MasterGetTransferStatus(Instance, NULL_PTR) == LPI2C_IP_BUSY_STATUS) && (ElapsedTicks < TimeoutTicks)); Is there any way to solve this problem? Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered Hi @zhangyu5454  Could you please check if the I2C Debug Enable option is selected? When MCR[DBGEN] = 1, the LPI2C module continues to work while the MCU is being debugged. When MCR[DBGEN] = 0, after programming the application and running the board normally (without a debugger attached), the LPI2C should work as expected. BR, VaneB Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered Hi @zhangyu5454  I have included the image below for reference: VaneB_0-1786396779346.png Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered Thanks for your reply.I use .mex to configure i2c, how can I set it to control MCR[DBGEN] =1 Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered Hi @zhangyu5454  This option has been added to the latest RTD release and can now be configured directly through the Peripherals Tool.  As you are using an earlier RTD version, configuring MCR[DBGEN] in the application code would be the recommended approach. Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered zhangyu5454_0-1786418199524.png I noticed that our pages display differently, I couldn't find this option, note that my version is RTD5.0

IMX95 bootcount managment Hi, I've been working recently on the imx95 19x19 EVK board and i'm interested in implementing a bootcount management mechanism for our distro update/recovery.  Looking in the TRM, i found out that the GPRs (General Purpose Registers) are in the BBNSM and are accessible via the SCMI protocol (requests to the SM running on the M33). In u-boot, scmi_get_bbnsm_gpr() and scmi_set_bbnsm_gpr() APIs are kindly provided (in arch/arm/mach-imx/imx9/scmi/soc.c) and i was able to implement my bootcount_store()/_load() without issues. However, in the kernel, no such APIs exist ! (I would want to reset the bootcount from Linux user-space after a successful boot.) Additionally, i came across the Cyber Resilient Recovery Module (CRRM) in your documentation, and now i'm questioning even if there is the need at all to self-manage a bootcount for distro updates. So I have the following questions for you: Why there is no support for SCMI APIs for GPR access in the kernel ? is it because the CRRM uses one of the GPRs ? With CRRM, does it make sense to have a bootcount for managing distro updates ? if yes, where do you recommend storing the bootcount other than GPR ? (or what other ways are available to access the GPRs) Any answer, is very well appreciated. SoC: i.MX 95 (19x19 LPDDR5 EVK) BSP: LF6.18.20_2.0.0 Thank you, Abder Re: IMX95 bootcount managment Hi @Chavira  Thank you for the valuable clarifications. Ok for using GPRs then, but will be there any official driver from NXP on the kernel side to add GPR access ? I can see in the kernel source under drivers/firmware/arm_scmi/vendors/imx that imx-sm-bbm.c defines the GPR commands but doesn't implement them !! enum scmi_imx_bbm_protocol_cmd { IMX_BBM_GPR_SET = 0x3, IMX_BBM_GPR_GET = 0x4, IMX_BBM_RTC_ATTRIBUTES = 0x5, IMX_BBM_RTC_TIME_SET = 0x6, IMX_BBM_RTC_TIME_GET = 0x7, IMX_BBM_RTC_ALARM_SET = 0x8, IMX_BBM_BUTTON_GET = 0x9, IMX_BBM_RTC_NOTIFY = 0xA, IMX_BBM_BUTTON_NOTIFY = 0xB, };   Is there any reason behind this decision i.e., implementing all the listed cmds but the GPR ones ? I prefer to align with NXP's intended approach here before relying on any custom implementation.   Best regards, Abder Re: IMX95 bootcount managment HI @Abder, Thank you for the detailed investigation. In simple terms, CRRM and ROM recovery do not replace a bootcount mechanism. They help recover from corrupted or invalid boot images, but they cannot determine whether Linux or your application has booted successfully. For OTA update solutions, a bootcount is still recommended to detect failed updates and perform automatic rollback. Regarding the BBNSM GPRs, U-Boot provides access through NXP-specific SCMI functions, but Linux currently does not expose an equivalent interface. If you need Linux access to these registers, a custom kernel driver or SCMI vendor extension would likely be required. For your use case, our recommendation is to continue using BBNSM GPRs for bootcount storage if they are already working in U-Boot. CRRM recovery and bootcount management serve different purposes and should be considered complementary mechanisms rather than alternatives. Best regards, Chavira Re: IMX95 bootcount managment HIi @Abder, Thank you for pointing this out. Your observation is correct. The IMX_BBM_GPR_SET and IMX_BBM_GPR_GET commands are defined in the BBM protocol specification, meaning the firmware supports access to the General Purpose Registers (GPRs). However, the current Linux imx-sm-bbm driver does not implement support for these commands. At present, the driver only exposes RTC and button-related functionality, as these integrate directly with existing Linux subsystems (RTC and input frameworks). Although GPR access is not yet available through the upstream driver, the driver already retrieves and stores information about the number of available GPRs during initialization. This indicates that the underlying infrastructure is partially in place and that GPR support was considered during the driver design. However, there is currently no official kernel interface or released driver implementation that exposes these registers to user space. Best Regards, Chavira

Example code for K344 & FS26 with MCAL component Sbc_fs26 and OS component freeRTOS Hello, Can you provide a S32K344 & FS26 chips source code example (S32DS project) that integrates the Sbc_fs26 and freeRTOS components? I am aware that there are individual RTD examples: 1)  Sbc_fs26_example_HLD_S32K344  (no freeRTOS) 2) FreeRTOS_Toggle_Led_Example_S32K344 (no Sbc_fs26) and also an example: 3) MR_CANHUBK3_IEEE1722 in which the watchdog is disabled and the Sbc_fs26 component is not used  Essentially I'm looking for a basic source code example for properly setting and refreshing a FS26 chip in a freeRTOS environment. Thank you. Re: Example code for K344 & FS26 with MCAL component Sbc_fs26 and OS component freeRTOS Hello Slavko, At the moment, I am not aware of an example project combining these components.   The examples you mentioned are the relevant reference points: - Sbc_fs26_example_HLD_S32K344 This demonstrates the FS26/SBC integration, but it does not use FreeRTOS. - FreeRTOS_Toggle_Led_Example_S32K344 This demonstrates a basic FreeRTOS setup on S32K344, but it does not include the FS26 SBC component. - MR_CANHUBK3_IEEE1722 This includes a broader system-level implementation, but the FS26 watchdog is disabled and the Sbc_fs26 component is not used. For your use case, the practical approach would be to start from the Sbc_fs26_example_HLD_S32K344 project and then integrate the FreeRTOS configuration from the FreeRTOS example. The FS26 initialization should remain part of the system startup sequence, while the watchdog refresh should be handled periodically from a FreeRTOS task or another deterministic timing mechanism.   BRs, Tomas

I.MX93 boot waiting for known usb device Bought IMX93 from Mouser  for NXPLinux summer school program, I used there the automated script to boot the board,  ./scripts/ loss.py boot command . After executing the command I keep getting waiting  for known usb device. Will appreciate all the help to enable me progress Ias am stuck . FRDM-i.MX93  Re: I.MX93 boot waiting for known usb device @Fidelbanks thanks a lot for your interest in i.MX FRDM board. I think your problem is similar with  https://community.nxp.com/t5/i-MX-Processors/I-MX93-UUU-emmc-sdcard-LIBUSB-ERROR-TIMEOUT-Error/td-p/2402801 @pengyong_zhang Linux kernel summer school is a project that wants to help people getting started with learning linux kernel by using the i.MX93 frdm board.  https://nxp-research.github.io/lkss-main/2026/about.html#getting-started We provided a script that helps users boot the board using the serial download mode Re: I.MX93 boot waiting for known usb device Hi @Fidelbanks  What project are you referring to? If you want to get started with the development board, you can directly use the demo image from the NPX website. I'm not familiar with how your summer school program is implemented. B.R