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.

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

TJA1028TK/3V3/20 FIT Hi, Where can I find the failure rate of TJA1028TK/3V3/20/J FIT. Can you provide the corresponding information? Thanks. Re: TJA1028TK/3V3/20 FIT This information is not publicly available and has been shared with you via email.

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

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.

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!

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

Debug interface recommendations for Kinetis and LPC? I do most of my development on the Kinetis series, and potentially some LPC parts in the near future. I've got a drawer full of debug interfaces from P&E Micro, including a Cyclone ACP that I use most. I sometimes find myself switching from the $600 Cyclone to the $20 LPC-Link2 because the Cyclone has so many weird problems with MCUXpresso. Honestly the LPC-Link2 does most of what I need, it's just a bit slow. Should I be looking at Segger interfaces? Can someone recommend a reliable, reasonably fast interface that's well-supported in MCUXpresso (and hopefully CodeWarrior 11 as well) that doesn't cause crashes all of the time, or fail to halt a running target? Trace support would be nice. Thanks! Re: Debug interface recommendations for Kinetis and LPC? Hi @richard37  Thank you for your post! You may want to consider a SEGGER J-Link. It supports both Kinetis and LPC devices when used with MCUXpresso, and it is also natively supported by CodeWarrior 11. This makes it a good alternative if you need a debug probe that can be used across both development environments and device families.

S32 IDE开发环境RTD插件无法安装 需要S32 IDE开发环境安装S32ZE RTD插件开展S32Z280处理器软件开发工作，在环境中无法安装，提示如图1，在NXP官网无法下载，提示需要License，请提供License获取渠道，谢谢。 Re: S32 IDE开发环境RTD插件无法安装 不客气，有任何问题随时联系！ Re: S32 IDE开发环境RTD插件无法安装 第一个连接要求账号登录，登录后没有显示安装包下载路径。第二个连接进入“汽车软件包管理器”后成功下载到安装包，谢谢。 Re: S32 IDE开发环境RTD插件无法安装 Hi,Flynn_T 1.您看这个链接可以下载吗？最新的RTD版本应该是2.0.1 QLP01，版本列表中没有你提到的1.1.45。另外注意，2.0.1 QLP01的RTD，需要的S32DS IDE的版本是3.6.1。 Design : Product Information : Automotive SW - S32Z/E - Real Time Drivers (RTD) 2.这个链接您也可以看下，是否可以下载。 汽车软件包管理器 | NXP 半导体 BR Joey Re: S32 IDE开发环境RTD插件无法安装 Hi， BR Joey     我使用的S32 IDE的版本是3.6.10。需要安装的RTD版本是1.1.45，我NXP官方网站没有找到S32Z/E RTD插件的下载路径，请提供一个下载连接。 Best Regard Flynn_T Re: S32 IDE开发环境RTD插件无法安装 Hi，Flynn_T 您使用的S32 IDE的版本是多少呢？RTD版本是多少呢？ 在IDE中加载S32Z/E RTD插件一般不需要license。 BR Joey

i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled NXP 官方团队，您好： 我们在使用 i.MX 8M Plus 平台开发系统，运行 Linux A53 与 FreeRTOS M7。在尝试将 SAI3 音频接口分配给 Linux 使用的同时运行 M7 时，遇到了内核崩溃（SError / 页错误）。 1. 软件版本与环境： Kernel 版本：Linux 5.10.72 U-Boot 版本：U-Boot 2021.04 M7 SDK：MCUXpresso SDK for i.MX8MP (rpmsg_lite_str_echo_rtos) 参考官方文章：NXP Knowledge Base: Test SAI3 while running M7 firmware with remoteproc 2. 系统配置情况：   <1> M7 固件（m7.bin）存放在系统分区，并在 U-Boot 阶段通过 bootaux 0x007e0000 命令直接启动。 <2> 在 Cortex-A53 Linux 侧，我们使用挂载在 SAI3 + I2C3 + SDMA3 总线上的物理声卡芯片（SGTL5000）。 <3> Cortex-M7 负责 GPIO2_IO09 管脚上的 采集并触发高频采样中断，并通过 RPMsg 虚拟串口（/dev/ttyRPMSG30）与 A53 Linux 进行跨核数据交互。 3. 遇到的问题： 不调整声卡资源到A53的话，/dev/ttyRPMSG30设备操作是正常的； 目前需要应用A53的声卡设备，参考了官方帖子<Test SAI3 while running M7 firmware with remoteproc>后做出了以下调整，但内核启动会存在问题，改动部分如下： <1> 内核 dts配置已恢复声卡配置到A53，如附件 <2> u-boot dts： 分配了声卡资源到A53，如 <3> ATF，将 SAI3、sdma3 和 i2c3 分配给 A53，修改imx8mp_bl31_setup.c，如： <4> M7 SDK： 注释BOARD_BootClockRUN和BOARD_RdcInit函数涉及AUDIO的改动，如附件 和 4. 内核 dmesg 崩溃日志： 开机进入内核会卡主，log如下： [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none 请帮忙看看问题点，是否有相关文档和改动可以解决，期待你们的建议和答复！感谢！ 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled 已解决，需要完整关闭M7端的音频配置才可以

Could someone please help me find the Safety Manual for the S32K3? Hi everyone, I'm looking for the Safety Manual for the NXP S32K3 MCU family. Could someone help me find it or provide information on how to access it? Re: Could someone please help me find the Safety Manual for the S32K3? Hi Have you already signed an NDA with NXP? If you are unsure whether company has signed an NDA with NXP, please tell me company's full name or address. If you already have a valid NDA, please refer to this document to register a Secure File account. Once you have Secure File access, you can click on Secure in the documentation section of the S32K3 product page and download the Safety Manual. Best Regards, Robin

MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage Hi Team,   I am evaluating the latest version of the MCUXpresso SDK and working with an NXP MCU.       For saving small configuration parameters (device settings, calibration values, counters, etc.) into internal Flash memory, what is the currently recommended approach?     Specifically:   1. Is it better to use a dedicated Flash storage area or EEPROM emulation (where supported)?   2. Are there any performance or reliability considerations when performing frequent Flash write operations? 3. Does NXP provide any example projects demonstrating best practices for parameter storage and wear leveling? 4. Are there any SDK libraries recommended for managing persistent configuration data? I have reviewed the available SDK documentation, but I would appreciate guidance on the recommended implementation approach for new projects.   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage Hello @Manjuanth, I see you've posted this on the S32K's product forum, however, S32K's MCUs are not compatible with MCUXpresso, and use S32 Design Studio instead. Could you share which NXP MCU you are using? Best regards, Julián 

How to enable and use GPIOs with Zephyr in the TrustZone Non-Secure environment with FRDM-MCXN947 This document describes the complete process required to enable and use GPIOs from a Zephyr Non-Secure application running on the FRDM-MCXN947. It covers the configuration of the AHB security attribution settings, the Zephyr and TF-M project configuration, and the use of the GPIO alias mirror registers to grant Non-Secure access to the desired GPIO ports. After completing these steps, GPIO peripherals can be controlled directly from the Zephyr application while maintaining the security isolation provided by TrustZone. MCXN Security(Edgelock | secure boot | OTP) FRDM-Training Package and IO|GPIO

MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hi, I am working with the MR-CANHUBK344 and want to use its 100BASE-T1 Automotive Ethernet interface. My first goal is simply to get a working Automotive Ethernet example running on the board before modifying it for my application. I downloaded the official MR_CANHUBK3_IEEE1722 example. This looks suitable because it demonstrates MR-CANHUBK344, 100BASE-T1, TJA1103, GMAC, IEEE 1722 ACF-CAN, CAN/CAN-FD to Ethernet conversion, and FreeRTOS. However, I am facing a toolchain/version compatibility issue. My available environments are: S32 Design Studio 3.5 with S32K3 RTD 3.0.0 S32 Design Studio 3.6.7 with S32K3 RTD 7.0.1 When I import the original MR_CANHUBK3_IEEE1722 project, I can see the source files, but when I try to open the .mex configuration I receive this error: Processor S32K344, the PlatformSDK_S32K3_2022_03 version is not supported by the current version of the tool. For example, FreeRTOS_Toggle_Led_Example_S32K344.mex cannot be opened because it expects PlatformSDK_S32K3_2022_03. I understand that the original MR_CANHUBK3_IEEE1722 demo was developed using an older S32DS/RTD environment. I also tried installing S32 Design Studio 3.4 and downloaded SW32K3_S32DS_3.4.3_D2112.zip. However, I currently cannot activate S32DS 3.4 because my NXP account does not show a v3.4 license entitlement. Could you please help me with one of the following? Is there a working MR-CANHUBK344 IEEE1722 project for S32DS 3.5 and RTD 3.0.0? Is there an updated MR-CANHUBK344 Automotive Ethernet example for S32DS 3.6.x and a newer RTD version? For now, I only need a simple Automotive Ethernet demonstration where two MR-CANHUBK344 boards establish a 100BASE-T1 link and transmit/receive basic Ethernet frames using the S32K344 GMAC and TJA1103. I do not need SOME/IP, TSN, or a complex TCP/IP application at this stage. If there is a working S32DS 3.5 port of MR_CANHUBK3_IEEE1722, an updated project, or a migration guide, please share it. Or, If you could help me in activating the license. I clicked on the download and didn't receive any e-mail for the version 3.4. I got one e-mail for 3.6 though.  Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hello @Aaditya773 , The original MR_CANHUBK3_IEEE1722 demo was released for an older S32DS / RTD environment, so the .mex incompatibility with newer S32DS 3.5 / 3.6.x versions is expected. I cannot confirm that an officially released migrated version of this exact IEEE1722 ACF-CAN demo is available for S32DS 3.5 or S32DS 3.6.x / RTD 7.0.1. For your current goal, which is to bring up the 100BASE-T1 Ethernet interface first, I would recommend starting from a newer Ethernet example rather than directly migrating the old IEEE1722 project. There is an MR-CANHUBK344 lwIP example available on NXP Community: Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600. This example is based on lwip_FreeRTOS_s32K344, was adapted for the MR-CANHUBK344 board and demonstrates pinging the lwIP stack. However, this example was prepared for an RTD 6.0.0-based setup. Therefore, for RTD 7.0.1 I would use it mainly as a reference, not as a project to be imported directly. A cleaner approach is to start from the current lwip_FreeRTOS_s32k344 example delivered with your installed TCP/IP stack and then adapt the MR-CANHUBK344-specific parts from the community example, mainly the GMAC / MII port mapping, pin configuration, clocks, interrupts, and TJA1103-related setup. As another reference, you may also use the S32K344_gptp_ds example from package SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip I have made a quick check with the following software configuration: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip After a few small fixes in the S32 Configuration Tools configuration, the S32K344_gptp_ds example can be built in this environment. Please note that this is not a direct port of the original IEEE1722 ACF-CAN demo. It is rather a practical path for basic 100BASE-T1 Ethernet bring-up on MR-CANHUBK344 using a newer software environment. To make the discussion easier to follow and useful for other users as well, let us keep this thread focused on the MR-CANHUBK344 Ethernet / 100BASE-T1 bring-up topic. If you need support for any other issue, please kindly create a separate Community thread.   Best regards, Pavel

So little talk about NXP MCX family Mcus How comes? At the start of the year we have ported some products from obsolete microcontrollers to the NXP MCXA family of microcontrollers. Main motivation for this choice was the long time availability. So I had a few month working with that chip and it's infrastructure. And what can I say: They are pretty good. Price is okay. Dev-Board availability is good. The software stack works. Integration into their Eclipse based IDE is fine (and you are not forced to use it). Yes, there are some warts in the software here and there, but nothing out of the ordinary. Hardware features: Pretty cool. It does all the basics and more. I especially like that they have fifos worth speaking of for nearly all peripherials. Found no silicon bugs so far, even when I used the more obscure features of the chip. Performance is good as well. And yet - you find nearly to no posts about these chips. How comes? MCXC Re: So little talk about NXP MCX family Mcus Hi @naofomi  Thanks for your interest in the MCXA product family. Since MCXA is a relatively new MCU series, there is naturally less community content and fewer forum discussions available compared to mature product families such as LPC and Kinetis. Customers also receive support through other NXP channels, including DFAEs and private support cases. If you have any questions, please feel free to post them here. We will be glad to help and support your development. Thank you. BR Alice

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