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.

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: 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

LIN to CAN in MBD I am using NXP MBD blockset and getting feedback from a LIN slave on CANoe using LIN receive frame block,and i am trying to publish the LIN feedback in CAN bus using CAN send block.To do this,I am using demux to the data which is giving me an dimension error and i am unable to use ldf file also and i tried storing the data in a storage and reading it from the storage,which doesnt give me any error but i am unable to publish the data. Re: LIN to CAN in MBD Hello, What MATLAB do you use? What toolbox do you use? If possible, can you try to send a snippet of the model and the received error? Best regards, Sorin Bancila

MAC Forwarding Configuration on the SJA1110 switch Hello, I would like to set up an L2 Forwarding rule in the SJA1110 switch where: - The traffic is received at Port 7, source MAC address: 00:00:01:00:00:10, destination MAC address: 00:00:01:00:00:50, VLAN ID 10, PCP 7; - The traffic is then forwarded to the Port 5 of SJA1110 switch for output. When the SJA1110 detects that a packet with destination MAC address 00:00:01:00:00:50 is injected from the port 7, it only needs to forward this packet out through the port 5; the gating on the port 5 can be controlled simply by identifying the PCP in the packet.   However, I am not sure how to configure it on the SJA1110 SDK for S32DS. I have tried to set a new L2 Lookup Table entry as follows: Also have tried to set VING_MIRR and VEGR_MIRR in the VLAN Lookup Table: Also have set the MIRR_PORT to 5 in General Parameters: In the MAC Configuration Table, I have set the ING_MIRR of port 7 to 1 and the EGR_MIRR of port 5 to 1. But it did not work. What is the correct approach for this configuration? Thank you very much for your support, Guilherme Re: MAC Forwarding Configuration on the SJA1110 switch Hello @GuilhermeS32G , Yes, that is correct. Since the SJA1110 SDK field does not accept the colon-separated MAC address format, the MAC address 00:00:01:00:00:50 can be entered either as a decimal or hexadecimal value, i.e. 16777296 or 0x1000050. Leading zeros do not change the value, so 0x1000050 is equivalent to 0x000001000050. Regarding the MASK field, the mask defines which parts of the L2 Lookup key are used for matching and which parts are treated as wildcards. A bit set to 1 means that the corresponding bit is compared, while a bit set to 0 means that the corresponding bit is ignored. So if you want to match only the MAC address and ignore IOTAG, VLANID and SRCPORT, your proposed mask is correct: MASK = 0x0000FFFFFFFFFFFF0 In this case, the L2 Lookup entry would match the configured MACADDR regardless of the ingress port and VLAN ID. For your original use case, where you want to match: VLANID = 10 MACADDR = 00:00:01:00:00:50 SRCPORT = 7 but not explicitly match IOTAG, the recommended mask would be: MASK = 0x0FFFFFFFFFFFFFFFF Then the L2 Lookup entry should be configured as follows: VLANID = 10 MACADDR = 0x000001000050 SRCPORT = 7 DESTPORTS = port 5 MASK = 0x0FFFFFFFFFFFFFFFF Please also remember that the final destination vector from the L2 Lookup Table is still filtered by the L2 Forwarding Table. Therefore, for traffic received on port 7, port 5 must also be allowed in the corresponding REACH_PORT configuration. Best regards, Pavel Re: MAC Forwarding Configuration on the SJA1110 switch Hello @PavelL , Thanks for your support once again. Just to clarify, in the SJA1110 SDK for S32DS, the field MACADDR supports inputs as integer or hexadecimal, I am not able to type: 00:00:01:00:00:50 due to the colons. So I may convert it to the integer format: 16777296 or use as input 0x1000050. Is that correct? Then, for the MASK field, it seems to support integer format with a value between 0 and  36893488147419103231 (0x1FFFFFFFFFFFFFFFF in hexadecimal). But I did not understand very well these MASK wildcards. If I want to match the MAC Address only, but not source port and VLAN ID should I use: MASK = 0x0000FFFFFFFFFFFF0 ? And what about if I want to match to VLAN ID 10 and source port 7? Best regards, Guilherme Re: MAC Forwarding Configuration on the SJA1110 switch Hello @GuilhermeS32G , Please refer to the relevant chapters in UM11107 and AN12925 for the detailed description of the SJA1110 forwarding tables. The used field names follow the terminology used in the S32DS SJA1110 SDK configuration.   For this use case, the correct approach is to use the L2 Lookup Table, not the mirroring functionality. If the requirement is to forward frames received on port 7 with destination MAC address 00:00:01:00:00:50 and VLAN ID 10 to port 5, you should create an L2 Lookup Table entry matching this destination MAC address, VLAN ID and source port and set DESTPORTS to port 5. Please also check the following points: 1. The MACADDR field should correspond to the MAC address you want to match. For your example, this should be the destination MAC address 00:00:01:00:00:50, not a different value. 2. Please review the MASK field. The mask defines which parts of the L2 lookup key are compared. For an exact match, the mask must not wildcard the relevant fields such as MAC address, VLAN ID and source port. Based on UM11107, MASK is composed of the following bits: 3. Please check the L2 Forwarding Table as well. The destination vector from the L2 Lookup Table is still filtered by the REACH_PORT field for the ingress port. Therefore, for traffic received on port 7, port 5 must be allowed in the corresponding L2 Forwarding Table entry. 4. The mirroring-related settings such as VING_MIRR, VEGR_MIRR, MIRR_PORT, ING_MIRR and EGR_MIRR are not required for normal forwarding. These settings are intended for traffic mirroring, not for defining the standard forwarding path. Regarding PCP 7, if the frame is already VLAN-tagged with PCP 7, the forwarding decision can still be made by the L2 Lookup Table. The PCP can then be used by the egress priority/scheduling/gating configuration on port 5. It does not need to be part of the L2 Lookup rule unless you specifically want to classify traffic based on PCP as well. Best regards, Pavel

rt1189 Boot Flow 1. As shown in the figure, does the "Authenticate Image" process verify the hash value during the SHA-512 hashing stage?  2. If I set the hash value, will the BootROM verify the image integrity? And if the BootROM verification fails, will it enter recovery mode? Re: rt1189 Boot Flow 1. Is hash verification enabled only when the signature authentication feature is enabled? How can hash verification be enabled independently? How can the device be transitioned into the OEM_CLOSED lifecycle state? 2. I will enable the Recovery Boot fuse. 3. My goal is to use an unencrypted image. The Boot ROM should calculate and verify the image hash. If the hash verification fails, the Boot ROM should enter the recovery boot flow and boot the recovery image from the LPSPI NOR Flash. Re: rt1189 Boot Flow Hi @yanyanwang , A1: Yes. RT1180 uses AHAB with two authentication layers: Signature layer: ECDSA (SHA-256 / SHA-384) verifies the Container header and image array entry (which stores each image's Hash). Hash layer: The ROM re-computes the digest of the loaded image body and compares it against the Hash stored in the image array entry. The SHA hashing stage in your figure is exactly this mandatory integrity check, which does verify the hash value. A2:The ROM always computes and compares the hash, but whether a failure is enforced depends on the device life cycle: the out-of-fab default is the Open configuration, where authentication runs but all authentication errors are ignored and the image still executes. Only after the device is moved to OEM_CLOSED will a hash mismatch actually block boot. Whether it enters recovery depends on the Recovery Boot fuse. if enabled, a primary-boot authentication failure triggers a re-load and re-authentication from the recovery device; if not enabled, the flow falls through to Serial Downloader / Fatal Mode / reset loop. Best regards, Gavin Re: rt1189 Boot Flow As shown in the figure above, if I only sign the image and do not encrypt it, will it be able to go through the bootrom verification flow? Additionally, with oem_close enabled, will it still be able to enter the bootrom verification flow?     Re: rt1189 Boot Flow Please find answers to your two questions below: 1. Can a signed-only (non-encrypted) image go through the BootROM verification flow? Yes. In the RT1180 AHAB, signing (authentication) is the mandatory part of secure boot, ensuring image authenticity and integrity, while encryption (OTFAD/IEE) is an independent, optional anti-cloning feature and is NOT a prerequisite for verification. Therefore, a signed-only image will go through the full AHAB signature verification flow normally, this is also the standard approach in NXP's official SPSDK rt118x_secure_boot example. 2. With oem_close (OEM_CLOSED) enabled, will it still enter the verification flow? Yes, and verification becomes mandatory. Recommendation: Before performing oem_close, please program the signed image in the OEM_OPEN state first and confirm it boots successfully with no ELE events, then close the device (SRKH is irreversible once fused) to avoid bricking the part. (Please refer to: i.MX RT1180 Security Reference Manual. After signing the NDA through your company account, submit a request to the online technic sales representative.)

FRDM-iMX93: MCU-Link Pro cannot connect to Cortex-M33 core via SWD Hi all, I have recently started developing with a FRDM i.MX 93 and purchased an MCU-Link Pro for Cortex-M33 debugging. I am trying to set up M33 debugging using the MCU-Link Pro connected via a SWD adapter to the external debug pin header on the board. Setup: Board: FRDM-IMX93  (MIMX9352) Probe: MCU Link Pro  with SWD Adapter  IDE: MCUXpresso for VS Code SDK: SDK_26_06_00_MIMX9352xxxxM Problem: After doing a firmware update on the probe, it is being recognised correctly by LinkServer, but when I try connecting to the M33 core it fails with Ee(42). Could not connect to core. What I've done: Connected the header pins correctly(P14) to the adapter and selected the right debug port on the MCU Link Pro (J7). Disconnected the R3017 & R3018 resistors. Exported the hello_world example from the SDK, built it successfully, and attempted to start a debug session in MCUXpresso for VS Code but it fails immediately: My launch.json configuration is the following:  { "configurations": [ { "type": "mcuxpresso-debug", "name": "Debug", "request": "launch", "cwd": "${workspaceFolder}", "executable": { "elf": "${workspaceFolder}/debug/mcimx93evk_hello_world_cm33.elf" }, "stopAtSymbol": "main", "probeSerialNumber": "WWCHLV4PL2JZX", "isAttach": true, "skipBuildBeforeDebug": false, "gdbInitCommands": [ "set remotetimeout 600", "set debug-file-directory", "set non-stop off" ], "gdbServerConfigs": { "linkserver": { "device": "MIMX9352:MCIMX93-EVK" }, "segger": {}, "pemicro": {} }, "showDevDebugOutput": "none" } ] } Ran the LinkServer GDB server from the command line and got the following output (key lines highlighted below): INFO: Selected device MIMX9352xxxxM:MCIMX93-EVK INFO: Selected probe #1 WWCHLV4PL2JZX (MCU-LINK Pro (r1CF) CMSIS-DAP V3.172) INFO: Firmware update: not required GDB server listening on port 2332 in debug mode (core cm33) INFO: Connected to core cm33 ... Wc: DpID = 00000000 <-- SWD DP ID reading as zero Wc: Error: Wire not connected <-- repeated throughout Wc: Error: Wire not connected Wc: Error: Wire not connected ... Wc: ... send a request to EdgeLock secure enclave to release the Cortex-M33 TROUT Wc: Resp1 : 0x000000C8 Wc: Resp2 : 0x000000C8 Wc: SCR = 0x000000C8 Wc: M33 kicked off Wc: Error: Could not read registers (0xA5) ... Ed:02: Failed on connect: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port INFO: Disconnected from core cm33 The full repeated Error: Wire not connected and DpID = 00000000 suggest the SWD physical connection is not working, even though the ELE (EdgeLock enclave) responses appear non-zero. Tried different boot mode switch settings on the board. Tried this guide and got to the Flash the Binary using UUU Tool step, but when I tried starting fastboot I got the following error: Failed to configure default pinctrl This stopped progress on that path as well. Questions: DpID = 00000000 and Error: Wire not connected: is this a physical wiring fault, or can it also indicate the M33 is still held in a state where SWD is not reachable even after R3017/R3018 are removed? Does VTref need to be connected on the MCU-Link Pro SWD adapter for this board? Could a missing VTref cause this symptom? If VTref need to be connected, does it need to be connected to a 3V3 or a 1V8 (it is a topic that has been raised frequently on forums)? Is P14 + J7 the correct header/port combination for M33 SWD access on the FRDM-IMX93, or is there another configuration that needs to be done on the MCU Link Pro and I have missed it?  The ELE responses show 0xC8, does that value indicate a problem with releasing the M33? Regarding the UUU fastboot error (Failed to configure default pinctrl), is there a specific U-Boot image or boot switch configuration required for fastboot to work on the FRDM-IMX93? References & resources I consulted: Before posting I went through the following resources, which shaped the steps I tried: https://community.nxp.com/t5/i-MX-Processors/How-to-Enable-SWD-Debug-on-the-FRDM-IMX91-and-FRDM-IMX93-Boards/m-p/2096804 https://community.nxp.com/t5/i-MX-Processors/Debugging-in-FRDM-i-MX-93-using-J-Link/m-p/2297828 How to Flash and Debug Cortex-M33 and Cortex-A55 on FRDM-i.MX93? AN14120: Debugging Cortex-M with VS Code on i.MX 8M, i.MX 8ULP, and i.MX 9 | NXP Semiconductors Any guidance or a working configuration example would be greatly appreciated. Thanks in advance! Re: FRDM-iMX93: MCU-Link Pro cannot connect to Cortex-M33 core via SWD Hi @AndreeaPascu, Thank you for contacting NXP Support! To debug the i.MX93 FRDM, you must first remove two resistors that interfere with the SWD signals. Without this modification, the debugger may not be able to communicate properly with the target device. Another important point is that, by default, the MCU-Link Pro must be flashed with the Segger firmware before it can be used to debug the i.MX93. Once the Segger firmware is installed, the MCU-Link Pro can be used as a standard J-Link debug probe. I published the following guide describing all the required hardware modifications and software setup steps needed to debug the i.MX93 using the MCU-Link Pro. I hope you find it useful: Getting Started with FRDM-IMX93 and MCU-LINK Pro for M Core Debugging  Best regards, Chavira

S32DS ARM 2018 R1 许可证延期申请 你好我的许可证已经过期，因此我想申请延期。 Re: S32DS ARM 2018 R1 许可证延期申请 谢谢

TJA1043问题咨询 NXP的各位专家们好： 我们项目使用了TJA1043芯片有两个问题需要咨询一下： 1、我们控制器进入休眠时，MCU会拉低STBN和EN引脚1043进入standby模式，此时1043的VBAT是24V，VCC是5V、VIO是3.3V，此时INH应该还是高电平24V吧？这个时候如果CAN总线上来了CAN报文，1043将被唤醒，INH上的电平在此期间（standby到normal）会一直是高电平还是说会有高-低-高跳变的动作？ 2、在24V系统中，短电源测试时，电源电压是32V，在使用TJA1043且CAN配置为终端节点（120ohm）的控制器，CANH短电源测试时，根据AH1014的fig39： Ip最大能到多少？上图红框中的电阻阻值是多少？相应的考虑到WCCA，我的RT/2电阻的功率应该选多大的？ 还请帮忙解答，不胜感激！ TJA1043  Re: TJA1043问题咨询 get，十分感谢您的回复！ Re: TJA1043问题咨询 Hi 1:一直是高电平 2：正常应用：60 Ω，0.1 W / 0.125 W 通常可以满足正常通信功耗。RT/2 功率由客户的 short-to-battery test condition 决定，NXP 文档中的图是说明 failure mechanism，不是指定 RT/2 power rating。对于一切datasheet以外的规格参数我们都无法提供对于TJA1043来讲

MCXA185 Reading values of a potentiometer MCXA185 LPADC Potentiometer Reading – Looking for a More Stable ADC Value I am working with an NXP MCXA185 and using the LPADC to read a potentiometer connected to P2_0 / ADC0_A0. My current implementation uses: ADC0 / ADC0_A0 High-resolution conversion mode LPADC hardware averaging of 128 samples Long ADC sample time (kLPADC_SampleTimeADCK19) One ADC reading every 1 ms (1000 Hz) Software-triggered conversions A block average of 100 samples The resulting average is updated every 100 ms So effectively, each value used in the block average has already been averaged by the ADC hardware over 128 conversions. Current approach cmdConfig.conversionResolutionMode = kLPADC_ConversionResolutionHigh; cmdConfig.hardwareAverageMode = kLPADC_HardwareAverageCount128; cmdConfig.sampleChannelMode = kLPADC_SampleChannelSingleEndSideA; cmdConfig.sampleTimeMode = kLPADC_SampleTimeADCK19; Then every 1 ms: LPADC_DoSoftwareTrigger(POT_LPADC_BASE, (1U << POT_LPADC_TRIGGER_ID)); while (!LPADC_GetConvResult(POT_LPADC_BASE, &result)) { /* Wait for conversion */ } s_blockSum += result.convValue; s_sampleCount++; if (s_sampleCount >= 100U) { s_lastAverage = (uint16_t)(s_blockSum / 100U); s_blockSum = 0U; s_sampleCount = 0U; } My question Is this a good approach for getting a stable potentiometer value, or is there a better ADC filtering/averaging strategy? In particular, I am wondering about: Is using 128-count hardware averaging + 100-sample software averaging excessive for a potentiometer? Does this actually provide useful additional noise reduction, or am I just increasing the response latency? Would it be better to use a smaller hardware average, such as 16 or 32 samples, and then use a software filter? Would an IIR/exponential moving average be better than a 100-sample block average for a potentiometer because it provides a smoother value while responding faster to knob movement? Is kLPADC_SampleTimeADCK19 appropriate for a typical potentiometer, or should I use a different sample time? Are there any MCXA185-specific LPADC settings that I should enable for better stability? Is polling the ADC result inside a 1 ms function a reasonable implementation, or would a hardware timer trigger + ADC FIFO/interrupt approach be preferable? Pin configuration I am currently using: cfg.pullSelect = kPORT_PullDisable; cfg.driveStrength = kPORT_LowDriveStrength; cfg.passiveFilterEnable = true; cfg.inputBuffer = kPORT_InputBufferDisable; The potentiometer is connected as a voltage divider, with the wiper connected to P2_0 / ADC0_A0. I am mainly interested in getting a value that is: Stable when the potentiometer is not moving Responsive when the potentiometer is turned Not unnecessarily delayed by excessive averaging Resistant to small ADC/wiper noise I would appreciate feedback on whether my current 128 hardware average + 100-sample block average approach is appropriate, and what filtering strategy you would recommend for this application. Analog(ADC|CMP|DAC|OpAmps) MCXA

Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) We cannot rotate the Platform SCP03 keys on SE050C1 from the NXP factory (OEF) keys to our own device-derived keys. PUT KEY is rejected in every variation we have tried, on a factory-fresh part, with both Plug&Trust 3.0.6 and 4.7.1. A Platform SCP03 session with the factory keys works correctly — we can open it and run applet commands (GetVersion, GetRandom, ReadObject, WriteBinary) successfully. Only PUT KEY fails. We would like to know the correct APDU sequence to rotate Platform SCP03 keys on this part, and ideally a reference implementation. Setup: Secure element SE050C1 (SSS_PFSCP_ENABLE_SE050C1 = 1) ATR 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F ("JCOP4 ATPO") Host MCU ESP32-S3, ESP-IDF v5.3.4 Transport T=1 over I2C (T1oI2C) Middleware Plug&Trust — tested 3.0.6 and 4.7.1, identical behaviour both mini  Auth SE05X_Auth=PlatfSCP03, SSS_HAVE_SE05X_AUTH_PLATFSCP03 Host crypto mbedTLS The part is factory-fresh: it has never been successfully rotated , and it authenticates with the SE050C1 OEF keys from ex_sss_tp_scp03_keys.h. what are we trying to do: Rotate the Platform SCP03 key set (ENC / MAC / DEK) from the factory OEF keys to device-unique keys derived on the ESP32 (PBKDF2-HMAC-SHA256 over the ESP32's eFuse-resident HMAC key), so that only that specific host MCU can open a Platform SCP03 session with its SE050. what is working: Opening a Platform SCP03 session with the factory keys succeeds, and commands inside it work:scp :DEBUG:Authentication Successful!!! APDU :DEBUG:GetVersion [] -> 90 00 APDU :DEBUG:GetRandom [] -> 90 00 APDU :DEBUG:WriteBinary [] -> 90 00 So the channel, keys, and secure messaging are all functioning. waht fails: case A :  PUT KEY is rejected with 6A80(Wrong data). Command header and plaintext data field (before SCP03 wrapping): hdr : 80 D8 0B 81 Lc=70 data: 0B <- key version number 88 11 10 <16 bytes ENC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes MAC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes DEK enc. under DEK> 03 <3-byte KCV> Key values are encrypted with the current (factory) DEK using AES-CBC with a zero IV; KCV is the first 3 bytes of the AES encryption of a 16-byte block of 0x01 under the new key. Case B: ISD Selected If we first select the ISD: GP_Select(A0 00 00 01 51 00 00 00) -> 90 00 response: 6F 10 84 08 A0000001 51000000 A5 04 9F 65 01 FF then the same PUT KEY is rejected with 6982(security not satisfied)  instead of 6A80. This suggests the ISD does recognise the command but requires a secure channel — and that in Case A the command was going to the SE050 applet, which has no D8 instruction. However, GP_Select() in the middleware sends a plaintext APDU, which tears down the existing SCP03 channel. Our attempts to re-establish SCP03 after selecting the ISD (calling nxScp03_AuthenticateChannel() again, having reset fp_Transform / authType / pdynScp03Ctx on the session) fail: scp :WARN :nxEnsure:'status == kStatus_SSS_Success' failed. At Line:148 Function:nxScp03_AuthenticateChannel case C: Sending via DoAPDUTxRx_s_Case4_ext (with Le) returns 6700 (wrong length), consistent with the ISD's FCI advertising 9F 65 01 FF (max data field 255). waht already ruled out: Each of these was tested and made no difference to the result: Variable Values tried P1 0x00 (create new), 0x0B (replace current), 0x11 (target version) Leading KVN byte in data field present / absent APDU case Case4 (short) / Case4_ext (extended) Key block structure 88 11 10 03 Key wrapping AES-CBC zero IV under current DEK (equivalent to ECB for one block) KCV method AES of 16×0x01 under the new key, first 3 bytes Middleware version Plug&Trust 3.0.6 and 4.7.1 DEK source verified the KEK is the same key set that opens the session With the applet selected all variants give 6A80; with the ISD selected all short-form variants give 6982. Question: What is the correct APDU sequence to rotate the Platform SCP03 keys on SE050C1? Specifically: is PUT KEY expected to be sent to the Issuer Security Domain, or to the SE050 applet? If it must go to the ISD, how should the Platform SCP03 channel be established against the ISD using the Plug&Trust middleware? Is EX_SSS_BOOT_SKIP_SELECT_APPLET the intended mechanism, and if so what is the correct call sequence (SELECT ISD → INITIALIZE UPDATE → EXTERNAL AUTHENTICATE → PUT KEY)? Is the key data field format above correct for this part, in particular the key type coding, the length encoding, the DEK wrapping mode, and the KCV algorithm? Our Plug&Trust package defines INS_GP_PUT_KEY (0xD8) in nxScp03_Const.h and global_platf.h, but contains no implementation and no example that uses it. Could you provide the Platform SCP03 key rotation example / demo (the equivalent of what se05x_Delete_and_test_provision is for provisioning), or point us to it in the full SDK? Could you provide AN12436 (referenced in ex_sss_auth.h as the source of the OEF Platform SCP03 keys), or the application note that documents key rotation for this part? Background — why this went unnoticed For transparency, this is a problem we created for ourselves and only recently detected. Our provisioning code called PUT KEY and then discarded the return status: sw = gp_put_key_using_nxp_middleware(se, DERIVED_SCP03_KEYVER, ...); /* status never checked */ mark_rotated(se, DERIVED_SCP03_KEYVER); /* writes "rotated" marker */ ESP_LOGI(TAG, "SCP03 keys rotated successfully"); /* printed unconditionally */ Because the marker write (WriteBinary) does succeed, every device ends up with a "rotated" flag set while its Platform SCP03 keys are still the factory ones, and provisioning reported success. We have since added the status check, which is how we discovered PUT KEY has never actually succeeded on any unit. We are not asking for help with that part — it is fixed. We mention it only to explain why we are raising this now rather than at bring-up, and to make clear that the part is genuinely unrotated rather than in some partially-rotated state. SE050 Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) Hi @Rutwik0409 , Based on the information provided, the SE050C1 appears to be working correctly at the applet level:  SELECT  ,  GetVersion  ,  GetRandom  ,  ReadObject  , and  WriteBinary  all succeed over Platform SCP03. Therefore, this does not look like a basic transport, T=1, SCP03 key, or secure-messaging failure. Since you are using ESP32-S3 with a custom T=1 over I²C transport, this is likely a porting/integration issue around the GlobalPlatform Security Domain SCP03 session, not evidence that SE050C1 does not support Platform SCP03 key rotation. For Platform SCP03 key rotation , the  PUT KEY  command is a GlobalPlatform Security Domain operation , not an SE050 IoT applet command. The documented sequence is: Select the Security Domain / SSD. Open the Platform SCP03 secure channel using  INITIALIZE UPDATE  /  EXTERNAL AUTHENTICATE  . Send  PUT KEY  to update the Platform SCP03 key set. This also matches the behavior observed: When the SE050 applet is selected,  PUT KEY  returns  6A80  , which is consistent with sending a GlobalPlatform command to the wrong target. When the ISD is selected but no secure channel is established to that domain,  PUT KEY  returns  6982  , which is consistent with “security status not satisfied.” So the main point to check is not only whether Platform SCP03 works to the SE050 applet , but whether the middleware is opening Platform SCP03 against the correct Security Domain before issuing  PUT KEY  . NXP provides a reference demo for this exact operation: se05x_RotatePlatformSCP03Keys The demo is specifically described as demonstrating authentication with the default Platform SCP keys and rotation of those keys to user-defined keys.  Our recommendation is to avoid manually constructing the  PUT KEY  APDU at first, and instead compare against the NXP reference implementation. Here I would first suggest that you verify the implementation using NXP's official reference paths—such as the `se05x_RotatePlatformSCP03Keys` demo found in the Zephyr + nano package so that your ESP32 MCU is well supported without any porting work. This demo serves as NXP's reference implementation for platform SCP03 key rotation. The current issue suggests that the `PUT KEY` command is being sent to the wrong target, or that the corresponding platform SCP03 secure channel was not correctly established after selecting the ISD/SSD. The fact that SCP03 communication with the SE050 applet is functioning correctly does not guarantee that the `PUT KEY` process at the GlobalPlatform Security Domain level has been correctly set up. Please refer to https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rst for more details.   Hope that helps,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

PN560 Hardware ID Hello NXP, I’m trying to identify which NXP chip corresponds to the Hardware ID ACPI\VEN_1FC9&DEV_3002. Could anyone also confirm which Hardware ID is expected for the PN560? Thank you in advance for any information or documentation references. Re: PN560 Hardware ID Hello Eduardo, Thank you for your reply and for your time. I would just like to note that this information appears to be publicly visible in Device Manager on laptops, tablets and any other devices equipped with these NFC readers. However, I understand your position and I will leave the matter here. Thank you again for your support. Best regards Re: PN560 Hardware ID Hello @johjoh Hope you are doing well. My apologies, information about these devices is not public and this is not the proper path to discuss any information about them. For further support, could you please contact your NXP Sales Representative or the person that provided you with information on these devices in a first place? Regards, Eduardo.

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? 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 .

Important question about motor control Hi, I am using the board S32K344MINI-EVB with driver GD3000 and Sunrise motor. I have tested a program where you can manage the speed of motor with the project "S32K344:mc_pmsm_1sh_s32ct". I have different questions because I want to prove new options.    1. I want to use the evaluation board to realize the control of motor, so I want to do the control FOC (2 controllers PI) but I want to simulate the plant (the motor PMSM) and the power electronics (GD3000). In this example, how I can modify it to simulate the plant but continue perfoming the control from the evaluation board? I suppose that I have to change something of state machine block but I don´t know what I have to change.  2. Could you tell me the pins that I am using to send different signals from GD3000 (driver of motor) to motor PMSM? I have information in your website about this but I don´t if that´s the case. I send you a pdf with this information, although it´s not yhe same board I think the pins are the same (INFO_Driver_MOtor.pdf). Thank you for all,  Jon Ander Amante   Re: Important question about motor control Hi, @JonAnder_Amante, You can find the answer to the initial thread here: missing Motor Control PMSM example in the 1.60 version of the S32K3 MBDT Best regards, Dragos Re: Important question about motor control Hi @JonAnder_Amante , In order to use the S32K344MINI-EVB, the following modifications are needed on the board: 1. Remove resistors R396 and R397, located on bottom PCB near DC Jack: 2. Populate with 0 (zero) Ohm  resistors R413, R414 and R418 located near J4 connector: And also because the VDD_HV_A is supplied with 3.3V instead of 5V: We need to modify the parameters for the Udc and Idc Gains: %% Application scales MBD_I_MAX = 20.625; MBD_U_DCB_MAX = 29.7;   After this we can connect the DEVKIT-MOTORGD (GD3000) board on top of S32K344MINI-EVB: Now Open FreeMASTER and run the example and check iABC waveforms:  Best regards, Stefan V. Re: Important question about motor control Hi,  Thank you for your reply. At now, I want to realize only the control of FOC in the board "S32K344 MINI-EVB", that is to say, I have another block of the plant that it´s represented the motor PMSM (Sunrise) with power electronics but I have to use the control of FOC with MBD. In this example, could you tell me which block I have to keep and what blocks I have to remove? I think that I have to keep the current loop and speed loop in the block called "state machine" but the problem is there are many variables and different blocks with different jumps between them.  Basically, my project´s target is to use the same control of FOC from this project but to use another plant. Thank you for all,  Jon Ander Amante Re: Important question about motor control Hi @JonAnder_Amante , I am not sure i understand what other plant you want to use, another motor maybe? We currently support the Sunrise Motor with parameters in s32k344_mc_pmsm_2sh_s32ct_data.m and Linix Motor with parameters in s32k344_mc_pmsm_2sh_s32ct_data_linix.m If you have any other motors, you will need to modify the parameters accordingly in data.m files, then do a clean Build. Have a good day, Stefan V. Re: Important question about motor control Hi, 1. I want to use Sunrise motor with its parameters but my question is if there is any block in SImulink that represents the plant because I want to have a block of the plant on one hand and the controller on the other.  2. Moreover, I send you the parameters of motor Sunrise and I don´t know if you can confirm that the dates are true. PARAM_Rs = 0.192; % Resistencia del estator [Ohms] PARAM_Mpp = 2; % Pares de polos [-] PARAM_Ld = 0.000096; % Inductancia eje D [H] PARAM_Lq = 0.000107; % Inductancia eje Q [H] PARAM_Ke = 0.005872; % Constante Back-EMF [V.sec/rad] PARAM_J = 0.12e-4; % Inercia [kg.m2] PARAM_r32_F_IP_Wb_motor1 = 0.00518; % Flujo magnetico   %% Parametros diseño LAZO DE CORRIENTE %Loop Bandwidth = 150 [Hz] %Loop Attenuation = 1 [-] %Loop sample time = 0.0001 [sec] %----------------------------------------------------- f_cutoff_current = 150; % Frecuencia de corte deseada [Hz] w0_current = 2 * pi * f_cutoff_current; % Frecuencia natural [rad/s] xi_current = 0.707; % Amortiguamiento Ts_current = 1 /fsw; % Tiempo de muestreo   % Cálculos eje D Kp_D = (2 * xi_current * w0_current * PARAM_Ld) - PARAM_Rs; Ki_D = (w0_current^2) * PARAM_Ld; % Cálculos eje Q Kp_Q = (2 * xi_current * w0_current * PARAM_Lq) - PARAM_Rs; Ki_Q = (w0_current^2) * PARAM_Lq;   % Current Loop Control (Calculado según NXP GFLIB) %---------------------------------------------------------------------- MBD_CLOOP_LIMIT = 0.9;   % Eje D (D-axis) MBD_D_CC1SC = Kp_D + (Ki_D * Ts_current / 2); MBD_D_CC2SC = -Kp_D + (Ki_D * Ts_current / 2);   % Eje Q (Q-axis) MBD_Q_CC1SC = Kp_Q + (Ki_Q * Ts_current / 2); MBD_Q_CC2SC = -Kp_Q + (Ki_Q * Ts_current / 2); 2. I send you the scheme that I am using in Simulink. My idea is  My idea is to not use the physical motor and to simulate it with the green block you see in the photos. and to perform the control (current loop and speed loop) with the MCLIB blocks.   Thank you for all; Re: Important question about motor control Good morning, I am using one of your evaluation boards, specifically the FRDM-A-S32K344 board, with the ‘S32K344_mc_pmsm_1sh_s32ct’ example in MATLAB and Simulink. The problem I’m having is that when I connect the interface to the Freemaster, some variables don’t appear and show up as a question mark; in other words, they aren’t being detected or aren’t implemented. Also, I’m trying to load the .elf file in case there was a compilation error, and I’m getting some errors saying that certain variables aren’t being detected. Could you help me? If i try to reload the file .elf I have: Re: Important question about motor control Hello, If variables are not detected in the FreeMASTER project make sure that the elf file is properly selected from the settings. If it is properly set, check in the model if the variables are set to External or Volatile. Otherwise, the FreeMASTER is not able to detect them. Best regards, Sorin Bancila

MRF300AN 27MHz Ref DesignTVS and Power Sequence Hi NXP Team, Two questions on MRF300AN-27MHz reference design: Q1: Can I put a 110V TVS across drain to ground for protection? Vds is 133V. Is this a good choice? Q2: What is the exact power-on sequence? Gate bias before drain or drain before gate? Also, should RF drive be ramped up slowly or can I apply full drive directly? Thanks. Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence Hello, In general, the TVS reverse standoff voltage should be selected above the maximum normal operating drain voltage to prevent unintended conduction during normal operation, while still providing protection against abnormal transient events. Regarding the power-up sequence, the drain supply can be applied before the gate bias, or vice versa. Both approaches are acceptable in a stable and properly tuned circuit. Additionally, it is recommended to ramp up the RF drive gradually rather than applying full drive abruptly, as this helps ensure a smoother startup and reduces stress on the device under operating conditions. Hope this helps!

Problem with my project Good morning, I am using one of your evaluation boards, specifically the FRDM-A-S32K344 board, with the ‘S32K344_mc_pmsm_1sh_s32ct’ example in MATLAB and Simulink. The problem I’m having is that when I connect the interface to the Freemaster, some variables don’t appear and show up as a question mark; in other words, they aren’t being detected or aren’t implemented. Also, I’m trying to load the .elf file in case there was a compilation error, and I’m getting some errors saying that certain variables aren’t being detected. Could you help me? If i try to reload the file .elf I have: Re: Problem with my project Hello, If variables are not detected in the FreeMASTER project make sure that the elf file is properly selected from the settings. If it is properly set, check in the model if the variables are set to External or Volatile. Otherwise, the FreeMASTER is not able to detect them. Best regards, Sorin Bancila

HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi, I am working on HSE-B AB Swap on an S32K312 MINI-EVB with HSE firmware version 0.2.55.0 (ab_swap variant). The board is in OEM_PROD lifecycle and Bank A is currently active. Both banks hold the same HSE firmware version. I have a working reference where a bare-metal main function polls HSE INIT_OK and then submits the activate passive block service. That call returns success and the swap applies on the next reset. Bank B contains a valid IVT with pointers compiled for the lower address space per section 11.3 of RM00286. The same MU submission code, moved into a bootloader after MCAL clock initialization, returns HSE response 55A5A26A (invalid address). HSE INIT_OK stays set. Other HSE services (AES, RSA, SHA) work correctly in this state. The only difference between the working and failing runs is that the bootloader path writes the MC_CGM MUX 0 divider registers during clock initialization, keeping the source on FIRC but changing the AIPS_SLOW to HSE_CLK ratio from 1:1 (SBAF default) to 1:4. My main question: what does the invalid address response refer to for the activate passive block service, since the service takes no data structure? Is there a documented sequence for reconfiguring MC_CGM dividers after HSE has reached INIT_OK, that keeps this specific service usable? I can share the failing binary, register dumps, and clock config on request. Thanks Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi David, Thank you for the guidance about the DCF client. To make sure I set this up correctly on the first attempt, could you please clarify a few things: 1. Point 5 in your list says the MC_CGM MUX 0 source must be PLL_PHI0. Is this a hard requirement — does the activate passive block service require the system clock to be on PLL, or can it also work with the system running on FIRC (48 MHz)? 2. Could you share the earlier points 1 to 4 from the same list? We only have points 5 and 6 in the image and suspect we are missing prerequisites. 3. Point 6 gives the DCF value for a 120 MHz HSE clock scenario. For a 48 MHz FIRC configuration with AIPS slow clock at 12 MHz (1:4 ratio), what value should be programmed into the UTEST_MISC DCF record's clock mode and gasket control bit field? 4. What is the exact UTEST address on S32K312 for this record, and is there a sample or a Design Studio / Cyclone algorithm file we can use to program it safely? Since UTEST is one-time programmable, we want to be certain before writing. 5. Are there any other DCF records required for AB Swap beyond UTEST_MISC — such as an OTA enable marker in UTEST, or OTA indicators inside the active and passive blocks? If yes, please share those as well. Board context: HSE firmware 0.2.55.0 ab_swap variant, OEM_PROD lifecycle, INIT_OK and OEM SU rights bits set. Thanks a lot, Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 I guess you don't have setup DCF client what is necessary for use as you described. Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 1) I didn't want to take a screenshot of point 5, but point 6. 2) It is taken from RM: 3) The key point is ratio 1:4. Also it is described in RM embedded attachment (S32K3xx_DCF_clients.xlsx) 4) DCF record address to be programmed you will have to find out yourself (to find first location with 0xFFFF_FFFF). Specifically is should be around address 0x1B000780, but double check it before programming. See following document to understand DCF records: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC57xx-DCF-records/ta-p/1114884 Also DCF calculator exists: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-DCF-Configurator/ta-p/1986243 I have been using TRACE32 script as follows: ; Program UTEST do ~~\demo\arm\flash\s32k3.cmm prepareonly flash.Program 3. /OTP ;put lines generated by S32K344 DCF configurator data.set 0x1B000780 %QUAD 0x0010000460000101 ;dcf_client_utest_misc flash.Program off Mentioned DCF calculator also allows you to create S-records that may be programmed by any programmer/debugger. 5) OTA flag is programmed automatically when AB_SWAP HSE FW is being installed, user don’t need to care of it. I am not aware of other DCF configurations needed. Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hello, Follow-up: I have prepared the DCF record for dcf_client_utest_misc per your instruction (value 0x0010000460000101, target address 0x1B000768 — first free QUAD on my board, verified). However, S32DS + PEmicro Multilink debug configuration silently skips the UTEST write — bytes at 0x1B000768 remain FFFFFFFFFFFFFFFF after the flash session. What is the correct tool/procedure to program a single DCF record into UTEST OTP on S32K312 using PEmicro Multilink (or any tool that ships with S32DS 3.6.4)? Do I need a specific flash algorithm file, a different debug configuration, or the standalone S32 Flash Tool?

WS2812 interface With LPC5514JBD64E Hi NXP Community, I am working with an LPC5514JBD64E-based controller and I need to interface a WS2812/WS2812B LED ring with the MCU. I am studying the LPC5514JBD64E datasheet and my controller schematic, but I am new to the LPC55xx family and need some guidance. I would like to know: 1. Which GPIO pin of the LPC5514JBD64E should be used for the WS2812 data (DIN) signal? 2. Since the LPC5514JBD64E uses 3.3 V logic and the WS2812 will be powered from 5 V, what is the recommended hardware connection between the MCU and WS2812? 3. Is a 74AHCT125 recommended between the MCU GPIO and WS2812 DIN? 4. Which peripheral or method should be used to generate the precise timing required by the WS2812 protocol? 5. Is there an official NXP SDK example, driver, or sample code for controlling WS2812 or NeoPixel LEDs using the LPC5514JBD64E? 6. If there is no WS2812-specific example, could you provide or point me to a basic working example code that makes a WS2812 LED or LED ring blink or change color? 7. What is the recommended development environment and programming/debugging procedure for this MCU? My immediate goal is to make the WS2812 LED ring blink and display different colors using the LPC5514JBD64E. I would appreciate guidance on the correct GPIO, hardware connection, peripheral, and example code. Thank you! LPC55xx

Matlab2023a Envokes S32DS3.5 Encountered Error Dear MBDT Team. We are using MATLAB2023a scripts to generate code after compiling Simulink models, then call eclipsec.exe to perform headless background compilation. Once the build is completed, a hyperlink is created in the Simulink Diagnostic Viewer to directly open the workspace corresponding to the compiled project. This workflow worked perfectly with S32DS 3.4. However, after upgrading to S32DS 3.5.8, two issues have occurred: Issue 1: Clicking the hyperlink that's created by Simulink will launch the background process s32ds.exe, which then pops up and exits immediately. We have tried several solutions like adding the parameter "-vm \bin\javaw.exe" to s32ds.ini (this has no effect on s32ds.exe), and prioritizing the JDK 11 path in system environment variables. None of these attempts resolved the problem. Issue 2: As previous described, calling eclipsec.exe via MATLAB scripts triggers the error shown in the screenshot: Java was started but returned exit code=1. We set "\bin\javaw.exe" and JDK 11 path at the top of system environment variables. The Command Prompt correctly displays Java 11 (64-bit), yet Simulink compilation still attempts to load jvm.dll. After deleting "client\jvm.dll" or "server\jvm.dll", the program will locate java.exe instead, but still reports an error with exit code=4. In addition, manual compilation remains successful in all cases. All the related files and settings will be uploaded for your reference. Please help give your advice to fix this. Thank you. Re: Matlab2023a Envokes S32DS3.5 Encountered Error Hello, From what I understand from your message, you have a Simulink Model and generate code for it using the Embedded Coder. Then you have set up a workflow to compile the code using eclipsec. The main problem I see is that MATLAB do not currently use the correct Java version. Have you tried to contact them about this problem? Moreover, I suspect that you don't use Model Based Design Toolboxes developed by NXP (e.g. S32K3, S32K1 etc). Let me know if I am wrong. Best regards, Sorin Bancila