iMX937のディープスリープモード iMX95lpddr5 evkを使用していますが、ディープスリープモードがトリガーされました。A55、M7、M33のサスペンドコアと非サスペンドコアの状態、クロック周波数、消費電力について知りたいです。 Re: Deep Sleep Mode of iMX937 i.MX95 LPDDR5 EVKでは、「ディープスリープ」は i.MX 95 Suspend/DSMスタイルの低消費電力ケースに割り当てられます。A55は吊り下げ/電源ゲート式です。M33はアプリケーションワークロードを実行中ではなく、通常はクロックゲート/アイドルとして表示されます。M7は、それもサスペンションするか、ウェイク/リアルタイムコアとして保持するかによります。AN14449のパワー数値はSoCレール/グループの合計であって、コアごとのパワーではありません。 低消費電力ケース Cortex-A55 状態/周波数 Cortex-M33の状態/周波数 Cortex-M7状態/周波数 DDR状態 報告された電力 DSMのシステム 一時停止; 時計が検出できません クロックゲーティング; クロックが検出されません 一時停止; 時計は提供されていません 保持 25.65 mW GROUP_SOC_FULL 合計 Linux サスペンド + CM7 WFI 一時停止 / 0 クロックゲーティングまたはアイドル / 0 WFI / 400 MHz 保持 178.48 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 CoreMark(TCM) 一時停止 / 0 クロックゲーティングまたはアイドル / 0 CoreMark / 400 MHz 保持 197.24 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 FlexCANトランザクション 一時停止 / 0 クロックゲーティングまたはアイドル / 0 FlexCAN / 800 MHz 稼働中、6400 MT/s 659.71 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 NETC / イーサネット 一時停止 / 0 クロックゲーティングまたはアイドル / 0 NETC / 800 MHz 稼働中、6400 MT/s 956.17 mW GROUP_SOC_FULL 合計 Linux サスペンド + WoL A55号線が停止 M33アイドル/低電力コンテキスト ウェイクアップ対応構成。取得したチャンクに正確なコアテーブルが含まれていません。 WoLの設定によります 342.72 mW GROUP_SOC_FULL 合計 解釈に関するいくつかの注釈： i.MX 95リファレンスマニュアルでは、不要なクロックや電源がオフで、Cortex-A55 CPUが完全に電源ゲートされ、電源を切れるPHYがオフになり、VDD_SOCがサスペンション電圧にまで下げられる最大省電力モードとしてサスペンデントモードと説明されています。 DSMのSystem AN14449では、使用例がCA55=サスペンデント、CM33=クロックゲーティング、CM7=サスペンデント、DDR=保持、そしてCA55とCM33が動作していないためクロックを検出できないことも明記されています。 M7をアクティブに保ったLinuxのサスペンドの場合、非サスペンドコアはCM7です。WFI/CoreMarkの保持ケースではクロックが400 MHz、FlexCAN/NETの場合は800 MHzで、A55およびM33はケーステーブルで0 MHzと表示されます。 公開されている電力データは、 A55/M7/M33コアごとに個別に示されているわけではありません。AN14449は、レールやグループ、GROUP_SOC_FULLやGROUP_DRAMなどの測定値を報告します。例えば、DSMはvdd_arm 0 mW、vdd_socを3.85 mWと報告し、合計25.65 mWのGROUP_SOC_FULL合計を含みますが、これはレールレベルの電力であり、個々のコア電力ではありません。 まとめ:M7も停止している場合、DSMは約25.65mWです。Linuxのサスペンド中にM7が稼働し続けると、ペリフェラルのワークロードに応じて、SoCの総消費電力は400MHzで約178〜197mWから800MHzで約660〜956mWに上昇します。 Re: Deep Sleep Mode of iMX937 I.Mx95には、RUNモード、低電力RUNモード、IDLEモード、SUSPENDモード、バッテリーバックアップ付きセキュアモジュールモードなど、いくつかの電源モードがあります。詳細な消費電力データについては、IMX95AECのデータシートを参照してください。i.Mx937については、現在試作段階であり、現時点では製品仕様書のみが入手可能です。 テストデータの出所や、あなたが言及しているディープスリープモードが何なのかよく分かりません…。

CodeWarrior 的 LA1224 插件 你好， 我目前正在评估 LA1224-RDB，对于软件环境有一些疑问。据我了解，为了评估目的，我可以在 LX2160A 上现有的 NxP 镜像上运行 Linux 应用程序。此外，我推测 LA1224 是在裸机上运行 FreeRTOS。我发现 LX2160A 的 Linux 目录中可以找到 LA1224 的固件。这是NxP提供的吗？它支持哪些功能？我想，如果我想在给定的固件基础上进行进一步开发，我必须获得 CodeWarrior 许可证和 TAP。 我已经下载了 CW_ARMv8_v2020.06_b200629GA_Win_Setup.exe，但是 LP1224 不可用。在 NxP 网站上搜索后，我发现除了 CW_ARMv8 之外，还需要一个额外的工具链。插件的完整下载网址是什么？我阅读了CodeWarrior 上关于 LA1224 的文档，但只给出了部分 URL：“ com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip”。 欢迎提供关于如何使用这些处理器的更多信息。 亲切的问候 N. Alexopoulos Re: CodeWarrior for LA1224 plugin 请从以下链接下载软件包 com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip。 https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US 请准备一个干净的安装环境。请先安装 CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe。然后，在新工作区路径中打开 CodeWarrior IDE。然后从 CodeWarrior IDE 的“帮助->安装新软件->添加->归档”安装服务包 com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip。

S32DS ARM 2018 R1 ライセンス延長申請 こんにちは。私の運転免許証の有効期限が切れてしまったので、延長を申請したいのですが。 zhangtr_0-1785825418457.png Re: S32DS ARM 2018 R1 许可证延期申请 こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター Re: S32DS ARM 2018 R1 许可证延期申请 ありがとう

S32K396 和 FS26 REG_CORRUPT 尊敬的各位， 我正在尝试消除 FS26 上的 REG_CORRUPT 标志 - 附件中的两张截图显示了对所有相关寄存器的读取。 在第一个“AE”读取命令之前，我已经成功地启动了看门狗，使 FS 状态机脱离 INIT_FS，以便评估故障保护寄存器状态的正确性，从 0x28 的响应可以看出，我们处于调试模式，并且 REG_CORRUPT 位已设置。 我确信看门狗启动成功了，因为我在启动后立即读取了 FS_DIAG_SAFETY1 - 返回值为 0x0103 - 没有错误标志，只有 ABIST1_OK 和 LBIST_STATUS = OK。 在执行 0xAE 命令后，我发出 0xAF 命令，尝试向寄存器写入 0x1800 以清除 OTP_CORRUPT 和 REG_CORRUPT 位，然后从寄存器 0x41 开始按顺序读取所有 12 个 FS 寄存器（显然，移位后的命令为 0x82）。 我已经查看了这些寄存器返回的值，并且没有发现返回值存在一致性问题（显然，考虑到我们不应该写入的位以及被保留/清零/0/1 的位）。 从最后读取 FS_STATES 可以看出，REG_CORRUPT 仍然处于设置状态。 很抱歉问这么直接的问题，但我到底漏掉了什么？ 此致， Andrew Snip1.pngSnip1.png Snip2.pngSnip2.png    Re: S32K396 and FS26 REG_CORRUPT 亲爱的艾丽卡， 感谢您的回复——我已经检查过很多次了，所以我才在最初的帖子图片中发布了完整的寄存器状态。如果您认为这些配置存在问题，请告诉我。 据我所知，寄存器是正确的（仅考虑数据手册中可写入的位）。我假设芯片本身会确保只读位处于有效状态，并且我假设指定为“0”或“保留”的位是不可写的。 写入这些位中的某一位是否有可能导致 REG_CORRUPT 位保持钳位？ 此致， Andrew Re: S32K396 and FS26 REG_CORRUPT 您好！ 对于 REG_CORRPUT 位，它将被置位，如下所示，这意味着当配置 FS 寄存器时，必须配置一个 NOT 寄存器以及异或规则。 ErikaC_0-1785954434399.pngErikaC_0-1785954434399.png 请检查是否存在某些寄存器配置不符合规则，导致此位置位？ Re: S32K396 and FS26 REG_CORRUPT 尊敬的各位， 回答我自己的问题，希望对以后遇到同样问题的人有所帮助…… 我不会发布数据表中的摘录，因为这会违反我为了获取该产品数据信息而签署的保密协议。但是，请仔细查看产品信息中定义为“0”或“保留”的部分。我的问题的解决方案与定义为“保留”的位有关。软件必须向该位置写入“1”，以防止设置 REG_CORRUPT 位。 我建议修改数据手册，以明确必要的位状态，并正确定义软件必须执行的操作——就像其他类似位一样。 此致， Andrew

imx8qm 显示器分辨率设置（AAOS 15） 大家好， 我们 在 i.MX8QM MEK 上 使用 AAOS 15.0.0_2.1.0 。刷 写 板 后 ， 物理 显示屏 的 分辨率 始终 设置 为 1024x600 ， 而 我们 希望 显示屏 以 1920x1080 的 分辨率 运行 。 我们采用多显示屏设置，包括安卓主默认显示屏和乘客显示屏。 我们 已 验证 1920x1080 在 支持 的 显示 模式 下 可用 ， 但 启动 后的 活动 显示 模式 仍然 是 1024x600 。我们 也 尝试 在 Android 系统 中将 首选 显示 模式 设置 为 1920x1080 ， 但 重启 后 显示 仍然 以 1024x600 分辨率 显示 。 请问 您 能否 提供以下建议： What determines the default physical display resolution during 启动? 如何 强制 物理 显示 分辨率 在 1920x1080@60Hz 启动 后 ？ ro.boot.displaymode 需要 进行 任何 配置 吗 ？显示 HAL、 HWC3 或 DRM ，以 将 1920x1080 设置 为 默认 运行模式 ？ 任何指导都将不胜感激。 Re: Display resolution setup on imx8qm with AAOS 15 你好， 请参阅我们提供的 Android Automotive 文档： https://www.nxp.com/docs/en/user-guide/UG10176.pdf 请特别参阅第 8.3.4 节。配置上述文档的主显示分辨率。 此致敬礼/Saludos， 阿尔多。

CodeWarrior for LA1224プラグイン こんにちは、 現在、LA1224-RDBの評価の途中で、ソフトウェア環境についていくつか質問があります。私の理解では、評価目的で既存のNxPイメージ上でLinuxアプリを動かすことはLX2160A可能です。さらに、LA1224はFreeRTOSを搭載したベアメタル環境で動作していると思われます。LX2160AのLinuxディレクトリにLA1224のファームウェアを保存できるのを見ました。これはNxPから提供されたものですか?何をサポートしていますか？提供されているファームウェア以上のものを開発したい場合は、コードウォーリアーライセンスとTAPを取得する必要があると思います。 CW_ARMv8_v2020.06_b200629GA_Win_Setup.exeをダウンロードしましたが、LP1224が利用できません。NxPのサイトを検索したところ、CW_ARMv8の上にさらに別のツールチェーンが必要であることがわかりました。アドオンをダウンロードするための完全なURLは何ですか？LA1224用のCodeWarriorを読んだところ、部分的なURLしか与えられていません。com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip" これらのプロセッサーの扱い方について、さらなる情報があればぜひ教えてください。 敬具 N. アレクソプロス Re: CodeWarrior for LA1224 plugin 以下のリンクから、com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip パックをダウンロードしてください。 https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US クリーンなインストール環境をご用意ください。まず、CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe をインストールしてください。その後、新しいWorkapceパスでCodeWarrior IDEを開きます。次に、CodeWarrior IDEのHelp->Install New ソフトウェア->Add->Archiveからサービスパックcom.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zipをインストールします。

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 本身就使用了它。 谢谢 & 此致敬礼 桑凯特·帕雷克

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

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

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

SC18IS606 - reading back issue Hello, We have I2C to SPI converter SC18IS606 manufactured by NXP. We are using Raspberry Pi to write and read data to SC18IS606 through I2C. The device SC18IS606 is shown listed in the Raspberry Pi OS terminal and is detected through “i2cdetect -y 1” command in the terminal with correct address. As a simple test, we tried write operation (set/clear) to the GPIO 0 to 2 and make them toggle in the loop with some delay in between. This part is working.  But when we read back from the SC18IS606, it reads 0x80 instead 0x00. Latter we tied the pins MISO and MOSI together making SPI loop back using a jumper wire. We are sending patterns 0x00 through 0x07 to SPI. The read back data we got is 0x80 through 0x87. The MSB is always 1 when we read back SPI in the loop back test. We have tested two SC18IS606 chips which we bought from Mouser and we got the same result.   Any idea what could be the issue ? How to fix ?  Re: SC18IS606 - reading back issue Hello johnpeter Good day! 1.- Please check the ORDER bit The SC18IS606 SPI configuration register contains an ORDER bit: ORDER = 0 → MSB first (default) ORDER = 1 → LSB first If the SC18IS606 is configured for LSB-first, but your software interprets the received byte as MSB-first, patterns can appear shifted and may look like the MSB is always set. Could you verify what value you are writing with the F0h Configure SPI Interface command? 2.- are you reading the buffer correctly? The SC18IS606 does not immediately return GPIO or SPI data after the command. The sequence is: Send GPIO Read (F5h) or SPI transaction. Wait for completion (poll device or use INT). Perform an I²C read of the buffer. For SPI operations, the received MISO data is stored in the internal buffer and must then be read back through an I²C read transaction. A protocol error when reading the buffer (for example treating the address byte as data, or reading one bit offset) could produce the exact "+0x80" I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: SC18IS606 - reading back issue I have attached python code running on RPi and it's outcome on the terminal. The SC18IS606 is connected to MAX31865. Have a looked at the Raw binary data in which MSB (7th bit) is high for every register read.  For example, RTD MSB raw data is 0xC6. After we mask the 7th bit in the python code we get 0x41. Any reason why we get 7th bit high for every register read ?  38.png38.png 39.png39.png 20260818_00h49m35s_grim_01.png20260818_00h49m35s_grim_01.png

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

IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure I have configured AE LIMITS with the maximum exposure set accordingly. However, during runtime, the AE algorithm only reaches 66666 exposure at most,and the gain hits its upper limit at this point. Readings via V4L2 confirm that AE exposure reaches less than half of the configured upper limit. LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png When manually configuring exposure via Live Control, the valid exposure can reach 150000,V4L2 exposure can also reach the upper limit. We suspect this issue is related to RowTime. We modified the Row Time parameter inside AE Dister, but this change shows no visible effect; the auto exposure performance remains exactly the same as before. We would like to know what adjustments are required to allow the AE algorithm to reach the configured maximum exposure under low-light conditions. Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure Based on the current behavior, the AE algorithm appears to be limited by the active sensor mode frame duration rather than by the absolute manual exposure capability. The value 66666 us corresponds to one frame at 15 fps. Therefore, even if the AE LIMITS maximum is set to 150000 us , AE will not be able to apply it unless the active sensor timing allows a frame period longer than 150 ms, or unless the driver/helper path extends VBLANK/frame length before programming exposure. Please check whether the sensor driver exposes and correctly updates V4L2_CID_EXPOSURE , V4L2_CID_VBLANK , V4L2_CID_HBLANK , and V4L2_CID_PIXEL_RATE . For low-light AE to reach 150000 us , the active frame rate must be reduced to about 6.67 fps or lower, or the AE control path must dynamically increase VBLANK/frame length. Changing Row Time in AE Dister alone may not affect AE if the active exposure range reported through the V4L2/CameraHelper path remains capped at about 66666 us . Please also confirm that the modified AE parameters are saved into the active DTP file referenced by config_ipa_uguzzi.yaml , copied to /usr/share/libcamera/ipa/nxp/neo/uguzzi/ , and that the camera pipeline is restarted or the corresponding algorithm reconfiguration is applied. Live Control changes are generally temporary unless saved into the project/DTP or applied through the proper reconfiguration path. My recommendation: treat this first as a frame-duration/VBLANK exposure-range issue, then verify DTP/profile activation. The fact that manual exposure reaches 150000 us is useful, but it does not prove the AE loop is allowed to request that value unless the AE-visible exposure range and frame timing are also updated.

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

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

FRDM-iMX93: MCU-Link Pro cannot connect to Cortex-M33 core via SWD Hi all, I have recently started developing with a FRDM i.MX 93 and purchased an MCU-Link Pro for Cortex-M33 debugging. I am trying to set up M33 debugging using the MCU-Link Pro connected via a SWD adapter to the external debug pin header on the board. Setup: Board: FRDM-IMX93  (MIMX9352) Probe: MCU Link Pro  with SWD Adapter  IDE: MCUXpresso for VS Code SDK: SDK_26_06_00_MIMX9352xxxxM Problem: After doing a firmware update on the probe, it is being recognised correctly by LinkServer, but when I try connecting to the M33 core it fails with Ee(42). Could not connect to core. What I've done: Connected the header pins correctly(P14) to the adapter and selected the right debug port on the MCU Link Pro (J7). 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

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来讲

MCXA185 Reading values of a potentiometer MCXA185 LPADC Potentiometer Reading – Looking for a More Stable ADC Value I am working with an NXP MCXA185 and using the LPADC to read a potentiometer connected to P2_0 / ADC0_A0. My current implementation uses: ADC0 / ADC0_A0 High-resolution conversion mode LPADC hardware averaging of 128 samples Long ADC sample time (kLPADC_SampleTimeADCK19) One ADC reading every 1 ms (1000 Hz) Software-triggered conversions A block average of 100 samples The resulting average is updated every 100 ms So effectively, each value used in the block average has already been averaged by the ADC hardware over 128 conversions. Current approach cmdConfig.conversionResolutionMode = kLPADC_ConversionResolutionHigh; cmdConfig.hardwareAverageMode = kLPADC_HardwareAverageCount128; cmdConfig.sampleChannelMode = kLPADC_SampleChannelSingleEndSideA; cmdConfig.sampleTimeMode = kLPADC_SampleTimeADCK19; Then every 1 ms: LPADC_DoSoftwareTrigger(POT_LPADC_BASE, (1U << POT_LPADC_TRIGGER_ID)); while (!LPADC_GetConvResult(POT_LPADC_BASE, &result)) { /* Wait for conversion */ } s_blockSum += result.convValue; s_sampleCount++; if (s_sampleCount >= 100U) { s_lastAverage = (uint16_t)(s_blockSum / 100U); s_blockSum = 0U; s_sampleCount = 0U; } My question Is this a good approach for getting a stable potentiometer value, or is there a better ADC filtering/averaging strategy? In particular, I am wondering about: Is using 128-count hardware averaging + 100-sample software averaging excessive for a potentiometer? Does this actually provide useful additional noise reduction, or am I just increasing the response latency? Would it be better to use a smaller hardware average, such as 16 or 32 samples, and then use a software filter? Would an IIR/exponential moving average be better than a 100-sample block average for a potentiometer because it provides a smoother value while responding faster to knob movement? Is kLPADC_SampleTimeADCK19 appropriate for a typical potentiometer, or should I use a different sample time? Are there any MCXA185-specific LPADC settings that I should enable for better stability? Is polling the ADC result inside a 1 ms function a reasonable implementation, or would a hardware timer trigger + ADC FIFO/interrupt approach be preferable? Pin configuration I am currently using: cfg.pullSelect = kPORT_PullDisable; cfg.driveStrength = kPORT_LowDriveStrength; cfg.passiveFilterEnable = true; cfg.inputBuffer = kPORT_InputBufferDisable; The potentiometer is connected as a voltage divider, with the wiper connected to P2_0 / ADC0_A0. I am mainly interested in getting a value that is: Stable when the potentiometer is not moving Responsive when the potentiometer is turned Not unnecessarily delayed by excessive averaging Resistant to small ADC/wiper noise I would appreciate feedback on whether my current 128 hardware average + 100-sample block average approach is appropriate, and what filtering strategy you would recommend for this application. Analog(ADC|CMP|DAC|OpAmps) MCXA Re: MCXA185 Reading values of a potentiometer Hello, Could you confirm if you are using a high-speed channel? Are you using an example from the SDK as base? You are using a high AVGS value, A higher value of conversions averaged will help you in having a more stable response, but if you are looking for a more balanced response, you can use a smaller AVGS as 16 samples (0100) for providing good noise suppression with much lower conversion time. In MCX-A-185 Datasheet, the Figure 11 and Figure 12 can help you in redirect on how much averaging do you need, considering a High speed mode. For using kLPADC_SampleTimeADCK19 It will depend on your application mission. The shortest sample time maximizes conversion speed for lower impedance inputs. Extending sample time allows higher impedance inputs to be accurately sampled. If you need to optimize conversion speed for a lower impedance as the potentiometer you can use a shorter sample time for example kLPADC_SampleTimeADCK7. If you need to calculate the Required sample time considering the desired accuracy, you can review for the formula in Datasheet Table 33 Subsection 4.B Probably the instructions for ADC Calibration in MCX-A-18 Reference Manual Chapter 45.5.1.2 - 45.5.1.4 are what you are looking for. Best Regards

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