i.MX RT1176 eDMA: CR[HALT] set by Halt-On-Error clears without any software write to C Hello, We are investigating eDMA errors on an i.MX RT1176 (rev B0) running NuttX on a PX4 flight controller board (fmu-v6xrt). The trigger of the errors has been found and fixed in NuttX, but we observed eDMA behavior that we cannot explain from the Reference Manual, and we would like to understand it. Background (public report): https://github.com/apache/nuttx/issues/20881 Fix merged in apache/nuttx: https://github.com/apache/nuttx/pull/20893 ## Configuration - eDMA (the one serving LPSPI, LPI2C and LPUART; not eDMA_LPSR) - CR[HOE] = 1 (Halt On Error), CR[EDBG] = 1 - Scatter/gather enabled; minor-loop channel linking (ELINK) enabled - Channels in use: LPSPI1/2/3, LPI2C1/2/3, LPUART3/4/5/6/8/10 ## What happened A driver bug linked a TCD with CITER = BITER = 0 (scatter/gather) after a valid TCD on LPUART TX channels. We captured the eDMA registers in the error interrupt handler, before clearing the error: - ES[NCE] set, failing channel = an LPUART TX channel, TCD CITER = BITER = 0 - CR = 0x432 (HALT set) When we read CR later from thread context (outside the interrupt), it was 0x412 (HALT clear). The errors came in pairs on the same channel. In most pairs both errors were in the same millisecond, but in some pairs the second error came 1-269 ms after the first. In those cases the LPSPI and LPI2C transfers stopped for almost the same time as the gap between the two errors (for example, 268 ms gap / 270.2 ms interruption). ## What the software does - CR is written only once, at initialization. No code writes CR[HALT] = 0 afterwards. - In the error interrupt handler, the driver writes CERR for the channel, then terminates the transfer on that channel: CEEI, CERQ, TCD CSR = 0, TCD DLASTSGA = 0. The Reference Manual (Rev. 5) describes CR[HOE] as: "any error causes the eDMA engine to write 1 to the HALT field. Subsequently, the eDMA engine ignores all service requests until you write 0 to the HALT field." Our observation does not match this, because HALT became 0 without any software write. ## Questions 1. With CR[HOE] = 1, under what conditions is CR[HALT] cleared without a software write to CR? For example, writing CERR or CERQ, or activating or terminating another channel. 2. While CR[HALT] = 1, what happens to a minor loop that is already executing on another channel, and to service requests that arrive during that time? Are they lost, or are they held and serviced after HALT is cleared? 3. After the error handler has written CERQ and TCD CSR = 0 on the failing channel, what can cause a second NCE on the same channel 1-269 ms later? 4. For a system where several peripherals share the eDMA, would NXP recommend HOE = 0 or HOE = 1? If HOE = 1, is the expected recovery to write CR[HALT] = 0 in the error handler? We have not found an erratum about this in the i.MX RT1170 Chip Errata (Rev. 1.6). We can share the register capture method and more details of the measurement if that helps. Thank you. i.MXRT Re: i.MX RT1176 eDMA: CR[HALT] set by Halt-On-Error clears without any software write to C Hi @miyawaki ， Thanks for the reaching out! Have you tried with some MCUXpresso SDK demo on an RT1176 rev B0 board to reproduce this issue? I think it would be a useful way to separate eDMA behavior from the NuttX driver and PX4 workload.  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. -------------------------------------------------------------------------------

Where is MCUXpresso toolchain Dear NXP users, I'm trying to build an external library (embed TLS) with the same toolchain MCUXpresso uses to build the final embedded firmware. I'm running MCUXpresso on linux, and I am building embed TLS on the same computer. Could you help me to link my embedTLS library generation makefile with the MCUXpresso tool chain ? Re: Where is MCUXpresso toolchain Hi @s_hdl  Thank you for the post! The default toolchain path in linux is /usr/local/mcuxpressoide- /ide/tools/bin/ you should modify the version to the actual one you are using, example mcuxpressoide-25.6.136 BR  Re: Where is MCUXpresso toolchain Thank you very much for your help.

i.MX RT1176 eDMA: CR[HALT]は、Halt-On-Errorによって設定され、Cへのソフトウェア書き込みなしでクリアされます こんにちは、 私たちは、PX4便でNuttXを搭載している i.MX RT1176(回転B0)のeDMAエラーを調査しています コントローラボード(FMU-V6XRT)。エラーのトリガーはNuttXで発見・修正されていますが リファレンス・マニュアルから説明できないeDMAの挙動を観察し、 理解するために。 背景（公開レポート）： https://github.com/apache/nuttx/issues/20881 修正がapache/nuttxにマージされました： https://github.com/apache/nuttx/pull/20893 ＃＃ 構成 - eDMA(LPSPI、LPI2C、LPUARTをサービスするもの;eDMA_LPSRではない) - CR[HOE] = 1(エラーで停止)、CR[EDBG] = 1 - 散乱/ギャザー対応;マイナーループチャネルリンク(ELINK)有効 - 使用チャネル:LPSPI1/2/3、LPI2C1/2/3、LPUART3/4/5/6/8/10 ＃＃ どうしたの ドライバーのバグにより、LPUART上で有効なTCDが実行された後にCITER = BITER = 0(散布/採集)とTCDが連結されました TXチャネル。エラー割り込みハンドラでeDMAレジスタをキャプチャしてからクリアします。 エラー: - ES[NCE] 設定、故障チャネル = LPUART TX チャネル、TCD CITER = BITER = 0 - CR = 1 0x432(停止集合) 後でThreadコンテキスト(割り込み外)からCRを読み取ったときは0x412(HALTクリア)でした。 エラーは同じチャネル上でペアで発生しました。ほとんどのペアでは、両方のエラーが同じでした ミリ秒単位だが、一部のペアでは、2番目のエラーは最初のエラーから1〜269ミリ秒後に発生した。そういう場合 LPSPIとLPI2Cの転送は、両者の間隔とほぼ同時期に停止しました エラー(例:268 ms ギャップ / 270.2 ms 中断)。 ## ソフトウェアが何をするか - CRは初期化時に一度だけ書き込まれます。その後、CR[HALT] = 0 と書き込むコードはありません。 - エラー割り込みハンドラで、ドライバはチャネルに対してCERRを書き込み、その後 そのチャネルでの転送:CEEI, CERQ, TCD CSR = 0, TCD DLASTSGA = 0。 リファレンス・マニュアル(改訂版)5) CR[HOE]を次のように説明しています。「エラーが発生すると、eDMAエンジンが書き込みます 1. HALT分野へ。その後、eDMA エンジンは、あなたが書き込むまで全てのサービス要求を無視します。 HALTフィールドに0を投入します。しかし、私たちの観察はこれと一致しません。なぜなら、HALTが 0 なしに 0 になるからです。 ソフトウェアが書く。 ## 質問 1.CR[HOE] = 1の場合、CR[HALT]はソフトウェアによるCR書き込みなしにどのような条件下でクリアされますか? 例えば、CERRやCERQの書き込み、あるいは別のチャネルの有効化や終了などです。 2. CR[HALT] = 1の場合、すでに別のループで実行中のマイナーループはどうなるのか その期間中に届くサービス要請に対して、チャネルやサービスに対応できるのでしょうか?彼らは迷子なのか、それとも HALTが解除された後に保管および整備されるのか？ 3.エラーハンドラが故障チャネルにCERQとTCD CSR = 0を書き込んだ後、 同じチャネルで1〜269ms後に2回目のNCEが発生する原因? 4. 複数のペリフェラルがeDMAを共有するシステムの場合、NXPはHOE = 0を推奨しますか? HOE = 1?HOE = 1 の場合、エラーハンドラに CR[HALT] = 0 を書き込むことが想定される回復処理ですか？ i.MX RT1170 チップの正誤表 (Rev.1.6）。私たちは共有できます レジスタキャプチャ方法と測定の詳細について教えてください。 よろしくお願いします。 i.MX RT Re: i.MX RT1176 eDMA: CR[HALT] set by Halt-On-Error clears without any software write to C こんにちは@宮脇、 ご連絡いただきありがとうございます！RT1176 rev B0ボードでMCUXpresso SDKのデモを使ってこの問題を再現してみましたか?これはeDMAの動作をNuttXドライバやPX4のワークロードから分離する有効な方法だと思います。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

MCUXpresso 工具链在哪里？ 尊敬的NXP用户： 我正在尝试使用与 MCUXpresso 构建最终嵌入式固件相同的工具链来构建一个外部库（嵌入式 TLS）。 我正在 Linux 系统上运行 MCUXpresso，并且正在同一台计算机上构建嵌入式 TLS。 您能否帮我将我的 embedTLS 库生成 makefile 与 MCUXpresso 工具链连接起来？ Re: Where is MCUXpresso toolchain 嗨@s_hdl 谢谢你的帖子！ Linux 系统中的默认工具链路径为 /usr/local/mcuxpressoide- /ide/tools/bin/ 您应该将版本号修改为您实际使用的版本号，例如 mcuxpressoide-25.6.136 BR Re: Where is MCUXpresso toolchain 非常感谢您的帮助。

S32K312 eDMA: Understanding CITER Auto-Reload Behavior Hi everyone, I am working with eDMA on the NXP S32K312 MCU and would like to understand the behavior of the TCDn_CITER register. I observed that when CITER reaches zero at the end of the major loop, it automatically reloads its value from TCDn_BITER. I would like to clarify the following: Is this automatic reload the expected hardware behavior on the S32K312? Under what conditions does CITER reload from BITER after the major loop completes? Is there any configuration that allows CITER to remain at zero instead of reloading from BITER? I am interested specifically in understanding the CITER register behavior. Thank you! Re: S32K312 eDMA: Understanding CITER Auto-Reload Behavior Hi @Prateeksha_Jain  Questions 1 and 2 are addressed in the S32K3xx Reference Manual, Rev. 12. The manual states that when the major iteration count is exhausted, the eDMA performs several end-of-major-loop operations, including the final source and destination address adjustments and reloading the BITER value into CITER. Regarding Question 3, there is no dedicated configuration bit that allows CITER to remain at zero once the major loop has completed. The reload of CITER from BITER is part of the eDMA hardware state machine and is performed automatically. However, if your goal is to stop the channel from servicing additional DMA requests after the major loop completes, you may want to look into using the DREQ bit. This scenario has been previously discussed in the thread How to prevent eDMA TCDn_CITER from auto reloading TCDn_BITER. BR, VaneB

TapLinx Android: licensing and app registration for internal APK use and possible future commercial Hello NXP team, I am developing an Android application for managing a riding stable and would like to use the TapLinx Android SDK with MIFARE DESFire EV3 chips. During development and initial use, the application will be installed directly via APK on our own Android devices. It is not currently published in an app store. However, I may offer it through Google Play or another app store in the future, potentially commercially. The TapLinx Developer Center requires selecting either “Google Play” or “Amazon App Store” when registering an Android application. Before proceeding, could you please clarify the following? 1. Which store option should I select for the current development and internal APK distribution phase? Does selecting “Google Play” require an existing store listing or a commitment to publish within a particular timeframe? 2. Is the current TapLinx Android SDK royalty-free during development, internal business use and potential later commercial distribution? Are there any one-time, recurring, per-device, per-user or activation fees, or credits that must be purchased? 3. The publicly linked Android EULA describes a royalty-free license, while another publicly accessible NXP portal agreement mentions paid “MIFARE SDK Credits”. Which agreement applies to the current TapLinx Android SDK and the intended use described above? - Android EULA: https://www.nxp.com/docs/en/disclaimer/EULA-TAPLINX-FOR-ANDROID.pdf - Portal terms: https://inspire.nxp.com/mifare/terms-of-use.html 4. Can the application operate entirely offline using an appropriate offline license, including on devices where it is installed directly via APK? If so, how can that license be obtained, and does it require any initial or periodic online activation? I previously sent these questions to the TapLinx contact address but have not received a reply yet. I also tried the support case portal, but it does not allow my account to create a case because my email address cannot be linked to a company, and it directed me to the community instead. I would appreciate confirmation of the applicable licensing terms, or a referral to the appropriate NXP team, before proceeding with app registration and SDK integration. Thank you for your help. Re: TapLinx Android: licensing and app registration for internal APK use and possible future commerc Hello @Blümel Hope you are doing well. TapLinx is an open API, free accessible for any developer. The mention for "MIFARE SDK Credits" appears to relate to a legacy licensing model. Please take into account the Evaluation License Agreement and the NXP Software License Agreement. You can select either of the two stores since there is no preferred option for an internal APK. Please note that the package name must be unique if it is intended to publish the application on Google Play. Even if it is not intended to publish the application, it is recommended to follow the rules of a meaningful package name as mentioned in TapLinx Android SDK User Guide, Section 2 "The online registration procedure". An application can operate offline using an appropriate offline license. For more information about offline registration, please refer to TapLinx Android SDK User Guide sections 2.1 and 2.3. Regards, Eduardo.

TapLinx Android：内部 APK 使用及未来可能的商业用途的许可和应用注册 您好，NXP团队， 我正在开发一款用于管理马厩的安卓应用程序，并且 我喜欢将 TapLinx Android SDK 与 MIFARE DESFire EV3 芯片一起使用。 在开发和初始使用阶段，应用程序将直接安装。 通过我们自己的安卓设备上的 APK 文件。目前尚未在应用程序中发布。 店铺。不过，我可能会通过 Google Play 或其他应用商店提供该应用。 未来，可能具有商业价值。 TapLinx开发者中心要求选择“Google Play”或 注册安卓应用时选择“亚马逊应用商店”。在继续之前， 请问您能否解释一下以下问题？ 1. 对于当前的开发和内部运营，我应该选择哪个存储选项？ APK分发阶段？选择“Google Play”是否需要已有账户 店铺上架信息或承诺在特定时间内发布？ 2. 当前 TapLinx Android SDK 在开发过程中是否免版税？内部使用 商业用途以及未来可能的商业分销？有吗？ 一次性费用、周期性费用、按设备收费、按用户收费或激活费，或积分 必须购买的？ 3. 公开链接的 Android EULA 描述的是免版税许可，而 另一份可公开访问的NXP门户网站协议提到了付费的“MIFARE SDK”。 鸣谢”。哪项协议适用于当前的 TapLinx Android SDK？ 上述用途是指什么？ - Android 最终用户许可协议： https://www.nxp.com/docs/en/disclaimer/EULA-TAPLINX-FOR-ANDROID.pdf - 门户网站条款： https://inspire.nxp.com/mifare/terms-of-use.html 4. 该应用程序能否使用合适的离线方式完全离线运行 是否允许在通过 APK 直接安装的设备上使用？ 如果属实，该许可证如何获得？是否需要任何初始手续？ 或定期在线激活？ 我之前已将这些问题发送到 TapLinx 的联系地址，但尚未收到回复。 尚未收到回复。我也尝试过通过支持案例门户网站提交申请，但是没有成功。 请允许我的帐户创建案例，因为我的电子邮件地址无法关联。 我输入了公司名称，结果它却把我引导到了社区。 我希望能够确认适用的许可条款，或者 在进行应用程序注册之前，请将问题转介给相应的 NXP 团队。 以及SDK集成。 感谢您的帮助。 Re: TapLinx Android: licensing and app registration for internal APK use and possible future commerc 你好@Blümel 希望你一切都好。 TapLinx 是一个开放的 API，任何开发者都可以免费使用。文中提到的“MIFARE SDK Credits”似乎与旧版许可模式有关。请参考评估许可协议和恩智浦软件许可协议。 由于内部 APK 没有首选方案，您可以选择这两个商店中的任何一个。请注意，如果打算在 Google Play 上发布应用程序，则软件包名称必须是唯一的。即使不打算发布该应用程序，也建议遵循TapLinx Android SDK 用户指南第 2 节“在线注册流程”中提到的有意义的包名规则。 使用相应的离线许可证，应用程序即可离线运行。有关离线注册的更多信息，请参阅 TapLinx Android SDK 用户指南第 2.1 节和第 2.3 节。 问候， 爱德华多。

MCAL Uart ドライバ - タイムアウトとエラーの区別方法は? MCAL Uartのドライバー機能「Uart_SyncSend」や「Uart_SyncReceive」を使うとき、エラーとタイムアウトによる返却をどう区別すればいいのでしょうか? どちらの関数も「E_OK」または「E_NOT_OK」のいずれかのみを返します。 基盤となる非公開API関数「Uart_StartSyncReceive」はこの情報を持っていますが、それを破棄します。 私はS32K1 RTD AUTOSAR R21-11バージョン3.0.0を使用していますS32K116用QLP06。 Re: MCAL Uart driver - how to differentiate between timeout and error? こんにちは、 @daniel_meier さん。 Uart_SyncSend()またはUart_SyncReceive()を呼んだ後、Uart_GetStatus()を使って転送の状況を確認できます。 この関数は、前回の転送の状態を示すUart_StatusType型の値を返します。 BR、VaneB

ACIMのMCX Aシリーズサポート こんにちは、 NXPはMCUXpresso SDKのモーター制御にMCX Aシリーズ用のACIM(誘導モーター制御)サポートを追加する予定ですか? 現在、ACIM対応は旧型のKinetis KV/KEシリーズで利用可能であり、これらは新しいデザインにはあまり適していません。新しいMCX AデバイスでACIMをサポートする計画やロードマップはありますか? MCXA モータ制御 Re: ACIM Support for MCX A Series こんにちは、 現時点で、MCXAのモータ制御に関する公開資料はPMSM/BLDC(正弦波)を指しており、 MCUXpresso SDK for モータ制御 および Application Code Hub [モータ制御]に様々な例やガイドが収録されています。 来月や年にこのトピックに関する新しい情報が追加されたり、アプリケーションコードハブに新しい例が追加されたりすれば、定期的に更新をチェックできます。 よろしくお願いいたします。

ACIM Support for MCX A Series Hello, Is NXP planning to add ACIM (induction motor) control support for the MCX A series to the MCUXpresso SDK for Motor Control? Currently, ACIM support seems to be available for the older Kinetis KV/KE series, which are less suitable for new designs. Are there any plans or a roadmap to support ACIM on the newer MCX A devices? MCXA Motor Control Re: ACIM Support for MCX A Series Hello, For now the published material regarding motor control in MCXA is referring to PMSM/BLDC (sinusoidal), with a portfolio of various examples and guides in MCUXpresso SDK for Motor Control and Application Code Hub [Motor Control], You can still keep on checking periodically for new updates next months or year if they add new information regarding this topic or if they add new examples in the Application Code Hub on this. Best Regards

MCAL Uart driver - how to differentiate between timeout and error? When using the MCAL Uart driver functions "Uart_SyncSend" or "Uart_SyncReceive", how can I differentiate between and error and the function returning due to a timeout? Both functions only return either "E_OK" or "E_NOT_OK". The underlying non-public API function "Uart_StartSyncReceive" has this information but discards it. I am using S32K1 RTD AUTOSAR R21-11 Version 3.0.0 QLP06 for S32K116. Re: MCAL Uart driver - how to differentiate between timeout and error? Hi @daniel_meier  After calling Uart_SyncSend() or Uart_SyncReceive(), you can use Uart_GetStatus() to check the status of the transfer. This function returns a value of type Uart_StatusType, which indicates the status of the previous transfer.  BR, VaneB

TapLinx Android:内部APK使用およびFUTUREの商用の可能性のためのライセンスおよびアプリ登録 NXPチームの皆様、こんにちは。 私は乗馬厩舎を管理するためのAndroidアプリを開発しており、 MIFARE DESFire EV3チップを搭載したTapLinx Android SDKを使用するのが好きです。 開発および初期使用時には、アプリケーションが直接インストールされます 私たちのAndroidデバイス上でAPK経由で。現在アプリには掲載されていません 店。ただし、Google Playや他のアプリストアを通じて提供するかもしれません。 FUTURE、商業的にの可能性もあります。 TapLinx開発者センターでは「Google Play」または Androidアプリを登録する際に「Amazon App Store」と表示されます。進む前に、 以下の点を明確にしていただけますか? 1. 現在の開発と内部向けにどのストアオプションを選択すべきですか？ APK配布段階ですか？「Google Play」を選択するには、既存の 店舗掲載や特定の期間内に出版する約束? 2. 現在のTapLinx Android SDKsは開発中にロイヤリティフリーですか?内部で使われていますか? ビジネス利用と将来の商業流通の可能性について?何かありますか? 一度きり、定期料金、デバイスごと、ユーザーごと、またはアクティベーション料金、またはクレジット それは購入しなければならないのですか? 3. 公開リンクされたAndroid EULAはロイヤリティフリーライセンスを説明しています。 別の公開されているNXPポータル契約には有料の「MIFARE SDK」が記載されています クレジット。どの契約が現在のTapLinx Android SDKsに適用されるか、 上記の意図された用途ですか? - Android EULA: https://www.nxp.com/docs/en/disclaimer/EULA-TAPLINX-FOR-ANDROID.pdf - ポータル用語: https://inspire.nxp.com/mifare/terms-of-use.html 4. アプリケーションは適切なオフラインを用いて完全にオフラインで動作できるか APK経由で直接インストールされているデバイスでもライセンスを適用できますか? もしそうなら、その免許はどのように取得できるのか、またイニシャルは必要ですか? それとも定期的にオンラインを起動するのでしょうか? 以前、これらの質問をTapLinxのお問い合わせに送ったのですが、まだ送っていません 返信はまだ届いています。サポートCASEポータルも試しましたが、対応しません メールアドレスを連携できないため、アカウントでCASEを作成させてください NXPについて向かい、代わりにコミュニティへと導かれました。 適用されるライセンス条件の確認をいただけるとありがたいですし、 適切なNXPチームへの紹介を行ってから、アプリ登録を進めてください SDK連携も含まれます。 ご協力ありがとうございます。 Re: TapLinx Android: licensing and app registration for internal APK use and possible future commerc こんにちは、 @Blümelさん あなたの調子が良いといいのですが。 TapLinxはオープンAPIであり、どの開発者でも無料で利用できます。「MIFARE SDK Credits」という言及は、レガシーライセンスモデルに関連しているようです。評価ライセンス契約およびNXPソフトウェアライセンス契約をご考慮ください。 内部APKの優先オプションがないため、どちらのストアも選択可能です。Google Playでアプリケーションを公開する意図がある場合は、パッケージ名が一意である必要があることにご注意ください。たとえアプリケーションを公開することを意図していなくても、 TapLinx Android SDKsユーザーガイド第2節「オンライン登録手順」に記載されている意味のあるパッケージ名のルールに従うことが推奨されます。 アプリケーションは適切なオフラインライセンスを用いてオフラインで動作できます。オフライン登録に関する詳細は、TapLinx Android SDKユーザーガイドのセクション2.1および2.3をご参照ください。 よろしくお願いいたします。 エドゥアルド。

MCAL UART 驱动程序 - 如何区分超时和错误？ 在使用 MCAL Uart 驱动程序函数“Uart_SyncSend”或“Uart_SyncReceive”时，如何区分错误和函数因超时而返回的情况？ 这两个函数都只返回“E_OK”或“E_NOT_OK”。 底层非公开 API 函数“Uart_StartSyncReceive”包含此信息，但将其丢弃。 我使用的是 S32K1 RTD AUTOSAR R21-11 版本 3.0.0。QLP06 适用于 S32K116。 Re: MCAL Uart driver - how to differentiate between timeout and error? 嗨@daniel_meier 调用 Uart_SyncSend() 或 Uart_SyncReceive() 后，可以使用 Uart_GetStatus() 检查传输状态。 此函数返回一个类型为 Uart_StatusType 的值，该值指示上一次传输的状态。 BR，VaneB

ACIM对MCX A系列的支持 你好， NXP 是否计划在 MCUXpresso 电机控制 SDK 中添加对 MCX A 系列的 ACIM（感应电机）控制支持？ 目前，ACIM 支持似乎仅适用于较旧的 Kinetis KV/KE 系列，这些系列不太适合新设计。是否有计划或路线图来支持新型 MCX A 设备上的 ACIM 功能？ MCXA 电机控制 Re: ACIM Support for MCX A Series 你好， 目前已发布的有关 MCXA 中电机控制的资料主要针对 PMSM/BLDC（正弦波）， MCUXpresso SDK for Motor Control和Application Code Hub [Motor Control]中包含各种示例和指南。 接下来的几个月或一年，如果他们添加了关于此主题的新信息，或者在应用程序代码中心添加了关于此主题的新示例，您仍然可以定期查看更新。 顺祝商祺！

i.MX95 的 CAN FD 接口分布 您好，NXP， 有一个问题希望您能帮我们确认一下。 问：共有五个 CAN FD 接口。我们只确保一个 CAN FD 接口仅由 M33 功能域（AON）控制，但其他四个CAN FD 接口位于唤醒功能域，不确定这四个 CAN FD 接口是否可以由 M7 或 A55 内核控制？ 非常感谢。         Re: Distribution of CAN FD interfaces for i.MX95 嗨志明， 知道了。 非常感谢。 Re: Distribution of CAN FD interfaces for i.MX95 嗨@jimmyli CAN2-5 可由 M7/A55 控制；时钟由 SM 统一控制，中断在 M33、M7 和 A55 之间是统一的。 以下是 M7 SDK 中的 IRQn。 CAN2_IRQn = 38, /**< CAN2 interrupt */ CAN2_ERROR_IRQn = 39, /**< CAN2 error interrupt */ CAN3_IRQn = 40, /**< CAN3 interrupt */ CAN3_ERROR_IRQn = 41, /**< CAN3 error interrupt */ CAN4_IRQn = 42, /**< CAN4 interrupt */ CAN4_ERROR_IRQn = 43, /**< CAN4 error interrupt */ CAN5_IRQn = 44, /**< CAN5 interrupt */ CAN5_ERROR_IRQn = 45, /**< CAN5 error interrupt */ 此致， 志明

S32K312 eDMA：了解 CITER 自动重载行为 大家好， 我正在使用 NXP S32K312 MCU 进行 eDMA 开发，想了解TCDn_CITER寄存器的行为。 我观察到，当主循环结束时 CITER 达到零时，它会自动从TCDn_BITER重新加载其值。 我想澄清以下几点： S32K312 的这种自动重新加载是预期的硬件行为吗？ 在什么情况下，CITER 会在主循环完成后从 BITER 重新加载？ 是否有任何配置可以让 CITER 保持为零而不是从 BITER 重新加载？ 我特别想了解 CITER 寄存器的行为。 谢谢！ Re: S32K312 eDMA: Understanding CITER Auto-Reload Behavior 你好@Prateeksha_Jain 问题 1 和 2 在 S32K3xx 参考手册第 12 版中得到解答。手册中指出，当主迭代计数耗尽时，eDMA 会执行几个主循环结束操作，包括最终的源地址和目标地址调整以及将 BITER 值重新加载到 CITER 中。 关于问题 3，没有专用的配置位允许 CITER 在主循环完成后保持为零。CITER 从 BITER 重新加载是 eDMA 硬件状态机的一部分，并且是自动执行的。 但是，如果您的目标是在主循环完成后阻止通道处理额外的 DMA 请求，您可能需要考虑使用 DREQ 位。之前在“如何防止 eDMA TCDn_CITER 自动重新加载 TCDn_BITER”这个帖子中讨论过这种情况。 BR，VaneB

Distribution of CAN FD interfaces for i.MX95 Hi NXP,       There is a question that hope you can check for us.       Question: There are five CAN FD interfaces. We only make sure that one CAN FD is only controlled by M33 domain (AON), but other four CAN FD are in Wake up domain, not sure about whether these four CAN FD interfaces can be controlled by M7 or A55 core ?       Thanks very much.         Re: Distribution of CAN FD interfaces for i.MX95 Hi Zhiming,       Got it.       Thanks very much. Re: Distribution of CAN FD interfaces for i.MX95 Hi @jimmyli  CAN2-5 can be controlled by M7/A55; the clock is uniformly controlled by SM, and interrupts are uniform across M33, M7, and A55. Here are IRQn in M7 SDK. CAN2_IRQn = 38, /**< CAN2 interrupt */ CAN2_ERROR_IRQn = 39, /**< CAN2 error interrupt */ CAN3_IRQn = 40, /**< CAN3 interrupt */ CAN3_ERROR_IRQn = 41, /**< CAN3 error interrupt */ CAN4_IRQn = 42, /**< CAN4 interrupt */ CAN4_ERROR_IRQn = 43, /**< CAN4 error interrupt */ CAN5_IRQn = 44, /**< CAN5 interrupt */ CAN5_ERROR_IRQn = 45, /**< CAN5 error interrupt */ Best Regards, Zhiming

S32K312 eDMA:CITER車載リロード挙動の理解 こんにちは、皆さん 私はNXP S32K312 MCUでeDMAを扱っており、TCDn_CITERレジスタの挙動を理解したい と思っています。 CITERがメインループの最後にゼロになると、 TCDn_BITERから自動的に値を再読み込みすることがわかりました。 以下の点について明確にしておきたいと思います。 この自動リロードは、S32K312における想定されるハードウェア動作なのでしょうか？ 主要ループ完了後、CITERはどのような条件下でBITERからデータを再読み込みしますか？ BITERから再読み込みするのではなく、CITERをゼロのまま維持できるような設定はありますか？ 私は特にCITERレジスタの動作を理解することに興味があります。 ご回答をお待ちしています。 Re: S32K312 eDMA: Understanding CITER Auto-Reload Behavior こんにちは、 @Prateeksha_Jainさん 質問1と2はS32K3xxリファレンスマニュアル、Rev. 12で解説されています。マニュアルには、メジャー反復回数が上限に達すると、eDMAは最終的な送信元アドレスと宛先アドレスの調整、BITER値をCITERに再ロードするなど、メジャーループ終了時のいくつかの操作を実行すると記載されています。 質問3に関してですが、主要ループが完了した後にCITERをゼロのままにするための専用の設定ビットはありません。BITERからCITERへの再ロードは、eDMAハードウェアステートマシンの一部であり、自動的に実行されます。 ただし、メジャーループ完了後にチャネルが追加のDMA要求を処理しないようにするのが目的であれば、DREQビットの使用を検討したほうがいいかもしれません。このシナリオは以前、 Thread「eDMA TCDn_CITERの自動リロードを防ぐ方法」でTCDn_BITER議論されています。 BR、VaneB

i.MX95のCAN FDインターフェースの配布 こんにちは、NXPさん。 質問があるので、ぜひ確認していただけると嬉しいです。       質問: CAN FDインターフェースは5つあります。1つのCAN FDがM33ドメイン(AON)のみで制御されていることを確認し、 他の4 つのCAN FDはウェイクアップドメインに属しています。これら4つのCAN FDインターフェースがM7コアかA55コアで制御できるかは不明です。 ありがとうございました。         Re: Distribution of CAN FD interfaces for i.MX95 こんにちは、志明さん わかった。 ありがとうございました。 Re: Distribution of CAN FD interfaces for i.MX95 こんにちは、 @jimmyliさん CAN2-5はM7/A55で制御可能です。クロックはSMによって一様に制御され、割り込みはM33、M7、A55で均一です。 こちらはM7 SDKのIRQnです。 CAN2_IRQn = 38, /**< CAN2 interrupt */ CAN2_ERROR_IRQn = 39, /**< CAN2 error interrupt */ CAN3_IRQn = 40, /**< CAN3 interrupt */ CAN3_ERROR_IRQn = 41, /**< CAN3 error interrupt */ CAN4_IRQn = 42, /**< CAN4 interrupt */ CAN4_ERROR_IRQn = 43, /**< CAN4 error interrupt */ CAN5_IRQn = 44, /**< CAN5 interrupt */ CAN5_ERROR_IRQn = 45, /**< CAN5 error interrupt */ よろしくお願いします、 志明

PQC合规性在发货后才发现为时已晚！从安全启动和固件更新的角度考虑量子攻击防护措施（日文博客） 继i.MX 94和i.MX 95之后，恩智浦半导体 (NXP) 发布了 MCX A5 系列，该系列产品在 ROM 中内置了安全引导加载程序，支持PQC（后量子加密）混合安全引导和安全固件更新。恩智浦半导体计划继续扩展其 PQC 兼容产品线。 恩智浦发布全新MCX A5 MCU，简化安全工业连接 | 恩智浦半导体 尽管量子计算机仍在开发中，而且使用量子计算机的具体攻击尚未开始，但现在采用内置 PQC 兼容安全引导加载程序的产品极其重要，特别是对于打算长期使用的设备，例如工业设备。 如果您打算稍后通过固件更新来解决该问题，那么您需要了解其中涉及的重大限制，以及在产品制造时需要采取哪些措施来确保符合 PQC 标准。 需要符合PQC规定的主要原因 以下是产品设计阶段就需要符合 PQC 标准的主要原因。 产品生命周期可能与量子计算机实际攻击的出现时间重叠 。工业设备、汽车设备、医疗设备等产品的使用寿命有时超过10年。如果这些产品在量子计算机真正普及之前就已经上市，那么市场届时就需要相应的应对措施。 “先获取后解密”意味着 现在获取的加密通信数据未来可以利用量子计算技术进行解密 。尤其对于需要长期保密的产品而言，攻击发生后再做出反应就为时已晚了。 资源需求可能非常庞大，而且以后很难解决。 根据具体算法的不同，PQC 算法可能比传统的 ECC/RSA 算法需要更高的资源（ROM、RAM、闪存、处理时间、功耗），这会增加后续实现的难度。如果您计划在未来支持 PQC，除了满足当前产品规格外，还需要从一开始就确保 PQC 所需的充足资源。 以上是一些常见的理由，但仅从以上内容来看，你可能会想：“如果处理的数据即使以后被解密也不会造成太大问题，那么现在就投入充足的资源进行设计，然后再通过固件更新添加 PQC 支持，岂不是更好吗？” 然而，实际上存在诸多限制。 由于固件更新，PQC 支持出现问题 后续PQC合规性的最大制约因素是： “第一条SBL（稍后详述）必须不可重写。” “固件更新镜像包含知识产权（IP）。” 这就是关键所在。 第一个 SBL（First SBL）与安全启动有关。 安全启动是一种重要的安全机制，它在启动固件之前通过签名验证来验证固件的完整性（固件未被损坏或篡改） 。 为此，需要一个安全引导加载程序 (SBL)，它独立于被验证的固件而存在，在被验证的固件启动之前运行，并执行签名验证。 具体来说，系统启动后最先执行的SBL在此被称为第一SBL，并且该第一SBL必须是不可变的。至于原因，请参阅下文“第一SBL不得被覆盖”一节。 MCU 中的安全启动和安全（OTA）更新基础知识（日文博客） 换句话说，第一级系统认证机构（1st SBL）在产品出货时，如果固件验证算法仍采用ECC/RSA，而没有采用与PQC兼容的算法，那么之后再添加对PQC兼容算法的支持是不可能的。如果第一级系统认证机构的固件验证算法仍然是ECC/RSA，那么在量子计算机普及应用后，其签名存在被伪造的风险，恶意固件可能会被植入。 第二点是，即使产品本身处理的数据在之后被解密时不会造成重大问题，但产品的固件通常包含大量的知识产权（IP）。 如果固件更新镜像的加密算法不支持 PQC，则将来可能会因为固件更新镜像内容被解密而导致 IP 泄露的风险。 此外，如果固件更新映像的签名算法不支持 PQC，则存在固件更新映像的签名可能被伪造，从而加载恶意固件的风险。 基于以上所述，如果我们考虑未来对 PQC 的支持，那么可以合理地得出结论：至少在产品制造时，使用第一 SBL 的固件验证算法以及固件更新映像的签名和加密算法必须与 PQC 兼容。 NXP产品可以解决PQC合规性方面的挑战。 MCX A5 的启动 ROM 集成了 PQC 兼容的安全启动功能，使其可用作首个安全启动模块 (SBL)。此外，该启动 ROM 还支持 PQC 兼容的安全更新。与将 SBL 置于闪存相比，它还能减少所需的闪存容量。 将符合 PQC 标准的功能产品化需要验证密钥管理、签名基础设施、制造配置、OTA 更新、身份验证、性能评估和标准合规性，因此需要较长的准备时间。对于第一版 SBL 而言尤其如此，如前所述，第一版 SBL 无法更新，因此需要更加严格的验证。 截至撰稿时，MCX A5 尚未量产，目前正在进行认证，但其设计目标是获得 PSA 3 级和 SESIP 3 级第三方安全认证（NXP 已有多款产品获得 PSA/SESIP 认证）。认证完成后，我们将提供包括安全目标（一份定义评估目标、安全声明、要求、范围等的文件）在内的相关文档。 通过利用 MCX A5 的 PQC 兼容安全启动集成启动 ROM，以及 NXP 的工具集（例如MCUXpresso 安全配置工具和MCUXpresso SDK） ，我们可以减少 PQC 兼容安全启动和固件更新所需的实施和验证工作量。 选择SESIP 3级认证产品的关键要点 关于SESIP认证，需要注意的一点是，即使是获得SESIP 3级认证的产品，其认证所涵盖的功能范围也可能存在显著差异。因此，不仅要检查SESIP认证级别，还要仔细查看安全目标文档的内容，这一点至关重要。 认证产品的文档可从以下链接下载。 SESIP证书 - TrustCB 例如，在 NXP 的 SESIP Level 3 产品“MCX N94x / 54x / 23x SESIP 安全目标 Rev 1.1”中，图 3 显示认证范围不仅包括 SoC ROM（包括安全启动），还包括许多安全功能，例如EdgeLock ® 安全隔离区 (ELS S50) 。 虽然其他一些公司通过 SESIP 3 级认证的产品缺乏许多此类安全功能，但一些逻辑范围产品仅凭生命周期管理和内存保护功能就获得了 SESIP 3 级认证。   此外，NXP 的 SESIP 安全目标包括与 IEC 62443-4-2 等安全标准/法规的映射，可用于满足这些标准以及未来安全标准/法规中的类似要求。 截至撰写本文时，最新认证产品“i.MX RT700 SESIP 安全目标 Rev. 1.0”还包括与 CRA 的 EU 2024/2847 附件 I 基本网络安全要求的映射。 注：上述安全目标文档版本名称截至撰写本文时有效，但可能会有所更改。此外，SESIP 认证及其与安全标准/法规的映射并不能保证使用 NXP 产品的最终产品完全符合相关标准/法规。最终产品层面的集成以及必要的其他措施可能必不可少。 ========================= 我们目前无法回复此帖子“评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但在进行咨询时，请参考“ NXP 技术问题 - 如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接咨询您的代表。） 继i.MX 94和i.MX 95之后，恩智浦半导体 (NXP) 发布了 MCX A5 系列，该系列产品在 ROM 中内置了安全引导加载程序，支持PQC（后量子加密）混合安全引导和安全固件更新。恩智浦半导体计划继续扩展其 PQC 兼容产品线。 恩智浦发布全新MCX A5 MCU，简化安全工业连接 | 恩智浦半导体 尽管量子计算机仍在开发中，而且使用量子计算机的具体攻击尚未开始，但现在采用内置 PQC 兼容安全引导加载程序的产品极其重要，特别是对于打算长期使用的设备，例如工业设备。 如果您打算稍后通过固件更新来解决该问题，那么您需要了解其中涉及的重大限制，以及在产品制造时需要采取哪些措施来确保符合 PQC 标准。 （阅读时间：10分钟） i.MX RT 处理器 i.MX 处理器 MCX 安全 日本博客