アプレット こんにちは、お願いします。どなたか助けてくれませんか? 1.SE051PでカスタムJava Cardアプレットをビルド・ロードするための実際の開発経路(どのSDK、ツール、Java Card/GlobalPlatformバージョンか)はどうなりますか?カスタムアプレッションは工場で(NXPやパートナーによって事前インストール)行われるのか、それともGlobalPlatformのセキュアチャネルを通じて現場で発行後に行うことができるのか、またどのようなキー管理要件が適用されるのか? 2. SE051P部品を入手し、カスタムアプレットを開発・提供する機能を利用するには、ライセンス、NDA、パートナーシップの要件、または最低注文数量はありますか？ B. ペイメントとカスタムロジックの共存(1つと2つのセキュア要素) 3. 単一のJCOP Pay(ペイメント)プラットフォームが、EMVCo認証の決済アプレットと独立したアプリケーションロジックを持つ別のカスタムJavaカードアプレットを同時にホストできますか?それともEMVCo認証ではチップは決済アプレットのみを動作させる必要があり、つまりカスタムロジックには別のセキュア要素が必要になるのでしょうか? 4. 単一のチップ上で共存が可能な場合、カスタムアプレットをロードすると支払いアプレットのEMVCo認証に影響または無効化されますか? C. カスタムアプレットで利用可能な単調カウンタと暗号化機能 (SE051P) 5. ネイティブの単調カウンタセキュアオブジェクトは、Java Card API経由でカスタムアプレットからアクセスできるのか、それとも事前インストールされたIoTアプレットインターフェースからのみアクセスできるのか? 6. SE051P上のカスタムアプレットで使用できる署名アルゴリズムとECC曲線はどれですか（例：ECDSA P-256/P-384、Ed25519）？チップ上に保存された値の内部署名（POLICY_OBJ_INTERNAL_SIGNメカニズムと同様）は、カスタムアプレットからも利用できますか？ D. コイン型電池（CR2032）デバイス用電源 7. ECDSA P-256署名処理1回あたりの標準的な所要時間（ミリ秒単位）はどれくらいですか？また、SE051Pのアクティブな暗号化処理を行っていないときのアイドル/スタンバイ電流はどれくらいですか？(したがって、1動作あたりのエネルギーと待機レインを推定できます。) 8. CR2032コイン型電池のような高インピーダンス電源で動作する部品の場合、NXPは暗号化動作中の16.5mAのピーク電流に対応するために、特定のデカップリングコンデンサまたはバッファを推奨していますか？ 9. SE051Pにおいて、非接触インターフェースはRF電源(リーダーフィールドからエネルギーを引き出す)で動作し、カスタムアプレット操作が可能ですか?それともカスタムオンチップロジックは外部電源(例:バッテリー)が必要ですか?RF駆動の動作が可能であれば、フィールドパワーのみの場合、ECDSA署名、署名検証、単調カウンターインクリメント、セキュアオブジェクト更新、その他の不揮発性メモリ書き込みなどの操作に制約はありますか? 仮想テスト Re: Applet こんにちは、 @aaschi さん。 ご連絡いただきありがとうございます！私の意見は以下の通りです。 1. SE051P上でカスタムJava Cardアプレットをビルド・ロードする実際の開発経路(どのSDK、ツール、Java Card / GlobalPlatformバージョンか)は?カスタムアプレッションは工場で(NXPやパートナーによって事前インストール)行われるのか、それともGlobalPlatformのセキュアチャネルを通じて現場で発行後に行うことができるのか、またどのようなキーマネジメント要件が適用されるのか?これらのトピックに関するドキュメントを提供していますので、セキュアファイルチャネルからリクエストしてください。詳細については、以下をご参照ください。 Kan_Li_0-1784275947082.png 2. SE051P部品を入手し、カスタムアプレットを開発・提供する機能を利用するには、ライセンス、NDA、パートナーシップの要件、または最低注文数量はありますか？// はい、NDAとMOQが必要です。詳細については、お近くのNXP担当者にお問い合わせください。 B. ペイメントとカスタムロジックの共存(1つと2つのセキュア要素) 3. 単一のJCOP Pay(ペイメント)プラットフォームが、EMVCo認証の決済アプレットと独立したアプリケーションロジックを持つ別のカスタムJavaカードアプレットを同時にホストできますか?それともEMVCo認証はチップが決済アプレットのみを動かすことを要求しているのでしょうか?つまり、カスタムロジックには別のセキュア要素が必要になるのでしょうか?いいえ、2つの安全な要素を使う必要があります。1つは認証済みペイメントSE、もう1つはSE051P/カスタムSEで、専用ロジック用です。 4. 単一のチップ上で共存が可能な場合、カスタムアプレットの読み込みは支払いアプレットのEMVCo認証に影響または無効化しますか?いいえ、それは不可能です。 C. カスタムアプレットで利用可能なモノトニックカウンターと暗号(SE051P)//SE05x IoTアプレットのドキュメントはモノトニックカウンターセキュアオブジェクトをサポートしているため、ハードウェアの観点からはSE051Pでもサポートしているはずですが、カスタムアプレットの実装によります。 5. ネイティブの単調カウンタセキュアオブジェクトは、Java Card API経由でカスタムアプレットからアクセスできるのか、それとも事前インストールされたIoTアプレットインターフェースからのみアクセスできるのか?SE051PにはSE05xのIoTアプレットをインストールできず、自分でカスタムアプレットを開発する必要があります。 6. SE051P上のカスタムアプレットで使用できる署名アルゴリズムとECC曲線はどれですか（例：ECDSA P-256/P-384、Ed25519）？チップ上に保存された値の内部署名（POLICY_OBJ_INTERNAL_SIGNメカニズムと同様）は、カスタムアプレットからも利用できますか？ SE05xのIoTアプレットは幅広いアルゴリズムと曲線をサポートしているため、SE051Pも対応可能ですが、カスタムアプレットの実装によります D. コイン型電池（CR2032）デバイス用電源 7. ECDSA P-256署名処理1回あたりの標準的な所要時間（ミリ秒単位）はどれくらいですか？また、SE051Pのアクティブな暗号化処理を行っていないときのアイドル/スタンバイ電流はどれくらいですか？(したがって、1動作あたりのエネルギーと待機レインを推定できます。)ECDSAP-256検証は55ミリ秒未満であることが文書化されていますが、署名タイミングは確認できませんでした。アクティブ非対称暗号電流は最大16.5mAです。この情報はSE05x IoTアプレットからのものであり、カスタムアプレットの場合は、独自の実装によって異なります。 8. CR2032コイン型電池などの高インピーダンス電源で駆動する部品の場合、NXPは暗号化動作中の16.5mAのピーク電流を処理するために、特定のデカップリングコンデンサまたはバッファを推奨していますか？//いいえ特定のCR2032バッファコンデンサ値が見つかりました。設計は約16.5 mAのピークに加え、動作時間とセルのESRを合わせます。 9. SE051Pにおいて、非接触インターフェースはRF電源(リーダーフィールドからエネルギーを引き出す)で動作し、カスタムアプレット操作が可能ですか?それともカスタムオンチップロジックは外部電源(例:バッテリー)が必要ですか?RF駆動の動作が可能であれば、フィールドパワーのみの場合、ECDSA署名、署名検証、単調カウンターインクリメント、セキュアオブジェクト更新、その他の不揮発性メモリ書き込みなどの操作に制約はありますか?//RF駆動の操作SE051の動作はサポートされていますが、カスタムアプレットの暗号/NVMアップデートのRFのみ対応は確認・テストが必要です。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: Applet こんにちは、カンさん。 詳細なご回答ありがとうございました。大変参考になりました。この投稿を正しいものとしてマークします。 質問1のフォローアップとして、あなたが言及したドキュメント(SE051P用のカスタムJava Cardアプレット開発パス — SDK、ツール、Java Card/GlobalPlatformバージョン、アプレットのプロビジョニング)をセキュアファイルチャネル経由でリクエストしたいと思います。 正確な手順を教えていただけますか?具体的には： 1.セキュアファイルチャネルにはどうアクセスすればいいのでしょうか?NXPのサポートポータルでこのコミュニティアカウントにリンクしたプライベートサポートCASEを開くべきでしょうか、それとも別の方法がありますか? 2. NDAが成立する前に利用可能な書類はどれで、質問2で述べたNDAや現地代表の経路が必要なものはどれですか? 現段階の目標は、プロトタイプフェーズを計画するために開発経路のドキュメントを見直すことです。その後、現地代表とのNDA/MOQの協議が行われます。 改めてありがとうございました。 アースチ

i.MX RT1010 Flashing Issue I am using the @i.MX RT1010 on a custom board and I'm facing a flashing issue. All power rails are stable and within specification. RESET pin is stable (HIGH after power-up). The debugger detects the target, but flashing always fails. I have already checked the hardware for shorts and soldering issues. Development Board Re: i.MX RT1010 Flashing Issue Hello @keerthisri123, In order to support you better, could you provide me the next information? -Are you using the same external flash device as the RT1010-EVK? If not, could you please provide the part number of the flash device used on your custom board? -Which image are you attempting to program? Is it an SDK example or your own custom application? -Which tool are you using to program the device? For example MCUxpresso IDE, Secure provisioning tool, etc? -Are you connected through JTAG or SWD? If there are any additional details you believe could help, please do not hesitate to let me know. BR Habib Re: i.MX RT1010 Flashing Issue Hello Habib, Thank you for your response. Please find the details below: External Flash: I am using the AT25SF128A-SHB-T QSPI NOR Flash on my custom board. same as a EVK Image: I am attempting to program the evkmimxrt1010_igpio_input_interrupt SDK example. Programming Tool: SEGGER J-Link Commander V9.56 and SEGGER J-Flash Lite V9.56. Debug Interface: JTAG, using the same interface as the RT1010-EVK. Image Also attached for Your reference keerthisri123_0-1783355889230.png All Power sequence Reset Line are correctly Working  Re: i.MX RT1010 Flashing Issue Hello @keerthisri123, Could you please confirm whether you are able to connect to your device through the UART interface? If so, could you please follow the steps described in Section 6.15.2, "Connecting the board for RT10xx/RT116x/RT117x devices," of the Secure Provisioning Tool User Guide v26.03 and let me know your results? This will help to determine whether the issue is related to the SWD connection or if there may be another hardware problem.  You can access the User Guide directly from the Secure Provisioning Tool by navigating to Help → User Guide. Habib_MS_0-1783375355897.png Additionally, I recommend reviewing Chapter 5, "Debugging and Programming," of the Hardware Development Guide for the MIMXRT1010 Processor. This chapter provides several recommendations and best practices regarding debug connector implementation that may help you verify your hardware design and ensure reliable debug operation. What is the status of the boot mode pins and boot configuration pins when measured during power-up? Are they stable? Finally, could you please provide oscilloscope captures of the power up sequence? This will allow to verify that the power up timing and initialization sequence are being performed correctly. BR Habib Re: i.MX RT1011 Flashing Issue Hi Habibi, I have attached some reference images showing the Secure Provisioning Tool that I am using. I am using both JTAG and UART interfaces, but I am still getting a "Check connection, power supply and reset to ISP mode" message, as shown in the error log below. Could you please advise me on the next steps to troubleshoot this issue? Are there any specific procedures I should follow for the secure provisioning process? Also, are there any hardware checks that should be completed before proceeding with these steps? Thank you in advance for your support. Re: i.MX RT1011 Flashing Issue Hello @keerthisri123, Since this thread is public, could you please open a support ticket so that we can continue the investigation through a more private communication channel and securely review your schematics? This will help to further analyze the issue and discard any potential hardware connection issue. When opening the ticket, please feel free to reference this post and mention my name so I can continue assisting you. To help perform an initial review, please include the complete board schematics, with particular attention to: -Boot mode pins and boot configuration pins. -External flash connections. -Core and debug interface connections. -Power supply circuitry. -Clock connections. -Oscilloscope captures of the power-up sequence and the state of boot mode pins and boot configuration pins during power up. BR Habib Re: i.MX RT1011 Flashing Issue Hii Habib  Thanks for your response  We have a find a Mistake Boot Option is not configured in correct Manner and Qspi is Not working We resolve the issue  Regards Maharaja M

LX2160A 上的 VSC8254 PHY 在 1G SGMII 模式下启动需要协助 大家好， 我们正在开发一款基于 LX2160A Rev2 SoC 的定制电路板，其中 VSC8254 PHY 通过 eMDIO1 连接到 SoC。目前我们在 1G SGMII 模式下启动 PHY 时遇到问题。 到目前为止，我们已经通过在 DPC 文件和 Linux 内核设备树中配置固定链路，成功地在 10G XFI 模式下启动了 PHY。启动后，我们执行 NXP 提供的 mdio_cl45_write 脚本来对所需的 Clause 45 寄存器进行编程，之后链接建立并正常运行。 但是，当我们将配置切换到 1G SGMII 模式时，我们会进行以下更改： 更新 DPC 和 Linux 设备树，使其使用 SGMII 而不是 XFI。 执行 1G 对应的 Clause 45 寄存器初始化序列。 根据新配置的要求，将 SERDES 参考时钟从 125 MHz 更新为 100 MHz。 尽管做了这些更改，PHY 链路仍然无法建立。 供参考： VSC8254 PHY 连接到 SERDES1 MAC3 和 MAC4。 我们使用 RCW 6 进行 10G XFI 配置。 我们对 1G SGMII 配置采用 RCW 4。 关于在 1G SGMII 模式下启动 PHY 是否需要任何额外的配置更改或初始化步骤，请与我们联系。 感谢您的时间和支持。 @yipingwang @chenyin_h Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. 请将 RCW[SRDS_PLL_REF_CLK_SEL_S1] 配置为“00”。 2. 请在 Linux 内核中配置“CONFIG_VITESSE_PHY”。 3. 在 Linux 启动 dts 文件 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 中，请修改 dpmac3 和 dpmac4 的配置，使其与下面的配置类似。 &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "带内状态"; }; aquantia_phy1：以太网物理层@4 { /* AQR107 PHY */ 兼容 = "ethernet-phy-ieee802.3-c45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; 修改为： &dpmac3 { phy-handle = <&sgmii_phy1>; phy-connection-type = "sgmii"; managed = "带内状态"; }; sgmii_phy1：以太网物理层@xx{ reg = <0xxx>;//指定与dpmac3相关的MDIO PHY地址         }; 4. 请按如下方式修改 dtc 文件 dpc-usxgmii.dts。 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; 修改为： 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY";                         };

i.MX RT1010 刷机问题 我正在使用定制板上的 @ i.MX RT1010 ，遇到了刷机问题。 所有电源轨均稳定且符合规格。 RESET引脚稳定（上电后为高电平）。 调试器可以检测到目标设备，但烧录总是失败。 我已经检查过硬件是否存在短路和焊接问题。 开发板 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 ， 为了更好地为您提供支持，您能否提供以下信息？ -您使用的外置闪光灯设备与RT1010-EVK相同吗？如果没有，请问您能否提供您定制板上使用的闪存设备的零件编号？ -您尝试对哪张图片进行编程？这是一个 SDK 示例还是您自己的自定义应用程序？ -您使用哪种工具来对设备进行编程？例如 MCUxpresso IDE、安全配置工具等？ -您是通过 JTAG 还是 SWD 连接？ 如果您认为还有其他细节可能有所帮助，请随时告诉我。 BR 哈比卜 Re: i.MX RT1010 Flashing Issue 你好，哈比卜， 感谢您的反馈， 详情如下： 外部闪存：我的定制板上使用的是AT25SF128A-SHB-T QSPI 或非 闪存，与 EVK 相同。 图片：我正在尝试对evkmimxrt1010_igpio_input_interrupt SDK 示例进行编程。 编程工具： SEGGER J-Link Commander V9.56和SEGGER J-Flash Lite V9.56 。 调试接口： JTAG ，使用与 RT1010-EVK 相同的接口。 图片也附在后面供您参考 keerthisri123_0-1783355889230.png 所有电源时序 RESET 线均正常工作 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 ， 请问您是否能够通过 UART 接口连接到您的设备？如果是这样，请您按照安全配置工具用户指南 v26.03 中的 6.15.2 节“连接 RT10xx/RT116x/RT117x 设备的板”中描述的步骤进行操作，并告诉我您的结果？这将有助于确定问题是与SWD连接有关，还是可能存在其他硬件问题。 您可以通过导航至“帮助”→“用户指南”，直接从安全配置工具访问用户指南。 Habib_MS_0-1783375355897.png 此外，我建议复习MIMXRT1010 处理器硬件开发指南的第 5 章“调试和编程”。本章提供了一些关于调试连接器实现的建议和最佳实践，可以帮助您验证硬件设计并确保可靠的调试操作。 上电时，启动模式引脚和启动配置引脚的状态如何？它们稳定吗？ 最后，能否请您提供上电过程的示波器波形图？这将有助于验证上电时序和初始化顺序是否正确执行。 BR 哈比卜 Re: i.MX RT1011 Flashing Issue 嗨，哈比比， 我附上了一些参考图片，展示了我正在使用的安全配置工具。 我同时使用了 JTAG 和 UART 接口，但仍然收到“检查连接、电源并重置为 ISP 模式”的消息，如下面的错误日志所示。 请问您能否指导我下一步该如何排查这个问题？ 在安全配置过程中，我应该遵循哪些具体步骤？另外，在执行这些步骤之前，是否需要完成任何硬件检查？ 感谢您提前给予的支持。 Re: i.MX RT1011 Flashing Issue 你好@keerthisri123 ， 由于本帖是公开的，能否请您提交一个支持工单，以便我们可以通过更私密的沟通渠道继续调查并安全地查看您的原理图？这将有助于进一步分析问题，并排除任何潜在的硬件连接问题。 提交工单时，请随时引用此帖并提及我的名字，以便我继续为您提供帮助。 为了便于进行初步审核，请提供完整的电路板原理图，尤其要注意以下方面： -启动模式引脚和启动配置引脚。 -外部闪存连接。 -核心和调试接口连接。 -电源电路。 -时钟连接。 -使用示波器捕获上电序列以及上电期间启动模式引脚和启动配置引脚的状态。 BR 哈比卜 Re: i.MX RT1011 Flashing Issue 嗨，哈比卜 谢谢你的回复 我们发现了一个错误：启动选项配置不正确，QSPI 无法正常工作。我们已解决此问题。 此致 大君M

Ubuntu LinuxでのMCUXpresso IDEサポートに一体何が問題なのでしょうか? LinuxのMCUXpresso IDEでHello Worldプログラムを作るような、本当に単純なことなんて一つもありません。私はrt700のevkbボードを使っていますが、そのIDEは何度もクラッシュして切れてしまいます。ここ2〜3日ずっと苦戦しています。一体これは一体何なんだ?ある日は十分なサポートがあるはずですが、ある日は動かないのに。解決策を見つけるためのガイドもありません。基本的なプロジェクトを作成しても、ペリフェラルの設定タブを開くと、なぜか動作せず、奇妙なことにプロセッサコアがこれをサポートしていないとか、そんな感じです。最近はMicrosoft WindowsからこのIDE、そしてある程度はUbuntuまで、スロップか何かしらしかありません。このIDEを動かすには、Windows上でどうすればいいのですか?どうかこの問題を直してください。スクリーンショットも撮れません。あまりにもひどくフリーズします。 prathamvora_0-1784244137157.png Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux EVKBのBOMファイル自体は、IDEプロジェクト作成で使われるのと同じパッケージを使用しています。 prathamvora_1-1784245217062.png Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux ぜひこの動画を見て、このツールの使い方についてトレーニング動画も作ってください。VScode拡張機能を使うなんて、どれほどサポートが壊れるのか想像するしかありません。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux prathamvora_0-1784244495436.png システムを再起動してIDEを開くとこれが起きています Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux こんにちは、 @prathamvora さん。 MCUXpresso統合開発環境(IDE)のウェブページによると、サポートされているUbuntuバージョンはUbuntu 22.04 LTSとUbuntu 24.04 LTSです。Visual Studio Code版MCUXpressoの場合、サポートされているUbuntuバージョンはUbuntu 20.04.2 LTS、Ubuntu 22.04 LTS、Ubuntu 24.04 LTSです。 MCUXpresso IDEにはサポートされているUbuntuバージョン、Visual Studio CodeにはMCUXpressoを使うことをおすすめします。 よろしくお願いします、 パブロ

RT1176 - BT_FUSE_SEL のプログラミング後に JTAG 経由で SPI NOR フラッシュの読み出しに問題が発生する こんにちは、 RT1176 CPU上で署名および暗号化処理のテストを行っています。 基本的なシステム構成は、UART/JTAG <-> RT1176 <-> SPI Nor Flashです テストに使用するソフトウェアは以下の通りです: - RT1176テストファームウェア（起動後にLEDを点灯させるだけのシンプルなファームウェア） - NXP MCUXpresso セキュアプロビジョニング / blhost (UART を介した署名および暗号化用) - Segger JFlash(JTAG経由でFlashアクセス用) これまでに以下のテストを実施しました: 1) CPUがアンロックされ、署名がオフになっている間、ファームウェア(署名なし/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 2) CPUがアンロックされて署名が有効な間、ファームウェア(署名済み/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 3) CPUがロックされて署名がオンになっている間、ファームウェア(署名済み/暗号化済み)が起動せず、JTAG経由でフラッシュへのアクセスが不安定になります。 つまり、暗号化の問題があるということです。しかし、大きな暗号化問題を検証する前に、ステップ3の不安定なフラッシュ挙動を理解したいと思います。 いくつかのテストで、フラッシュ問題はBT_FUSE_SELが吹き抜けた直後に必ず発生することが明らかになりました(BT_FUSE_SEL無傷時はJTAG経由のフルフラッシュアクセスBT_FUSE_SEL、吹き飛ばすとJTAG経由の不安定なフラッシュアクセス)。現在テスト中のため、ヒューズ設定によるJTAGの無効化は行っていません。 では、質問はこうです: なぜBT_FUSE_SELがフラッシュへのアクセスを失わせるのでしょうか?（CPUがロックされているときに、何らかの読み出し保護機能が有効になっているのでしょうか？）segger jflashツールは、CPUがロックされている場合に問題が発生するのでしょうか？ こちらもご覧ください： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/mp/2044051 -同じ問題>:BT_FUSE_SEL >フラッシュアクセスできません よろしくお願いします。 よろしくお願いします、 フロリアン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @florian_arndt さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ BT_FUSE_SELは、SPI NOR読み出し保護を直接有効にしたり、JTAGを無効にしたりするものではありません。その機能は、ブートROMにBOOT_CFGピンではなく、eFuseに保存されているブート構成を使用させることです。 OTFAD/encrypted-XIP構成がeFuseにもプログラムされている場合、BT_FUSE_SELを書き込むことで、その構成が起動のたびに有効になり、BOOT_CFGピンを介してそれをバイパスする可能性がなくなります。誤ったOTFADコンテキスト、キー、アドレス範囲、または暗号化されたイメージは、アプリケーション開始前にブートROMが失敗する原因となることがあります。 したがって、現時点で最も可能性の高い原因は、ブートに関連するGPIOがバイパスされているものの、対応するeFuseが正しく設定されていないことだと考えられます。BT_FUSE_SEL自体はJTAG接続に影響を与えません。問題点を迅速に特定するために、A/Bテストを実施することをお勧めします。 よろしくお願いします、 ギャビン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @Gavin_Jia さん、 ご回答ありがとうございます！ 本日、暗号化処理に関する不具合（ファームウェアのバグ）を修正しました。当社のファームウェアは、CPU内で署名/暗号化が有効になった状態で起動するようになりました。 つまり、大きな問題は解決しました。 残っているのは、BT_FUSE_SELを設定した後のJTAG経由のSPIフラッシュ読み出しの問題です。 添付ファイルにヒューズマップがあります。 問題の原因になりそうなものは見えますか? 前もって感謝します。 フロリアン

FRDM中的ISP调谐 我目前正在 Verdin iMX95 FRDM 套件中安装拜耳传感器，已经获得了信号流，即将开始 ISP 调优。这里的调音完全不同，与 iMX8M Plus 有很大的不同。有人用Verdin iMX95套件进行过调校吗？

what the hell is wrong with MCUXpresso IDE support on ubuntu linux not a single bloody simplest of the simplest thing like creating a hello world program in the MCUXpresso IDE on Linux. I have a rt700 evkb board and that ide just keep crashing and hanging up i am struggling with it for the past 2-3 days just what in the world is this BS. it is obviously expected to have a decent enough support one day it works and then the other day it does not. there is also no guide to have some fix. even after creating some basic project when opening the peripheral configuration tab it magically just does not work it weirdly just say the processor core whatever does not support this or something like that. these days all we have is slop or what from Microsoft windows to even this IDE and then to some degree ubuntu as well.  to run this ide what is do you expect us to do to run it on windows? please for love of everything please fix this issues and i can't even take a screenshot it hangs up that bad.   prathamvora_0-1784244137157.png Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux The BOM file for the EVKB itself uses the same package as being used in ide project creation.  prathamvora_1-1784245217062.png Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux please have  a look at this video and please make some training videos on how to even use this tool. let alone use the vscode extension i can only imagine what kind of broken support it is going to be. Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux prathamvora_0-1784244495436.png this is what i get after rebooting my system and opening the IDE Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux Hi @prathamvora, According to the MCUXpresso Integrated Development Environment (IDE) webpage, the supported Ubuntu versions are Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. In the case of MCUXpresso for Visual Studio Code, the supported Ubuntu versions are Ubuntu 20.04.2 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. I would recommend using one of the supported Ubuntu versions for MCUXpresso IDE or MCUXpresso for Visual Studio Code. Best Regards, Pablo

RTC 示例程序在 frdm_mcxw72 开发板上无法成功编译。 您好， 我的工作台无法成功编译 RTC 示例。您可以在下面的截图中找到基本设置信息。 anliu114036_1-1784022974445.png 以下是构建过程中的日志信息： 配置任务已启动... 工作区位于 d:\ABC\rtc 正在加载 Zephyr 默认模块（Zephyr 基础模块（已缓存））。 -- 应用程序：D:/ABC/rtc -- CMake 版本：3.30.0 -- 找到 Python3：C:/Users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe（找到合适的版本“3.12.12”，最低要求版本为“3.12”）找到的元器件：解释器 缓存文件将写入：D:/ABC/zephyr/zephyr/.cache -- Zephyr 版本：4.4.1 (D:/ABC/zephyr/zephyr) -- 已找到西部（找到合适的版本“1.5.0”，最低要求为“0.14.0”） -- 板：frdm_mcxw72，资格赛选手：mcxw727c -- 找到主机工具：zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 找到工具链：zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 找到 Dtc：C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe（找到合适的版本“1.6.1”）最低要求为“1.4.6”） -- 找到 BOARD.dts 文件：D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- 找到设备树覆盖文件：D:/ABC/rtc/boards/frdm_mcxw72.overlay -- 生成的 zephyr.dts 文件：D:/ABC/rtc/build/zephyr/zephyr.dts -- 生成的 pickle 格式 edt 文件：D:/ABC/rtc/build/zephyr/edt.pickle -- 生成的 devicetree_generated.h：D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h 正在解析 D:/ABC/zephyr/zephyr/Kconfig 已加载配置“D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig” 合并配置“D:/ABC/rtc/prj.conf” 配置已保存到“D:/ABC/rtc/build/zephyr/.config” Kconfig 头文件已保存到 'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h' -- 找到 GnuLd：C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe（找到版本“2.43.1”） -- C 编译器标识为 GNU 14.3.0 -- CXX 编译器标识为 GNU 14.3.0 -- 汇编编译器标识为 GNU -- 找到汇编程序：C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe -- 在 D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ 中查找设备 MCXW727C -- 找到设备文件夹：D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- 找到 gen_kobject_list：D:/ABC/zephyr/zephyr/scripts/build/gen_kobject_list.py 配置完成（耗时26.9秒） 生成完成（耗时 1.8 秒） 版本文件已写入：D:/ABC/rtc/build 配置完成，返回代码为 0 * 终端将被任务重复使用，按任意键即可关闭。 * 正在执行任务：CMake：版本 工作区位于 d:\ABC\rtc 构建任务已启动…… C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] 正在生成 include/generated/zephyr/version.h -- Zephyr 版本：4.4.1 (D:/ABC/zephyr/zephyr)，构建版本：v4.4.1 [2/156] 正在生成 misc/generated/syscalls.json 和 misc/generated/struct_tags.json [3/156] 正在生成 include/generated/device-api-sections.ld 和 include/generated/device-api-sections.cmake [4/156] 正在生成 include/generated/zephyr/driver-validation.h [5/156] 正在生成 include/generated/zephyr/kobj-types-enum.h 和 include/generated/zephyr/otype-to-str.hinclude/generated/zephyr/otype-to-size.h [6/156] 正在生成 include/generated/zephyr/syscall_dispatch.c、include/generated/zephyr/syscall_exports_llext.c，syscall_weakdefs_llext.c，包含/generated/zephyr/syscall_list.h [7/156] 正在构建 C 对象 zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] 正在生成 ../../include/generated/zephyr/heap_constants.h [9/156] 正在构建 C 对象 zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] 正在生成 include/generated/zephyr/offsets.h [11/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] 正在构建 C 对象 CMakeFiles/app.dir/src/main.c.obj [13/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] 正在构建 ASM 对象 zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init.S.obj [32/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/subsys/tracing/tracing_none.c.obj [39/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] 正在构建汇编对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/nmi_on_reset.S.obj [41/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] 构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fault_s.S.obj [43/156] 构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/fatal.c.obj [44/156] 正在生成 linker_zephyr_pre0.cmd [45/156] 构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/nmi.c.obj [46/156] 正在构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/reset.S.obj [47/156] 正在构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/tls.c.obj [48/156] 构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/vector_table.S.obj [49/156] 构建 C 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fpu.c.obj [50/156] 链接 C 静态库 zephyr\arch\common\libisr_tables.a [51/156] 正在构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/svc.S.obj [52/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/scb.c.obj [53/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fault.c.obj [54/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/prep_c.c.obj [55/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/irq_manage.c.obj [56/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/thread.c.obj [57/156] 正在构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/swap_helper.S.obj [58/156] 构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/__aeabi_read_tp.S.obj [59/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/cpu_idle.c.obj [60/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/exc_exit.c.obj [61/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/irq_init.c.obj [62/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/thread_abort.c.obj [63/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/isr_wrapper.c.obj [64/156] 正在构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_core_mpu.c.obj [65/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/cmse/CMakeFiles/arch __arm__ core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] 正在构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_mpu_regions.c.obj [67/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/assert.c.obj [68/156] 构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_mpu.c.obj [69/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/cbprintf.c.obj [70/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/chk_fail.c.obj [71/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/errno_wrap.c.obj [72/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/exit.c.obj [73/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/time/time.c.obj [74/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/locks.c.obj [75/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/fnmatch.c.obj [76/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/stdlib/abort.c.obj [77/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/stdio.c.obj [78/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/stdlib/malloc.c.obj [79/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/getentropy.c.obj [80/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/getopt_shim.c.obj [81/156] 正在构建 C 对象 zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] 正在构建 C 对象 zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] 构建 C 对象 zephyr/drivers/pinctrl/CMakeFiles/drivers __pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__ gpio.dir/gpio_mcux.c.obj [85/156] 正在构建 C 对象 zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] 正在构建 C 对象 zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] 正在构建 C 对象 zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] 正在构建 C 对象模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] 正在构建 C 对象 zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_Arm.c.obj [91/156] 正在构建 C 对象 zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] 正在构建 C 设备 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] 链接 C 静态库 app\libapp.a [133/156] 链接 C 静态库 zephyr\libzephyr.a [134/156] 链接 C 静态库 zephyr\arch\common\libarch __common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__ arm__core.a [136/156] 链接 C 静态库 zephyr\arch\arch\arm\core\cortex_m\cmse\libarch __arm__ core__cortex_m __cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ arm __core__ mpu.a [138/156] 链接 C 静态库 zephyr\arch\arch\arm\core\cortex_m\libarch __arm__ core__cortex_m.a [139/156] 链接 C 静态库 zephyr\lib\libc\common\liblib __libc__ common.a [140/156] 链接 C 静态库 zephyr\lib\posix\c_lib_ext\liblib __posix__ c_lib_ext.a [141/156] 链接 C 静态库 zephyr\drivers\clock_control\libdrivers__clock_control.a [142/156] 链接 C 静态库 zephyr\lib\libc\picolibc\liblib __libc__ picolibc.a [143/156] 链接 C 静态库 zephyr\drivers\console\libdrivers __console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__ gpio.a [145/156] 链接 C 静态库 zephyr\drivers\pinctrl\libdrivers __pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__ serial.a [147/156] 链接 C 静态库 zephyr\drivers\rtc\libdrivers __rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__ timer.a [149/156] 链接 C 静态库 modules\hal_nxp\libmodules__hal_nxp.a [150/156] 链接 C 静态库 zephyr\kernel\libkernel.a [151/156] 链接 C 可执行文件 zephyr\zephyr_pre0.elf 失败：zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd .&& C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.azephyr/libzephyr.azephyr/arch/common/libarch __common.a zephyr/arch/arch/arm/core/libarch__ arm__core.azephyr/arch/arch/arm/core/cortex_m/libarch __arm__ core__cortex_m.azephyr/arch/arch/arm/core/cortex_m/cmse/libarch __arm__ core__cortex_m __cmse.a zephyr/arch/arch/arm/core/mpu/libarch__ arm __core__ mpu.azephyr/lib/libc/picolibc/liblib __libc__ picolibc.azephyr/lib/libc/common/liblib __libc__ common.azephyr/lib/posix/c_lib_ext/liblib __posix__ c_lib_ext.azephyr/drivers/clock_control/libdrivers__clock_control.azephyr/drivers/console/libdrivers __console.a zephyr/drivers/gpio/libdrivers__ gpio.azephyr/drivers/pinctrl/libdrivers __pinctrl.a zephyr/drivers/rtc/libdrivers__ rtc.azephyr/drivers/serial/libdrivers __serial.a zephyr/drivers/timer/libdrivers__ timer.amodules/hal_nxp/libmodules__hal_nxp.a-Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a-fuse-ld=bfd -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space"-lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /DD:\ABC\rtc\build\zephyr && C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe:app/libapp.a(main.c.obj): 在函数 `k_sleep` 中： D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94):未定义对“__device_dts_ord_92”的引用 collect2.exe：错误：ld 返回 1 退出状态 ninja：版本停止：子命令失败。 构建完成，但出现错误。 * 终端进程终止，退出代码为：1。 * 终端将被任务重复使用，按任意键即可关闭。 非常感谢您帮忙检查这个问题。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 示例： zephyr/samples/drivers/counter/alarm运行良好，但即使我创建的 overlay 文件与快照中的相同， RTC 示例在构建过程中仍然存在问题。 anliu114036_0-1784094520929.png 以下是构建过程中出现的关键错误信息，它应该能帮助您解决问题。非常感谢！ [5/64] 正在构建 C 对象 zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj 失败：zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS __ -D__ PROGRAM_START -D__ZEPHYR_SUPERVISOR __ -D__ ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/.-ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/.-ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers -isystem D:/ABC/zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -MF zephyr\drivers\rtc\CMakeFiles\drivers__rtc.dir\rtc_counter.c.obj.d-o zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -c D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c 从 D:/ABC/zephyr/zephyr/include/zephyr/toolchain.h:52 包含的文件， 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel_includes.h:23， 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel.h:17， 来自 D:/ABC/zephyr/zephyr/include/zephyr/drivers/rtc.h:26， 来自 D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36:错误：静态断言失败：“RTC 初始化优先级必须大于计数器” 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: 注意：在宏“BUILD_ASSERT”的展开中 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ，希望你一切都好。 当前MCXW72的RTC驱动程序实现旨在与counter.h配合使用。Zephyr库。考虑到这一点，我建议使用以下示例测试 RTC 功能： zephyr/samples/drivers/counter/alarm 。如下图所示： RomanVR_0-1784070722139.png 该项目模板将把 RTC 配置为具有报警功能的计数器。为了进行测试，请在/boards文件夹中创建一个名为 [frdm_mcxw72.overlay] 的覆盖文件。并将以下内容添加到文件中： / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; 请告诉我这些修改是否对您的开发有所帮助。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ， 要使 RTC 示例正确构建，您必须将以下设置添加到prj.conf文件中： CONFIG_RTC_INIT_PRIORITY=70 请告诉我这是否对您有效。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ， 请将该设置添加到名为prj.conf的文件中。因为将其添加到名为frdm_mcxw72.conf的创建文件中，Zephyr 版本系统不会像处理 overlay 文件那样自动获取它。 RomanVR_0-1784217266337.png 请告诉我这是否有帮助。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 我已经添加了包含该设置的 prj.conf 文件。 CONFIG_RTC_INIT_PRIORITY=70 anliu114036_0-1784163152280.png 但它仍然无法通过构建，错误提示信息也相同，您可以在附件中找到完整的构建日志。希望这能有助于找到问题所在。 顺祝商祺！ Re: RTC example can't build successfully in frdm_mcxw72 board 嗨@anliu114036 ，很高兴得知你已经成功构建了示例。 关于实时时钟 (RTC) 功能，目前 Zephyr 的 RTC 驱动程序 (rtc.h) 与我们用于 MCXW72 RTC 节点的底层驱动程序 (counter_mcux_rtc.c) 不兼容，因此 W72 的 RTC 应通过counter.h来使用。由于 API 与底层驱动程序中定义的 API 兼容，因此该驱动程序是可行的。 我之前分享的闹钟示例（zephyr/samples/drivers/counter/alarm）演示了我们 RTC 驱动程序的全部当前功能。 请告诉我这些信息是否解答了您的疑问。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 在 prj.conf 文件中添加设置后，问题解决了，谢谢你的帮助！ 但是仍然存在一个问题，就是当我把镜像刷入EVK后，RTC功能似乎仍然无法正常工作，因为打印出来的时间信息没有变化。 anliu114036_0-1784258576109.png 能否帮忙查一下？非常感谢！

小程序 您好，请问。请问有人能帮帮我吗？ 1.在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？ 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？ B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者 EMVCo 认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要单独的安全元件？ 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的 EMVCo 认证失效？ C. 自定义小程序可使用单调计数器和加密功能 (SE051P) 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？ 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。） 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐特定的去耦电容或缓冲器来处理加密操作期间的 16.5 mA 峰值电流？ 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作是可能的，那么在仅使用场功率的情况下，ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？ 虚拟测试 Re: Applet 嗨@aaschi ， 感谢您的联系！我的评论如下： 1. 在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？// 我们提供有关这些主题的文档，请通过安全文件通道索取。更多详情请参考以下内容。 Kan_Li_0-1784275947082.png 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？是的，需要签署保密协议，并且需要达到最低订购量。请联系您当地的恩智浦代表了解更多详情。 B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者，EMVCo认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要一个单独的安全元件？不，您必须使用两个安全元件——一个经过认证的支付 SE 和一个用于专有逻辑的 SE051P/自定义 SE。 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的EMVCo认证失效？//不，这不可能。 C. 自定义小程序 (SE051P) 可使用单调计数器和加密 // SE05x IoT 小程序文档支持单调计数器安全对象，因此从硬件角度来看，SE051P 也应该支持，但这取决于您的自定义小程序实现。 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？// 您无法在 SE051P 上安装 SE05x 预装的 IoT 小程序，您必须开发自己的自定义小程序。 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ SE05x IoT 小程序支持多种算法和曲线，因此 SE051P 也可能支持，但这取决于您的自定义小程序实现。 D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。）//ECDSAP-256 验证记录为 <55 毫秒；未找到签名计时。主动式非对称加密电流高达 16.5 mA。这些信息来自SE05x IoT 小程序，对于自定义小程序，则取决于您自己的实现。 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐使用特定的去耦电容或缓冲器来处理加密操作期间 16.5 mA 的峰值电流？//否确定了 CR2032 缓冲电容的具体值；设计峰值电流约为 16.5 mA，加上工作时间和电池 ESR。 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作可行，那么在仅使用场强的情况下，诸如 ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？//射频供电支持 SE051 操作，但必须确认和测试对自定义小程序加密/NVM 更新的 RF 专用支持。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Applet 嗨，Kan， 感谢您的详细解答，非常有帮助。我会将此帖子标记为正确答案。 关于问题 1：我想通过安全文件通道请求您提到的文档（SE051P 的自定义 Java Card 小程序开发路径 — SDK、工具、Java Card / GlobalPlatform 版本和小程序配置）。 请问您能告诉我具体的操作步骤吗？具体来说： 1.我该如何访问安全文件通道？我应该在与此社区帐户关联的 NXP 支持门户上开一个私人支持案例，还是有其他途径？ 2. 在签署保密协议之前，哪些文件可以获取？哪些文件需要通过您在问题 2 中提到的保密协议/当地代表途径获取？ 我现阶段的目标是审查开发路径文档，以规划原型阶段；之后将与当地代表讨论保密协议/最低订购量。 再次感谢， 阿斯基

MPC5746C 在 115°C 环境温度下死机（无法启动，UART 无输出） 部件号： MPC5746C（电源架构 Z4，SDK：NXP MPC57xx 平台 SDK） 在 115°C 环境温度下进行热室测试时，我们基于 MPC5746C 的板在启动时完全无响应——没有任何 UART 控制台输出，并且在该温度下每次启动尝试都会发生这种情况。冷却后该部件似乎完全恢复：在室温下重新刷写/重启即可恢复正常运行，且不会造成永久性损坏。 有趣的是，即使电路板温度高达 115°C，我们仍然可以通过 PEMicro JTAG 调试探针成功地对闪存进行重新编程——我们通过在高温下刷入版本字符串递增的构建版本，并在冷却后读取新版本，证实了这一点。因此，调试探测闪存路径在 115°C 下工作；只有应用程序启动路径挂起/处于错误状态。 手册上说MCU可以承受高达125°C的温度。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ Re: MPC5746C hangs (no boot, no UART) at 115°C ambient 你好， 手册上说MCU可以承受高达125°C的温度。 是的，这不是问题。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ 由于这是你的定制板，而且问题在冷却后消失，我怀疑： 1. 时钟启动问题（可能性最高） 在 115°C 时： 外部晶体（FXOSC）启动时间增加。 振荡器增益裕度降低。 负载电容的电容值会随温度变化。 PCB漏电加剧。 调试器仍然可以访问该部分，因为调试逻辑使用自己的基础架构，并不依赖于应用程序是否执行到 main() 函数。 FXOSC 状态位 CMU时钟监测故障 仅 FIRC 启动实验 完全通过 FIRC 运行，并暂时禁用外部晶振。 JTAG编程在115°C下仍能正常工作，这有力地表明核心基础设施仍然运行正常，故障发生在应用程序启动路径的早期阶段，而不是闪存阵列本身。 顺祝商祺！ Peter Re: MPC5746C hangs (no boot, no UART) at 115°C ambient 感谢@petervlna的真知灼见。 随后，我和我的同事@mnargund进行了进一步调查，我们成功地让 MPC5746C 在 115°C 下启动。以下是我们发现的结果总结。 根本原因：在预初始化期间，我们配置系统启动 FIRC、FXOSC 和 PLL，然后将系统时钟从 FIRC 切换到 PLL。随后，我们触发了向 DRUN 模式的模式转换（尽管系统默认已处于 DRUN 模式，但如手册中所述，需要转换到相同模式才能使新配置生效），并轮询 MC_ME_GS.MTRANS 以等待转换完成。 然而，即使在 MC_ME_GS.MTRANS 清除之后，代码仍然出现 IVOR1 异常，这可能表明在执行继续进行时，转换尚未完全稳定。在高温（115°C）下，转变似乎比在室温下需要更长时间，导致系统在执行下一条指令时处于不一致的状态。 已采取的变通方法：我们在 MC_ME_GS.MTRANS 轮询之后、在继续执行其余初始化操作之前插入了一个显式的软件延迟。延迟 500 毫秒，在 115°C 下启动始终成功。我们还测试了 100 毫秒的延迟，在我们的设置中也能可靠地工作。 在初始化过程中，是否存在一个可以安全插入的最大推荐软件延迟？ 在高达 125°C 的整个工作温度范围内，是否有推荐的做法来确保时钟稳定可靠？

NXPカップ2026のNXPコミュニティ参加に関する質問 私は2026年のNXPカップに参加しています。コミュニティやグループの一部としてリアルタイムで情報やリソースの情報を伝えるメールは送っていますが、郵送中のグループリンクにはアクセスできません。それが私が直面している問題であり、その解決策を求めています。

FRDMにおけるISPチューニング 現在、Verdin iMX95 FRDMキットでBayerセンサーを導入していて、Streamを手に入れてISPのチューニングを始めようとしています。ここでのチューニングは全く異なり、iMX8M Plusとは大きな違いがあります。Verdin iMX95キットを使ってチューニングを行った方はいますか？

MPC5746Cは周囲温度115℃でハングアップする（起動せず、UARTも動作しない）。 パート: MPC5746C(Power Architecture Z4、SDK:NXP MPC57xxプラットフォームSDK) 周囲温度115℃での恒温槽試験中、当社のMPC5746Cベースのボードは起動時に完全に反応しなくなり、UARTコンソール出力が全くなくなります。この現象は、その温度での起動試行のたびに発生します。冷却後、部品は完全に回復するようです。室温で再フラッシュ/再起動すると、永続的な損傷なく正常な動作に戻ります。 興味深いことに、基板が115°Cの状態でもPEMicro JTAGデバッグプローブを使ってフラッシュを再プログラム することは可能です 。これは、温度でバージョンストリングをフラッシングし、冷却後に新しいバージョンを読み返すことで確認済みです。したがって、デバッグプローブのフラッシュ経路は115°Cで動作します。アプリケーションのブートパスだけがハング/悪い状態になります。 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 問題の根本原因と解決方法を教えていただけませんか。 Re: MPC5746C hangs (no boot, no UART) at 115°C ambient こんにちは、 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 はい、それは問題ありません。 問題の根本原因と解決方法を教えていただけませんか。 これはカスタムボードであり、冷却後に問題が解消されることから、私は次のことを疑っています。 1. 時計の起動に関する問題（最も可能性が高い） 115℃の場合： 外部水晶発振器（FXOSC）の起動時間が長くなります。 発振器のゲインマージンが減少する。 負荷コンデンサの値は温度によって変化する。 プリント基板からの漏洩電流が増加します。 デバッグロジックは独自のインフラストラクチャを利用し、アプリケーションがmain(に到達する)に依存しないため、デバッガーは部品にアクセスできます。 FXOSCステータスビット CMUクロックモニタの障害 FIRCのみのブート実験 FIRCから完全に実行し、外部水晶発振器を一時的に無効にする JTAGのプログラミングが115°Cで動作し続けていることは、コアインフラストラクチャがまだ生きており、故障がフラッシュアレイ自体ではなくアプリケーションのブートパスの非常に早い段階で起きていることを示す最も強い手がかりです よろしくお願いいたします。 ピーター Re: MPC5746C hangs (no boot, no UART) at 115°C ambient @petervlna さん、貴重なご意見ありがとうございます。 これを受けて、同僚の@mnargundと私はさらに調査を進め、MPC5746Cを115℃で正常に起動させることに成功しました。以下に、調査結果の概要を示します。 根本原因: 事前初期化時にシステムをFIRC、FXOSC、PLLを起動するように設定し、その後システムクロックをFIRCからPLLに切り替えました。続いて、DRUN モードへのモード遷移をトリガーしました（システムはデフォルトで既に DRUN モードでしたが、マニュアルに記載されているように、新しい設定を有効にするには同じモードへの遷移が必要です）。そして、MC_ME_GS.MTRANS をポーリングして遷移が完了するのを待ちました。 しかし、MC_ME_GS.MTRANSがクリアされた後でも、コードはIVOR1例外でエラーを起こしました。これは、実行が続行された時点で遷移が完全に安定していなかったことを示している可能性があります。高温（115℃）では、室温よりも遷移に時間がかかるようで、次の命令が実行されたときにシステムが不安定な状態になる。 回避策の適用例: MC_ME_GSの後に明示的なソフトウェア遅延を挿入しました。MTRANSのポーリングを行い、その後の初期化を進めます。500ミリ秒の遅延を設けると、115℃の環境下でも起動は安定して成功する。100ミリ秒の遅延もテストしましたが、私たちの環境では問題なく動作しました。 初期化のこの段階で安全に挿入できる最大推奨ソフトウェア遅延はありますか? 125℃までの全動作温度範囲において、動作前にクロックの安定性を確実に確保するための推奨手順はありますか？

S32K389 AES_ACCEL が 64KB のデータを暗号化する際にハング/フリーズする こんにちは、NXPチームの皆様、 私はS32K389を使用しており、 AES_ACCEL（ACE/MSC）モジュールをテストしています。大規模なデータバッファをプロセッシング中に安定性の問題に直面しました。 テスト設定: モード:AES-CBC CASE 1(合格):4KBデータの暗号化は正しく動作します。 企业微信截图_17834738161180.png ケース2(失敗):64KBのデータを暗号化すると、AESサービスが実行されるとチップが即座にクラッシュまたはハングします。 観察された行動： S32DS(S32 Design Studio)はAESサービスの実行中にフリーズします。 デバッガを介してS32K389に接続しようとすると、完全に失敗します。 企业微信截图_17834744241242.png 質問: AES_ACCELトランザクションあたりの最大データ長に関して、既知の制限事項はありますか？ よろしくお願いします、 シアンロン Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは@wuxianlong 確認させてください。できるだけ早くご連絡いたします。 よろしくお願いいたします。 ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 遅れてすみません。内部リソースへのアクセス権に問題があり、解決に予想以上に時間がかかっています。できるだけ早くお答えします。ご辛抱いただきありがとうございます。 よろしくお願いいたします。 ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは@wuxianlong CMACが検証サービスを生成する際には、以下の制限があります。 lukaszadrapa_2-1784041947940.png 暗号化にも制限があるかどうか、現在確認中です。後ほどお知らせします。 よろしくお願いいたします。 ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは、 @lukaszadrapa ご説明いただき、誠にありがとうございました。暗号化とCMAC検証は、おそらく同じ制約に直面しているだろう。 よろしくお願いします、 シアンロン Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data サイズ制限は512KBで、LENビットフィールドのサイズは19ビットであるという情報を得ました。 興味深いことに、実行が完全にクラッシュした。パラメータが無効な場合にエラーコードを返すだけAES_ACCELと思います。 それはXRDCが原因ではないですか？XRDCは有効になっていますか？テスト目的で無効にしてみてもらえますか? よろしくお願いいたします。 ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは、 @lukaszadrapa 64KBでのテストも依然として失敗します。AECエラー検出を有効にすると、IPドライバマクロが制限を (1 << 19)- 1ビット<64 KBに設定していることがわかりました。 image.png 敬具 仙龍

Android 16：为什么恩智浦半导体（NXP）在 vendor_boot 中发明了一种处理设备树的独特方法？ 检查 Android 16 1.4.0 版本中包含的最后一个 u-boot 启动加载程序，我发现启动加载程序中添加了一个配置选项“CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT”。 我以为这样就能解决问题，因为旧版本的 Android 使用“dtbo”分区来存储主设备树。我的理解是错误的，因为主设备树应该放在“vendor_boot”分区中（至少对于vendor_boot v4来说是这样），而dtbo分区填充了设备树覆盖层，这些覆盖层可以应用于主设备树以支持硬件变体。 请参见 https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions 文档中明确指出，vendor_boot 中只能有一个设备树。 但现在 NXP 已经实现了放弃“dtbo”分区，并使用 vendor_boot 内部的“dt_table_header”结构体，直接向 vendor_boot 添加多个完整的设备树。此标头通常用于“dtbo”分区内，以组织多个设备树覆盖层，但不用于“vendor_boot”分区内。 NXP 的这种处理设备树的特殊方式与 Android 的标准方式相冲突，Android 的标准方式是使用一个主设备树和来自 dtbo 的设备树覆盖层。这使得像我这样使用设备树覆盖概念来维护其 Android 移植版本的用户变得困难。 NXP 为什么选择以这种方式实现设备树变体？ 你们是否有计划将此行为改回 Android 官方文档中描述的方式？ Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot 你好， 请注意，Android 并不强制要求拥有多个设备树，因此，除非操作系统架构发生强制性变更，否则我认为我们提供 电路板支持包。 的方式不会改变，因为到目前为止，这已经是许多版本的默认做法。 另外，请注意，引导加载程序在选择设备树时需要执行以下操作： 1> 识别SoC并加载相应的.dtb文件从存储器到内存。 2> 识别开发板并加载相应的 .dtbo 文件从存储器到内存。 3> 覆盖 .dtb 文件将 .dtbo 合并为一个 DT。 4> 根据合并后的 DT 的内存地址启动内核。 因此，我们无法确定应该使用哪个设备树，因为我们使用相同的硬件，只是针对不同的实现/演示做了一些小的改动。我认为只有在使用相同的 SOM（相同的基本配置 SoC+DDR+电源 IC）但使用不同的硬件时，这种方法才有用。因此，这不符合我们交付硬件/软件的方式，添加它也没有任何好处。 此致敬礼/Saludos， 阿尔多。

Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Inspecting last u-boot bootloader contained in Android 16 1.4.0 release I have discovered that an config option "CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT" has been added to the bootloader. I assumed that it fixes the problem, that older Android versions used "dtbo" partition to store the main device tree. In my understanding that was wrong, because main device tree should be placed in "vendor_boot" partition (at least for vendor_boot v4) and dtbo partition gets filled with device tree overlays which can be applied to the main device tree to support hardware variants. See https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions where it is documented, that only one device tree to be inside vendor_boot. But now NXP has made an implementation to abandon "dtbo" partition and use the "dt_table_header" struct inisde vendor_boot to add more than one full device tree directly to vendor_boot. This header is normally used inside "dtbo" partition to organize multiple device tree overlays, but not inside "vendor_boot". This NXP specific way of handling device trees conflicts with the standard Android way to use one main device tree and device tree overlays from dtbo. This makes it hard for users (like me) who use the concept of device tree overlays to maintain their Android ports. Why has NXP chosen to implemeted device tree variants in that way? Do you have plans to change this behaviour back to the way as documented by Android? Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Hello, Please note that having multiple device tree is not mandatory for Android, so unless there is a mandatory change in the architecture of the OS I do not think this will change on how we provide our BSP as this has been the default for many versions so far. Also, note that for selecting the device tree the bootloader needs to: 1> Identify the SoC and load the corresponding .dtb from storage into memory. 2> Identify the board and load the corresponding .dtbo from storage into memory. 3> Overlay the .dtb with the .dtbo to be a merged DT. 4> Start kernel given the memory address of the merged DT. Following this we do not have a way to identify if one device tree should be used or the other, as we use the same hardware and just small changes for different implementation/demonstration, I would see this useful only if you are working with different hardware while using the same SOM (same basic configuration SoC+DDR+power IC). So, this does not comply on how we deliver our hw/sw and see no benefit on adding it. Best regards/Saludos, Aldo.

S32K389 AES_ACCEL 在加密 64KB 数据时会挂起/冻结 您好，NXP团队： 我正在使用S32K389并测试AES_ACCEL (ACE/MSC)模块。我在处理大型数据缓冲区时遇到了稳定性问题。 测试设置： 模式： AES-密码块链接(CBC) 案例 1（通过）：加密4KB数据工作正常。 企业微信截图_17834738161180.png 案例 2（失败）：加密64KB数据会导致芯片在执行 AES 服务时立即崩溃/挂起。 观察到的行为： S32DS（S32 设计工作室）在执行 AES 服务期间冻结。 尝试通过调试器连接到 S32K389 完全失败。 企业微信截图_17834744241242.png 问题： 对于每个 AES_ACCEL 事务的最大数据长度，是否存在任何已知的限制？ 此致， 显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong 让我查一下。我会尽快回复您。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 很抱歉耽搁了，我遇到了一些内部资源访问权限方面的问题，解决起来比预期要花更多时间。我会尽快回复。感谢您的耐心等待。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong CMAC生成验证服务存在以下限制： lukaszadrapa_2-1784041947940.png 我还在确认加密方面是否存在限制。我稍后会通知你。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 非常感谢您的解释。加密和 CMAC 验证可能面临同样的局限性。 此致， 显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 我了解到大小限制为 512KB - LEN 位域的大小为 19 位。 有趣的是，程序执行完全崩溃了。我预计 AES_ACCEL 在参数无效的情况下会返回一些错误代码。 那不是XRDC引起的吗？XRDC 是否已启用？您能否尝试将其禁用以进行测试？ 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 使用 64KB 进行测试仍然失败。启用 AEC 错误检测后发现，IP 驱动程序宏将限制设置为(1 << 19) - 1​ 位 < 64 KB。 image.png 此致， 显龙

A query regarding joining the nxp communities for nxp cup 2026 I am participating in NXP Cup in 2026. In that I have got a mail to be part of some communities and groups to be updated in real time and to be updated with the resources and all but I can't access those group links in the mail. That's the issue I am facing and I want the resolution for it. 

S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi NXP team, I’m working with the S32K389​ and testing the AES_ACCEL (ACE/MSC)​ module. I’ve encountered a stability issue when processing large data buffers. Test Setup: Mode:​ AES-CBC Case 1 (Pass):​ Encrypting 4KB​ data works correctly. 企业微信截图_17834738161180.png Case 2 (Fail):​ Encrypting 64KB​ data causes the chip to crash/hang immediately when the AES service is executed. Observed Behavior: S32DS (S32 Design Studio) freezes during the execution of the AES service. Attempts to Attach​ to the S32K389 via the debugger fail completely. 企业微信截图_17834744241242.png Questions: Are there any known limitations regarding the maximum data length per AES_ACCEL transaction? Best Regards, xianlong Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi @wuxianlong  Let me check this. I will get back to you as soon as possible.  Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data I'm sorry for delay, I have some issues with access rights to internal resources and it takes more time than expected to solve it. I will answer this as soon as possible. Thanks for your patience.  Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi @wuxianlong  There's following limitation for CMAC generate a verify services: lukaszadrapa_2-1784041947940.png I'm still checking if there's a limitation also for encryption. I will let you know later.  Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi,@lukaszadrapa  Thank you very much for your explanation. It is probable that encryption and CMAC verification face the same limitations. Best Regards, xianlong Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data I got information that size limitation is 512KB - the size of LEN bit field is 19 bits.  Interesting thing is that the execution crashed completely. I would expect that AES_ACCEL just returns some error code in case of invalid parameters.  Isn't that caused by XRDC? Is XRDC enabled? Could you try to disable it for test purposes? Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi,@lukaszadrapa  Testing with 64KB still fails. Enabling AEC error detection revealed the IP driver macro sets the limit to (1 << 19) - 1​ bit < 64 KB. image.png Best Regards, xianlong