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

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

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

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

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

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

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

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

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: GuilhermeS32G_0-1786505280150.png Also have tried to set VING_MIRR and VEGR_MIRR in the VLAN Lookup Table: GuilhermeS32G_1-1786505432456.png Also have set the MIRR_PORT to 5 in General Parameters: GuilhermeS32G_2-1786505483489.png 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: PavelL_0-1786518971668.png 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

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). AndreeaPascu_1-1786520264415.png AndreeaPascu_3-1786520357897.png 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: AndreeaPascu_0-1786518994463.png 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 许可证延期申请 你好我的许可证已经过期，因此我想申请延期。 zhangtr_0-1785825418457.png 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： smarklink_0-1786504166890.png 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来讲

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? Alice_Yang_0-1786344510075.png Thank you. BR Alice Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Thank you for pointing this out @Alice_Yang . I checked the FRDM-MCXA156 schematic and confirmed that R36, which connects the P0_2/SWO signal to the onboard MCU-Link debugger, is marked as DNP. I also noticed that on the FRDM-MCXN947, the equivalent SWO connection (R130) is populated with a 0 Ω resistor. Could you please confirm whether R36 on the FRDM-MCXA156 should also be populated with a 0 Ω resistor to enable SWO tracing through the onboard MCU-Link debugger? Additionally, could you please clarify why R36 is left unpopulated (DNP) by default on the FRDM-MCXA156? Is there a specific board-design reason or limitation that requires it to remain unpopulated? So I cannot use SWO feature?  Thank you for your help. Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Hello @sidsal  " Could you please confirm whether R36 on the FRDM-MCXA156 should also be populated with a 0 Ω resistor to enable SWO tracing through the onboard MCU-Link debugger?" ->>Yes. If you want to use the SWO function, you need to install a 0 Ω resistor or solder the connection accordingly. “Additionally, could you please clarify why R36 is left unpopulated (DNP) by default on the FRDM-MCXA156? ” ->>I think this is because not all users require the SWO function, so the 0 Ω resistor is not populated by default. Thank you. BR Alice Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE Thank you for your support @Alice_Yang .

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.    JonAnder_Amante_1-1770196663700.png 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: stefanvlad_0-1770819182442.png 1. Remove resistors R396 and R397, located on bottom PCB near DC Jack: stefanvlad_4-1770819788524.png 2. Populate with 0 (zero) Ohm  resistors R413, R414 and R418 located near J4 connector: stefanvlad_3-1770819728806.png And also because the VDD_HV_A is supplied with 3.3V instead of 5V: stefanvlad_2-1770819465940.png We need to modify the parameters for the Udc and Idc Gains: stefanvlad_6-1770820165900.png %% 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: stefanvlad_5-1770819975008.jpeg Now Open FreeMASTER and run the example and check iABC waveforms: stefanvlad_7-1770821519787.png  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? JonAnder_Amante_0-1770883302148.png 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.  JonAnder_Amante_1-1770883826681.png 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  JonAnder_Amante_1-1771229540348.png JonAnder_Amante_2-1771229553893.png JonAnder_Amante_4-1771229596623.png JonAnder_Amante_3-1771229577117.png 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? JonAnder_Amante_0-1780475763418.png JonAnder_Amante_1-1780475763497.png If i try to reload the file .elf I have: JonAnder_Amante_2-1780475763491.png 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? JonAnder_Amante_0-1780474522107.png JonAnder_Amante_1-1780474600546.png If i try to reload the file .elf I have: JonAnder_Amante_2-1780474650900.png 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. davidtosenovjan_0-1786371576770.png 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: davidtosenovjan_0-1786445766359.png 3) The key point is ratio 1:4. Also it is described in RM embedded attachment (S32K3xx_DCF_clients.xlsx) davidtosenovjan_1-1786445766362.png 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?