External Data Abort when calling Clock_Ip_Init() Hi there, I'm attempting to initialise some peripheral clocks using the RTD and S32 DS mex tool. (Note im generating the code in a M7 project, but actually building and running for a A53 project) However, an external data abort occurs inside Clock_Ip_Init(). Specifically, the call stack looks like this: Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref(). This appears to be the first attempt to actually write to the CMU peripheral memory. The fault occurs on a LDR instruction on memory 0x4005'C028 which according the S32G3 memory map correctly resides within the CMU memory area. At this stage, the MMU is not enabled, but my understanding is an external data abort occurs outside the CPU/MMU and is probably linked to secure access or a "locked" peripheral. Am i right in saying the CMU needs to be made "accessible" from the A53 core in some manner prior calling Clock_Ip_Init()? If so, could you advise on the steps to do so? Best regards, Jonny Device = S32G399A Compiler = S32DS_GCC _11_4 Core = Cortex A53 Re: External Data Abort when calling Clock_Ip_Init() Hi，jonnyWHIS Thank you for contacting us. Do you intend to create bare-metal code running on the S32G A53 core in the S32DS IDE? BR Joey

Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor Hi, I have a T2081 NXP processor connected to an external NAND Flash MT29F64G08AECAB via IFC. My goal is to run diagnostic test on this NAND Flash on code warrior or simply read the device and manufacturer ID of this device on Code Warrior (for which I have written the code). To achieve this goal, I have done the following already: 1. Configured LAW for the NAND IFC in the generated T2081QDS_init_core.tcl starting from 0xFF800000 and of size 1MB.  ## LAW3 to IFC - NAND   # LAWBARH   mem [CCSR_ADDR 0x000C30] = 0x00000000   # LAWBARL   mem [CCSR_ADDR 0x000C34] = 0xFF800000   # LAWAR   mem [CCSR_ADDR 0x000C38] = 0x81F00013 2. Also have configured the CSPR and FTIM registers corresponding to NAND like below : set NAND_CS   5 # NAND Flash, addr 0xFF800000, 1MB size, 8-bit NAND, ECC disable   # CSPR_EXT   mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000   # CSPR   mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103   # AMASK   mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000   # CSOR   mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100   # IFC_FTIM0   mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507   # IFC_FTIM1   mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B   # IFC_FTIM2   mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819   # IFC_FTIM3   mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 Note that there are 2 chip selects (CS5 and CS6) going from the processor to NAND and for the time being I am trying to access the first 4GB and hence configuring CS5 only. 3. Configured TLB: fine   1M TLB entry  5 : 0xFF800000 - 0xFF8FFFFF for NAND   cache-inhibited, guarded   reg ${CAM_GROUP}L2MMU_CAM5  = 0x5000000A1C08000000000000FF80000000000000FF800001 4. And since the device support for this MT29F64G08AECAB could not be found in the installed directory, I followed the manual and created a .xml for this device (for 4GB) which I have attached here. After doing all of this, when I run the diagnostic test for the NAND device on code warrior, I get the below error: Nisarga_R_0-1786096350786.pngNisarga_R_0-1786096350786.png As an alternative I tried to write a simple C code to read back the device id from this device. So I wrote the below code in code warrior and I have attached it here. And as a result when I read back the IFC_NAND_MDR register I get back 0x124E0000 which is not matching with the Device ID. I would like to know if I am doing something wrong or missing out something because I am unable to run the diagnostic test or read back the device id. I have attached the respective T2081QDS_init_core.tcl and also the respective schematics for reference. Regards, Nisarga R   QorIQ T2 Devices Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor I am discussing with the internal team now. Thanks Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor Your NAND flash hardware connections appear to be aligned with the recommended design guidelines, assuming RCW[IFC_GRP_E2_BASE] = 0 and the NAND device is not being used as the boot source. Having said that, what Device ID value are you expecting to read back from the IFC_NAND_MDR register? We have never tried and tested with dual-die NAND devices and are not sure about its operation.  Based on our experience with the single die NAND flash devices, please check the following and share the results with us for further investigation. 1) Share the complete IFC register dump if possbile 2) Share the IFC interface pin-mux configuration. 3) If there is any update of the Codewarrior debug, please also let me know. 4) Please refer the below sections of RM and verify if your NAND flash implementation aligns with the information documented therein:  a) 13.2 External signal descriptions b) 13.5 NAND flash control machine c) 13.9 Initialization/Application information Thanks

SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) I am reporting a bug in S32K3 Safety Peripheral Drivers (SPD) version 1.0.3, specifically in the eMcem module's XDM configuration file which prevents it from being imported into Elektrobit (EB) Tresos Studio. Environment ┌───────────────────┬─────────────────────────────────────────┐ │ Item │ Version / Path │ ├───────────────────┼─────────────────────────────────────────┤ │ MCU │ S32K344 (S32K3XX) │ ├───────────────────┼─────────────────────────────────────────┤ │ SPD │ S32K3_SPD 1.0.3 (S32K3_SAF_1.0.3_D2306) │ ├───────────────────┼─────────────────────────────────────────┤ │ RTD │ SW32K3_RTD 4.4 R21-11 3.0.0 P01 │ ├───────────────────┼─────────────────────────────────────────┤ │ EB Tresos │ 29.0.0 (installed at C:\EB\tresos) │ ├───────────────────┼─────────────────────────────────────────┤ │ S32 Design Studio │ 3.6.0 │ └───────────────────┴─────────────────────────────────────────┘ Issue Description When attempting to import the eMcem module (eMcem_TS_T40D34M10I3R0) into an EB Tresos project, the XDM parser throws the following error: ▎ "Invalid Attribute 'a' for tag 'a'" at line 717 of config/eMcem.xdm This prevents the eMcem module from being imported into any EB Tresos project entirely. Root Cause Analysis The file C:\NXP\S32K3_SPD_1.0.3\eclipse\plugins\eMcem_TS_T40D34M10I3R0\config\eMcem.xdm contains an invalid XDM schema structure at lines 715–718,in the RecoveryTimeoutEnabled parameter block: Buggy code (lines 715–718): VariantPreCompile The problem is the nested inside the element. According to the XDM schema (http://www.tresos.de/_projects/DataModel2/08/attribute.xsd), an element cannot contain another element as a child. The correct structure used by all other occurrences in the same file (e.g., the ReactionType parameter at lines 684–687)is: Correct code: VariantPreCompile This is the only occurrence of this malformed nesting in the entire eMcem.xdm file (20+ other IMPLEMENTATIONCONFIGCLASS blocks are correctly formed). It is clearly a copy-paste error during the SPD packaging process. Verification - The Bist module (Bist_TS_T40D34M10I3R0) and SafetyBase module (SafetyBase_TS_T40D34M10I3R0) from the same SPD 1.0.3 package do not have this bug —their .xdm files are correctly structured and import into EB Tresos without any errors. - I confirmed that the Bist.xdm file has zero occurrences of nested inside . Why This Is a Deadlock The META-INF/CRYPTOMANIFEST.MF and META-INF/CRYPTOMANIFESTSIG.MF files in the eMcem plugin contain DSA cryptographic signatures (Key ID: Freescale, Provider: dreisoft.tresos.launcher2.CryptoKeyProvider) for key plugin files including config/eMcem.xdm. Any modification to the .xdm file —even a single-line fix —breaks the DSA signature verification, causing EB Tresos to reject the module with a license/integrity error. This creates an irrecoverable deadlock: - Cannot import with the bug —XDM schema validation fails - Cannot fix the bug —DSA signature verification fails →license error - Cannot remove the signatures —EB Tresos fails to start (plugin integrity check) Request Please provide one of the following: 1. A hotfix release of SPD (or at minimum, a corrected eMcem.xdm file with updated CRYPTOMANIFEST signatures) compatible with our environment 2. An updated SPD version (e.g., 1.0.4 or newer) that includes this fix 3. A license re-activation or workaround that allows us to apply the necessary one-line fix to eMcem.xdm without triggering the DSA signature validation failure 4. Confirmation of whether a newer SPD version exists that resolves this issue, along with download/upgrade instructions This issue is blocking our S32K344 safety software integration, specifically the eMcem (Extended Microcontroller Error Manager) module configuration in EB Tresos. Additional Note The SPD 1.0.3 Release Notes state compatibility with RTD 3.0.0 / 3.0.0 P07. We are using RTD 4.4 (SW32K3_RTD_4.4_R21-11_3.0.0_P01). Could you also confirm the compatibility status between SPD 1.0.3 and RTD 4.4, and advise if a newer SPD version is required for RTD 4.x integration? --- Thank you for your assistance. Please let me know if you need any additional information or logs. Best regards. Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) Hello @WuDiDi, The issue is also present in SPD 1.0.4. I can see that it has been fixed in SPD 1.0.5 and SPD 1.0.6: danielmartynek_0-1786090704875.png SPD version 1.0.5 is compatible with S32K3_S32M27x Real-Time Drivers ASR R21-11 Version 5.0.0 and 4.0.0. Version 4.0.0 is supported for all derivatives except S32K3E ones (S32K39x and S32K36x). SPD version 1.0.6 is compatible with S32K3 Real-Time Drivers Version 7.0.0 + 6.0.0. Could you update to a newer RTD/SPD version? Many RTD, SPD bug has been fixed since version 1.0.3. Please note that NXP does not provide hotfixes for outdated software versions. Regarding SPD 1.0.3 compatibility, we can only guarantee functionality with the RTD version explicitly specified in the release notes. Compatibility with other RTD versions is not guaranteed. Regards, Daniel Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) Hi Daniel, Thank you for the clarification. I am already using SPD 1.0.5 (D2503) with RTD 4.0.0 P01 for S32K342, so the version compatibility should be fine. I have a specific question about implementation scope: the SPD 1.0.5 Demo project (S32_SPD_Demo) only provides TresosProject configurations for S32K344/S32K358/S32K388/S32K396, not S32K342. I am adapting it to S32K342. Could you confirm the following for S32K342: 1. Lockstep fault injection: Does S32K342 support lockstep fault injection via the DCM/EIM mechanism? The S32K342 is a single-core lockstep device —I see EMCEM_DCM_NCF_3_LC_ERR and EMCEM_DCM_NCF_0_PLTFRM_CM7_0_LUP in the DCM fault list. Are those the correct injection points? 2. LBIST/MBIST: The Bist_TS_T40D34M10I5R0 plugin has S32K342 EPD variants. Are the LBIST MISR golden signatures and MBIST partition tables in Bist_SpecificTables_S32K3XX.c already correct for S32K342 silicon? Do we need any S32K342-specific adjustments? 3. Is there an application note or reference manual specifically for S32K342 safety verification (LBIST/MBIST/lockstep FI) that you can share? Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) Hi @WuDiDi, The follow-up questions are not related to the original topic. Could you please create a new thread for them? Thank you. BR, Daniel

GUI Guider 2.0 图片存储类型选择Flash,无法显示 Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 嗨@sk-l 请 您 提供 更 详细 的 问题 描述 ？It would be very helpful if you could also attach screenshots or relevant pictures for 参考，引用.   谢谢。   BR 哈里 Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 skl_2-1786613588252.png skl_0-1786612933574.png skl_1-1786612993765.png 图片/动画图片 颜色格式 I4，存储类型 Flash，模拟期间不显示； 颜色格式 I4，存储类型 C 数组，图像显示正常；

需要S32DS的激活码 s32ds 安装的激活码 需要签署NDA 需要用到公司邮箱 没有公司邮箱 请确认下 怎么申请 Re: 需要S32DS的激活码 你好， 你喜欢用哪个版本的S32DS？

FS32K144UAT0VLLT哪个Time具备Input capture功能？ 经理： 请教问题： （1）FS32K144UAT0VLLT规格书显示具备8个独立TIME，只看到FTM0，FTM1，FTM2，还有哪些也是TIME？ （2）FS32K144UAT0VLLT的哪个TIME具备Input capture功能？ 谢谢！ Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Robin_Shen 你好，补充问题： 1. S32K-RM Rev14.2的Table 47-1. FTM instances and features 表格里，“Fault inputs"是什么参数？ 2. S32K-RM Rev14.2手册多少页显示每个FTM都具备input capture功能？ 谢谢！ Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ A1. 就是支持几路外部Fault输入，以S32K144为例Table 47-1写了支持4路，你可以在左侧表格看到FTM0_FLT0\1\2\3 这4路。 Table 47-1. FTM instances and features Table 47-2. FTM signal descriptions.png A2. 每个FTM都支持的功能，通常不会特地写出来。你按照Table 47-5. Channel Modes Selection配置寄存器就能实现47.5.5 Input Capture Mode 提到的input capture 模式了。

PCA9615 I am writing to ask for help with the circuits at either end of dI2C communication - between two PCBs across a twisted wire bundle (DSDAP & DSDAM; DSCLP &  DSCLM; two GND; and two 5V lines). Leading up to this I decided to test Gemini so I regretably relied on AI to generate the parts of the two PCBs that related to the dI2C comms. Attached are the parts of the schematics associated with the dI2C. Unsuprisingly there is no comms between the boards, but my laziness and I have to say stupidity (leason learnt) has cost me a lot of time. I finally referred to the datasheet and the user manual for the demo board and one obvious difference is that there are 600 Ohm resistors between the positive lines (DSCLP and DSDAP) and VDD(B), the same from the negative lines (DSCLM and DSDAM) and VSS, and 120 Ohms between the respective positive and negative lines which apparently result in 100 Ohms between the positive and negative lines (I know that 1/600 + 1/120 = 1/600 + 5/600 = 100, but I can't see it electrically- maybe because I'm a mechanical engineer ??). Is the error (maybe one of a number of errors) caused by not having what may be considered a 600 Ohm pull up resistor, a 600 Ohm pull down resistor and a 120 Ohm resistor between the respective pair of wries (characteristic impedance of a 28 AWG twisted wire pair is about 100 Ohms cabling used in internal data links and USB/Ethernet configurations and 78 Ω to 95 Ω for standard spacing configurations using PVC or FEP insulated wires), but instead a simplified and likely erroneous version of just a single 100 Ohm resitor at either end of the connecting wire on the dI2C side of the PCA9615?  That is one significant difference between what AI gave me and what I see in Figs 1, 7, 8 and 9 of the datasheet. Another difference is that AI suggested different capacitor arrangements for the two PCBs whereas there's only one type of arrangement on the demo board (which I assume gets used on both sides of the dI2C connecting line). Further, there appears to be two capacitors for each of the VDDA pin and the VDDB pin - both ceramic capacitors (although my first thought was that the two yellow capacitors would have been tantalum type). Can I use the capacitor arrangement provided in the demo user manual and ignore what AI provided and shown in the attached? Another issue is that on the master side (on which I am using a 3.3V microcontroller) originally Ai instructed that the enable pin be conencted to the 5V line, but after having had the boards made, the lack of any function across the two boards in part prompted the AI to determined that the enable pin on the master side should have been connected to the 3.3V line (VDD(A) on the master board was connected to the 3.3V line). It then requested that all all supply to the enable pin on the master PCB be cut completely as a test. Can you please advise what supply, if any all, should be channeled to the EN pin? I will not be hot swapping any electrical hardware during test or final operation. I am considering implementing the above changes, but would really appreciate your help before I proceed further with costly boards. Re: PCA9615 Just a further thing regarding the capacitors, only decoupling capacitors were suggested for both VDDA and VDDB pins on the master PCB. Decoupling capacitors were also suggested for the slave PCB, but two additional capacitors were also suggested for the VDDB pin on slave PCB.  Re: PCA9615 Hello! Thank you for the detailed explanation. Please note that NXP provides an evaluation board for the PCA9615 family that can be used as a reference design for your implementation. We strongly recommend comparing your schematic against the PCA9615 evaluation board and its associated user manual, as the design includes the recommended differential I²C termination network, biasing resistors, decoupling capacitors, and EN pin connections that have been validated by NXP. Using the evaluation board schematic as a baseline is often the best approach when designing a custom PCA9615-based system, as it minimizes the risk of configuration or layout issues and follows the recommendations provided in the datasheet and application documentation. We suggest reviewing the evaluation board schematic and updating your design accordingly before committing to another PCB revision. https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL Hope this helps!

Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compile Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compile. In the past, my project used S32DS V2.2 and SDK RTM 2.0.0. Now, after reinstallation, I am using S32DS.ARM.2018.R1 and have also installed SDK RTM 2.0.0. But now I can't compile the project. It seems that it can't recognize the project itself. You can see the details in the picture. Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi Hi @yangcao1234  Please note that S32K1 SDK RTM 2.0.0 was released specifically for S32DS for ARM 2018.R1 Update 6. It was not intended to be used with S32DS for ARM 2.2, and compatibility with that version is not guaranteed. BR, VaneB

SL3S1206FUD2/HA Request for Good Die identification documentation / Wafer Map Dear Supplier, We would like to confirm whether you have provided any documentation or markings that distinguish “Good Die” from “NG Die” on the wafer. Specifically, we are looking for: A wafer map (indicating which die passed/failed testing), A test result report, or Physical markings on the wafer surface (e.g., ink dots, laser marks) that clearly identify usable die. After inspecting the wafer under our microscope, we could not find any visible physical markings. This raises concerns that we may not be able to reliably differentiate good die from defective die. Could you please help check whether such information was included with the shipment, or assist us in obtaining these materials from the manufacturer? We need this data for our subsequent processing steps. Thank you for your kind assistance. We look forward to your reply.

EasyEVSE 1060 to sigbrd2x interface issues This is a follow up to this post: https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 Short synopsis: I have a RT1060EVKB/Sigbrd2x EVSE, and a RT1064/Sigbrd2x EV running v5.0.8 software that I’m trying to stand up.  This was originally posted as a response to the question above, but I wasn’t sure whether the tech reps followed up on the thread responses. Thank you for your response.  I'm back working on this and am having issues getting EVSE code v5.0.8 that I got from NXP’s Git to work.  It builds fine and displays the GUI, but when I try to use its debug interface and request the version information, I get a correct response for the 1060 code of 5.0.8, but the version of the sigbrd2x shows as hw: v 255, and sw: v255.255.0.  I seem to recall reading a post somewhere that said there was some issue with a communications conflict with the LCD display on the 1060 board.  I can program the sigbrd2x and step code, so I'm pretty confident that that side is executing.  I'm using the EVSE-RT106X-CBL rather than the arduino headers.  My primary symptoms (besides the EV and EVSE sides not talking to each other) are the version reporting above that seems suspect, and I can't get past the "firmware download" status on the EVSE LCD, and the EVSE code on the 1060 won't start if the sigbrd2x is powered up (I'm powering them separately).  It feels like a communications issue.  Is there a patch / workaround for this?  If so, can you point me to documentation on how to resolve it? Best Regards, Chris Edwards Re: EasyEVSE 1060 to sigbrd2x interface issues Hi @chrisedwards , Thanks for your interest in NXP MIMXRT series! It seems the RT1060 is reading an idle/pulled-up SPI bus and getting no valid data back. This means the RT1060 ↔ Sigbrd2x SPI link never established — which also explains why the EVSE stays at "firmware download" and why the two sides don't talk. Suggested steps: - Scope the SPI lines (SCK/MOSI/MISO/CS). If MISO stays high, the board isn't responding → confirms the 0xFF. - Check the EVSE-RT106X-CBL wiring against the connector pinout in the signal-board manual — verify all SPI lines + GPIO are connected correctly. - LCD vs. SPI pin conflict: Temporarily disable the LCD and re-read the version to isolate it. - Follow the power-up order in the user guide, or power the host first. Best regards, Gavin Re: EasyEVSE 1060 to sigbrd2x interface issues Hi Gavin, Check sigboard’s qspi flash:               Powering the boards separately, I don’t see any traffic on the SPI pins of U17 (which is where I believe the switch gets its firmware).  I do see traffic on these pins on U17 of my EV setup (physically different board).  Check sigboard’s host interface SPI:               I don’t see any traffic on the spi pins of the host connector (19,21,23,24) when I have the 1060 powered and then apply power to the sigbrd2x (with the 1060 and sigbrd powered separately), nor when I power the sigbrd via the cable that goes to J32, with J2&J3 appropriately set). From digging into the User Guide (UG10140): I noticed that LEDs D18, D21, and D33 never illuminate.  They do on the sigbrd2x I have in my EV setup.  D24 does not illuminate on either setup.  D19 blinks. End state of debugging steps, after disabling the GUI: Ok with the LCD disabled by setting ENABLE_EVSE_UI to 0 in EVSE_config.h, the 1060 boots while connected to the sigbrd2x, using the cable that powers the sigbrd from J32 on the 1060, I can get a version number for the sigboard hw ( v2), and the sigboard sw v1.2.0.  Still no traffic on sigboard’s U17 nor illumination on LEDs D18, D21, 24, or D33.  D19 blinks.  Still no activity on the SPI pins on the sigboard’s host connector. So… progress, but it feels like the switch is not coming up at all. The user’s guide implies that the LEDs indicate that the switch isn’t working. Thanks and Best Regards,               Chris

In standby mode, the pins of the S32K328 cannot output a high level I followed the configuration steps in the operation manual to configure some GPIO pins of the S32K328 to maintain a high level in standby mode, but it failed. Below is my configuration process. I did not perform the fourth step recommended in the manual. Does this have an impact? I have performed similar configurations on the S32K312 before without any errors. My understanding is that, since I did not disable the pin keep function after reset, even if I configure the GPIO pins to output a low level after wake‑up, the output pin level should still maintain the high level that was set before entering standby mode. Currently, in actual measurements, the several GPIO pins configured in both standby mode and run mode have remained at a low level. 6ABE3FCC-00F4-4165-B025-E31BB4B1BEBC.png de7ee9ab18af4cbe9fe5a0f4dbd21427.png Re: In standby mode, the pins of the S32K328 cannot output a high level Hi @hhggll23, I did not perform the fourth step recommended in the manual. Does this have an impact? Yes, it does. If you enable Pad Keeping before going to standby mode (write DCM_GPR->DCMRWF1[STANDBY_IO_CONFIG] = 0. Which is default register value no matter PKE of SIUL2 is set or not), but you did not disable it after wakeup, the SIUL2 module cannot be initialized again. If you don’t need the Pad Keeping function while the MCU needs to go to standby mode and wakeup, you need to write 1 to this bit anywhere and leave it alone. This is done through the Power_Ip_Init() API: Julin_AragnM_3-1786127814879.png Now, I/O pins retain their last set states in run mode during standby mode, regardless of Pad Keeping configuration. Since S32K3 will always perform a reset sequence after waking up, and since SIUL2 module resets the GPIO pads to its default state on a functional reset, pad keeping ensures that the pin can retain its state from wakeup until user unlock it. Julin_AragnM_0-1786126733106.png Julin_AragnM_4-1786128871517.png Are you trying to set all of the pins shown in the image to HIGH on Standby? Are all of them going LOW upon entering Standby? Or when exiting?  Best regards, Julián Re: In standby mode, the pins of the S32K328 cannot output a high level Thank you very much for your reply. I rechecked the program and found that after pulling the pins high before standby, an unintended routine ran that re‑initialized all GPIO pins, which caused the pins to remain at a low level during standby. After the modification, the GPIO pin levels have been successfully pulled high in standby mode. Now a new issue has arisen: after the GPIO pins are pulled high in standby mode, the standby current seems to have increased. Currently, under standby conditions, the quiescent current of the controller is about 3 mA with a 24 V supply. After troubleshooting other circuits, I suspect that the S32K328 consumes most of this current. At 24 V, 3 mA corresponds to about 14.4 mA when converted to the controller's 5 V supply. I have pulled high 8 GPIO pins in standby mode. Is this standby current normal? To address this issue, can I configure the GPIO pins of the S32K328 as high‑impedance in standby mode, so that an external pull‑up resistor can maintain the high level on the pins during standby?

GPIO Based on the S32K324 MCU, how to configure a GPIO to high‑impedance state using S32DS. Re: GPIO Hi Please refer to previous similar discussions: S32K3 GPIO HIGH-Z If the pin may have previously enabled internal pull, in order to satisfy the tristate definition in S32K3XXRM, Siul2_Port_Ip_SetPullSel(..., PORT_INTERNAL_PULL_NOT_ENABLED) should be called to ensure PUE=0; Best Regards, Robin

Query Regarding PCA9450CHN Voltage Configuration Through I2C We are using the PCA9450CHN PMIC and understand that it powers up with default regulator voltages, which can be modified through I2C programming. Could you please explain the complete sequence for changing these voltages after power-on, including when the SoC starts communicating with the PMIC? Also, please let us know the recommended debugger or tools to monitor and verify the PMIC register programming and voltage changes. Board Design HW-Open-Source Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png You can refer to above after the POR_B signal pull high and the PCA9450C enter into RUN mode you can change its power rails output value.

S32K566 LPUART Communication Issue Hi, I am using the Uart_Example_S32K566_M7 module on the S32K566 microcontroller with an LPUART module clock of 50 MHz. I configured the baud rate to 115200 and am sending 0xAA data to the PC using a UART-to-USB converter. However, the received data is incorrect (0x00 0x80 0x80). When I configure the baud rate to 115200/8 = 14400, the data is received correctly. I also tried different baud rates such as 9600 and 19200. I am using S32DS 3.6.6 and SDK 0.8.0. Uart_Example_S32K566_M7 source code also attached here please find.  I have attached the configuration and received data screenshots for reference. Manikandan_Aruchamy_0-1786092514163.png Receiver terminal window baud rate is 115200: Manikandan_Aruchamy_1-1786092584169.png Receiver terminal window baud rate is 14400: Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue Hello @Manikandan_Aruchamy , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. Thank you for your understanding. Best regards, Pavel

The SPI duty cycle of S32K322 is not 50% for 8MHz Dear NXP team,           We are working on an improvement activity where we need to have the 8MHz SPI SCLK to be periodic within SPI transactions. We measured the SPI SCLK for 8MHz (which is driven by the SPI peripheral driver in S32K322) and found that 50% duty is not maintained. When we lower the frequency to 1/2/4 MHz we see 50% duty being maintained for those SCLK frequencies.  Question - Is this any Hardware limitation of the Peripheral driver or by changing the driver settings, desired 50% duty can be obtained for 8MHz? PFA the screenshots where duty is maintained for 1MHz and not for 8MHz Note: We have connected Logic Analyzer from Saleae that has higher sampling resolution (250MS/s) to measure the SPI signals Re: The SPI duty cycle of S32K322 is not 50% for 8MHz Hi, the LPSPI clock duty cycle is determined by the SCKSET and SCKHLD timing parameters. A 50/50 duty cycle is only obtained when these fields are programmed to equal values. Depending on the selected LPSPI functional clock and the divider values required to generate 8 MHz, an exact 50/50 duty cycle may not be achievable due to the timing resolution of the clock generator. The observed 76 ns / 48 ns high-low times appear consistent with such divider quantization effects. PetrS_0-1786090730852.png So, try to calculate the expected duty cycle from your LPSPI functional clock frequency, TCR[PRESCALE], and the contents of the CCR/CCR1 registers (SCKSET, SCKHLD, SCKDIV), and determine whether a different clock source or divider configuration could achieve a duty cycle closer to 50/50.   BR, Petr

MIMXRT1170-EVK FreeRTOS Hello Example Issue Hi Team, I imported the evkbmimxrt1170_freertos_hello_cm7 example project from the MCUXpresso SDK into MCUXpresso IDE without making any significant modifications. The project builds successfully without any errors or warnings and downloads to the MIMXRT1170-EVK(MIMXRT1176DVMAA) board successfully. The task created successfully and executes only once and then stops at address 0xDEADBEEE. This behavior occurs every time. LED Toggle Task: To verify whether the problem was related to vTaskSuspend(), I've created another task with a simple LED blinking task. Expected behavior: LED should toggle every 100 ms continuously. Actual behavior: LED toggles only once. After the first execution, debugger again stops at: 0xDEADBEEE Kindly clarify the following queries, What does address 0xDEADBEEE indicate in the MCUXpresso SDK for i.MX RT1170? Why does the task execute only once instead of running periodically? Is there any additional configuration required to work correctly on the MIMXRT1170-EVK? What changes are required to make the task execute periodically as expected? Rosh_0-1786093292545.png Rosh_1-1786093311524.png Rosh_2-1786093339102.png Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue Hello @Rosh, I understand that you are currently using the MIMXRT1170-EVK. Please note that the SDK for the MIMXRT1170-EVK is different from the SDK provided for the MIMXRT1170-EVKB. Could you please download and test with the SDK specifically generated for the RT1170-EVK using the MCUXpresso SDK Builder? Habib_MS_0-1786125239179.png I understand your point. The SDK examples are intended to provide a common use cases for each peripheral functionality. The 0xDEADBEE value is typically associated with a HardFault condition. Could you please run the example without any modifications and let me know the results using the latest available SDK version? BR Habib Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue Hi @Habib_MS  I've downloaded the SDK specifically generated for the RT1170-EVK using the MCUXpresso SDK Builder and tested it. It is working fine now. Thank you for your support.

FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Hello Everyone, I am currently working with the FRDM-MCXA156 development board and have been facing an issue with SWO (Serial Wire Output) while debugging. Although the application debugs successfully, I am unable to receive any data in the SWO Trace windows, including: SWO Data SWO Profile SWO Interrupt Trace SWO ITM Console To troubleshoot the issue, I have already verified the following: The SWO pin has been correctly configured using Config Tools. The TRACE clock is enabled and configured to 96 MHz, matching the MCU core clock (MCXA156 runs at 96 MHz). The project is being debugged using LinkServer with the on-board MCU-Link probe. Despite these configurations, all the SWO trace windows remain empty during debugging. For reference, I have attached screenshots of the SWO Trace Configuration, SWO Data, SWO Profile, and other windows, along with the relevant project configuration. I would greatly appreciate any guidance or suggestions on what might be causing this issue or if there are any additional configuration steps required to enable SWO trace on the FRDM-MCXA156. Thank you for your time and assistance. #swo #frdm-mcxa156  Development Board MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE With respect to previous thread, The screenshot of SWO enable configuration and clocks are attached below. Thanks Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Hello @sidsal  For the FRDM-MCXA156 board, resistor R36, which connects the SWO signal to the onboard debugger, is DNP (not populated) by default. Could you please populate R36 and test again? Alice_Yang_0-1786344510075.png Thank you. BR Alice Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Thank you for pointing this out @Alice_Yang . I checked the FRDM-MCXA156 schematic and confirmed that R36, which connects the P0_2/SWO signal to the onboard MCU-Link debugger, is marked as DNP. I also noticed that on the FRDM-MCXN947, the equivalent SWO connection (R130) is populated with a 0 Ω resistor. Could you please confirm whether R36 on the FRDM-MCXA156 should also be populated with a 0 Ω resistor to enable SWO tracing through the onboard MCU-Link debugger? Additionally, could you please clarify why R36 is left unpopulated (DNP) by default on the FRDM-MCXA156? Is there a specific board-design reason or limitation that requires it to remain unpopulated? So I cannot use SWO feature?  Thank you for your help. Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Hello @sidsal  " Could you please confirm whether R36 on the FRDM-MCXA156 should also be populated with a 0 Ω resistor to enable SWO tracing through the onboard MCU-Link debugger?" ->>Yes. If you want to use the SWO function, you need to install a 0 Ω resistor or solder the connection accordingly. “Additionally, could you please clarify why R36 is left unpopulated (DNP) by default on the FRDM-MCXA156? ” ->>I think this is because not all users require the SWO function, so the 0 Ω resistor is not populated by default. Thank you. BR Alice Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Thank you for your support @Alice_Yang .

S32K356 RTD选择 我们计划使用S32K356，发现只有7.0.0和7.0.1可以用，但是对应autosar R23，如果使用autosar R21，哪个版本可以推荐？ wenming_0-1786093683425.png Re: S32K356 RTD选择 SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510，我也尝试了，但是尝试了很多次都失败了，猜测跟S32Ds版本有关系，3.6.7也试过了，还是S32D32用哪个版本呢？ wenming_0-1786106406261.png Re: S32K356 RTD选择 从6.0.0的描述看，并不支持S32K356. wenming_0-1786103361744.png Re: S32K356 RTD选择 wenming_0-1786415389796.png wenming_1-1786415468027.png  如上图，6.0.0 QLP01也无法安装，还有另一个问题，通过RTD release note，只需要S32DS3.6.2即可满足安装要求，为什么我用3.6.7，还提示要更新组件，这个跟release note 不符合，是什么原因。 Re: S32K356 RTD选择 wenming_0-1786523357428.png 这是安装RTD7.0.1的错误信息，看起来是版本限制吗？另外，RTD release描述的对应的S32DS的版本，按理解说，应该是直接可以安装，不再需要更新S32DS组件，如果还需要更新组件，还不如推荐更新的安装版本，更便于使用。 Re: S32K356 RTD选择 S32DS版本不符合的问题怎么解决的，为什么我在S32DS3.6.7中安装RTD7.0.1，还是装不上，提示更新。 wenming_0-1786513965538.png Re: S32K356 RTD选择 你好@wenming ， 问题可能与 S32DS 版本有关。 但是，请务必先安装 QLP01，正如 SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510_ReleaseNotes.txt 中所述：“此版本基于 S32K3_S32M27x 实时驱动程序 AUTOSAR R21-11 版本 6.0.0 QLP01。” 顺祝商祺！ 帕维尔 Re: S32K356 RTD选择 你好@wenming ， 我还有一些补充发现。 好消息是，我能够在 S32DS 3.6.2 中安装 RTD 6.0.0 QLP01 和 P05。然而，尽管发行说明中如此描述，RTD 6.0.0 QLP01 必须先安装在干净/基础的 RTD 6.0.0 安装之上。之后，P05 也能成功安装。 遗憾的是，即使按照上述安装步骤操作后，SDK 仍然无法附加到 S32DS 中的 S32K356 项目。 我了解到您正在寻找旧版本的 AUTOSAR。然而，根据观察到的行为，我无法确认 S32DS 中 RTD 6.0.0 的 S32K356 设置是否正常工作。对于 S32K356，较新的 RTD 7.0.0 版本似乎提供了实用的 S32DS 支持。/ 7.0.1 版本。 顺祝商祺！ 帕维尔 Re: S32K356 RTD选择 你好@wenming ， 问题1：如何解决S32DS版本不兼容问题？ 请您更具体地描述一下您看到的兼容性错误信息？   Q2：为什么我无法在 S32DS3.6.7 中安装 RTD7.0.1，并且它一直提示我更新？ 更新提示本身并不是错误。当所选 RTD 软件包依赖于更新或附加的元器件时，S32DS 可能会要求更新相关的平台/工具软件包。   另外，请确保 S32 Design Studio 中已安装 S32K3 RTD 软件包所需的 GCC 10.2 工具链。   顺祝商祺！ 帕维尔 Re: S32K356 RTD选择 你好@wenming ， 谢谢你提供的截图。 从错误信息来看，这似乎不是 S32DS 版本限制。S32DS 在收集/下载待安装项目时发生错误，关键信息为： ZLIB 输入流意外终止 失败的项目是与 S32DS 平台/调试相关的工件，例如： com.nxp.s32ds.doc.platform.resources com.nxp.s32ds.lrc.gdb.arm64.linux.win32 这通常表明其中一个文件没有完全下载，或者在下载/提取过程中损坏了。因此，这个问题看起来更像是更新站点/下载/缓存问题，而不是 RTD 7.0.1 与 S32DS 3.6.7 之间的直接兼容性限制。 关于发行说明：所列出的 S32DS 版本应理解为该 RTD 版本的基准/测试 S32DS 版本。然而，S32DS 是模块化的，如果当前安装中缺少或过时了相关的平台、工具、调试器、编译器或文档组件，则 RTD 安装可能仍然需要更新或安装这些组件。 请尝试以下步骤： 重启S32DS，然后再次尝试安装。 请确保与 NXP 更新站点的网络连接稳定。 如果可能，请在安装过程中使用官方离线更新站点的 ZIP/软件包，而不要仅依赖在线下载。 检查 S32DS 中是否已安装所需的 GCC 10.2 工具链。 如果问题仍然存在，请尝试全新安装 S32DS 3.6.x 版本。安装时，请先安装 RTD 7.0.1 基本软件包，然后再应用任何其他补丁/更新软件包。 因此，根据目前的截图，我不会得出 RTD 7.0.1 不能与 S32DS 3.6.7 一起使用的结论。当前错误指向的是所需 S32DS 更新文件的下载不完整/已损坏。 作为参考，我已成功在 S32DS 3.6.6 中安装了 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip。在我的配置中，我只需要额外安装 S32K3 RTD 软件包所需的 GCC 10.2 工具链。   顺祝商祺！ 帕维尔 Re: S32K356 RTD选择 我将S32DS版本改为3.6.10了，这个版本可以安装RTD7.0.1，不需要额外安装其他组件。我们现在先使用S32DS3.6.10+RTD7.0.1开发。如果后续autosar R21的版本有更新的消息，麻烦告知一下，谢谢了。

IW612 working on IMX95-19x19 EVK board based on Android 16 In default, IMX95-19x19 EVK board enables the PCIe M.2 interface for Wi-Fi modules. But for SDIO interface M.2 Wi-Fi module, we could not use it directly. This doc is a step by step guide about how to make IW612 SDIO M.2 module(Murata 2EL) working on IMX95-19x19 EVK board based on Android 16. 1.Download I.MX Android BSP package, copy with scp to VMSIS. 16.0.0_1.4.0_ANDROID_SOURCE 2.Decompressing android bsp tar -xzf imx-android-16.0.0_1.4.0.tar.gz 3. source ./imx_android_setup.sh to download Android source code. 4.Prepare cross compiler GCC cross compiler: Download the tool chain for the AArch32 and AArch64 on: Arm GNU Toolchain I download the latest version: Arm GNU Toolchain 15.3.rel1 Need to pay attention, for I.MX95, need both 64 bit and 32 bit GCC compile tool. 64bit: arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz 32 bit: arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz For AArch64 toolchain nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$export AARCH64_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- For 32bit toolchain: nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ export AARCH32_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi- 5.Set the external clang, kernel-build-tools, rust, and clang-tools tools for kernel building: nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ sudo ./device/nxp/common/tools/setup_android_kernel_prebuilts.sh 6.Set up the environment for building. This only configures the current terminal, if change to another terminal need to re-run the configurations. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh 7.Execute the Android lunch command for i.MX95-EVK. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$lunch evk_95-nxp_stable-userdebug 8.Optional Steps: Execute the imx-make.sh script to finish the whole images compiling. Or you can follow below steps to only build required images. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ ./imx-make.sh -j4 2>&1 | tee build-log.txt 9.Modify the device tree to disable pcie0 and enable usdhc3 like below: ~/Android/imx-android-16.0.0_1.4.0/android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale$ git diff diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index 69508a66f1c8..dfa1d3d51a9c 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -26,10 +26,19 @@ / { aliases { mmc0 = &usdhc1; mmc1 = &usdhc2; + mmc2 = &usdhc3; serial0 = &lpuart1; ethernet0 = &enetc_port0; ethernet1 = &enetc_port2; }; + + usdhc3_pwrseq: usdhc3_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc3_pwrseq>; + post-power-on-delay-ms = <100>; + }; + bt_sco_codec: audio-codec-bt-sco { #sound-dai-cells = <1>; @@ -651,7 +660,7 @@ &pcie0 { reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; supports-clkreq; - status = "okay"; + status = "disable"; }; &pcie1 { @@ -733,6 +742,22 @@ &usdhc2 { status = "okay"; }; +&usdhc3 { + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; + pinctrl-0 = <&pinctrl_usdhc3>; + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + pinctrl-3 = <&pinctrl_usdhc3>; + mmc-pwrseq = <&usdhc3_pwrseq>; + vmmc-supply = <&reg_pcie0>; //Both PCIE0 and USDHC3 use same power supply. + bus-width = <4>; + keep-power-in-suspend; + non-removable; + wakeup-source; + status = "okay"; +}; + + &enetc_port0 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enetc0>; @@ -1225,6 +1250,45 @@ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e >; }; + + pinctrl_usdhc3_pwrseq: usdhc3pwrseq { + fsl,pins = < + IMX95_PAD_XSPI1_SCLK__GPIO5_IO_BIT9 0x31e + >; + }; + + pinctrl_usdhc3: usdhc3grp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe + >; + }; }; &thermal_zones { 10.Build dtbo image. Need about 40 minutes. DTBO image holds the device tree binary of the board. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ lunch evk_95-nxp_stable-userdebug nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$./imx-make.sh dtboimage -j4 Then you will see that the dtbo images time stamp are updated as below: Christine_Li_0-1786168405295.png Below info is for your reference. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/common/build/dtbo.mk This makefile includes the logic how to pack dtbo image. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/SharedBoardConfig.mk Christine_Li_1-1786168463709.png  This Macro: SUPPORT_GBL is not enabled in default, so still use dtbo image for the device tree. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/BoardConfig.mk Christine_Li_2-1786168477241.png  Wi-Fi/Bluetooth FW located here: Christine_Li_3-1786168507234.png  Wi-Fi/Bluetooth driver located here: Christine_Li_4-1786168518852.png Can modify the Makefile accordingly if needed. After compiled, the Wi-Fi driver and cfg80211.ko is located here: Christine_Li_5-1786168540709.png 11.Download prebuilt Image and decompress it. 16.0.0_1.4.0_DEMO_95//Pay attention to the version, need to match with our Android Source code download version. 12.Replace dtbo image. Rename the original dtbo-imx95.img to dtbo-imx95_original.img in the prebuilt image directory to be a backup. Then copy the dtbo-imx95.img from the remote android source code compiled directory: ~/Android/imx-android-16.0.0_1.4.0/android_build/out/target/product/evk_95/dtbo-imx95.img to the prebuilt image directory. Like below: Christine_Li_6-1786168893998.png 13.Flash images into board. Change the I.MX95-19*19-EVK board's SW7 to 1001 (from 1-4 bit) to enter serial download mode, then connect the board's USB1 port with type C cable to Windows PC. Download the UUU binary file from GitHub: Releases · nxp-imx/mfgtools Open the cmd interface in administrator mode, and enter to the prebuilt image directory. Flash the images into I.MX95-19*19-EVK board with below command: uuu_imx_android_flash.bat -f imx95 -a -e -u trusty-dual For the details of each parameter, can refer to: Android Quick Start Guide 14.Verify Wi-Fi and Bluetooth functions. After flash finished successfully, power off the board and change the board's SW7 to switch the board back to 1010 (form 1-4 bit) to enter eMMC boot mode. Check dmesg logs to confirm IW612 Wi-Fi driver is loaded successfully: Christine_Li_7-1786169134244.png   Check Wi-fi and Bluetooth work as expected in UI.  Can use this application: scrcpy on windows instead of connecting a LCD. Christine_Li_8-1786169192905.png Christine_Li_9-1786169200898.png This guide can also be a reference for other M.2 Wi-Fi modules with SDIO interface working on I.MX95 19*19-EVK board with Android or Linux OS. Reference: Android Quick Start Guide Android User's Guide Linux-Kernel Archive: [PATCH V3 2/3] arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts Finished by Christine.Li. Aug 5 2026.

A2DP test on IW612+I.MX8MPlus-EVK L6.6.52 This doc is a brief step by step introduction for how to play music through A2DP on IW612 + I.MX8MPlus-EVK based on L6.6.52. Step 1: Load WiFi/Bluetooth Driver • NXP i.MX Release Distro 6.6-scarthgap imx8mpevk ttymxc1 imx8mpevk login: root root@imx8mpevk:~# modprobe moal mod_para=nxp/wifi_mod_para.conf root@imx8mpevk:~# root@imx8mpevk:~# dmesg | grep wlan [ 562.728200] wlan: Loading MWLAN driver [ 562.728788] wlan: Register to Bus Driver... [ 562.730460] wlan: Enable TX SG mode [ 562.730464] wlan: Enable RX SG mode [ 563.554778] wlan: uap%d set max_mtu 2000 [ 563.622367] wlan: version = SDIW612---18.99.3.p21.10-MM6X18505.p4-GPL-(FP92) [ 563.625611] wlan: Register to Bus Driver Done [ 563.625622] wlan: Driver loaded successfully root@imx8mpevk:~#modprobe btnxpuart root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 DOWN RX bytes:774 acl:0 sco:0 events:48 errors:0 TX bytes:496 acl:0 sco:0 commands:47 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT • Step 2: Up BT interface and enable the power save feature root@imx8mpevk:~# hciconfig hci0 up root@imx8mpevk:~# hciconfig hci0 piscan root@imx8mpevk:~#hciconfig hci0 noencrypt root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNINGPSCAN ISCAN RX bytes:1900 acl:0 sco:0 events:109 errors:0 TX bytes:1365 acl:0 sco:0 commands:108 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx8mpevk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, CI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) • Step 3: Scan, Pair and Connect to Headset root@imx8mpevk:~# bluetoothctl hci0 new_settings: powered connectable discoverable bondable ssp br/edr le secure-conn cis-central cis-peripheral Agent registered [CHG] Controller D0:17:69:EE:71:4F Pairable: yes [bluetooth]# power on Changing power on succeeded [bluetooth]# default-agent Default agent request successful [bluetooth]# agent on Agent is already registered [bluetooth]# scan on [NEW] Device B1:96:11:68:9C:09 联想thinkplus-HE05X II代 [bluetooth]# scan off [bluetooth]# pair B1:96:11:68:9C:09 Attempting to pair with B1:96:11:68:9C:09 hci0 device_flags_changed: B1:96:11:68:9C:09 (BR/EDR) supp: 0x00000000 curr: 0x00000000 [DEL] Device 67:02:B9:7C:ED:B5 67-02-B9-7C-ED-B5 [DEL] Device 80:F4:16:4C:48:F2 HI-Apiyoo-12MIQ001981 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes hci0 new_link_key B1:96:11:68:9C:09 type 0x04 pin_len 0 store_hint 1 [CHG] Device B1:96:11:68:9C:09 Bonded: yes [DEL] Device 6A:98:7A:08:0F:B8 6A-98-7A-08-0F-B8 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [CHG] Device B1:96:11:68:9C:09 Paired: yes Pairing successful5X II代]# [DEL] Device 6C:59:25:E5:66:77 6C-59-25-E5-66-77 [DEL] Device 61:CC:7D:CE:20:4E 61-CC-7D-CE-20-4E [DEL] Device 64:C1:4B:76:C1:80 64-C1-4B-76-C1-80 [DEL] Device 72:50:16:14:52:A6 72-50-16-14-52-A6 hci0 B1:96:11:68:9C:09 type BR/EDR disconnected with reason 2 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: no [CHG] Device B1:96:11:68:9C:09 Connected: no [bluetooth]#trust B1:96:11:68:9C:09 [CHG] Device B1:96:11:68:9C:09 Trusted: yes Changing B1:96:11:68:9C:09 trust succeeded [bluetooth]#connect B1:96:11:68:9C:09 Attempting to connect to B1:96:11:68:9C:09 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1 [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep2 [NEW] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 [CHG] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 Delay: 0x05dc (1500) Connection successfulII代]# [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [联想thinkplus-HE05X II代]#quit • Step 4: Start pipewire and wireplumber Service then list and choose default Audio Source/Sink Card root@imx8mpevk:~#systemctl --user start pipewire wireplumber root@imx8mpevk:~#wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1552] Audio -Devices： 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] -Sinks： 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] -Sources: 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] -Filters: -Streams: Video -Devices: 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: root@imx8mpevk:~#wpctl set-default 82 root@imx8mpevk:~#wpctl set-default 59 root@imx8mpevk:~# wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1572] Audio 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] 分区Bluetooth 的第4 页 * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] Streams: Video 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: 0. Audio/Sink bluez_output.B1_96_11_68_9C_09.1 1. Audio/Source alsa_input.platform-sound-xcvr.iec958-stereo Step 5: Copy、Play and Enjoy Music Drag the music file yesterday-once-more.wavto I.MX8MP-EVK board by connecting Windows PC and I.MX8MP-EVK board into one local area network. root@imx8mpevk:~# pw-play -v ./yesterday-once-more.wav sndfile: opened file "yesterday-once-more.wav" format 00010002 channels:2 rate:44100 sndfile: using default channel map: FL,FR PCM: fmt:s16 rate:44100 channels:2 width:2 rate:44100 latency:4410 (0.100s) connecting playback stream; target=(null) stream state changed unconnected -> connecting stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Tag stream param change: Spa:Enum:ParamId:Props stream properties: application.name = "pw-play" node.name = "pw-play" media.software = "Lavf58.29.100" media.format = "WAV (Microsoft)" node.rate = "1/44100" node.latency = "4410/44100" media.type = "Audio" media.category = "Playback" media.role media.filename = "yesterday-once-more.wav" media.name = "yesterday-once-more.wav" stream.is-live = "true" node.want-driver = "true" node.autoconnect = "true" media.class = "Stream/Output/Audio" remote 0 is named "pipewire-0" stream state changed connecting -> paused stream param change: Spa:Enum:ParamId:Props stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Format stream state changed paused -> streaming stream set volume to 1.000 -success stream node 88 stream time: now:0 rate:1/48000 ticks:0 delay:9248 queued:0 buffered:0 buffers:0 avail:2 size:0 stream time: now:4821374572568 rate:1/48000 ticks:49152 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4822355905886 rate:1/48000 ticks:96256 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4823379905870 rate:1/48000 ticks:145408 delay:9248 queued:1881 buffered:32 buffers:1 avail:1 size:1881 Finished By Christine.Li Jul 22th,2026.