CANドライバの復旧 こんにちは、 私はFRDM-A-S32K344プラットフォーム上でFlexCANドライバ（割り込みモード）の開発に取り組んでいます。CANドライバが、システムリセットやイグニッションリセットなしでCANバス障害からの自動復旧をサポートしているかどうかを確認したい。このリカバリ機能がSDKバージョン3.0.0に存在する場合、ドライバのどこに実装または反映されているのか、また、どこで確認すればよいのか教えてください。 Re: CAN driver recovery こんにちは、 @ganavi1 さん。 @shepさんが指摘したように、RTDパッケージに含まれるFlexCANドライバを使用すると、「AutoBus Recovery」機能を有効にできます。 これはデフォルトで設定されており、追加の設定は必要ありません。このビットが有効になると、FLEXCANは自動的にバスオフ状態から正常状態への復旧を試みます（バスオフの原因となった外部条件が解消された場合）。 よろしくお願いします、 ジュリアン Re: CAN driver recovery S32K FlexCANレジスタは、バスオフ時の自動復旧機能をサポートしています。SDKのマニュアルは持っていませんが、関連するセクションを検索して、リファレンスマニュアルに記載されている部分と連携しているかどうかを確認してみてください。 以下はリファレンス・マニュアルからの抜粋です。 CTRL1レジスタ BOFFREC バスの事故復旧 FlexCANがバスオフ状態からどのように復旧するかを決定します。0の場合、CAN仕様2.0Bに従ってバスオフ状態からの自動復旧が行われます。1の場合、バス停止からの自動復旧は無効になります。このフィールドに1を書き込むまで、モジュールはバスオフ状態のままです。 CANバス上で11ビットの劣性ビットのシーケンスが128回検出される前にこのフィールドが0になった場合、バスオフからの復旧は、このフィールドが一度も1になったことがないかのように行われます。11ビットの劣性ビットのシーケンスが128回発生した後にこのフィールドが0になった場合、FlexCANはバスと再同期します。バスに加わる前に、11個の劣性遺伝子を待つ。 このフィールドが0になった後、バスオフ中に再び1になることができますが、それはモジュールが次にバスオフになったときにのみ有効になります。モジュールがバスオフ状態のときにこのフィールドが0になった場合、このフィールドに1を書き込んでも、現在のバスオフからの復旧には効果がありません。 詳細については、CANプロトコル規格ISO 11898-1:2015の「バスオフ」の項を参照してください。 注記 0b - 有効 1b - 無効 このビットのデフォルト値は0なので、デフォルトではバスオフからの復旧が自動的に実行されます。 Re: CAN driver recovery 以下にいくつかのエラー訂正機能を示します。お役に立てば幸いです。 メモリ読み出しアクセスにおけるエラーの検出と訂正： FlexCANメモリの各バイトは、5ビットのパリティビットに対応しています。 誤り訂正機構により、この13ビットワードの1ビットにおける誤り（訂正可能な誤り）を訂正することが可能になります。 —2ビットのエラーは検出できますが、訂正することはできません（訂正不可能なエラー）。

[S32K328 和 S32K358 ] 关于 HSE-B 的绩效 亲爱的 我想知道 HSE-B（网络安全引擎）在 S32K328GHT1MJBST 和 S32K358GHT1MPCST 的网络安全功能或性能方面是否有所不同。 谢谢， Bryan Re: [S32K328 and S32K358 ] About performance for HSE-B 你好@bryan_hong 没有区别。S32K328 和 S32K358 共享相同版本的 HSE 固件。而且这两款设备也有相同的时钟限制。因此，安全功能和HSE性能将完全相同。 此致， Lukas

Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi NXP expert, When I do shipping mode validation, I found an abnormal current leakage in NX20P0407 when VSYS=0V in shipping mode; Abnormal finding: NX20P0407 has an equivalent 75K pull down resistance on SBU1 line(system side) when VSYS=0V, which is not defined in datasheet's block diagram. Schematic: The system side SBU1 is only connected to MCU's SWDIO(MCU: nRF52840), which has 13K pullup resistor(V_pullup=3.3V); In my application's shipping mode, MCU is alive but NX20P0407 will be disconnected from power(VSYS=0V); When i did measurement on the SBU1 pin, found SBU1 pin's voltage is 2.8147V, which means there is 75K pull down resistor on SBU1 line and also caused 37uA current leakage; I also tried to de-soldering the NX20P0407, and the 37uA current leakage disappear which double confirmed that NX20P0407 caused the current leakage; So i would like to confirm whether my finding is correct or not, and if that's correct, why it is not specified in the data sheet, many thanks! Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Zong, I suspect the leakage current is flowing from the SBU1 pin to VSYS, than to the GND through the pull-down resistor. Please try to disconnect the VSYS pin completely and see if the leakage current will decrease. The 32uA leakage current is closest to the leakage current you see. Please make sure you have pulled the SBUEN pin to GND when the NX20P0407 is unused. Leaving the SBUEN floating may pull it high by an EMI.  With Best Regards, Jozef Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Adding the simplified block diagram related to NX20P0407 for reference. Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Jozef， Thanks for you quick response, please see my reply as below: Have you connected the VSYS to GND? Or have you left it floating? --Reply: There is a load switch between PP3V3 power rail and NX20P0407's VSYS; MCU will turn off the load switch to de-power NX20P0407 in shipping mode; How is the rest of the NX20P0407 pins connected in shipping mode --CC1&CC2 are connected to PD controller's CC lines which is also being de-powered in shipping mode, SBUEN is connected to the same PD controller's one GPIO; SBU2 is connected to MCU's SWDCLK which has internal pull down resistor; Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Zong, thank you for detailed description and schematic. Please confirm how you have connected the VSYS pin in shipping mode (when you measured 37uA on SBU1 pin). Have you connected the VSYS to GND? Or have you left it floating? How is the rest of the NX20P0407 pins connected in shipping mode?  With Best Regards, Jozef

在 i.mx8ULP 上启动 SPI 与非 你好 我正在尝试从 i.MX8ULP 上的 SPI 与非 启动。 evk 连接了 SPI 或非，我可以从中启动，但是在我们的主板上尝试使用 与非 时我无法让它起作用。我已经配置了 BT*_CFG* 引脚，我看到启动 ROM 尝试读取与非，但是 M33 和 A35 内核似乎都无法启动，所以我认为启动映像不正确。 我正在使用 imx-mkimage flash_singleboot_m33_flexspi 目标构建映像，它使用 fspi_header 文件作为头块，但是这个文件中的注释似乎表明这是针对串行 或非 而不是 与非 的，所以我正在研究这个 flexspi 配置块标头。 如何为我们的目标制作合适的头文件？ 我找到了 kobs-ng 但它似乎不适合 8ulp（没有 GPMI 与非 控制器，无论如何即使在轻微打补丁之后也无法运行） 我在 8ulp 文档中也找不到任何关于 FCFB 块的文档。我在 i.MX 8M 迷你应用处理器参考手册（以及在 u-boot mkimage 中添加了相关选项的 u-boot 补丁）中找到了一些关于它的文档，但即使它的格式确实相同，那么如何将其用于 i.MX8ULP（尤其是要使用哪个 LUT 表）也将不胜感激。 谢谢！ 多米尼克-马蒂内

RTDバージョンの移行理由と目的：バージョン3.0.0への移行 チームの皆さん、こんにちは。 現在、 RTD 2.0.0からRTD 3.0.0への移行作業を進めています。そして、既存のブートローダー実装への影響について理解を深めたいと考えています。 以下の点についてご説明いただけますでしょうか。 RTD 2.0.0とRTD 3.0.0の間で、設定項目やAPIに大きな変更点はありますか？それは既存の実装に影響を与えるでしょうか？ RTD 2.0.0を使用して開発された既存のブートローダーコードについて、RTD 3.0.0に合わせるために修正を加える必要はありますか？ RTD 2.0.0のブートローダーコードをRTD 3.0.0のソースファイルで直接再利用することは可能でしょうか？それとも、ブートローダー開発には引き続きRTD 2.0.0を使用することが推奨されますか？ この移行作業に関するガイダンスやベストプラクティスがあれば、ぜひ教えていただきたいです。 よろしくお願いいたします！ Re: RTD version migrated reason and purpose of version migrate to 3.0.0 こんにちは、 @Aravind_Togaralli さん。 現在RTD 7.0.1を使用していますが、RTD 3.0.02023年3月まで遡る。 リリースノートには既知の問題と変更点が記載されていますが、それらは主にバグ修正に関するものです。 RTDリリース全体にわたるAPIや設定の変更を追跡するドキュメントは存在しません。 APIと生成されるコードの両方に違いが生じる可能性があるため、古いRTDバージョン用に書かれたコードを再利用できるとは限りません。 よろしくお願いいたします。 ダニエル

Request for Technical Support and Documentation for NCx3321 Integration Dear Team, I am currently working on an application based on the NCx3321 device interfaced with a Texas Instruments MSPM0G3519 controller for authentication-related functionality. I would like to request your guidance and technical support regarding the integration process. Specifically, I am looking for: -NCx3321 datasheet and technical documentation SPI communication protocol details -Register map and initialization sequence RF field enable procedure -Reference software/examples or application notes Recommended development flow for card detection and authentication It would be very helpful if you could guide me on the recommended process and resources required to start development with the NCx3321 device. Please also let me know if there are any NDA requirements, SDK packages, or additional support channels that need to be followed for accessing the complete documentation. Looking forward to your support and guidance. Re: Request for Technical Support and Documentation for NCx3321 Integration Hello @Ja10  Yes, you need to sign an NDA with NXP, and then you can request technical documents. Please establish an NDA by going NXP Technical Support and Resources for Developers | NXP Semiconductors and select

VSYS=0V時のNX20P0407 SBU1のプルダウン抵抗を確認する こんにちは、NXPのエキスパートさん。 出荷モードの検証を行った際、出荷モードでVSYS=0VのときにNX20P0407に異常な電流漏れが発生していることがわかりました。 異常な所見：NX20P0407は、VSYS=0VのときにSBU1ライン（システム側）に75K相当のプルダウン抵抗を持ちますが、これはデータシートのブロック図には定義されていません。 概略図： システム側のSBU1は、13KΩのプルアップ抵抗（V_pullup=3.3V）を備えたMCUのSWDIO（MCU：nRF52840）にのみ接続されています。 私のアプリケーションの出荷モードでは、MCUは動作していますが、NX20P0407は電源から切断されます（VSYS=0V）。SBU1ピンで測定を行ったところ、SBU1ピンの電圧は2.8147Vであることがわかりました。これは、SBU1ラインに75Kのプルダウン抵抗があり、37μAの電流漏れを引き起こしていることを意味します。 また、NX20P0407のはんだ付けを外したところ、37μAの電流漏れが消えたため、NX20P0407が電流漏れの原因であることが改めて確認されました。 私の調査結果が正しいかどうか、また、もし正しいのであれば、なぜデータシートに記載されていないのかを確認させていただきたいです。よろしくお願いいたします。 Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V こんにちは、ゾンさん リーク電流はSBU1ピンからVSYSへ流れ、その後プルダウン抵抗を介してGNDへ流れているのではないかと推測されます。VSYSピンを完全に切断してみて、リーク電流が減少するかどうか確認してください。32μAの漏洩電流は、観測された漏洩電流に最も近い値です。NX20P0407を使用しないときは、SBUENピンをGNDに接続していることを確認してください。SBUENをフローティング状態にしておくと、EMIによってSBUENが上昇する可能性があります。 敬具、 ヨゼフ Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V 参考資料として、NX20P0407に関連する簡略化されたブロック図を追加します。 Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V こんにちは、ヨゼフさん、 迅速なご対応ありがとうございます。以下に私の返信内容を記載いたします。 VSYSをGNDに接続しましたか？それとも接続せずに放置しましたか？ --返信: PP3V3電源レールとNX20P0407のVSYSの間には負荷スイッチがあります。MCUは出荷モードで負荷スイッチをオフにしてNX20P0407への電源供給を停止します。 出荷モードでは、NX20P0407の残りのピンはどのように接続されていますか？ --CC1&CC2はPDコントローラのCCラインに接続されており、出荷モードでは電源が切断されます。SBUENは同じPDコントローラの1つのGPIOに接続されています。SBU2は内部プルダウン抵抗を備えたMCUのSWDCLKに接続されています。 Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V こんにちは、ゾンさん 詳細な説明と図解をありがとうございました。出荷モード（SBU1ピンで37μAを測定した時）でVSYSピンをどのように接続したか確認してください。VSYSをGNDに接続しましたか？それとも接続せずに放置しましたか？出荷時、 NX20P0407の残りのピンはどのように接続されていますか？ 敬具、 ヨゼフ

CAN driver recovery Hello, I am working on the FlexCAN driver (interrupt mode) in the FRDM-A-S32K344 platform. I want to verify whether the CAN driver supports automatic recovery from CAN bus faults without a system or ignition reset. If this recovery feature exists in SDK version 3.0.0, where is it implemented or reflected in the driver, and where should I check it? Re: CAN driver recovery Hi @ganavi1, As @shep mentioned, the FlexCAN driver from the RTD package can enable the "AutoBus Recovery" feature. This is set by default, and no additional settings are required. Once the bit is enabled, FLEXCAN will automatically try to recover from the bus-off state to the normal state (assuming the external conditions that caused the bus-off are removed). Best regards, Julián Re: CAN driver recovery The S32K FlexCAN register has support for automatic bus-off recovery. I don't have the SDK manual, but you can search thru the relevant section to see if it interacts with the bit described in the reference manual. Here is the text from the reference manual: CTRL1 Register BOFFREC Bus Off Recovery Determines how FlexCAN recovers from Bus Off state. If 0, automatic recovering from Bus Off state occurs according to the CAN Specification 2.0B. If 1, automatic recovering from Bus Off is disabled. The module remains in Bus Off state until you write 1 to this field. If this field becomes 0 before 128 sequences of 11 recessive bits are detected on the CAN bus, Bus Off recovery happens as if this field had never become 1. If this field becomes 0 after 128 sequences of 11 recessive bits occurred, FlexCAN resynchronizes to the bus. It waits for 11 recessive bits before joining the bus. After this field becomes 0, it can become 1 again during Bus Off, but it will only be effective the next time the module enters Bus Off. If this field becomes 0 when the module is in Bus Off, writing 1 to this field is not effective for the current Bus Off recovery. See Bus Off in the CAN protocol standard ISO 11898-1:2015 for details. NOTE 0b - Enabled 1b - Disabled The default value of the bit is 0, so by default it will perform bus-off recovery automatically. Re: CAN driver recovery Here is some error correction feature as below, hope it helps. Detection and correction of errors in memory read accesses: —Each byte of FlexCAN memory is associated to five parity bits. —The error correction mechanism ensures that errors in one bit of this 13-bit word can be corrected (correctable errors). —Errors in two bits can be detected but not corrected (noncorrectable errors).

请求为 NCx3321 集成提供技术支持和文件 亲爱的团队， 我目前正在开发一款基于 ncx3321 设备的应用程序，该应用程序与德州仪器 MSPM0G3519 控制器接口以提供身份验证相关功能。我想请您就整合过程提供指导和技术支持。 具体而言，我在找： -ncx3321 数据表和技术文档 SPI 通信协议详细信息-注册映射和初始化序列 RF 字段启用程序 -参考软件/示例或应用说明卡检测和身份验证的 推荐开发流程如果您能指导我了解开始使用 NCx3321 设备进行开发所需的推荐流程和资源，将非常有帮助。 还请告诉我，访问完整文档时是否需要遵循任何保密协议要求、SDK 包或其他支持渠道。期待您的支持和指导。 Re: Request for Technical Support and Documentation for NCx3321 Integration 你好@Ja10 是的，您需要与恩智浦签署一份 NDA，然后就可以申请技术文件。请通过以下方式签订保密协议 恩智浦开发人员技术支持和资源|恩智浦半导体 并选择

RTD version migrated reason and purpose of version migrate to 3.0.0 Hi Team, We are currently working on migration from RTD 2.0.0 to RTD 3.0.0 and would like to understand the impact on our existing bootloader implementation. Could you please clarify the following: Are there any major changes in configuration fields or APIs between RTD 2.0.0 and RTD 3.0.0 that would affect existing implementations? For the existing bootloader code developed using RTD 2.0.0, do we need to make modifications to align it with RTD 3.0.0? Is it possible to reuse the RTD 2.0.0 bootloader code directly with RTD 3.0.0 source files, or is it recommended to continue using RTD 2.0.0 for bootloader development? Any guidance or best practices for handling this migration would be appreciated. Thanks in advance! Re: RTD version migrated reason and purpose of version migrate to 3.0.0 Hi @Aravind_Togaralli, We’re currently on RTD 7.0.1, while RTD 3.0.0 goes back to March 2023. The release notes do list Known Issues and Changes, but those mainly focus on bug fixes.  There isn’t any document that tracks API or configuration changes across RTD releases. You should expect differences in both APIs and generated code, so it’s not always possible to reuse code written for an older RTD version. Regards, Daniel

i.MX8ULPでのSPI NANDブート こんにちは、 i.MX8ULPのSPI NANDからブートしようとしています。 evkにはSPI NORが搭載されており、そこから起動することはできましたが、当社のボード上のNANDで試したところ、うまくいきませんでした。BT*_CFG*ピンを設定したところ、ブートROMがNANDを読み取ろうとしていることは確認できましたが、M33コアもA35コアも起動しないようなので、ブートイメージが正しくないのではないかと考えています。 imx-mkimage flash_singleboot_m33_flexspiターゲットを使用してイメージを構築していますが、このターゲットはヘッダーブロックとしてfspi_headerファイルを使用します。しかし、このファイル内のコメントを見ると、これはシリアルNOR用でありNAND用ではないようですので、このflexspi構成ブロックヘッダーについて調べています。 ターゲットに適したヘッダーファイルを作成するにはどうすればよいでしょうか？ kobs-ngを見つけたのですが、8ulp向けには設計されていないようです（GPMI NANDコントローラーがなく、軽くパッチを適用しても動作しません）。 8ulpのドキュメントにも、FCFBブロックに関するドキュメントは見当たりませんでした。i.MX 8M Mini Applications Processorのリファレンスマニュアル（およびu-boot mkimageにそれに関するオプションを追加するu-bootパッチ）でそれに関するドキュメントを見つけましたが、たとえそれが本当に同じフォーマットだとしても、i.MX8ULPでそれを使用する方法（特にどのLUTテーブルを使用するか）を教えていただけると助かります。 ありがとうございました。 ドミニク・マルティネ

NCx3321統合に関する技術サポートおよびドキュメントのリクエスト チームの皆様へ 現在、認証関連機能のために、NCx3321デバイスとTexas Instruments MSPM0G3519コントローラをインターフェースされたアプリケーションを開発しています。統合プロセスに関して、ご指導と技術サポートをお願いしたいのですが。 具体的には、以下のものを探しています。 -NCx3321データシートおよび技術文書、SPI通信プロトコルの詳細、レジスタマップおよび初期化シーケンス、RFフィールドイネーブル手順 - 参考ソフトウェア/サンプルまたはアプリケーションノート カード検出および認証に関する推奨開発フロー NCx3321デバイスを使用した開発を開始するために必要な推奨プロセスとリソースについてご教示いただければ大変助かります。 完全なドキュメントにアクセスするために、NDA（秘密保持契約）の要件、SDKパッケージ、または追加のサポートチャネルなど、遵守すべき事項があればお知らせください。皆様のサポートとご指導を心よりお待ちしております。 Re: Request for Technical Support and Documentation for NCx3321 Integration こんにちは@Ja10 はい、NXPと秘密保持契約（NDA）を締結する必要があります。その後、技術文書を請求できます。NDAを確立するには、 NXPの技術サポートと開発者向けリソース | NXPセミコンダクターズ そして選択する

Enabling Cortex-M7 Asymmetric Multiprocessing boot support for i.MX8MPEVK on Qemu As part of this brief blog, we are enabling Asymmetric Multiprocessing (AMP) boot support for the Cortex-M7 core on the i.MX8MP SoC device model in Qemu. The M7 firmware can be loadedand started from Linux running on the Cortex-A53 cores via the remoteproc framework. Asymmetric Multiprocessing (AMP) Boot To those of you wondering what AMP is: - It refers to a boot configuration where different processor cores run different operating systems or applications independently. The i.MX8M Plus contains: 4x Cortex-A53 cores (application processors running Linux/Android) 1x Cortex-M7 core (real-time processor for RTOS/bare-metal) In AMP mode, the boot sequence typically works as follows: Primary boot: Cortex-A53 cores boot first (running U-Boot, then Linux) Secondary boot: Cortex-M7 is loaded and started by Linux or U-Boot  There are 2 control paths for Cortex-M7 on iMX8MP:- Firmware-mediated (via SMC/ATF) MMIO driven path (via SRC and GPR access) "fsl,imx8mp-cm7-mmio" in linux exists specifically to select the MMIO path and avoid dependence on firmware interfaces that aren’t guaranteed in qemu. This mode uses the SRC syscon block and the IOMUXC GPR for start/stop control. Memory carveouts for resource table, vrings need to be specified in the "imx8mp-evk-rpmsg.dts". Follow this application note to make the necessary changes - https://www.nxp.com/docs/en/application-note/AN5317.pdf When Linux boots CM7 via remoteproc, the typical flow is: Linux booted with imx8mp-evk-rpmsg.dtb Linux loads the CM7 ELF into a reserved DDR region Linux toggles the CM7 start/stop control (SRC/GPR CPUWAIT, etc.) CM7 starts executing from that DDR entry The attached patch series introduces the following peripheral models needed for AMP:   - GPC (General Power Controller)   - GPR (General Purpose Registers)   - SRC (System Reset Controller)   - MU (Messaging Unit)   - Extends the CCM with M7 clock outputs and wires into the i.MX8MP SoC   - Enable Cortex-M7 boot in i.MX8MP EVK functional test //How to apply the patches: -  1. Fetch the qemu repo's master branch and apply the patches attached with this blog. 2. Build qemu after the patches are applied. Steps to build are mentioned in the repo's readme itself - https://github.com/qemu/QEMU //Testing the AMP boot of Cortex-M7 from linux on Cortex-A53 Pre-requisites: - a. Build a bare metal M7 elf from MCUXpresso SDK of iMX8QXP. Make sure you use this build script - build_ddr_release.sh we will be using this example for demonstration - boards/evkmimx8mp/driver_examples/uart/polling you will obtain an elf. b. imx8mp-evk-rpmsg.dtb built with the help of AN5317. copy the iMX8MP kernel to the location ~/qemu-emulation/iMX8MP/ copy imx8mp-evk-rpmsg.dtb to the same location Download .img for imx8mp from here - Buildroot 2024.02 Release for i.MX Platforms | Ezurio Testing:- Execute the following from the build folder of your qemu:- ./qemu-system-aarch64 -M imx8mp-evk -smp 4,maxcpus=5 -global fsl-imx8mp.enable-cm7=on -m 3G -display none -serial null -serial stdio -serial null -serial pty:/tmp/imx8mp-uart -kernel ~/qemu-emulation/iMX8MP/Image -dtb ~/qemu-emulation/iMX8MP/imx8mp-evk-rpmsg.dtb -append "root=/dev/mmcblk2p1" -drive file=~/qemu-emulation/iMX8MP/20240522-br2024.02-nitrogen8mp_qt5_gst1.img,if=sd,bus=2,format=raw,id=mmcblk2 -net nic,model=imx.enet -net user,hostfwd=tcp::2222-:22         Now in another cli tab execute this to open the M7 console - "screen /tmp/imx8mp-uart 115200", an empty screen will open up. now in the console where linux guest is running, execute the following: -     As soon you do this, you will observe in the other tab that M7 binary has started executing: -     As part of this brief blog, we are enabling Asymmetric Multiprocessing (AMP) boot support for the Cortex-M7 core on the i.MX8MP SoC device model in Qemu. The M7 firmware can be loaded and started from Linux running on the Cortex-A53 cores via the remoteproc framework. IMX8MPLUSEVK

MCX W72 Lifecycle and Debug Authentication This MCXW72 training video talk about the Lifecycle state model, explain in detail the purpose, and security recommendations for each state.  Training shows the fuses involved in this process to advance lifecycle and enable the basic security features like Secure Boot and Secure Debug. Video also includes examples about how to use MCUXpresso Secure Provisioning Tool (SEC) to create Root of Trust Key Hash (RoTKTH) and SB3KDK Encryption key as well as hoe to active debug authentication before to move Lifecycle states. (function() { var wrapper = document.getElementById('lia-vid-6396149338112w1280h720r742'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) Hands-On Training

HSE_b: RSAキーをRAMにインポートすることは許可されていません 1024ビットのRSA公開鍵を1つRAMカタログにインポートして鍵インポートサービスを使用する方法を理解しようとしていますが、サーバーからHSE_SRV_RSP_NOT_ALLOWEDという応答が返されます。 私のテストアプリケーションは、RAMキーカタログを次のようにフォーマットします。 { { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_RSA_PUB, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY1024_BITS, }, { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_ECC_PUB_EXT, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY256_BITS, }, { muMask = 0, groupOwner = 0, keyType = 0, numOfKeySlots = 0, maxKeyBitLen = 0 }, } そして、サーバーからの応答としてHSE_SRV_RSP_OKを受け取りました。 次に、以下のキー情報を使用してRSAキーをインポートしようとします。 { keyFlags = HSE_KF_USAGE_VERIFY, keyBitLen = HSE_KEY1024_BITS, keyCounter = 0x0, smrFlags = 0x0, keyType = HSE_KEY_TYPE_RSA_PUB, specific = { pubExponentSize = 4, } } 私の要望は以下のとおりです。 { targetKeyHandle = 0x20000, pKeyInfo = 0x20401f74, pKey = { 0x210034b4, 0x21003534, 0x0}, keyLen = { 0x80, 0x4, 0x0}, } . HSE_RAM_PUB_KEY_IMPORT_POLICY_ATTR_ID を HSE_KM_POLICY_ALLOW_RAM_PUB_KEY_IMPORT に設定し、読み戻した結果も同じでした。 LC属性は0x04、HSEエラーフラグは0x0000、HSEステータスフラグは0x0B60です。ファームウェアバージョンは、0x0F SoC ID 0x0000 FWタイプ 0x02 メジャー 0x32 マイナー 0x00 パッチと読み取られます。 Re: HSE_b: Not allowed to import RSA key to RAM こんにちは、 @Emma_G-gbgさん パラメータは正しく設定されています。特に問題は見当たりません。スーパーユーザー権限を持っている場合は、その属性を設定する必要すらありません。 昨日、これと非常によく似たことをテストしていたので、1024ビットのRSA公開鍵と4バイトの公開指数をインポートするようにコードを少し更新しました。見た目はこんな感じです。 RSA公開鍵をインポートする際には、pubExponentSizeを設定する必要がないことに注意してください。HSEはこのパラメータを無視します。代わりにkeyLen[1]を使用します。 パラメータ pubExponentSize は、サービス HSE_SRV_ID_GET_KEY_INFO によって keyInfo を読み取る際に使用されます。そのキーのkeyInfoを読み取った結果は以下のとおりです。 それは単なるデータキャッシュの問題ではないでしょうか？データキャッシュを無効にして、違いが出るかどうか試していただけますか？ よろしくお願いいたします。 ルーカス Re: HSE_b: Not allowed to import RSA key to RAM ありがとうございます。暗号鍵と認証鍵のハンドル情報の入力を忘れていました。確認していなかったので、HSE_INVALID_KEY_HANDLE はゼロになると思っていました。 現在は、キャッシュメモリ内の少なくとも一部の値を使用して動作しており、サービス呼び出しの前後にキャッシュメンテナンス操作が行われています。既存のプロジェクトにHSEサービスを追加しているため、キャッシュ構造を変更することはできませんが、共有メモリに実際に書き込まれていることを確認する限り、これまでのところすべて正常に動作しています。ただし、関連するメモリのキャッシュを無効にしてみましたが、違いはありませんでした。

使用世纪佳缘 J-Link 调试 i.MX95 上的 M7-Core 嗨，团队、 我目前正在开发 i.MX95 EVK，并在探索合适的平台和 SDK，以便开始开发--特别是针对 M7 内核的开发。根据恩智浦的建议，我使用 MCUXpresso SDK 以及 Visual Studio Code 和 MCUXpresso 扩展进行开发。 根据应用笔记 " 使用 VS Code 调试 Cortex-M (AN14120) "，调试需要 SEGGER J-Link。但是，应用笔记仅提供i.MX8系列和i.MX93的补丁和示例设置。据我所知，i.MX95 的调试程序与 i.MX93 类似，但我无法在文档或恩智浦的官方网站上找到 i.MX95 的特定 SEGGER J-Link 补丁。 能否请您帮助我，告诉我在 i.MX95 的 M7 内核上进行开发和调试所需的适当步骤、工具或补丁？ 如果您能及时回复，我们将不胜感激，这将有助于开发工作的顺利进行。 Re: Debugging M7-Core on i.MX95 using SEGGER J-Link 亲爱的@Manuel_Salas 我打算购买 FRDM i.MX95，我能问一下这个主板是否支持 JTAG，如果是，软件是否完全支持？ Re: Debugging M7-Core on i.MX95 using SEGGER J-Link 你好@Abinandhan 希望你一切都好。 遗憾的是，由于 i.MX95 仍处于试生产阶段，我们对其了解不多。 没有为i.MX95准备的**应用笔记**或补丁，因此，我们需要等待**版本**才能获得更多信息、调试步骤和补丁。 顺祝商祺！ 萨拉斯

RT1172 在开机时无法启动 大家好， 我们有一款基于 RT1172 的定制主板。使用 GUI Flash 工具（使用 " 执行时 RESET 目标 "）或处于调试模式时，程序将按预期启动和运行。但是在给主板加电时，我看不到任何启动反应。如果 XIP_BOOT_HEADER_ENABLE 定义设为 1，则应将 IVT 添加到图像中。有人知道如何调试这样的问题吗？ 顺便说一句，我们还有另一种基于 RT1176 的非常相似的设计，该主板按预期启动，其配置（据我们所见）与 RT1172 主板相同。 顺祝商祺！ 马蒂亚斯 Re: RT1172 does not boot on Power up 这个问题一直没有解决？ 我在 RT1172 中观察到类似情况，当 ITC RAM 保留> 64 KBytes 时，从 FlexSPI 闪存加载到 FlexRAM 时，RT1172 的 BootRom NXP 代码存在一些已知问题？ Re: RT1172 does not boot on Power up 你好@ingdb， 感谢您提供的最新信息。 还需要更清楚地了解您的问题。 1。通过 J-Link 下载程序时（我从未尝试过任何其他调试器），主板正在运行，应用程序正在运行，USB 正在运行等等，一切都如预期。 =>kerry：这种方法何时下载，是否有 IDE？还是只用 JLINK 指令器或 Jflash 下载应用程序？ 您使用的应用项目是什么？是否与问题调试项目的应用程序相同？ 2。但是，当开启主板而不使用 J-Link 下载和启动程序时，应用程序卡在 0x223104 =>Kerry：如果不使用 JLINK 下载，您的意思是，仍然使用 JLINK，只是使用 JLINK 调试与 MCUXPresso IDE 相结合的问题吗？ 您使用的是什么项目？使用 JLINK 下载的应用程序是否可以正常工作？ 3.0x223104 是 ROM 地址，我想你可以尝试在项目中取消选择 RESET，调试配置。 下面的博客也证明了这一点： https://www.cnblogs.com/henjay724/p/15725966.html 顺祝商祺！ kerry Re: RT1172 does not boot on Power up 你好，通过 J-Link 下载程序 时（我从未尝试过任何其他调试器），主板正在运行，应用程序正在运行，USB 正在运行等等，一切都如预期。 因此，我的主板上没有软件，也没有硬件问题。 但是，当启动板而不使用J-Link下载和启动程序时，应用程序卡在0x223104。(见我下面的评论）。 除了 JTAG 之外，我没有尝试过任何其他启动工具，因为软件正在运行，我假设我在使用 XIP 时对闪存进行了正确的编程。 最诚挚的问候 Matthias Re: RT1172 does not boot on Power up 你好@ingdb、 感谢您提供的最新信息。 你提到：主板正在启动 使用其他调试器而不是 JLINK，你觉得它正在启动？ 你是否尝试使用 SPT 或 mcubootUtilityt 工具下载，使用该工具下载应用程序，无论启动与否？ 我还想知道，您的项目是否适合 RT1172？如果硬件没有问题，那么还需要检查软件。 顺祝商祺！ kerry Re: RT1172 does not boot on Power up 嗨，凯瑞、 感谢你的帮助，但我们没有硬件问题，主板正在启动，但只有在使用 J-Link 进行调试时，启动主板时它才无法启动。使用 FlexSPI1、Q-SP I、或非-FLASH 将启动模式配置为内部启动模式 顺祝商祺！ 马蒂亚斯   Re: RT1172 does not boot on Power up 你好@ingdb、 您现在使用哪个调试器？ 不管你能不能找到 Arm 内核，我建议你先用 JLINK 来连接你的 RT1172 板？如果没有，说明硬件有问题。 如果是，你可以将 RAM 代码下载到芯片上，检查它是否能正常工作，直到它能正常工作，然后你可以检查它是否可以下载到闪存中，然后你还需要检查 BOOT_CFG、BOOT_MODE 引脚，确保 boot_cfg 满足你使用的闪存要求，boot_mode 应该是内部启动模式，而不是串行下载模式。 希望它能帮到你！ 顺祝商祺！ kerry Re: RT1172 does not boot on Power up 在检查加电后无法启动的目标时我发现它卡在这里了

RT1172 does not boot on Power up Hello all, we have a custom board based on the RT1172. When using the GUI FLash tool (with "Reset target on execution") or in debug mode the program is booting and working as expected. But when powering up the board I don't see any boot reaction. The XIP_BOOT_HEADER_ENABLE define is set to 1, the IVT should be added to the image. Does anyone have an idea how to debug such a problem? By the way, we have another very similar design based on the RT1176, this board is booting as expected with (as far as we see) the same configuration as the RT1172 board. best regards Matthias Re: RT1172 does not boot on Power up This issue has never been solved ? I'm observing something similar in RT1172  There is some known issue in RT1172 in BootRom NXP code when loading from FlexSPI-Flash to FlexRAM when ITC RAM reserved > 64 KBytes ? Re: RT1172 does not boot on Power up Hi @ingdb ，    Thank you for your updated information.   Still need more clear about your issues.   1. when downloading a program over J-Link (I never tried any other debugger) the board is working, the application is running, USB is working etc. everything is as expected.  =>kerry: when this method downloading, with IDE or not? Or just the JLINK commander or the Jflash to download the application? What's the application project you are using? Whether the same app as the issue debug project? 2. But when powering up the board and not using J-Link to download and start the program, the application got stuck at 0x223104 =>Kerry: if not use JLINK to download, do you mean, still use JLINK, just use JLINK debug with the MCUXPresso IDE meet the issues?  What's the project you are using? The working app which download with JLINK to confirm it is working? 3. 0x223104 is the ROM address, I think you can try to deselect the reset in the project, debug configuration. The following blog also demostrate it: https://www.cnblogs.com/henjay724/p/15725966.html Best Regards, Kerry Re: RT1172 does not boot on Power up Hi, when downloading a program over J-Link (I never tried any other debugger) the board is working, the application is running, USB is working etc. everything is as expected.  So no software and no hardware issues on my board.  But when powering up the board and not using J-Link to download and start the program, the application got stuck at 0x223104. (see my comment below). I did not try any other boot utilities than JTAG, as the software is running I am assuming the flash to be correctly programmed as I am using XIP. best regards Matthias Re: RT1172 does not boot on Power up Hi @ingdb ,    Thanks for your updated information.   You mentioned:  the board is booting   How do you think it is booting, with other debugger not the JLINK?    Do you try to download with the SPT or the MCUbootUtilityt tool, use the tool to download the app, whether that boot or not?   I am also thinging, whether your project is correct for the RT1172 or not? If hardware not issues, then you also need to check the software. Best Regards, Kerry Re: RT1172 does not boot on Power up Hi Kerry, thanks for your help but we don't have hardware problems, the board is booting but only when debugging with J-Link, it's not booting when powering up the board. Boot mode is configured as internal boot mode with FlexSPI1, Q-SPI, NOR-FLASH Best regards Matthias   Re: RT1172 does not boot on Power up Hi @ingdb ,    Which debugger you are using now?    I suggest you use the JLINK to connect your RT1172 board at first, whether you can find the ARM core or not? If not, it means the hardware have issues.     If yes, you can download the RAM code to the chip, check whether it works, until it works, then you can check wether it can download to the flash or not, then also you need to check the BOOT_CFG, BOOT_MODE pin, make sure the boot_cfg meet your used flash requirement, and the boot_mode should be the internal boot mode, not the serial download mode. Wish it helps you! Best Regards, Kerry Re: RT1172 does not boot on Power up When examining the not booting target after Power up I see it got stuck here

SEGGER J-Linkを使用してi.MX95上でM7-Coreをデバッグする チームの皆さん、こんにちは。 現在、i.MX95 EVKの開発に取り組んでおり、開発開始に適したプラットフォームとSDKを検討しています。特にM7コアをターゲットとしています。NXPの推奨に従い、開発にはMCUXpresso SDKとVisual Studio Code、そしてMCUXpresso拡張機能を使用しています。 アプリケーションノート「VS Codeを使用したCortex-Mのデバッグ（AN14120）」によると、デバッグにはSEGGER J-Linkが必要です。ただし、アプリケーションノートには、i.MX8シリーズとi.MX93用のパッチと設定例のみが記載されています。i.MX95のデバッグ手順はi.MX93と同様であることは理解していますが、i.MX95専用のSEGGER J-LinkパッチをドキュメントやNXPの公式ウェブサイトで見つけることができません。 i.MX95のM7コア上で開発およびデバッグを可能にするために必要な適切な手順、ツール、またはパッチについて教えていただけますでしょうか？ 迅速なご回答をいただければ大変ありがたく、開発を円滑に進める上で大変役立ちます。 Re: Debugging M7-Core on i.MX95 using SEGGER J-Link @Manuel_Salas様 FRDM i.MX95の購入を検討しているのですが、このボードはJTAGをサポートしていますか？また、サポートしている場合、ソフトウェアは完全に対応していますか？ Re: Debugging M7-Core on i.MX95 using SEGGER J-Link こんにちは、 @Abinandhan さん お元気でお過ごしのことと思います。 残念ながら、i.MX95はまだ試作段階にあるため、詳しい情報はほとんどありません。 i.MX95 用のアプリケーションノートやパッチはまだ用意されていないため、詳細情報、デバッグ手順、パッチを入手するにはリリースを待つ必要があります。 よろしくお願いいたします。 サラス。

HSE_b：不允许将 RSA 密钥导入 RAM 我试图了解如何使用密钥导入服务，将单个 1024 位 RSA 公钥导入 RAM 目录，但服务器的响应是 HSE_SRV_RSP_NOT_ALLOWED。 我的测试程序将 RAM 密钥目录格式化如下： { { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_RSA_PUB, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY1024_BITS, }, { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_ECC_PUB_EXT, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY256_BITS, }, { muMask = 0, groupOwner = 0, keyType = 0, numOfKeySlots = 0, maxKeyBitLen = 0 }, } 我得到服务器回复 HSE_SRV_RSP_OK。 然后，我尝试导入一个 RSA 密钥，其密钥信息如下： { keyFlags = HSE_KF_USAGE_VERIFY, keyBitLen = HSE_KEY1024_BITS, keyCounter = 0x0, smrFlags = 0x0, keyType = HSE_KEY_TYPE_RSA_PUB, specific = { pubExponentSize = 4, } } 我的请求如下 { targetKeyHandle = 0x20000, pKeyInfo = 0x20401f74, pKey = { 0x210034b4, 0x21003534, 0x0}, keyLen = { 0x80, 0x4, 0x0}, } . 我已将 HSE_RAM_PUB_KEY_IMPORT_POLICY_ATTR_ID 设为 HSE_KM_POLICY_ALLOW_RAM_PUB_KEY_IMPORT，读回的结果也是如此。 LC 属性为 0x04，HSE 错误标志为 0x0000，HSE 状态标志为 0x0B60。固件版本读作 0x0F SoC ID 0x0000 FW 类型 0x02 major 0x32 minor 0x00 patch。 Re: HSE_b: Not allowed to import RSA key to RAM 你好@Emma_G-gbg 你的参数是正确的，我看不出有什么问题。如果你有超级用户权限，甚至不需要设置该属性。 我昨天正在测试非常相似的东西，所以我只是稍微更新了我的代码，导入了带有 4 字节公共指数的 1024 位 RSA 公钥。看起来是这样的 请注意，导入 RSA 公钥时无需设置 pubExponentSize。HSE 会忽略该参数。它使用 keyLen[1] 代替。 参数 pubExponentSize 用于通过服务 HSE_SRV_ID_GET_KEY_INFO 读取 keyInfo 时。这就是我读取该键的 keyInfo 时得到的结果： 这不就是数据缓存问题吗？您能否尝试禁用数据缓存，看看是否会有影响？ 此致， Lukas Re: HSE_b: Not allowed to import RSA key to RAM 谢谢你，我漏填了密码和授权密钥句柄信息，我没有检查过，所以我以为 HSE_INVALID_KEY_HANDLE 应该为零。 目前，它至少可以处理缓存内存中的部分值，并在服务调用前后进行缓存维护操作。由于我们是在现有项目中添加 HSE 服务，所以我们不能更改缓存结构，但只要确保写入共享内存，到目前为止一切都能正常工作，不过我也尝试过禁用相关内存的缓存，但效果并不明显。