Feasibility of KMS in S32G3 Can KMS functionality be implemented through custom logic in the HSE Demo application, or is the use of HSE_FWTYPE = 9 / HSE_FWTYPE = 22 mandatory? Re: Feasibility of KMS in S32G3 Hello, @Pranathi06  Thanks for the post. The KMS service mentioned in the demo app is targeted for using the custom HSE FW, which is the reason for HSE_FWTYPE = 9(22), since it is function included in the premium software, I suggest contacting your local NXP representative(if not available, raising tickets via support.nxp.com) for details. BR Chenyin  Re: Feasibility of KMS in S32G3 Hello, @Pranathi06  Thanks for your reply. Sorry that I am not sure what kind of the standard/spec your KMS implementation referring to,  I may not be able to provide a clear confirmation of it, sorry for your inconvenience. From my opinion, you may firstly check the latest standard HSE FW API document(with all APIs/services that be supported in the standard HSE FW including key import/export/generate, etc., which could be found from the HSE FW package), to clarify all key management services that HSE FW supported, then based on your crypto stack/custom application, to analyze if the full functions defined in your KMS could be implemented correctly based on current standard HSE FW of S32G3 BR Chenyin   Re: Feasibility of KMS in S32G3 Can KMS functionality be implemented through custom logic in the HSE Demo application[standard]?

Std_Types.h が見つかりません 私はちょうどS32DSバージョン3.5にアップグレードし、ピンとドライバを設定しました。 必要なファイルは生成しましたが、コンパイルしようとすると次のエラーメッセージが表示されます。 Std_Types.h: No such file or directory このファイルは、生成されたファイルの一つである Port_Ci_Port_Lp.h に含まれています。 /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" 私は何が間違っているのでしょうか？ バージョン3.5は、非常に使いやすかった3.4から大きく後退したように感じます。 😞 アンディ Re: Missing Std_Types.h このようなディレクトリを探しています。 Re: Missing Std_Types.h FUTUREこれを読むかもしれない人へ: 手動で追加すれば、この問題は解決するかもしれません。 Re: Missing Std_Types.h 私はDS3.4のSDM RTM 4.0.2に戻って、ほぼ宣伝通りに動作するものを手に入れました。しかし、NXP SDKを使えば使うほど、ますます嫌いになってきました... Re: Missing Std_Types.h この件について何か進展はありますか？ @ArkAndyFraser さん、 Std_Types.h が見つからない問題は解決できましたか？生成されたRTDファイルに含まれるファイルですか？ Std_Types.h が見つかりませんでしたNXPが提供する例にもファイルが含まれています。 Re: Missing Std_Types.h 3.6　状況は改善しなかった。こいつらは回帰テストすらやろうとしない。

Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi NXP Technical Support Team, [Project Background] We are developing a production project based on the i.MX8M Plus platform. Our current software stack is: - Target SoC: i.MX8M Plus (Cortex-A53, ARMv8-A 64-bit) - BSP / Yocto Version: Yocto Project 5.0 (Scarthgap) / meta-imx - Linux Kernel: 6.6 (AArch64) [Customer Requirement] Our end-customer has raised a new requirement: they need to run both 32-bit Linux applications and 32-bit Qt GUI applications on this 64-bit Linux OS environment (due to legacy 32-bit dependencies/codebase from older platforms). To evaluate whether this requirement is commercially and technically feasible, could you please clarify NXP's official stance on the following points: 1. Feasibility of 32-bit Applications & 32-bit Qt: Does NXP officially support running 32-bit user-space applications—specifically 32-bit Qt GUI applications—on a 64-bit i.MX8M Plus kernel via Yocto Multilib or any other official mechanism? 2. Availability of 32-bit Hardware Acceleration & Qt Libraries: If this is feasible: a) Does NXP provide 32-bit user-space GPU acceleration binaries (e.g., a 32-bit version of `imx-gpu-viv` for EGL/GLES) and VPU binaries compatible with i.MX8M Plus on a 64-bit kernel? b) Does NXP provide official Yocto recipes, BSP support, or validated configurations for building a 32-bit Qt stack (`lib32-qtbase`, `lib32-qtdeclarative`, etc.) on the i.MX8 family? 3. Performance & Rendering Limitations (If Acceleration is Absent): If 32-bit proprietary GPU drivers are NOT provided for i.MX8M Plus, is running a 32-bit Qt GUI via software rendering (e.g., LinuxFB, software Mesa/llvmpipe) officially recommended or considered production-ready by NXP for commercial products? 4. Official Recommendation / Solution: If running hardware-accelerated 32-bit Qt on i.MX8M Plus is not supported, what is NXP's official statement and recommended architectural solution for customers migrating legacy 32-bit applications/Qt to the i.MX8M Plus platform? A formal statement from NXP will serve as our official engineering and architectural baseline for the customer. Looking forward to your reply! Thanks and regards i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi, Thank you very much for the prompt and clear explanation! This fully clarifies the architectural boundaries of the i.MX 8M Plus BSP regarding 32-bit user-space components and GPU/multimedia acceleration. We will follow NXP's official recommendation and push forward with the native AArch64 deployment for our customer's Qt and application stack. Thanks again for your support! I have marked your reply as the accepted solution. Best regards, Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi @DADAXIN  Our BSP for the I.mx8mp is a 64-bit version. It is compiled and tested exclusively for AArch64, covering components such as the Vivante GPU user-space libraries (EGL/OpenGL ES/Vulkan), the VPU, and Qt 6 (provided via meta-qt6). Using 32-bit Qt with hardware acceleration on the i.MX 8M Plus falls outside the scope of the BSP release and is not a supported configuration. Our recommended approach is to recompile it as a native AArch64 applications/Qt. If a 32-bit solution is a hard requirement, please contact our Professional Services following below link： https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

S32K3 AES Key Provisioning after ADKP protection Hello Team, We have enabled SHE Based Secure Boot on S32K platform. Also we are protecting JTAG interface by programming ADKP password and Advancing Life Cycle to OEM.  May i know if I can re-provision AES keys (Key Catlog is already aligned for AES keys) to device with ADKP protection enabled with Life Cycle in OEM.  Or do we need to set Life Cycle to IN_FIELD? Also, do Specify what should be the OWNER type for KEY to be updated? Thank You, Bhushan Re: S32K3 AES Key Provisioning after ADKP protection Hi @Bhushan1312  The keys can be updated also in OEM_PROD or in IN_FIELD life cycle but it depends on user rights, Host Identity (HID) and key owner. In HSE firmware reference manual rev. 2.8, see please: Table 42. Key group owners 6.2.3.2  Key Selection This section is important: “• If the host is granted with Super User (SU) rights, the owner of the target key handle must match the host identity (HID) (see Execution Rights (Super User vs. User)) If the host has User rights, the owner of the target key handle must be HSE_KEY_OWNER_CUST if LC is CUST_DEL, or HSE_KEY_OWNER_OEM if LC is OEM_PROD” Then there are tables 47, 48 and 49 which explain if authentication and encryption is needed based on user rights when importing a key to empty slot or when updating a key. For example, if you elevate to super user rights using authorization key owned by CUST, you can import or update CUST keys also in OEM_PROD. But you can’t import keys owned by OEM before the life cycle is advanced to OEM_PROD. That’s because you don’t have OEM authorization key yet. Regards, Lukas

ADKP保護後のS32K3 AESキープロビジョニング こんにちは、チームの皆さん、 S32Kプラットフォーム上でSHEベースのセキュアブートを有効にしました。また、ADKPパスワードのプログラミングとOEMへのライフサイクル推進などでJTAGインターフェースを保護しています。 AESキー(Key CatlogはすでにAESキーにアライメントされています)を、OEMのライフサイクルでADKP保護を有効にしたデバイスに再プロビジョニングできるか教えていただけますか? それとも、ライフサイクルをIN_FIELDに設定する必要があるのでしょうか？ また、更新するキーの所有者タイプを指定してください。 ありがとうございました。 ブーシャン Re: S32K3 AES Key Provisioning after ADKP protection こんにちは、@Bhushan1312さん キーはOEM_PRODやライフサイクルIN_FIELD更新可能ですが、ユーザー権限、ホスト識別(HID)、キー所有者に依存します。 HSEファームウェアのリファレンスマニュアルでは、2.8を参照してください。 表42。主要なグループ所有者 6.2.3.2キー選択 このセクションは重要です。 「• ホストにスーパーユーザー(SU)権限が付与された場合、ターゲットキーハンドルの所有者はホストの識別子(HID)と一致しなければなりません(実行権(スーパーユーザー対ユーザー)を参照) ホストがユーザー権を持っている場合、LCがCUST_DELの場合はターゲットキーハンドルの所有者がHSE_KEY_OWNER_CUSTされ、LCがOEM_PRODの場合はHSE_KEY_OWNER_OEM」とされています。 次に、表47、48、49があり、キーを空スロットにインポートする際や鍵を更新する際にユーザー権限に基づく認証や暗号化が必要かどうかを説明しています。 例えば、CUSTが所有する認可キーを使ってスーパーユーザー権利に昇格した場合、OEM_PRODでもCUSTキーをインポートまたは更新できます。 しかし、ライフサイクルがOEM_PRODに進むまではOEM所有の鍵をインポートすることはできません。それは、まだOEM認証キーをお持ちでないためです。 よろしくお願いいたします。 ルーカス

Code compression MPC556 Hi there. I'm working on a legacy MPC556 microcontroller where I don't have an option to change it. I need any code compressor. Reading MPC555UM, I could find the following at 4.3.1: "Compression is done off line by a special compressor tool, using a fixed vocabulary instruction based algorithm, optmized for the PowerPC instruction set." I've searched for some compiler or even other tool to compress my C code but I've no idea which one I must use. I saw somebody mentioning about Squeezard compressor but I couldn`t find it to download or even buy it. Is there something I can do to compress my C code ? It can be any tool (compiler with a compression option or compressor software) even in case I need to buy it! My last option will be to develop by my own but I don't know how tough is that. Re: Code compression MPC556 Hi, colleague! Have you managed to find any information about the code compression mechanism? Please contact with me [email protected] Re: Code compression MPC556 Hi @juninholiveira90  I'm sorry but the tools and documentation for code compression are not available anymore. Also MPC555/556 are already in End Of Life status, the device is no longer manufactured, so it's not supported anymore. Regards, Lukas

コード圧縮 MPC556 やあ。私はレガシーのMPC556マイクロコントローラを扱っていて、変更オプションがありません。コード圧縮ツールが必要です。MPC555UMを読んでみると、4.3.1で次のような記述が見つかりました。「圧縮は、PowerPC命令セットに最適化された固定語彙命令ベースのアルゴリズムを使用する専用の圧縮ツールによってオフラインで行われます。」 Cコードを圧縮できるコンパイラや他のツールを検索しましたが、どれを使えばいいのか全くアイデアがありません。Squeezardコンプレッサーについて言及している人を見かけたのですが、ダウンロードも購入もできませんでした。Cコードを圧縮する方法はありますか?圧縮オプション付きのコンパイラやコンプレッサーソフトウェアなど、どんなツールでも使えますし、購入が必要になった場合にも対応できます! 最後の手段は自分で開発することですが、それがどれほど大変なことなのか分かりません。 Re: Code compression MPC556 こんにちは、同僚さん！コード圧縮の仕組みに関する情報は何か見つかりましたか？どうかお問い合わせください [email protected] Re: Code compression MPC556 こんにちは、@juninholiveira90 申し訳ありませんが、コード圧縮のためのツールやドキュメントはもう利用できません。 また、MPC555/556はすでにエンドサービス状態にあり、製造中でサポートされていません。 よろしくお願いいたします。 ルーカス

MCUXpressoツールチェーンはどこにありますか？ NXPユーザーの皆様へ、 MCUXpressoが最終的な組み込みファームウェアを構築するのと同じツールチェーンを使って、外部ライブラリ(埋め込みTLS)を構築しようとしています。 私はLinuxでMCUXpressoを実行し、同じコンピュータで組み込みTLSをビルディングしています。 embedTLSのライブラリ生成メイクファイルを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 ご協力いただき、誠にありがとうございました。

i.MX RT1176 eDMA：错误时停止机制设置的 CR[HALT] 无需任何软件写入即可清除。 你好， 我们正在调查运行在 PX4 飞行器上的 NuttX 的 i.MX RT1176（rev 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 后，将 TCD 与 CITER = BITER = 0（分散/聚集）关联起来。 TX通道。我们在错误中断处理程序中捕获了 eDMA 寄存器，然后清除它们。 错误信息： - ES[NCE] 已设置，故障通道 = LPUART TX 通道，TCD CITER = BITER = 0 - CR = 0x432（已设置 HALT） 稍后我们从线程上下文（中断之外）读取 CR 时，它是 0x412（HALT 清除）。 同一信道上出现了成对的错误。大多数配对中，两个错误都出现在同一位置。 毫秒，但在某些配对中，第二个错误发生在第一个错误之后 1-269 毫秒。在这些情况下 LPSPI 和 LPI2C 传输停止的时间几乎与两者之间的时间间隔相同。 错误（例如，268 毫秒间隙 / 270.2 毫秒中断）。 软件的功能 - CR 只在初始化时写入一次。之后没有代码会写入 CR[HALT] = 0。 - 在错误中断处理程序中，驱动程序会为通道写入 CERR，然后终止程序。 该通道上的传输：CEEI、CERQ、TCD CSR = 0、TCD DLASTSGA = 0。 参考手册（修订版）5) 将 CR[HOE] 描述为：“任何错误都会导致 eDMA 引擎写入 1 到 HALT 场。随后，eDMA 引擎会忽略所有服务请求，直到您写入为止。 将 0 设置为 HALT 场。我们的观察结果与此不符，因为 HALT 在没有任何任何变化的情况下就变成了 0。 软件编写。 ＃＃ 问题 1.当 CR[HOE] = 1 时，在什么条件下 CR[HALT] 会被清除而无需对 CR 进行软件写入？ 例如，写入 CERR 或 CERQ，或者激活或终止另一个通道。 2. 当 CR[HALT] = 1 时，如果一个子循环已经在执行，会发生什么？ 渠道，以及在此期间收到的服务请求？他们是迷路了吗？还是…… HALT 清除后是否需要继续维护？ 3.在错误处理程序将 CERQ 和 TCD CSR = 0 写入故障通道后，会发生什么？ 是否会在 1-269 毫秒后在同一通道上引发第二次 NCE？ 4. 对于多个外设共享 eDMA 的系统，NXP 是否建议 HOE = 0 或 HOE = 1？如果 HOE = 1，预期的恢复操作是否是在错误处理程序中写入 CR[HALT] = 0？ 我们在 i.MX RT1170 芯片勘误表（修订版）中没有找到关于此的勘误。1.6）。我们可以分享 如果需要，可以提供寄存器捕获方法以及测量的更多详细信息。 谢谢！ i.MXRT 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周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

代码压缩 MPC556 你好呀。我正在使用一款老旧的MPC556微控制器，没有办法更换它。我需要一款代码压缩器。阅读MPC555UM手册时，我在4.3.1节中找到了以下内容：“压缩是由一个特殊的压缩工具离线完成的，该工具使用基于固定词汇表指令的算法，并针对 PowerPC 指令集进行了优化。” 我一直在寻找一些编译器或其他工具来压缩我的 C 代码，但我不知道应该使用哪一个。我看到有人提到Squeezard压缩器，但我找不到下载或购买的地方。有什么办法可以压缩我的C代码吗？可以是任何工具（带有压缩选项的编译器或压缩软件），即使我需要购买它也没关系！ 我的最后一个选择是自己开发，但我不知道这有多难。 Re: Code compression MPC556 嗨，同事！你找到任何关于代码压缩机制的信息了吗？请联系我：[email protected] Re: Code compression MPC556 你好@juninholiveira90 很抱歉，代码压缩的工具和文档已不再提供。 此外，MPC555/556 已经停产，该设备不再生产，因此不再提供支持。 此致， Lukas

MC705J1ACDWE Need confirm COD Spoiler (Highlight to read) The MC705J1ACDWE product has reached its end-of-life (EOL). Please help confirm the wafer diffusion location (COD) for this product. Thank you. The MC705J1ACDWE product has reached its end-of-life (EOL). Please help confirm the wafer diffusion location (COD) for this product. Thank you. 回复： MC705J1ACDWE Need comfirm COD Thank you for your reply and support. Additionally, I obtained original label information from another source, which shows "Diffused In:TH". I can still use this to confirm the information, right? Re: MC705J1ACDWE Need comfirm COD Im sorry for the inconveniences this might cause you, there is no information available to share for this End of Life/Obsolete family Part Number. Best Regards. 回复： MC705J1ACDWE Need comfirm COD Could you help us to confirm your source? Could you please contact your product distributor for further information about this inquiry? As this can help you find the correspondent COD. Best Regards

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 [モータ制御]に様々な例やガイドが収録されています。 来月や年にこのトピックに関する新しい情報が追加されたり、アプリケーションコードハブに新しい例が追加されたりすれば、定期的に更新をチェックできます。 よろしくお願いいたします。