IMX8MP 片上 RAM 存储器访问 你好， 我想学习如何访问 OCRAM 来读取内存中的数据。 请问有人知道如何在Linux Cortex A-53上实现这个功能吗？ 片上内存 - OCRAM（576 KB） 起始地址：0x00900000 -> 保留给 ROM 起始地址：0x00918000 -> OCRAM 空闲区 结束地址：0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM 谢谢！ IMX8MPLUS i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access 你好，Roman Luz， 这个方法对你有用吗？ 问候， 斯特凡诺·吉利 Re: IMX8MP On chip RAM memory access 嗨@Roman_Loz ，你可以尝试添加 compatible = "shared-dma-pool"; 应该就可以了。 ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; 此致， 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好， 我尝试按照您建议的方式使用 OCRAM，但是当我尝试向其中进行 memcpy 操作时，出现了内核崩溃。 请问您能否帮我分析一下我哪里做错了或者漏掉了什么？ dtsi： resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... 模块初始化： // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } 复制： memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap ， 请注意，NXP不建议对节点进行448 KB OCRAM空间的修改，因为其他驱动已使用该空间。 可以通过兼容的 =“共享 dma-pool” 属性，在0x970000后使用内存区域支持 DMA。 谢谢 & 此致敬礼 桑凯特·帕雷克 Re: IMX8MP On chip RAM memory access 你好@Sanket_Parekh ， 谢谢你的回复，很有帮助！ 如果我不能将 448 KB OCRAM 空间用于用户应用程序，我是否可以修改设备树以支持 DMA？ 谢谢，此致敬礼！ 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap ， 希望你一切都好。   您可以通过查看SoC的dtsi文件（保留内存节点）来确定OCRAM中Linux内核为自身保留了多少内存。 以 imx8mp 为例，大小为 448 KB。   resmem：保留内存 { #address-cells = <2>; #size-cells = <2>; 范围； ocram: ocram@900000 { 无地图； reg = <0 0x900000 0 0x70000>; };   ..... .....   }   因此，这里保留了 0x70000 ( 448K) 字节供 Linux 使用。并且不能按照 no-map 属性指定的方式虚拟映射到用户空间。 在 0x7000 字节之后，您可以将其用于其他应用程序。 但您需要确保任何 M7 核心应用程序不使用 OCRAM。这可以通过查看特定应用程序的链接器脚本来确定。   谢谢 & 此致敬礼 桑凯特·帕雷克   Re: IMX8MP On chip RAM memory access 你好，Sanket， 能否查明 Linux 系统占用了多少内存，以及剩余的内存可供用户应用程序使用？ 如果可行，我该如何验证这一点，并为我的应用程序分配剩余内存？ 谢谢，此致敬礼！ 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap 希望你一切都好。 要访问 OCRAM，首先需要确保您不会尝试访问 ATF 使用的区域。 对于 u-boot，可以使用 md/mw 命令直接访问 OCRAM。 不建议在用户空间中使用 OCRAM，因为 Linux 本身就使用了它。 谢谢 & 此致敬礼 桑凯特·帕雷克

Kinetis (../45/47/43;MCX W71/72/70) および MCX W23 電源プロファイルツール (ローカライズ機能を含む) このページは、Kinetis (KW35/KW38/KW45/KW47) および MCX Wx (MCX W71/72 および MCX W23) 電力プロファイル ツール専用です。 これにより、あなたのアプリケーション(オートモーティブ、IIoT、トラッカー/タグ、連続血糖モニタリング[CGM])の消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、単独製品またはフルシステムアプリケーション向けの専用パワープロファイルツールを提供する4つのマーケットセグメントが含まれています:   1. オートモーティブ Kinetis(KW3x/4x)オートモーティブ用パワープロファイルツール - NXPコミュニティ KW35/36製品用のBluetooth LEをスタンドアロンで使用。 Bluetooth LEはKW37/38/39製品用のスタンドアロン対応です。 KW45/KW47製品用のBluetooth LEをスタンドアロンで使用。 スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ) スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ) 2.IIoT Kinetis MCX Wxx(MCX W71/72 および MCX W23)IIoT用パワープロファイルツール - NXPコミュニティ Bluetooth LEは単体でMCX W71/MCX W72製品用です。 MCX W23製品のBluetooth LEをスタンドアロンで提供します。 スタンドアロン (IIoT) の MCX W71 および W72 マター製品用の 802.15.4 Matter ICD SIT & LIT および ZED。 Aliro Doorlockアプリケーション    3. オートモーティブおよび工業技術向けローカリゼーションアプリケーション(CCC CS) Kinetis MCX Wxx(KW47およびMCX W72)Bluetoothローカライゼーション用パワープロファイルツール - NXPコミュニティ 4．新しいツールが登場： Zephyr・ズボス Zephyr BLE KW45/MCX W71 または KW47/MCX W72 を使用して PCB を構築し、無線の性能と無線認証 (CE/FCC/IC) に関する情報をすべて得るには、次の重要なリンクを参照してください。 KW45（カーアクセサリ）を使ってPCBを構築する最良の方法 - NXPコミュニティ 電力および低電力アプリケーションノートについては、製品ページをご覧ください。便宜上、いくつかの直接リンクを次に示します。 MCXW71 - 電源管理ハードウェア KW45/K32W148 - 電源管理ハードウェア 異なる体験:One コネクティビティ Power Profilingツール コネクティビティの電力プロファイリングツールをすべて一つにまとめています。 Kinetis(KW3x/4x、MCX W7xおよびMCX W23)One コネクティビティ Power Profile Tool - NXPコミュニティ 注:このツールはかなり遅いですが、Kinetis製品を比較するのに非常に興味深いです。 製品: K32W0 製品: K32W1 製品: KW 34|35|36 製品: KW 37|38|39 製品: KW41Z |31Z | 21Z 製品: QN9080|SIP 製品: QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、エベレット。 パスワードは、変更や競合他社のベンチマークの詳細が多すぎることを避けるために設定されています。 ご不便をおかけして申し訳ございませんが、それはCANません。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、christophe_menardさん。 @christophe_menardシート保護のパスワードを教えていただけますか。よろしくお願いします。 EverettRao_0-1729134009121.png Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは 、 OneConnectivityPowerProfilingtool_SDK_26_03.zip を使用したいのですが、トロイの木馬が検出されました。 このツールの使い方。 サポートありがとうございます Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer この件を確認するため、社内のIT部門に問い合わせチケットを発行しました。 近いうちにまたご連絡します。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer IT認証の結果、CrowstrikeやDefenderのソフトウェアを使ってトロイの木馬ウイルスは検出されませんでした。

Kinetis (.. /45/47/43；MCX W71/72/70) & MCX W23 Power 我的 工具（包括本地化） 本页专用于 Kinetis（KW35/KW38/KW45/KW47）和 MCX Wx（MCX W71/72 & MCX W23）Power 我的 工具。 它将帮助您估算应用（汽车、工业物联网、追踪器/标签和连续血糖监测 [CGM]）中的功耗，并评估解决方案的电池寿命。 本页面包含 4 个市场细分领域，分别针对独立产品或完整系统应用提供专用的功率分析工具： 1. 汽车 Kinetis (KW3x/4x) 汽车行业功率我的分析工具 - NXP 社区 KW35/36 产品独立组网 (SA)的蓝牙低功耗功能。 KW37/38/39 产品独立组网 (SA)的蓝牙低功耗功能。 KW45/KW47 产品独立组网 \(SA\)的蓝牙低功耗功能。 SmartFob 应用（BLE/KW45；UWB Ranger4；SE；运动传感器） SmartFob 应用（BLE/KW47；UWB Ranger5；SE；运动传感器） 2.工业物联网 (IIoT) ... Kinetis MCX Wxx（MCX W71/72 和 MCX W23）工业物联网电源我的工具 - NXP 社区 MCX W71/MCX W72 产品独立组网 \(SA\)蓝牙低功耗 (Bluetooth LE) 功能。 MCX W23 产品独立组网 (SA)的蓝牙低功耗 (Bluetooth LE)。 802.15.4 Matter ICD SIT & LIT 和 ZED 适用于 MCX W71 & W72 独立组网 (IIoT) 产品。 Aliro门锁应用 3. 面向汽车和工业物联网的定位应用（CCC CS） Kinetis MCX Wxx (KW47 & MCX W72) 蓝牙定位电源我的工具 - NXP 社区 4.新工具即将推出： Zephyr Zboss Zephyr BLE 请找到这个重要链接，使用 KW45/MCX W71 或 KW47/MCX W72 版本 PCB，以及所有与无线电性能和无线电认证 (CE/FCC/IC) 相关的内容： 使用KW45版本 PCB 的最佳方式（汽车配件...-恩智浦社区 有关功耗和低功耗应用笔记，请参阅产品页面。以下是一些直接链接，以方便您使用： MCXW71 - 电源管理单元硬件 KW45/K32W148-电源管理单元硬件 不同的体验：One 连接 Power Profiling 工具 它将所有连接电源分析工具集成在一个工具中。 Kinetis（KW3x/4x、MCX W7x 和 MCX W23）连接电源我的工具 - NXP 社区 注意：此工具速度较慢，但对于比较 Kinetis 产品非常有用。 产品：K32W0 产品：K32W1 产品：KW 34|35|36 产品：KW 37|38|39 产品：KW41Z |31Z |21Z 产品：QN9080|SIP 产品：QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 嗨，埃弗雷特、 密码的设置是为了避免在太多细节上出现变化或竞争对手的基准。 很抱歉给您带来不便，但这是不可能的。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 你好，克里斯托夫-梅纳德。 @christophe_menard能否提供Sheet 保护 密码 ，非常感谢。 EverettRao_0-1729134009121.png Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 你好 ， 我们想使用OneConnectivityPowerProfilingtool_SDK_26_03.zip，但检测到了木马程序。 如何使用这个工具？ 感谢您的支持 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 嗨@pierre_demeyer 我已向IT部门提交了工单以核实此事。 我会尽快通知您最新情况。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 嗨@pierre_demeyer 经 IT 部门核实，使用 Crowstrike 或 Defender 软件均未检测到木马病毒。

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

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

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.