SL3S1013FTB0,115 design check request 1) Is the transponder schematic above correct for a 3.6V-powered and RFID-powered configuration?   2) Is the voltage stated correct for a 3.6V-powered and RFID-powered configuration for the RFID transponder?   a) 2.6V - 3.1V (3.6V powered) b) 1 - 1.5V (RFID powered) Re: SL3S1013FTB0,115 design check request Your supply voltage correction has been received. I will make the correction.  Your question: Is this the intended purpose for your application? Answer: We don't have an application for the current product, but we want to understand how this tamper alarm works.  I calculated the Vout for 1.8V and 2.2 V. Is this calculation correct? If yes, the Vout is too low to do anything meaningful. Vout = Ivdd X 1k Ivdd = Iinternal +Iout The typical, permanent current consumption will be ~120 µA for 1.8V and ~340 µA for 2.2V. For VDD = 1.8 V, Idd = 0.00012A For VDD = 2,2 V, Idd = 0.00034A For VDD = 1.8 V, Vout =  0.00012 X 1kohm Vout = 0.12V For VDD = 2.2 V, Vout =  0.00034 X 1kohm Vout = 0.34V Re: SL3S1013FTB0,115 design check request Hello @pragashsangaran When externally supplied, VDD pad requires a voltage between 1.8V and 2.2V; for a higher value, a series resistance would be required. For proper calculation, please refer to AN10940 FAQs on UCODE G2i, Chapter 3/Chapter 4. OUT pad is a digital output that can be used for tamper loop, a small external circuit or as indicator; these configurations require VDD pin to be externally suppled. If you populate R35, it will introduce a connection that could activate the "tamper indicator" bit, as per Tag Tamper Alarm feature (please see AN10940 FAQs on UCODE G2i, Chapter 16). Is this the intended purpose for your application? Expected voltage level on OUT pin is described in AN10940 FAQs on UCODE G2i, Chapter 13. A solution that powers a device connected to OUT pin requires an external supply on VDD pin. I will recommend you taking a look at the AN11237 UCODE G2iM+ demo board documentation, Fig 3 and Fig 5 for some reference connections. Regards, Eduardo. Re: SL3S1013FTB0,115 design check request Hi, In order to use the OUT pin functionalities, such as digital output/switch or powering an external circuit, an external supply is required. Also, as mentioned in AN10940 FAQs on UCODE G2i, Chapter 16 "How is the Tag Tamper Alarm used?" this feature is based on a galvanic connection between VDD and OUT; something important to remark is that the tamper feature and the external supply mode cannot be used at the same time. Regarding the calculations, please consider that the voltage level available on the OUT pin is defined by the voltage level on VDD reduced by the voltage drop on the internal series resistor. You can find a few examples on AN10940 FAQs on UCODE G2i, Chapter 5.3. Regards, Eduardo. Re: SL3S1013FTB0,115 design check request EduardoZamora, thank you so much. After many attempts to ask the same questions again and again, I finally feel like I im getting the correct answers to my questions. I really hope we can resolve my question in this ticket.  I also want to know if it is the Vout of the RFID-powered configuration (without VDD). Can you please let me know as well?  im not using a tamper indicator. I hope we can justify the use of SL3S1013FTB0,115 vs a Schottky diode. If a Schottky diode can provide higher Vout without a supply voltage, I'd rather go for a Schottky diode. 

DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs Hi all, I'm evaluating NXP S32K3 family MCUs for a program that requires DFARS-compliant sourcing, and I'm hoping someone here can help point me in the right direction or has dealt with this before. Specifically, I'm trying to confirm: Country of manufacture/assembly (wafer fab and package/test locations) for specific S32K3 part numbers — compliance is generally tied to whether the part is manufactured in a DFARS "qualifying country" per DFARS 252.225-7002 (Qualifying Country Sources as Subcontractors), so I need this at the part-number/package level rather than a general "NXP is compliant" statement. Whether NXP can issue a Certificate of Origin (COO) or formal DFARS compliance statement for specific parts. Whether there's a TAA compliance letter available as well, since that may also apply to our program. Parts of interest (open to alternatives that fit the same tier): S32K344 S32K358 S32K314 We're targeting MCUs with ≥512 kB flash, ≥128 kB RAM, so I'm mainly looking at the higher-memory S32K3 variants, but happy to hear if other S32K3 family members (or the broader S32K1/S32K2 lines) are better documented for compliance purposes. Questions for the community: Has anyone successfully obtained COO/DFARS documentation directly from NXP for S32K3 parts? If so, who did you work with (FAE, distributor, quality team)? Is this something NXP publishes at all, or is it always a case-by-case request per part/date code? Are there specific S32K3 part numbers or packages known to be sourced from DFARS-qualifying countries vs. others that aren't? Given S32K3 is heavily positioned for automotive/industrial safety applications, has anyone had experience getting compliance docs for defense-adjacent programs specifically? I understand this may not be something community engineers have direct access to, so if there's a better channel (regional FAE, distributor compliance desk, etc.) I should be routing this to instead, please point me there. Appreciate any guidance! Thanks! Re: DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs Hi @dbow12, We do not have this information publicly available. For COO inquiries, you may contact [email protected]. For any export control inquiries, contact [email protected]. However, I would recommend contacting your local distributor first, they should be able to assist you in this regard. Regards, Daniel 

RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, I'm experiencing an issue with RTD 5 when configuring the LCU module. Specifically, when I select Instance -> 1 in LCU, it throws an error (please refer to the image below). There are no other changes made, and this configuration works fine in RTD 4. Additionally, after pressing "OK," it does not allow adding more than one LCU Output Physical — the "+" button in the peripherals section becomes unresponsive. I’ve verified this behavior in both S32 Design Studio v3.5 and v3.6, and the issue persists in both versions. Could you please look into this? Thank you. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Info: I am using S32DS 3.6.10 with RTD 7.0.1 Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Yeah, this is the same workaround I was using as well. I keep LCU_IP_HW_INST_0 in the configuration while setting everything up, even though it is not used, and then remove Instance 0 at the end. NXP did suggest updating/reinstalling the RTD, but that did not resolve this particular issue. The post was eventually closed, so I’m not sure if this was fixed in a later S32DS/RTD version. I saw the issue in both S32DS 3.5 and 3.6. Thanks for adding this to the community @Micha4566465 . It’s useful to have the workaround here so others can refer to it if they run into the same issue. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hi,  I have this issue, too. The issue only appears, when using LCU Hardware Instance LCU_IP_HW_INST_1 as only instance in "LCU Logic Instance"-Item. If you keep the LCU_IP_HW_INST_0 beside the LCU_IP_HW_INST_1, although it will not be used, there is no problem. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 this updated version works Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, here is what i see when configure Instance 1: I do not see any issue. Best regards, Peter Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Thanks for the responses! I tried the suggestions you provided — things are working better now. I'm able to add the LCU instance, which is good progress. However, I  the issue only occurs when selecting hardware instance 1(as mentioned before). In the image you shared, it shows instance 0, which doesn't seem to have the same problem. Occasionally, an error still pops up when working with instance 1, but it's not a blocker since I can exit it without any functional impact. Could you please confirm if this is a known issue in RTD v5, or if it might be related to something else? Also, if there's a fix or recommended workaround, that would be helpful. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, I have just tried it in S32DS 3.5. with RTD 5.0.0. and I do not see such issue: The error seem to be tied to your installation. Since the issue is also present in S32DS 3.6 I suggest to reinstall the RTD pluggin and intall the latest update of RTD 5..0.0.HF1 But the fact is that I am using much older release and do not see the issues. It can also be linked to S32DS GUI. Maybe it is somehow corrupted or has restricted access to the configuration in LPC. Best regards, Peter

关于FS2613芯片的选型 FS2613系列芯片功能是比较强大的，各个电源轨的数值和时序是可以编辑的。但我们没有太多软件开发的精力，也尽量不想自行OTP。请问有没有哪个型号，出厂的默认配置就是适配S32K358的？比如下图？ Re: 关于FS2613芯片的选型 看附件 Re: 关于FS2613芯片的选型 嗯嗯，请问对于MFS2633AMDB2AD型号，默认上电后，以下各通道的输出电压分别是多少？ VCORE、LDO1、LDO2、VREF、VBST；TRK1与TRK2跟随来源是哪里？ Re: 关于FS2613芯片的选型 MFS2633AMDB2AD Search | NXP Semiconductors 你可以选择这个！ Re: 关于FS2613芯片的选型 MFS2633AMDB2AD已停产，同等参数，我应该替换成：MFS2633HMDB2AD，对吧？ Re: 关于FS2613芯片的选型 是的！

MIMXRT1064CVL5B Custom PCB Flash Failure Hi everyone, I am bringing up a custom board utilizing the MIMXRT1064CVJ5B processor. The board is powered by an external 5V SMPS power supply fed into a 3.3V LDO regulator. I am using a CMSIS-DAP / DAP-Link debug probe to program and debug via the SWD interface inside MCUXpresso IDE. I am encountering a highly specific, repeatable power state crash when attempting to flash my code.   The Symptoms: Instant Power Drop on Connection: When the board is running independently, it works fine and the power LED stays fully illuminated. However, the exact millisecond I connect my DAP-Link probe harness to the board's SWD header, the 3.3V rail collapses, the power LED turns completely off, and the board powers down. This happens before executing any commands or clicking "Debug" in the IDE. Momentary Power Recovery and Crash During Debug: If I leave the probe connected and click the Debug button in MCUXpresso, the board suddenly gets powered back up and the LED turns back on. However, right when the flashing sequence begins, the system freezes at 3% progress with a Wire ACK Fault and a bus hang-up at memory location 0x2000A750. Immediately after this crash, the board powers down again and the LED turns off.   LinkServer Debug Console Log Output: ============= SCRIPT: RT1064_connect.scp ============= RT1064 Connect Script DpID = 0BD11477 APID = 0x04770041 Disabling MPU Configure FlexRAM for 768KB OC RAM, 128KB I-TCM, 128KB D-TCM Finished ====================================================== ... Writing 1322080 bytes to address 0x70000000 in Flash 70008000 done 3% (32768 out of 1048576) request to clear DAP error failed - status 5 After error Nn(05). Wire ACK Fault in DAP access - Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access failed to send op Terminate message - rc Em(17). Debug port inaccessible after access at location 0x2000A750 Target error from Commit Flash write: Em(17). Debug port inaccessible after access at location 0x2000A750   What I have tried so far: Hardwired BOOT_MODE[1:0] to 01 (Serial Downloader mode) via physical solder pads to isolate application interference. Target memory spaces are properly mapped to the internal 4MB QSPI flash baseline region at 0x70000000 within the IDE linker properties. The exact same DAP-Link probe seamlessly programs an official NXP MIMXRT1064-EVK kit using identical code and configuration parameters. Why is the connection causing an immediate power drop, why does the board temporarily wake up during debugging, and why does it consistently deadlock at the 3% flash mark? Any guidance on how to reliably program the chip with this layout behavior would be highly appreciated. Thanks! Evaluation Board Re: MIMXRT1064CVL5B Custom PCB Flash Failure if power drop by connecting the probe，the power supply maybe undervoltage since the cmsis probe absorb energy suddenly during connectting. Can you check the power rail in the system？How many current the debugger need？ Re: MIMXRT1064CVL5B Custom PCB Flash Failure Hi @Anushka_SS , Thanks for your interest in NXP MIMXRT series! All three symptoms (power drop when the probe is plugged in → board wakes up when you click Debug → hang at 3%) point to one single root cause: insufficient 3.3V supply margin on the board combined with an SWD/VTref wiring issue, causing a brown-out shutdown — not a software or flash-driver problem. Why we're confident: You've hard-wired BOOT_MODE to Serial Downloader, so the application never runs — this rules out "app occupying the debug pins." The same probe and configuration work fine on the official EVK, so the difference is purely your custom-board hardware. A plain SWD connection draws almost no current, yet it collapses the entire 3.3V rail — this can only mean the probe is loading/back-feeding the 3.3V rail while the LDO trips into over-current protection. About 0x2000A750: this address sits in DTCM (the 0x20000000 region), where the flash algorithm (flashloader) runs. The 3% mark is exactly when continuous writes to the QSPI flash begin and the core + FlexSPI current peaks — the supply can't hold up, the core browns out and resets, hence the Wire ACK Fault. It's simply where the device died on brown-out, not bad memory or a code bug. Best regards, Gavin Re: MIMXRT1064CVL5B Custom PCB Flash Failure Thank you for you reply! Actually I am facing an issue with the power-up and SWD programming of my custom i.MX RT1064 board. I am using a TLV75733PDBV 3.3 V LDO. The LDO input is stable at 5 V, but sometimes the regulator does not produce 3.3 V because its EN pin remains low or has no voltage. The EN pin is controlled directly by the RT1064 through the PMIC_ON_REQ signal. Sometimes PMIC_ON_REQ/EN suddenly becomes about 3.3 V, the regulator turns ON, the 3.3 V rail comes up correctly, and the board power LED starts glowing. However, this behavior is not consistent — sometimes the board powers up, sometimes it does not. When the board is powered correctly and I then connect my MuseLab CMSIS-DAP probe for SWD programming, the 3.3 V rail drops again and the board powers down. At that point I get SWD errors such as: Wire ACK Fault Debug port inaccessible Could not connect to core The measured behavior is approximately: Without probe: U1 IN = 5.0 V U1 EN = 3.3 V (sometimes) U1 OUT = 3.3 V POR_B = 3.3 V After connecting probe: U1 IN = 5.0 V U1 EN = 0 V U1 OUT = around 1.2–1.8 V POR_B = around 2.1 V So it looks like the LDO itself is not losing input power. Instead, the regulator is being disabled because its EN pin goes low. My main questions are: Why is PMIC_ON_REQ from the RT1064 not consistently going high? Is this random power-up behavior caused by the RT1064 power-sequencing or reset circuit? Why does connecting the SWD probe cause PMIC_ON_REQ/EN to go low? Should the 3.3 V regulator EN be controlled directly from PMIC_ON_REQ, or should it be pulled up/handled differently? What is the recommended way to keep the 3.3 V rail stable so that I can reliably power and program the RT1064? Are there any important requirements for POR_B, DCDC_IN, DCDC_OUT, VDD_SNVS_IN, VDD_HIGH_IN, or boot-mode pins that could cause this behavior? I previously made another custom board based on the Teensy 4.1 power circuit, and that board could be programmed successfully using the same CMSIS-DAP probe. The new PCB uses a very similar power circuit, but I added access to the boot-mode pins and changed the reset/power section slightly. I am attaching my regulator section, reset circuit, power-pin connections, and boot-mode schematic. I would appreciate help checking whether the PMIC_ON_REQ/EN connection or RT1064 power-sequencing circuit is incorrect, and what changes are needed to get stable power and reliable SWD programming. Re: MIMXRT1064CVL5B Custom PCB Flash Failure Hi @Anushka_SS , Thank you for providing the schematic. I took a look at it and found a few issues. 1. VDD_SNVS_IN:  It cannot be floating. VDD_SNVS_IN supply must be turned on before any other power supply or be connected(shorted) with VDD_HIGH_IN supply. (Please strictly follow the power-up sequencing specified in the datasheet/RM and verify it on your board.) 2. Furthermore, this 3.3 V supply must not depend on PMIC_ON_REQ, while at the same time being used to power VDD_SNVS_IN. Otherwise, the SNVS domain will be de-energized during a cold start, and the internal state machine will not have a reliable condition to output PMIC_ON_REQ.  Therefore, your LDO cannot power up reliably. PMIC_ON_REQ can only be driven reliably after the RT1064's SNVS/PMU domain is up and running, and the SNVS domain first requires a valid supply on VDD_SNVS_IN. Since VDD_SNVS_IN is left floating on your board, PMIC_ON_REQ behaves erratically — the board powers up only intermittently, and it unexpectedly powers down the moment you connect the SWD probe. In addition, do not drive the LED directly from PMIC_ON_REQ. A power-indicator LED should be placed on the stable 3.3 V rail, or isolated with a buffer/MOSFET. Hanging an LED + 470 Ω to ground on the PMIC_ON_REQ node effectively adds a significant load / pull-down path on this critical power-request pin. If the pin is in a high-Z or open-drain "ON" state, the LED branch pulls EN toward a low level; and even with a push-pull output, it forces this small SNVS-domain control pin to source the LED current — which is not recommended. Best regards, Gavin

lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello! I am working with the 3-Phase Permanent Magnet Synchronous Motor Control Development Kit with S32K396 MCSPTR2AK396. To test the base firmware, I installed the following stack: S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC version 10.2 After several unsuccessful attempts to synchronize all software versions, it finally worked, and the base firmware started functioning. However, I wanted to test the Ethernet communication functionality next, and that’s where I encountered unresolved issues at the moment. I additionally installed: SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 And I took the test project lwip_FreeRTOS_s32k396, but it never compiled without errors; there were always conflicts in descriptions and other issues. I tried using the latest version of SW32K3_TCPIP_STACK_5.0.0_CD01_D2605, and I had to apply a file replacement during the update code process. In the end, the firmware compiled with warnings but no errors. After that, I moved on to testing. I set up the system as follows: personal computer -> GeekStore 100BT1-PRO2 Automotive Converter (http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/) -> MCSPTR2AK396. I aligned the IP addresses of the Ethernet connection on the computer and the one specified in the firmware so they would be in the same subnet. However, attempting to ping the motor's assigned IP from the computer was unsuccessful, although it seems the network polling is ongoing, as indicated by the converter. What could be the issue? Could it be that I shouldn’t have used the latest version of TCPIP_STACK? Are there possible issues with the board itself? On the controller board stickers, revisions B1 and B are indicated. Is it possible to obtain additional documentation specifically for these revisions (on the website, I only saw documentation for revision A)? I would appreciate any advice or clarifying questions. Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Firstly, I am not sure what errors were present with TCPIP v4.0.0, since it is also compatible with RTD 7.0.0 & FreeRTOS 7.0.0 CD01 packages, however, latest TCPIP stack (v5.0.0) is OK. Can you share what was the file modification? I was able to import, generate and compile the project without problem. My environment: S32DS v3.6.0, RTD v7.0.1, FreeRTOS v7.0.0 CD 01 and TCPIP Stack version 5.0.0 CD 01. It seems that MCSPTR2AK396 has a design oversight. EMAC_MII_RMII_RX_DV (PTD14) is not connected to RX_CTL - CONFIG6: MCSPTR2AK396 EVB ethernet connectivity, CRS_DV signal clarification. That said, is the task and OS is running?  xTickCount — this should be incrementing continuously if the RTOS tick interrupt is active. xSchedulerRunning — this should be set to 1 if the scheduler is running. Best regards, Julián    Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello  Regarding the design files, I can see that the HW Design Package for MCSPTR2AK396 includes revision B2: Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Yes, the fsdata.c and EthIf.c in previous release was reported and fixed; EthIf.c file from RTD is just a stub. We provide our own minimal implementation for EthIf, so the file from RTD can be safely excluded from the project. Secondly, yes, from your description, it seems that the example works properly. The connection is needed and should be done as mentioned (routing/soldering CRS_DV to PTD14).  Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Julián_AragónM! The issue with building the test project using TCPIP v4.0.0 was resolved by excluding two files, fsdata.c and EthIf.c, from the build. This conflict seems to have been automatically resolved in version 5.0.0. I also checked the values of the variables xSchedulerRunning and xTickCount through the Expressions window in the S32DS debugger. xSchedulerRunning indeed takes the value 1, and the second one increases sequentially (1, 5001, 10001...), leading me to conclude that FreeRTOS is functioning correctly on the board, and the problem is not in the software. If I understand correctly, the only remaining cause is a hardware issue—the absence of a connection between CRS_DV (CONFIG6) on the TJA1103A and pin PTD14? To resolve this, do I need to solder these two contacts together? Please confirm. Best regards, Anna 

MPXM2053GS air leakage We have assembled MPXM2053GS pressure sensors onto our PCB. During initial testing, a number of units were found to have an output voltage of 0V, which we guess is due to air leakage. After removing the defective devices from the board, we inspected the bottom vent holes and found that they differ visibly from those of the good units. Specifically, the interior of the vent holes on the failed parts appears to contain melted or heat-damaged material. What is the possible root cause of this defect? Re: MPXM2053GS air leakage Hi David, The most effective prevention is to define a solder paste exclusion zone on your PCB stencil directly beneath the vent hole location. This ensures no paste is deposited in that area and cannot be drawn into the hole during reflow. Additionally, using a no-clean flux minimizes residue that could otherwise migrate into the opening. For further support, I would recommend contacting STMicroelectronics directly, as they are the current owner of the MPXM2053 and are best positioned to provide support. BRs, Tomas Re: MPXM2053GS air leakage Do you have any suggestion how to prevent solder paste or flux intrusion from entering the bottom vent? Re: MPXM2053GS air leakage Hi David, The melted/heat-damaged material inside the vent holes is most likely caused by solder paste or flux intrusion during reflow soldering or by exceeding the maximum permitted peak package body temperature of 250°C (max. 30 seconds). Since the MPXM2053GS is a vented gauge sensor that uses the bottom vent as its atmospheric reference, any blockage of that hole will cause a loss of reference and result in 0V output. One additional note for your awareness: as of February 2, 2026, NXP MEMS sensor products — including the MPXM2053 series — have been transitioned to STM. For formal failure analysis or ongoing product support, STM is the appropriate contact. BRs, Tomas

寻求培训资料 你好，我想学习关于EIS的课程，但是如何借助恩智浦eisBMS芯片更安全、更快速地为电池充电——软件支持/系统集成/激励这几部分目前都无法观看，也没有课程资料。 请问该如何学习这几部分呢

Voltage injection tests for OV and UV scenarios and associated behavior Hello Community,  SBC FS4503 is used in one of our projects and configured as below for OV / UV conditions. VCCA, VCORE and VAUX are configured to have impact on FS0B only in an OV condition and an impact on RSTB and FS0B both in case of an UV condition. Voltage injection test was performed by injecting voltages at the VCORE, VAUX and VCCA pins by using a second power supply while the first power supply provided 12V input to the SBC.  Results of the test as below: 1. VAUX OV - Asserts FS0B, 2. VAUX UV- Triggers RESET 3. VCORE OV- Asserts FS0B but VCORE is cut off, as mentioned in the data sheet. 4. VCORE UV- Triggers RESET 5. VCCA OV- Asserts FS0B, but VCORE is pulled down for a short time, and hence reset 6. VCCA UV- Triggers RESET. VPRE- OV - Datasheet mentions regulator is switched off, and we observe a RESET. Below are the queries: 1. Is the Bench test procedure valid? Where, for OV conditions around 5.5V was injected on the respective pin and for UV conditions around 3.5V was injected on the pins. 2. Is the observation with VCCA OV condition acceptable? 3. When an OV condition occurs at VPRE, the datasheet mentions the regulator is switched off, does this cut-off the VCORE supply as well? Thank you, Aditya Re: Voltage injection tests for OV and UV scenarios and associated behavior 1. Is the Bench test procedure valid? Where, for OV conditions around 5.5V was injected on the respective pin and for UV conditions around 3.5V was injected on the pins. [gw]OV should use voltage above 5.5V, UV test should be lower than 3V. Also need meet the filter time and reaction time requirement. 2. Is the observation with VCCA OV condition acceptable? [gw]Does the second power supply(OV voltage) reverse-supply through the VCCA pin, causing disturbances in the VPRE/VCORE loop? Did you monitor the VPRE during this VCCA OV test？ 3. When an OV condition occurs at VPRE, the datasheet mentions the regulator is switched off, does this cut-off the VCORE supply as well? [gw]Yes, VCORE is provided by VPRE. Re: Voltage injection tests for OV and UV scenarios and associated behavior Hello @guoweisun ,  Thank you for the response. This is helpful.  Please find my queries below: [gw]Does the second power supply(OV voltage) reverse-supply through the VCCA pin, causing disturbances in the VPRE/VCORE loop? Did you monitor the VPRE during this VCCA OV test？ [ab]: VPRE was not monitored. I will monitor it with new tests. Could you please help me understand what is meant by reverse-supply through VCCA pin? [gw]OV should use voltage above 5.5V, UV test should be lower than 3V. "Also need meet the filter time and reaction time requirement." [ab]: As I am performing this activity manually, the filter time of 100-200us and reaction time of 314us are satisfied for the OV cases.  Below are some additional queries,  1. How is OV/ UV detected, what is the sampling rate used by the SBC? 2. What is the significance of the filter time and reaction time? 2. How many not ok samples are allowed before detecting an OV/ UV fault on any of the pins? Thank you, Aditya

CAN Bus Handling in MBDT I’m using NXP’s MBDT for S32K344 for configuring FlexCAN0. I want to understand what part of CAN message handling is managed by the NXP blocks/toolbox and what needs to be handled by the application. Are arbitration and buffer handling managed by the driver/toolbox? Example: If I send 0x18FEF111 first, then 0x18FEEF00 neither appears on the bus. But if 0x18FEEF00 is sent first, both are transmitted. When triggered together, only one appears. So, do we need to assign dedicated Tx Hardware Objects to each message ID when sending multiple frames simultaneously? Does the MBDT or SDK handle message prioritization and retries automatically if ACK is not received? If a high-priority ID fails (e.g., no ACK), will it block other messages? How do we detect and recover from this? Do we need to manage buffer allocation or transmission timing manually in the model to avoid blocking or message loss? What’s the best way to configure multiple Tx message IDs in MBDT? With dynamic buffers. Please clarify what is handled internally vs. what we must handle in the application. Example Models Re: CAN Bus Handling in MBDT Hello @SorinIBancila , I've run into a scenario where I need to send more frames than the available HTH hardware object count. Since the CanIf transmit buffering implementation cannot be leverage in S32CT, can you recommend simulink-based buffer solution to this problem? Thanks & regards, Sandesh Re: CAN Bus Handling in MBDT Hello, The 32 Can Hw Object Count is not the limit. You can increase the limit even further, depending on what MCU you have. You can modify the number of Can Hw Object Count and if you put a number too large, the S32CT is going to throw an error. Best regards, Sorin Bancila Re: CAN Bus Handling in MBDT Understood! So If I need to transmit more than 32 messages, should I create additional Tx Hardware Objects? Also, what is the maximum number of Hardware Objects that can be configured under a single CAN transceiver or controller in S32K3 using S32CT? Looking to understand the best way to structure HOHs for large message sets while staying within the limits. Re: CAN Bus Handling in MBDT Hello, How many messages do you think you need to transmit at one time? I've tested on a S32K358 HVBMS reference design the following scenario: Use a single TX Hardware Object and set the Can Hw Object Count to 32 (to allow a maximum of 32 messages in the buffer). In Simulink, I populated the message buffer with 32 messages, increasing the priority as it populates the buffer, to prove the arbitration process. The results: As expected, the first messages sent are with low priority, as the message buffer is not completely populated. Around the 6th message, the buffer is populated and we can see that the messages with higher priority are sent first. Since you want to use a single transceiver, it is not really possible to simultaneously send all the messages at the same time. Best regards, Sorin Bancila Re: CAN Bus Handling in MBDT Hi Sorin, Thanks for your input! I wanted to clarify the best way to configure multiple Tx message IDs in MBDT when using dynamic buffers. In my case, the controller is being used for an EV application with a J1939-based CAN setup involving hundreds of cyclic messages. Creating separate hardware objects for each message in S32CT doesn’t seem scalable or practical. I’m looking to use a single Tx Hardware Object to handle multiple messages dynamically and transmit them simultaneously over one CAN interface. Could you please guide on the recommended setup or best practice for this use case? Also please do suggest the documentation I must refer in order to understand the working of config setting and involved Functions used in MBDT. Re: CAN Bus Handling in MBDT Hello, First of all, I want to point out that the MBDT for S32K3xx is build on top of the S32K3 RTD. The configuration of a peripheral is done in the S32 Configuration Tool to allow full flexibility on the settings you need. So basically, to check if a feature is supported by the NXP's MBDT S32K3xx, you can check the source code used by the peripheral (in the S32K3 RTD) and its available settings in the S32 Configuration Tool. In the toolbox, you can find the implementation for the FlexCAN peripheral here: {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ Note! The name of the S32K3 RTD might differ, depending on which version of the MBDT S32K3 do you use. The answers to your questions are based on my experience and they might not be totally accurate. 1 & 2 & 5: The toolbox does not handle any arbitration, but I am not sure what options are available in the SDK for this matter. In your example, you create another CanHardwareObject and use it to send the second message, but this approach might be difficult to manage. The second solution might be to increate the Can Hw Object Count to allow more messages in the buffer. 3: The MBDT for S32K3 does not handle any message prioritization. As far as I know, that's the job of the FlexCAN controller to retry to send the message until the ACK is received, while blocking the message the buffer. 4. One way to detect if a message is sent or not is to use interrupt CanIf_TxConfirmation in the Hardware Interrupt Callback to mark that a message is sent. If the interrupt is not triggered for the specified PDU, it means that the message is not sent. Moreover, there is another interrupt (CAN_ControllerBusOff) available that triggers when the conditions for CAN Bus Off are met. In the S32 Configuration Tool, there is an option to automatically recover from Bus Off. If you have any questions, do not hesitate to reply. Best regards,  Sorin Bancila Re: CAN Bus Handling in MBDT Hello, Hello, I think one way to bypass the Hw Object Count limit is to configure multiple CAN controllers and to connect them to the same bus. Then, to avoid receiving messages sent from the other CAN Controller, you can take advantage of filter codes and masks to discard the messages right at the controller level. (offloading the MCU). Then, in the Simulink, you can use both CAN Controller to send data to the bus, either by round robin or any method you find suitable. I did not try this method yet, but I will keep you updated to see if it works. Best regards, Sorin Bancila

How to enter in LPM mode of MSDI MC33CD1030 on S32K396BMS-EVB using NXP MBDT Hi,  I need some MBDT reference settings or ready model for entering LPM in CD1030 using S32K396BMS-EVB. Please support. Thanks Re: How to enter in LPM mode of MSDI MC33CD1030 on S32K396BMS-EVB using NXP MBDT Hello, In the CD1030 datasheet (page 43/75), we can see that a specific SPI word must be sent to the IC: To learn more how to integrate the CD1030 into your model, please check the following article: How to: MSDI MC33CD1030 on S32K396BMS-EVB using NXP MBDT  Best regards, Sorin Bancila

Need help verifying CAN communication on the RD33772C14VEVM board Hello, My name is Hyewoon Jang. I am currently trying to test the RD33772C14VEVM board, and I have set up my environment as follows: Software: MBDT for BMS 1.2.0 + MBDT for S32K3xx 1.4.3 (I installed version 1.4.0 first and then applied the 1.4.3 patch.) Model: MBDT for BMS → BMS_Examples → rd33772c14vevm → rd33772c14vevm_s32ct → rd33772c14vevm_s32ct.mdl Hardware: The hardware is connected as shown in the attached photo. For now, I have not connected a battery, since I would like to check the basic operation of the model first. I am only supplying 12 V power to the board. After setting up the environment as described above, I tried to download the model to the board, but the download process shows “Could not connect to target.” Therefore, I imported the generated code into S32 Design Studio 3.5 and tried to download it from there. In S32DS, the build process completes successfully. Therefore, I connected the board to Vector CANalyzer in order to check whether any CAN messages are being transmitted from the board. However, no CAN messages are displayed in CANalyzer. Since I suspected that the issue might be related to the J-Link debugger, I also tried connecting the board using TRACE32. However, the reset indicator repeatedly turns red, and TRACE32 shows the error message “target power fail.” At this point, I simply want to verify whether the board is operating properly by checking if any CAN messages are transmitted. I really would like to resolve this issue. If there are any items that I should check, I would greatly appreciate it if you could let me know. I will follow your guidance and try each step. Could you please advise me on what I should do to solve this problem? #rd33772c14vevm, #CAN, #s32k344, #JTAG, #MBDT Re: Need help verifying CAN communication on the RD33772C14VEVM board Hello, First of all, I am sorry for the late reply. From the message you sent, I suspect that the board is not properly powered. I see that you built the application in S32DS too, but the build process to do not involve to deploy the application to the board. You have to create a Debug Configuration compatible for S32K344 and deploy the .elf from there. Since you didn't connect a battery yet, I recommend you to power the board from cell emulator instead of the beefy screws found on the EVB. I am not sure that you can power up the board using the Shunt resistor (R62), please thoroughly check the schematic. In the readme for the model, it states that you can power up the board from the emulator board: Connect the power supply to the emulator board: 12V -> BH1(K30_12V_L) and GND -> BH2(GND_KL31_DOWN) Let me know if this solves your problem. Best regards, Sorin Bancila

freemaster I built a Simulink model for the S32K344-WB to make an LED toggle on and off every 1 second. I then imported the ELF file into FreeMASTER and monitored waveforms via J-Link. However, after I clicked Go, the signal level on the FreeMASTER oscilloscope stayed as a flat line and did not toggle. When I pressed the physical Reset button on the board, the LED started blinking normally, but the waveform display in FreeMASTER paused. How should I configure the settings to observe waveforms on the FreeMASTER oscilloscope while the MCU runs normally with the LED toggling continuously? Re: freemaster Hello, First of all, sorry for the late reply. If you reset the evaluation board while FreeMASTER is already connected to the board, you have to STOP the FreeMASTER connection and start it again. Otherwise, it is going to get stuck. One way I do what you want to achieve is to store the state of the LED in a Data Store Memory. Apply the NOT operation (to change from LOW -> HIGH and HIGH -> LOW) and feed the value to Dio_WriteChannel. This way, you can mark the Data Store Memory as Volatile or External so you can load it into FreeMASTER project. If you want to be to perform the read and write operation on a DIO channel, you need to configure the pin to be configured as INOUT (Pins tab in S32CT). Best regards, Sorin Bancila

Device with MK22FN1M0VLQ12 resetting loop after working for some time Hi guys, I have a device that runs on a MK22FN1M0VLQ12. The thing is that after working for some time it starts to get stuck on a reset loop at startup. First i thought it was a problem with corrupted flash memory (the application saves logs in the flash). I used a ping-pong strategy to resolve that. But some devices returned with a similar problem. I tried to debug one of the devices and without setting any breakpoint it always stops at ASerialLDD2_Init or IntFlashLdd1_Erase, both are functions generated by processor expert. Other devices I used memory dump and was able to see that the memory was indeed corrupted so that's why I fixed how I use the FLASH. Other important note is that some times it happens after some months, other almost after a year. Also i have devices installed over a year and a half that are running ok. Other thing is that I tried to memory dump (with usbdm) this device, and trying to read the same address, sometimes it reads fine, and sometimes it returns ARM Transation Fault. Anyone seem anything like that? Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Thank you for the reply I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output. That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init(). I am using a PE Micro multilink to debug. Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Hello @Rigolon , Thanks for your post. I think this looks more like a Flash-operation-related fault or Flash-content corruption issue, rather than an issue in ASerialLDD2_Init or IntFlashLdd1_Erase themselves. The RM states that if the MCU reads an FTFE resource while it is being manipulated by an active Flash command, FSTAT[RDCOLERR] is set, and the read data is not guaranteed. You can refer to AN4835 , it also says:" Interruption of an erase or program command can lead to corruption of the flash contents. Interruptions could include reset, loss of power, or a conflict with code running on processor."  This matches the observation that reading the same address sometimes succeeds and sometimes returns an ARM Transaction Fault : if a Flash region is corrupted or in an indeterminate state, reading it may trigger a bus fault; in similar cases, erasing the affected sector, or mass erase if needed, is used to recover the Flash array. Please refer to Solved: Find corruption on internal Flash MK22FX512VLH12 - NXP Community for more details. Hope it helps. BR Celeste Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Thank you for the reply I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output. That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init(). I am using a PE Micro multilink to debug.

When using mculink, debugging can find the probe, but there is an exception when selected When I completed the steps outlined in the MCU-LINK installation guide and proceeded to use MCU-LINK in conjunction with MCUXpresso IDE, I encountered an issue. After connecting the computer to MCU-LINK, I can debug and the probe is recognized. However, after I select it, it keeps reconnecting and pops up this exception. What could be the reason for this? Could you please help me understand? Thank you! i.MXRT 600 Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_  If the D11 is not on, there is a power distribution problem at the board. The debugger is still working that is why you detect the board when connected the USB.  Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi@carlos_o I didn't modify the development board, and the jumper position has also been restored to the default position, but the D11 of the development board is still not on. After connecting the computer through LINK USB, the Device manager displays the new USB "Composite device", but the development board still can't burn the example code, and it still displays "Unable to connect wire for probe index 1." Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_  The D2 flashing means that the on-board debugger is running.  The D11 is a power on indicator that you could see at the schematic of the board. The D8 is blue led that is controlled by P0_26 Did you modify the board in any way? or did you move any of the mini jumper default position? Re: When using mculink, debugging can find the probe, but there is an exception when selected What is circled in red is that it would be on after normal burning, and the blue part would be on after pressing. Now D8, D9, D10 and D11 are not on, and they can't be burned in. Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi@carlos_o I'm sorry it took so long to get back to you. Before, I tried to connect the interface on my board, but the error was still displayed. Recently I got the development board of RT685. At the beginning, I used the data cable to connect J5 to the computer, and then successfully burned the program of HelloWorld. D8 and D11 on the board are in constant state, and D2 flickers. Later, I went to check my board. The above interface is type-C, and the pins are DM and DP, and A5, B8 and VBUS, GND. I don't know why the computer is connected through the type-C port. The computer can't find any external devices, and it doesn't show the access of unknown devices. Today, when testing the development board, I also encountered a very strange problem. Originally, the development board was intact, and I burned the case code to enable normal burning. But when I first failed to burn my board, I changed the data line and then burned the development board, and the development board also had the initial problem of this post. Moreover, after connecting the J5 port, only the D2 light is flashing, and D8 and D11 are not on. Now it can't be burned in, and it always shows "unable to connect wire for probe index 1. Error: Wire Ack Fault - target connected?" What's the reason for that? Is the board broken? Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_  Please try to connect all the 10 connectors of the MCU-LINK to the corresponding signal on your RT600 board  VREF is needed to the proper work of the level shifters at the MCU-LINK IF_DETECT is needed to go to gnd of your board to detect the board.  Please try to connect all the 10 pins if possible  Re: When using mculink, debugging can find the probe, but there is an exception when selected Hello@carlos_o I'm glad to see your reply. I didn't connect MCU-LINK to the GND of the board before. After reading your reply, I connected SWDIO, SWCLK and SWO and then connected their GND. But it's a pity that the result is still the same as before. This error is after I click Debug, I see the probe, and it appears after I select the MCU probe, and it will Retrying once. Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_  Apologies for the late reply Thank you for clarifying your setup It seems that the issue is that the RT685 Board you are using are not being recognized by the MCU Link. Could you confirm that both boards are sharing a common ground reference?  Those error you are facing appear when you start debugging or during running the debug?  Re: When using mculink, debugging can find the probe, but there is an exception when selected The following figure is the error that pops up after clicking Debug. Re: When using mculink, debugging can find the probe, but there is an exception when selected Hello@carlos_o I 'm sorry. I regret to reply you that I do not have an RT685EVK board. The chip I use on my board is only the RT685SFFOB. Following your instructions, I connected the RST pin to PIN10 of the MCU-Link on my board, but the issue remains the same. I'd like to briefly describe the current situation. I just used the RT685SFFOB chip on my board. Now I need to carry out a chip test on it to verify whether its function is normal. If it is normal, I'll carry out my own two development. The problem is that when I connect the muc-link to the computer, and then connect my board to the mcu-link, the above problems will occur in Debug. I want to know what causes the above problems and how to solve them. I'm looking forward to your answers. Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_ Please could you try to connect directly the MCU-LINK connector to the SWD 10 pin connector on the RT685EVK board. Let me know if this solves your issue. Re: When using mculink, debugging can find the probe, but there is an exception when selected I carefully checked my board again, and the chip on it is RT685SFFOB I use 1.8V power supply for it Re: When using mculink, debugging can find the probe, but there is an exception when selected The picture shows my connection status   Re: When using mculink, debugging can find the probe, but there is an exception when selected Hello @carlos_o After reading your reply Yes, I am using the MIMXRT685-EVK. I provide independent power supply for the board, and connect the MCU-LINK to the computer via USB. Then, I connect my board using the target debug connector. For the SWD target connection header, I only use SWDIO, SWO, and SWCLK. After that, the situation shown in the above figure will occu. Re: When using mculink, debugging can find the probe, but there is an exception when selected Hi @Yu_  Thanks for your question Are you using a custom board or the MIMXRT685-EVK? Are you using an external power supply for the board? or are you using the MCU-Link? Another thing to mention is the Additional information included at the MCU-Link User Manual [MCU-Link Base standalone Debug Probe, Page 7] Re: When using mculink, debugging can find the probe, but there is an exception when selected Hello! Any updates on this case? I have exactly the same message, when using a working functional debugger but on another PC. I think this problem is related to communicating with the debugger MCU-Link itself, (meaning that leaving it connected to a board/MCU or unconncted would give same error. At that point it would be an error of Could not connect to Target, instead of the current error). So i am very proned to think about a specific PC problem, either drivers or USB COM, however i haven't managed to fix this issue, even though i have tried many different things to fix. Re: When using mculink, debugging can find the probe, but there is an exception when selected You should start your own thread for your specific issue rather than hijacking a months-old one.

ECSPI1 does not generate expected SPI clock on custom board Hi Team, We are working with an i.MX8MP custom board based on the i.MX8MP EVK configuration. On the i.MX8MP EVK, we have an SPI device connected through ECSPI2. With the existing EVK Device Tree configuration, SPI communication is working correctly, and we can observe the expected SCLK waveform on the oscilloscope. On our custom board, the SPI interface is connected to ECSPI1 instead of ECSPI2. We therefore modified the Device Tree configuration to use ECSPI1. However, with ECSPI1, we are not able to observe the expected/correct SPI clock pulses on the SCLK pin. We have tried several different Device Tree configurations, but the issue remains. 1. ECSPI1 configured similar to the existing ECSPI2 configuration We changed the controller from ECSPI2 to ECSPI1 and created the corresponding ECSPI1 pinctrl group, including SCLK, MOSI, MISO and CS. 2. Separate CS pinctrl group We also tried defining a separate pinctrl_ecspi1_cs and using it along with the ECSPI1 pinctrl group. 3. Explicit ECSPI1 pinmux configuration We also tried explicitly defining the ECSPI1 pins. However, with ECSPI1, we are still unable to observe the expected SPI clock pulses. We would like to know when configuring ECSPI1 on i.MX8MP, are there any additional Device Tree or pinctrl changes required apart from enabling &ecspi1 and configuring the ECSPI1 SCLK/MOSI/MISO/CS pins? In particular, is there any ECSPI1-specific pinctrl, clock, IOMUX, or other Device Tree configuration that needs to be added for ECSPI1 to operate correctly? The same SPI setup works on ECSPI2, so we would like to understand whether there is any additional configuration required when moving the interface from ECSPI2 to ECSPI1. Thanks in advance for your guidance. Re: ECSPI1 does not generate expected SPI clock on custom board Hi ,  Please find the dts file attached Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  Please share your dts file about ECSPI1.  B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  I have checked your dts file, I found the following errors： 1. ECSPI pins have been reused, causing a pin usage conflict. Please remove this part or use other pins for reuse.     pinctrl_ecspi1: ecspi1grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK       0x48             MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI       0x48             MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO       0x48         >;     };     pinctrl_uart3: uart3grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX      0x140             MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX      0x140             MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS      0x140             MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS     0x140         >;     }; 2. The ECSPI1 chip select (CS) configuration is contradictory. Please change it to the following code.     pinctrl_ecspi1_cs: ecspi1cs {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09     0x40000         >;     }; B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @pengyong_zhang, Please find the below observations 1. Logic analayser result when used the suggested changes 2. Another observation when used the below patch on top of the previously attached dts the above graph observed with this changes pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x80 MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x80 MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x80 >; }; With the suggested changes, we could see the clock is not as expected. 

SC18IS606 - reading back issue Hello, We have I2C to SPI converter SC18IS606 manufactured by NXP. We are using Raspberry Pi to write and read data to SC18IS606 through I2C. The device SC18IS606 is shown listed in the Raspberry Pi OS terminal and is detected through “i2cdetect -y 1” command in the terminal with correct address. As a simple test, we tried write operation (set/clear) to the GPIO 0 to 2 and make them toggle in the loop with some delay in between. This part is working.  But when we read back from the SC18IS606, it reads 0x80 instead 0x00. Latter we tied the pins MISO and MOSI together making SPI loop back using a jumper wire. We are sending patterns 0x00 through 0x07 to SPI. The read back data we got is 0x80 through 0x87. The MSB is always 1 when we read back SPI in the loop back test. We have tested two SC18IS606 chips which we bought from Mouser and we got the same result.   Any idea what could be the issue ? How to fix ? 

S32K388 JumpApp Only runs with core 0 active. I created a bootloader program and placed it at addresses 0x400000 to 0x420000. Whenever I update the program via serial port, only Core 0 continues to run. How can I enable the other cores to also run? S32_SCB->VTOR = 0x00422000;     __asm volatile(         "msr msp, %0"         :         : "r"(appStack)         : "memory");     ((pFunction)appEntry)(); Re: S32K388 JumpApp Only runs with core 0 active. Hi @zhangyu5454, You can enable the cores in the startup code. Refer to the startup code (startup_cm7.s) of the default S32DS project. For example, if CM7_2_ENABLE == 1, the startup code will enable CM7_2 during system startup. The cores can also be enabled later from the CM7_0 application, either by configuring the relevant registers directly or by using the MCU MCAL driver or the Power_Ip driver. Refer to this example: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K358-Multicore-Start-CM7-2-from-CM7-0/ta-p/1923889 BR, Daniel Re: S32K388 JumpApp Only runs with core 0 active. Thank you for your response. I have tried using Power_Ip, but when the line “Power_Ip_Init(&Power_Ip_HwIPsConfigPB);” appears in the program, the debugging process automatically ends. Moreover, even when I don’t press the reset button, the reset light remains illuminated, resulting in the device not being able to operate at all. When I use IP_MC_ME, the program runs normally, but it doesn’t produce any results. The other components also fail to start. This code snippet seems not to work well for model 388. Re: S32K388 JumpApp Only runs with core 0 active. Hi @zhangyu5454, If the MCU goes through a system reset, you need to read the source of the reset. You can call  Power_Ip_GetResetReason(); at the beginning of main() before  Power_Ip_Init(); Likely root cause is the V15 Switched-mode power supply - it must match the HW design. BR, Daniel Re: S32K388 JumpApp Only runs with core 0 active.#S32K388 According to your advice, I will implement it in the int main(void) section. Power_Ip_GetResetReason() was called. However, the test results remain unchanged.   int main(void) { Power_Ip_GetResetReason();         Power_Ip_Init(&Power_Ip_HwIPsConfigPB);     Clock_Ip_Init(&Mcu_aClockConfigPB[0]);         Power_Ip_SetMode(&Power_Ip_aModeConfigPB[0]); while (1) { Re: S32K388 JumpApp Only runs with core 0 active.#S32K388 Hi @zhangyu5454, What is the reset reason then? If I had to guess, it would be a POR/LVR. How is V15 powered on the PCB? Do you configure Power_Ip accordingly? Regards, Daniel Thank you. Re: S32K388 JumpApp Only runs with core 0 active.#S32K388 Thanks for your reply. I don't know much about these functions. Is there any related example or tutorial files? I tried to follow the S32K358 example but didn't succeed. Regarding the V15 power supply, I found that it is generated from an external 3.3V through a transistor controlled by a microcontroller to make 1.5V, with 1.1V also generated under microcontroller control. I also noticed that my hardware design doesn't have a 32.768 crystal oscillator, and the program gets stuck in Clock_Ip_ExtOsc.c in the loop do { SxoscStatus = ((Clock_Ip_apxXosc[Instance]->STAT & SXOSC_SXOSC_STAT_OSC_STAT_MASK) >> SXOSC_SXOSC_STAT_OSC_STAT_SHIFT); TimeoutOccurred = Clock_Ip_TimeoutExpired(&StartTime, &ElapsedTime, TimeoutTicks); } while ((0U == SxoscStatus) && (FALSE == TimeoutOccurred)); Re: S32K388 JumpApp Only runs with core 0 active.#S32K388 Hello @zhangyu5454, I understand that you are using an SMPS on the PCB, so it must be enabled in the Configuration Tool: Regarding SXOSC, make sure it is disabled:

Alternative to Key Import API on i.MX95 (ELE) — need to inject a pre-shared AES key We see in the Readme.md file of the imx-secure-enclave repository the following statement: “Key Import API not supported."(link to repo: https://github.com/nxp-imx/imx-secure-enclave) For our use case, we want to be able to inject a pre shared AES key to ELE so it can be used for cryptographic operations What is the plan for supporting this feature? Is there any alternative you can suggest?

IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure I have configured AE LIMITS with the maximum exposure set accordingly. However, during runtime, the AE algorithm only reaches 66666 exposure at most,and the gain hits its upper limit at this point. Readings via V4L2 confirm that AE exposure reaches less than half of the configured upper limit. When manually configuring exposure via Live Control, the valid exposure can reach 150000,V4L2 exposure can also reach the upper limit. We suspect this issue is related to RowTime. We modified the Row Time parameter inside AE Dister, but this change shows no visible effect; the auto exposure performance remains exactly the same as before. We would like to know what adjustments are required to allow the AE algorithm to reach the configured maximum exposure under low-light conditions.