因软件许可到期而申请延期   尊敬的技术支持团队： 如附图所示，我收到一封电子邮件通知我，我的 S32DS 许可证即将到期。 我需要继续使用 S32DS 来进行我的工作。请问您能否延长我的软件使用许可，以便我能继续使用该软件？ 感谢您的协助。 顺祝商祺！ Re: Request for Software License Extension Due to Expiration 你好， 我查看了您的账户，您的许可证有效期至2028年。

Performance degradation in Facemesh Landmark model ptq conversion We were using Google's FaceMesh model released by NXP after ptq in this repo: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 · nxp-imx-support/nxp-demo-experience-demos-list But this model is based on Google's old FaceMesh model, which had 468 landmark points. Now we want to move to Google's new FaceMesh model, which has 478 landmark points. We want to run this on iMX 95 FRDM board NPU. So, we wanted to quantize this. We are using NXP's eIQ-neutron-sdk-linux-3.1.3 to quantize this model. After this quantization, we are seeing significant degradation in model performance, almost unusable for actually using it. Initially we were quantizing it with MIN-MAX option. That model was unusable. Then we tried using percentile option and found a better performance with percentile set to 95 (even though this was regressor outputs). But this is still not giving great performance 1) When NXP created the ptq file for old FaceMesh(468) model which option did they use, MIN-MAX? Or percentile? 2) Is there anything else we need to check when the performance degrade drastically after quantization 3) we profiled with the CelebA dataset used the serialize_image.py in scripts dir with model options specific options, should we run the full media pipe and create the calibration dataset or make changes in serialize script  options supplied serialize_image.py:  -i            //218 x 178 front facing RGB images  -o -f bin -t float32 -m 0to1 -s 256, 256 -layout NHWC -co RGB tflite-profiler: --input  --dataset --output tflite-quantizer: --input  --profile  --quantize-inputs=false      --quantize-outputs=false --quantization-calibration-method= //MinMax or Percentile Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @dhilshad, Thank you for contacting NXP Support! 1) Unfortunately, we do not have that information available at this time. 2) This behavior is expected. Quantization is only one part of the deployment process; converting and optimizing a model for execution on embedded hardware involves several additional steps, such as graph optimization, operator mapping, hardware-specific transformations, and runtime validation. As a result, model behavior and performance can vary even when the model is already quantized. For new designs and evaluations, I recommend using eIQ Olive, as it provides a more modern framework for model optimization and deployment on NXP i.MX platforms. It includes updated workflows and improved support for current machine learning deployment scenarios. Please refer to the following tutorials and documentation for more information: https://eiq.nxp.com/learning-hub/tools/olive/index.html These resources cover the recommended workflows and best practices for deploying machine learning models on i.MX devices. Best regards, Chavira

[S32N55 / HSE2] 调试卡请求 — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR 您好， 后续内容：S32N55 (HSE2) 安全调试。CRS(APP)挑战-响应认证现在可以工作（最终响应0x4A4A4A4A）。我现在正在执行调试卡请求 (HSE_DEBUG_CMD_CARD_REQUEST)，它返回： HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — "调试卡中的调试功能域映射无效。" 我根据您之前的反馈发送的内容： Packet2 调试功能域信号列表：数组样式，List[22..26] = 每个 0x01（CRS：Cortex-M7、PCIe、CRS NoC/CAN NoC、CANXL0-1、CANXL2-3），所有其他字节为 0x00。 Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 按照建议（位 22-26）。 AuthScheme：macAlgo = HSE_MAC_ALGO_CMAC = 0x11。 AuthTag：对卡片信息进行 AES256-CMAC 认证，authLen = 16。 我尝试过对 enabledDebugDomainMap（uint64_t，传输 8 字节）进行以下操作： 小端序：00 00 C0 07 00 00 00 00 → 0x20 大端序：00 00 00 00 07 C0 00 00 → 0x20 bit27 (0x08000000，匹配 AUTH 目标 0x1B) → 0x20 所有返回值均为 0x20。 问题： 1.对于 CRS，HSE 期望的 enabledDebugDomainMap (uint64_t) 的确切值是什么，以及其字节顺序是什么？ 2. enabledDebugDomainMap（Packet3 位掩码）是否必须与调试功能域信号列表（Packet2，数组 List[22..26]）一致？它们之间究竟是什么关系？ 3. RM 示例说明“功能域 1,3 已启用 → 0x00..A0”。能否解释一下功能域到位的映射关系，以便我计算 CRS 值？ 4. HSE 是否在验证 AuthTag 之前验证功能域映射？我想确认 0x20 是否仅表示功能域映射错误，还是其他字段（例如 AuthTag / 签名数据范围）也可能导致 HSE 在此停止。 我还想确认卡 AuthTag 的签名数据范围：我目前对卡信息字段（authKeyRef + reserved0 + ownerId + authScheme + signal list + 功能域映射 + UID list）计算 AES256-CMAC。这是要签署的正确数据吗？ 顺祝商祺！ Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR 你好， @EddiePark 感谢你的帖子。 1.很高兴得知第一阶段顺利通过。关于您提出的第二阶段问题，我仍在核实相关信息以获得更清晰的描述，如有任何有价值的更新，我会稍后回复您。 为了确保信息一致，能否请您再次与我分享最新的日志和相应的脚本？可以像往常一样通过消息分享。 BR 陈银

imx8mp 是否支持 Yocto 6.0？ 你好， imx8mp 是否支持 Yocto 6.0？ 如果属实，预计版本日期是什么时候？ 有顾客询问过这个问题。 谢谢！ Re: Does the imx8mp support Yocto 6.0? 是的，NXP Yocto 6.0 (Wrynose) 电路板支持包。 支持 i.MX8MP，LF6.18.20_2.0.0 版本已于 2026 年 6 月 25 日发布。   https://github.com/nxp-imx/meta-imx Re: Does the imx8mp support Yocto 6.0? 非常感谢

Request for Assistance: S32 Design Studio for ARM License Renewal Error Dear NXP Support Team, Hello, I am writing to request support regarding an error encountered while trying to renew the license for S32 Design Studio for S32. Below are the details of my license and the error message received: < License Information > < Error Message > Could you please advise on how to resolve this issue and successfully extend/renew the license? Thank you for your time and assistance. Best regards, Suhyun Sung

LX2160AでMPキーの取得に失敗しました こんにちは、NXPさん。 LLDP LX2160Aベースの安全なブートシステムを構築し、MPキーの機能検証も行っています。 LX2160Aボードのセキュアブートシステムのインストールと起動は問題なく、ITSのビット値は1だと考えていますが、「mp_app -p」コマンドを実行すると「Device is not initiated」エラーが出ます。 この問題について確認するためのアドバイスはありますか？ ありがとうございました。 ジェフリー Re: LX2160A get MP key failed 顧客はLLDPの文書6.4.4項を守りましたか?   のような Linuxプロンプトからtee-supplicant & commandを実行してください。 Linuxカーネルのバージョンによっては、右フォルダからinsmod securekeydev.koを使用していました また、顧客が「mp_app」を実行する際にカーネルPrintkを有効にしてもらい、ログを共有してください。 エコー 8 > /proc/sys/kernel/printk dmesg

Does the imx8mp support Yocto 6.0? Hello, does the imx8mp support Yocto 6.0? If so, when is the expected release date? We have customers asking about this. Thank you. Re: Does the imx8mp support Yocto 6.0? Yes, i.MX8MP is supported in the NXP Yocto 6.0 (Wrynose) BSP, and the LF6.18.20_2.0.0 release was published on 25 June 2026   https://github.com/nxp-imx/meta-imx Re: Does the imx8mp support Yocto 6.0? thank you very much

LX2160A 获取 MP 密钥失败 您好，NXP， 我们正在构建基于LLDP的LX2160A安全启动系统，并验证MP密钥功能。 在我们的 LX2160A 板上安装并启动安全启动系统没有问题，因此我们认为 ITS 位值为 1，但在执行“mp_app -p”命令后出现“设备未初始化”错误。 您有什么建议可以帮我检查这个问题吗？ 谢谢！ 杰弗里 Re: LX2160A get MP key failed 客户是否遵循了 LLDP 文档第 6.4.4 节？   例如 在 Linux 提示符下运行 tee-supplicant & 命令。 根据所使用的 Linux 内核版本，从正确的文件夹运行 insmod securekeydev.ko 脚本。 请让客户在运行“mp_app”时启用内核 printk，并分享他们的日志。 echo 8 > /proc/sys/kernel/printk dmesg

GC7000 GPU hang galcore timeout Issue Summary During execution of NavApp, the display freezes completely. Investigation of the kernel logs indicates that this is not an application crash, but a Vivante GC7000 GPU (Galcore) hang. Observations: The kernel reports a GPU timeout after 30 seconds (gpuTimeout = 30000). Galcore generates a GPU State Dump and invokes: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() The driver then reports: [galcore]: Stop driver to keep scene. The GPU state dump indicates multiple GPU blocks are stuck: FE not idle SH not idle TX not idle MC not idle DMA appears to be stuck Driver Configuration Current Galcore configuration shows: recovery = 0 gpuTimeout = 30000   Since GPU recovery is disabled (recovery = 0), the driver stops after detecting the hang, leaving the last rendered frame on the display, which explains the observed screen freeze. GPU Memory Status: GPU memory statistics do not indicate memory exhaustion. Total GPU memory: 256 MB Used: ~155 MB Free: ~113 MB Therefore, the issue does not appear to be caused by GPU out-of-memory. GPU Client: The GPU database shows that NavApp is the only active GPU client at the time of the hang. The GPU state dump references multiple command buffers submitted by: NavApp This indicates the GPU hang occurred while executing rendering commands submitted by NavApp.   Application Timeline: From the application logs, the following sequence is observed immediately before the GPU hang: Continuous map zoom in/out operations Offline map/tile access Route calculation Route information display GPU timeout and state dump The GPU hang occurs immediately after intensive rendering activity. Conclusion: Based on the collected evidence: There is no kernel panic, OOM, or application crash. The failure is a GPU command processing hang detected by the Galcore watchdog. NavApp is the rendering client when the hang occurs, but the failure is observed inside the GPU driver. GPU memory usage is within limits and does not indicate resource exhaustion. Request to TVS team please investigate: Vivante GC7000 / Galcore GPU driver hang during rendering. Whether this issue is a known GPU driver or firmware limitation. Whether GPU recovery (recovery=1) is supported and recommended on this platform. Analysis of the GPU state dump to identify which GPU command or hardware block caused the timeout. Whether there are updated BSP, GPU driver, or firmware releases addressing similar GPU timeout issues. Re: GC7000 GPU hang galcore timeout Hi @Zhiming_Liu  SOC - iMX8qxpComek BSP version - Scarthgap L6.6.5 Spoiler (Highlight to read) Spoiler (Highlight to read)     Re: GC7000 GPU hang galcore timeout Hi @Ram2  Please provide SOC part number, BSP verison and reproduce steps. Best Regards, Zhiming Re: GC7000 GPU hang galcore timeout Hi @Zhiming_Liu  Reproduce Steps : The screen freeze issue does not have a fixed set of reproduction steps, as it occurs randomly and intermittently. However, I have observed that it is more likely to occur when the available system memory becomes very low (typically below 60 MiB). To increase the likelihood of reproducing the issue, I performed the following activities continuously: Created 2-3 long-distance routes. Started navigation and exited within about a minute. Repeatedly created routes using the Home, Office, and Hotel quick action buttons. Explored different map regions by panning and performing frequent zoom in/out operations. During these activities, the screen freeze was observed when the available memory dropped to a low level. For example: MiB Mem : 1709.5 total, 55.8 free, 1298.1 used, 567.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used, 411.4 avail Mem This suggests the issue is more likely to occur under sustained usage when free memory is nearly exhausted. Re: GC7000 GPU hang galcore timeout Hi @Ram2  Please provide steps to reproduce the issue on the EVK. Best Regards, Zhiming Re: GC7000 GPU hang galcore timeout Hi @Ram2  The Linux BSP released by NXP does not include a navigation app. Please provide a test app and testing instructions. Best Regards, Zhiming

NFC天线工具 - 皮肤效果 你好！我有一个关于NFC天线工具的问题。该工具在计算天线参数时是否考虑了趋肤效应？ Re: NFC Antenna Tool - Skin effect 你好@lucas_uy_13 是的，确实如此。

S32Kコンパレータの許容差/オフセット S32K116の比較器でテストを行っています。 入力電圧(238mV)をINN(またはINP)に印加し、バンドギャップを基準にしてからVOSELを0から255に上げ、コンパレータ出力の変化を監視します。 入力電圧とバンドギャップの接続を入れ替えると、MCU2で異なる許容誤差/オフセットが見られるという現象が見られます。（詳細はテスト1およびテスト2を参照） 1) これはVAIOのような既知の機能なのでしょうか、それとも他の何かですか? 2) この許容差/オフセットについて安定していますか?また、校正でこれを除去できますか? （例えば、目標電圧におけるトリガーVOSELを記録するなど） テスト1：入力電圧V-、バンドギャップV+ 、低速モード テスト2：入力電圧V+、バンドギャップV- 、低速モード Re: S32K comparator tolerance/offset 1) 入力ピン CMP0_INは常にチャンネル0に設定されています。(ピン26、PTA0) はい、入力電圧は同じCMP0_INピン26、PTA0を通じて入力されています。 2) バンドギャップ 私が知りたいのは、2つのMCUの違いではありません。INNとINPを入れ替えたときの同じMCUからの許容差やオフセットの違いが原因です。この交換操作の間、バンドギャップは変化しないはずだと私は考えています。(ここでのMCU1のデータはあくまで参考資料として利用しています) 3)VDD/VDDA: 2つのMCUは同じ+3.3Vネットワーク(LDO許容範囲内)を使っています。 MCUのバンドギャップに違いがあることは十分理解していますが、やはり交換時の違いを確認しています。 4) 試験方法 上記のテストデータは入力電圧を上げているのではなく、固定入力電圧を使い、VOSELを上昇させています。(VOSELを減らす方法はまだテストしていませんが、後で確認します。) 固定VOSELで入力電圧を上下に調整する場合、同様の-9mVがあります。 5) ヒステリシス 低速モードでのヒステリシスに関するテストデータはあります。 ここでのテストデータは、入力電圧を固定し、VOSELを増加させるものです。 6) MCUの写真 添付の写真「MCU1.PNG」と「MCU2.PNG」を参照してください。 はんだマスクは FS32K11-6LFMFM-ON96V-S12YM16 Re: S32K comparator tolerance/offset こんにちは、Sid_Zhouさん。 入力電圧はどのCMP0_INピンに接続していますか？ INNとINPを入れ替えた場合、入力電圧は依然として同じCMP0_INピンを通して入力されますか？ また、バンドギャップ電圧の範囲は0.97～1.03Vです。2つのMCUのバンドギャップ電圧の違いによって引き起こされる問題を、一時的に除外することを検討しましたか？例えば、より正確な外部電圧基準を入力するために別のCMP0_INピンを使うことはできますか? 2つのS32K1のVDD/VDDA電圧が同じかどうか確認しましたか？ デバッグ中にOFFSET=1およびHYSTCTR=0であることが確認されていましたか？ 入力電圧を上げてVOSELを記録したことに気づきました。入力電圧を下げてVOSELを記録するテストは行いましたか？また、 アナログ比較器のヒステリシス が影響を受けているかも確認してください。ただし、HYSTCTR=0に設定されているようですね。 S32K116写真を2枚撮って、MCUのマスクについて教えてくれ。 よろしくお願いいたします ロビン Re: S32K comparator tolerance/offset 詳しいご説明をありがとうございました。S32K1のデータシートにある VAIO (アナログ入力オフセット電圧)パラメータについてご懸念されていることが理解できました。 内部では、AEチームの説明を見ました: AIOオフセットはコンパレータ自体のオフセットです。INPとINNのオフセットです。 INL誤差はDNLに関する積分であるため、DNL誤差を含みます。 エラーは |V_AIO| + |INL| となります。 私の理解では、外部信号源から直接2つのアナログ電圧を入力 INP と INN にそれぞれ使い、 VAIO をテストする方がバンドギャップ電圧分圧器を使うよりも直感的だと思います。 ご質問についてですが、同じMCUの場合、VAIOは瞬間ごとにランダムに変わる値ではありませんが、動作条件、特に温度によって変動することもあります。データシートのVAIO値は、全温度範囲にわたる保証/最悪ケースの限界として理解すべきです。 しきい値を設計する際には、VAIOを無視できる値、または固定された校正済み値として扱わないでください。マージンは最悪の温度|VAIO|、さらにDAC/INLエラーも加わります。 また、以前の S32K116 コンパレータ許容についての議論も確認しました。 CMPの精度は、お客様のニーズを満たしていないようです。S32K1XXRM Rev14.2の「 44.5.5 自動比較機能 」の項で説明されている機能について検討されましたか？ S32K1データシート Rev15の「 表41. 12ビットADC特性（2.7V～3V） 」には、最大 TUE が±8LSBと記載されています。これはCMPよりも正確であるように思われる。 Re: S32K comparator tolerance/offset 詳しい説明をありがとうございました。 ADCの方が私たちのアプリケーションでは精度が高いかもしれないと指摘しました。 しかし、なぜか高レベルアーキテクチャからCMPをセーフティモニターとして使う要件があり、これをADCに変更できるかはわかりません。

LX2160A get MP key failed Hi NXP, We are building LX2160A secure boot system based on LLDP and verifying MP key function. Install and start up the secure boot system on our LX2160A board are OK and so we think ITS bit value is 1, but get "Device is not initiated" error after execute "mp_app -p" command. Do you have any advice to check this issue ? Thank you, Jeffrey  Re: LX2160A get MP key failed Did customer follow LLDP document section 6.4.4?   Such as Run tee-supplicant & command from the Linux prompt. Depending on the Linux kernel version used insmod securekeydev.ko from right folder Please also let customer enable kernel printk when run 'mp_app', and share their log. echo 8 > /proc/sys/kernel/printk dmesg

Facemesh Landmarkモデルptq変換におけるパフォーマンス低下 このリポジトリでは、ptq後にNXPがリリースしたGoogleのFaceMeshモデルを使っていました: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 ·NXP-IMX-support/NXP-demo-experience-demos-list しかしこのモデルは、468のランドマークポイントを持つGoogleの旧FaceMeshモデルに基づいています。 次に、Googleの新しいFaceMeshモデルに移行したいと考えています。これには478のランドマークポイントがあります。これをiMX 95 FRDMボードのNPU上で実行したいと考えています。そこで、これを量子化したかったのです。NXPのeIQ-neutron-sdk-linux-3.1.3を使っていますこのモデルを量子化するために。 この量子化の後、モデルのパフォーマンスは著しく劣化し、実際に使うにはほとんど使えない状態です。 当初はMIN-MAXオプションを使用して量子化していました。そのモデルは使い物にならなかった。次に、パーセンタイルオプションを使用してみたところ、パーセンタイルを95に設定した方がパフォーマンスが向上することがわかりました（これは回帰モデルの出力でしたが）。 しかし、それでも十分な性能は得られていません 1) NXPが古いFaceMesh(468)モデルのptqファイルを作成した際、どのオプションを使っていましたか?MIN-MAX?それともパーセンタイル？ 2) 量子化後にパフォーマンスが著しく低下した場合、他に確認すべき事項はありますか？ 3) CelebAデータセットでプロファイリングを行い、スクリプトのserialize_image.pyをモデルオプションで使いました。メディアパイプ全体を実行してキャリブレーションデータセットを作成するか、シリアル化スクリプトで変更すべきか オプション提供 serialize_image.py: -i //218 x 178 前面向けRGB画像 -<パス/トゥ/calib_bins> -Fビン -T float32 -0to1 -256、256 -NHWCレイアウト -コRGB TFLITE-Profiler: --input --データセット --出力 TFLITE-クオンタイザ: --input --プロファイル --quantize-inputs=false --quantize-outputs=false --量子化-キャリブレーション-方法= //最小最大値またはパーセンタイル Re: Performance degradation in Facemesh Landmark model ptq conversion こんにちは@dhilshad。 NXPサポートにご連絡いただきありがとうございます! 1) 残念ながら、現時点ではその情報は入手できません。 2) この挙動は想定内です。クオンタイズは展開プロセスの一部に過ぎません。組み込みハードウェア上でモデルを変換・最適化するには、グラフ最適化、演算子マッピング、ハードウェア固有の変換、ランタイム検証など、いくつかの追加ステップが必要です。その結果、モデルがすでに量子化されていても、モデルの挙動や性能は異なることがあります。 新しいデザインや評価には、eIQ Oliveの使用をおすすめします。NXP i.MX プラットフォームでのモデル最適化と展開のためのよりモダンなフレームワークを提供するからです。ワークフローの更新と、現在の機械学習展開シナリオへのサポート強化が含まれています。 詳細については、以下のチュートリアルおよびドキュメントをご参照ください。 https://eiq.nxp.com/learning-hub/tools/olive/index.html これらのリソースは、i.MX デバイスに機械学習モデルを導入するための推奨ワークフローやベストプラクティスをカバーしています。 よろしくお願いします、 チャビラ

登録:S32K eMIOSエンコーダーのCW/CCWカウンタの静的ローター位置での挙動 チームの皆さん、こんにちは。 私はS32K322マイクロコントローラを使っており、位置センサーからローター角度を得るためのエンコーダーインターフェースを実装しています。 申請ノートに基づいて、TRGMUX、LCU、eMIOSを含む必要なMCALモジュールを構成しました。エンコーダーの機能は正常に動作していますが、CWカウンターとCCWカウンターで予期しない動作が見られました。 私の質問は以下のとおりです。 ローターが動いていない静的なローター位置では、CWおよびCCWカウンターがフリーランニングカウンターとして振る舞うことが期待されますか? 私の場合、CWとCCWカウンターは増加し続けますが、絶対ポジション値はゼロのままです。これは想定される動作ですか？ もしこれが予想されるなら、ローターが静止しているのにCWやCCWカウンターが増加する理由は何ですか? もし予想外の情報があれば、以下の方法を提案していただけませんか: MCALの設定（TRGMUX、LCU、またはeMIOS）において、必要な構成変更はありますか？ ローターが静止しているときにCW/CCWカウンターが増加しないように、追加のソフトウェア機構やフィルタリングを実装すべきでしょうか? 参考のために動画を添付しました。 AWSライブラリS32K3 よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 LCnからのCWおよびCCW出力は、それ自体で位置カウンターではありません。インクリメンタルエンコーダの実装によれば、使用されるLCnは、検出された直交シーケンスに応じて、A/B信号の各エッジでCWまたはCCW出力にパルスストリームを生成します。eMIOSはこれらのパルスをカウントして位置を蓄積します。これは、PHA/PHBがLCUで処理され、eMIOSが位置蓄積のカウンターとして機能するS32K3の直交方式と一致しています。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 ローターが本当に静的でエンコーダのA/B入力が安定している場合、新しいCW/CCWパルスを連続的に生成すべきではありません。したがって、CWとCCWの両方のカウンターが、絶対位置がゼロのまま増加するのは期待される「理想的な」挙動ではありません。 いくつか確認しておくと良い点があります。 eMIOSチャネルが本当にCW/CCWの入力パルスをカウントしているか、内部クロックソースではないか確認してください。 デバッガで使用されているeMIOSチャネルのUINステータスを確認してください。カウンターが増加してもUINが一定のままであれば、チャネルは意図した外部入力を使っていない可能性があります。 もしローターが静止している間にUINがトグルしている場合は、エンコーダA/B信号、TRGMUXルーティング、LCU出力、入力フィルタリングを調べてください。 また、ノイズやグリッチがないことを確認するために、エンコーダのA/B信号とLCUのCW/CCW出力をオシロスコープで監視してください。 これにより、問題の原因がエンコーダ信号の活動/ノイズによるものか、eMIOSの設定の問題によるものかを判断するのに役立つはずです。 BR、ペトル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 I could not find any register corresponding to the UIN status in the S32K322 リファレンス・マニュアル. Could you please check and guide me on how to verify this for further analysis? I debugged the registers that update the CW and CCW counters. According to the 参考マニュアル, eMIOS チャンネル 5 MCU CNT corresponds to the CW counter, and eMIOS チャンネル 6 MCU CNT corresponds to the CCW counter. しかし、MCU CNTのレジスタは、ローターが静的状態でも0から65535(フリーランニング)まで連続的に増加し続けるのを観察しました。この行動が予想されるものなのか、あるいは何が原因なのか教えていただけますか? 参考までに、関連するレジスタ値のスクリーンショットを添付しました。 さらに、MCALの設定も確認しましたが、共有されたアプリケーションノート通りに正しく設定されています。 早くもサポート よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 質問にお答えください。 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 UINと書きましたが、チャネルSレジスタのUCINビットであるはずです。 レジスタビューに基づくと、コントロールレジスタは0x20E06D1に設定されており、これは外部信号のカウントである0x51が使用されている正しいモードを示しています。 私の理解ではLCnはCWまたはCCW出力の各A/B信号エッジでパルスストリームを生成するため、定常モーター/エンコーダ信号ではパルスを発生させず、カウントされることはありません。 また、TRGMUX出力が選択されているかを確認するために、それぞれのSIUL IMCRレジスタも確認できます BR、ペトル  

GC7000 GPU 挂起 galcore 超时 问题概要 在 NavApp 运行时，屏幕完全冻结。对内核日志的调查表明，这是 不是应用程序崩溃，而是 Vivante GC7000 GPU (Galcore) 挂起。 观察结果： 内核报告 GPU 超时时间为 30 秒（gpuTimeout = 30000）。 Galcore生成 GPU状态转储和调用： gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() 司机随后报告： [galcore]：停止驱动程序以保持场景。 GPU状态转储显示多个GPU模块卡住： FE 不怠速 SH 未空闲 TX非空闲状态 MC非怠速 DMA似乎卡住了。 驱动程序配置 当前 Galcore 配置显示： 恢复时间 = 0，GPU超时时间 = 30000   由于 GPU 恢复功能已禁用（恢复 = 0），驱动程序在检测到挂起后停止运行，屏幕上会留下最后渲染的帧，这就解释了观察到的屏幕冻结现象。 GPU内存状态： GPU内存统计信息 并不表示记忆力衰竭。 GPU总显存：256 MB 已用：约 155 MB 免费：约 113 MB 因此，该问题似乎并非由 GPU 内存不足引起。 GPU客户端： GPU数据库显示 程序卡死时， NavApp 是唯一活跃的 GPU 客户端。 GPU状态转储引用了以下人员提交的多个命令缓冲区： 导航应用 这表明 GPU 挂起发生在执行 NavApp 提交的渲染命令时。   申请时间表： 从应用程序日志中可以观察到，在 GPU 挂起之前，会立即出现以下序列： 连续地图缩放操作 离线地图/图块访问 路线计算 路线信息显示 GPU超时和状态转储 GPU 死机通常发生在高强度渲染活动之后。 结论： 根据收集到的证据： 有 没有内核崩溃， OOM ，或 应用程序崩溃。 失败是 Galcore 监控程序检测到GPU 命令处理挂起。 NavApp 是渲染客户端，当程序卡死时，故障却在 GPU 驱动程序内部被发现。 GPU内存使用率在允许范围内，并不表示资源耗尽。 请TVS团队调查此事： Vivante GC7000 / Galcore GPU 驱动程序在渲染过程中挂起。 这个问题究竟是已知的GPU驱动程序限制还是固件限制？ 此平台是否支持和推荐使用 GPU 恢复（recovery=1）。 分析 GPU 状态转储，以确定是哪个 GPU 命令或硬件块导致了超时。 是否有更新的 电路板支持包、GPU 驱动程序或固件 版本 来解决类似的 GPU 超时问题。 Re: GC7000 GPU hang galcore timeout 嗨@Zhiming_Liu SOC - iMX8qxpComek BSP 版本 - Scarthgap L6.6.5 剧透 （高亮部分可供阅读） 剧透 （高亮部分可供阅读）     Re: GC7000 GPU hang galcore timeout 嗨@Ram2 请提供 SOC 部件号、BSP 版本以及重现步骤。 此致， 志明 Re: GC7000 GPU hang galcore timeout 嗨@Zhiming_Liu 重现步骤： 屏幕冻结问题没有固定的重现步骤，因为它随机且间歇性地发生。但是，我发现当可用系统内存非常低时（通常低于 60 MiB ），这种情况更容易发生。 为了增加重现问题的可能性，我持续执行了以下操作： 开辟了 2-3 条长途路线。 启动导航后，大约一分钟内退出。 反复使用“家” 、 “办公室”和“酒店”快捷操作按钮创建路线。 通过平移和频繁的缩放操作探索不同的地图区域。 在这些活动期间，当可用内存下降到较低水平时，观察到屏幕冻结现象。例如： 内存使用量（MiB）：总计 1709.5，可用 55.8，已用 1298.1，缓冲/缓存 567.2 MiB 交换空间：总计 0.0，可用 0.0，已用 0.0，可用内存 411.4 这表明，当可用内存几乎耗尽时，持续使用过程中更容易出现此问题。 Re: GC7000 GPU hang galcore timeout 嗨@Ram2 请提供在 EVK 上重现此问题的步骤。 此致， 志明 Re: GC7000 GPU hang galcore timeout 嗨@Ram2 NXP发布的Linux 电路板支持包。不包含导航应用程序。请提供测试应用程序和测试说明。 此致， 志明

支援要請:S32 Design StudioによるARMライセンス更新エラー 親愛なるNXPサポートチームへ、 こんにちは、 S32 Design Studioのライセンス更新を試みる際に発生したエラーについてサポートをお願いしたいのでお願いしています。 以下に、私のライセンスの詳細と受信したエラーメッセージを示します。 < License Information >＜ライセンス情報＞ < Error Message >＜エラーメッセージ＞ この問題を解決し、ライセンスの延長や更新を成功させる方法についてアドバイスをいただけますか? お時間とご協力に感謝いたします。 よろしくお願いいたします。 ソン・スヒョン

RT1176(1コアあたり1つのイーサネット)におけるデュアルコアイーサネット例 i.MX リクエスト NXPチームの皆様、こんにちは。 現在、 MCUXpresso IDE v11.9.1(ビルド2170、2024年4月19 日)を使って i.MX RT1176 評価ボード を開発中 です。 NXP が、独立したイーサネットインターフェースを持つCortex-M7とCortex-M4コアの両方の利用を示すマルチコアの例プロジェクトを提供しているかどうか知りたいです。 私の要望は以下のとおりです。 イーサネットポート1 は Cortex-M7 コア で初期化・管理されるべき です。 イーサネットポート2 は Cortex-M4 コア で初期化・管理されるべき です。 両方のイーサネットインターフェースは、それぞれのコア上で同時に独立して動作すべきです。 もしコア間通信(RPMsgやMU)が必要な場合は、推奨されるアプローチを説明する例やドキュメントがあれば教えていただけるとありがたいです。 MCUXpresso SDKの例を探しましたが、このユースケースに合うプロジェクトは見つかりませんでした。 教えていただけませんか? M7コアにイーサネットコントローラーを使い、M4コアにもう一方のイーサネットコントローラーを搭載している公式のNXPマルチコア例はありますか? もしそのような例があれば、プロジェクトを共有していただけるか、対応するSDK例名やリポジトリリンクを教えていただけませんか? もしそのような例が存在しない場合は、i.MX RT1176でこの構成を実装するための推奨アーキテクチャを教えていただけますか? 参考プロジェクト、アプリケーションノート、またはドキュメントがあれば大変ありがたいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 アラヴィンド・トガラリ Re: Request for Dual-Core Ethernet Example on i.MX RT1176 (One Ethernet per Core) @Aravind_Togaralli様、 残念ながら、Cortex-M7とCortex-M4が独立したイーサネットインターフェースを同時に動作させている公式な例は現在存在しません。 しかし、推奨されるアーキテクチャは、2つのイーサネットサブシステムを完全に独立させておくことです。 一方のイーサネットコントローラ(例:ENET/ENET_QOS)をCM7に、もう一方をCM4に割り当てます。 各コアは独自のMACドライバー、PHY制御、lwIPスタック、netifインスタンス、DMAディスクリプタ、パケットバッファ、割り込み、ネットワーク構成を管理すべきです。 RPMsg-Lite、MU、または共有メモリは、コア間の制御およびステータス通信が必要な場合にのみ使用してください。 開発中にRDC/XRDC2を使ってイーサネット周辺機器とメモリリソースを2コア間で分離することを検討してください。 イーサネットDMAバッファの場合、選択したメモリ領域が対応するCPUとイーサネットDMAマスターの両方がアクセスできるようにしてください。 提案する実装方法は以下のとおりです。 動作するRT1170マルチコアのサンプルから始めましょう。 標準的なlwIPの例を使ってCM7でイーサネットを起動します。 2つ目のイーサネットコントローラーを使ってCM4でイーサネットを起動します。 両方のイーサネットインターフェースがIPCなしで同時に動作しているか確認してください。 必要に応じてRDC/XRDC2アイソレータを追加してください。 アプリケーションがコア間相互作用を必要とする場合にのみ、RPMsg-LiteまたはMU/共有メモリ通信を導入してください。 また、RT1170マルチコアアプリケーション開発に関する指針や推奨が記載されているアプリケーションノート AN13264 役立つかもしれません。 よろしくお願いいたします。 シェリー・チャン

S32K358 + FreeRTOS: PendSV_Handler実行中にランダムなハードフォルトが発生 チームの皆さん、こんにちは。 FreeRTOSを実行しているS32K358で、ランダムなハードフォルトが発生しています。 アプリケーションは長時間正常に動作しますが、突然フリーズします。システムが実行を停止した後、ソフトウェア・ウォッチドッグ(SWT)はサービスされず、最終的にコントローラがリセットされます。 障害は即座に発生するわけではなく、約1～2時間の連続実行後に発生する。 障害発生後に停止すると、コールスタックには以下が表示されます。 PenSV_Handler() ↓ HardFault_Handler() レジスタ値: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5は、有効な戻りアドレスというよりは、メモリ初期化パターンのように見えます。 その他の登録簿： R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 ご提案やデバッグに関するアドバイスなど、何でもいただければ大変ありがたいです。 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @nirmal_masilamani さん。 FreeRTOSのコンテキスト切り替え時に保存されたタスクコンテキストが破損しているようです。 PendSVはFreeRTOSによってコンテキスト切り替えに使用されるため、PendSV_Handler()内でHardFaultが発生した場合、多くの場合、スケジューラが無効なタスクコンテキストを復元しようとしていることを意味します。 考えられる根本原因の一つは、タスクスタックオーバーフローです。タスクのスタックサイズを増やし、FreeRTOSのスタックオーバーフロー検出機能を有効にすることをお勧めします。 configCHECK_FOR_STACK_OVERFLOW 実装: vApplicationStackOverflowHook()。 さらに、uxTaskGetStackHighWaterMark()を使って各タスクの残りのスタック空間を定期的に監視することもできます。これにより、故障が発生する前にスタック限界に近いタスクを特定するのに役立ちます。 よろしくお願いいたします。 ダニエル Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @danielmartynek さん、 ご回答ありがとうございます。 既にスタックサイズを増やしたり、スタックオーバーフローフックを有効にしたりしてみました。 Overflow Hookにdebug CAN msgを追加しましたが、故障発生時にそのメッセージが届きません。 また、障害が発生した際には uxTaskGetStackHighWaterMark()を監視します。 タスク 1 : 1977 × 4 ≈ 7908 バイトの空き容量 タスク2：1971 × 4 ≈ 7884バイトの空き容量 タスク3：3988 × 4 ≈ 15952バイトの空き容量 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler こんにちは、 @nirmal_masilamani さん。 したがって、根本原因としてスタックオーバーフローを除外できるでしょう。 しかし、タスクコンテキストは依然として破損している。プロセッサはLR = 0xA5A5A5A5を復元しており、これがUsageFaultを引き起こします。0xA5A5A5A5 は tskSTACK_FILL_BYTE (0xA5U) から生成されるパターンで、FreeRTOS がタスクスタックを作成する際にタスクスタックを埋めるために使用されます。 したがって、LRが0xA5A5A5A5になった場合、コンテキストは有効なレジスタ値ではなく、元のスタックフィルパターンが残っている場所から復元されます。 SPが破損した場合に起こり得ます。その場合、PendSV_Handler()はRAM内の誤った場所からタスクコンテキストを復元します。 スタックポインタのアドレスからSRAM領域を特定できるはずです。 MPUとXRDCを使用して、その領域を適切に保護することをお勧めします。 また、FreeRTOS APIを呼び出す割り込み処理はありますか？もしそうなら、FromISR()のバリアントを使っているのか、configMAX_SYSCALL_INTERRUPT_PRIORITYに関して優先順位は正しく設定されているのか? よろしくお願いいたします。 ダニエル

HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am currently working on the i.MX95 FRDM EVK board using Zephyr RTOS. On the Linux side, HDMI output is already supported and working correctly. However, I would like to know how to enable and configure HDMI in Zephyr. Could you please guide me on the following? Does Zephyr support HDMI output on the i.MX95 FRDM EVK? If yes, what drivers and Device Tree configurations are required? Is there any reference implementation or sample application available for HDMI on Zephyr? Any guidance or documentation would be greatly appreciated. Thank you. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I confirmed with the AE team. HDMI is not supported in IMX95 Zephyr currently.  Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am looking for the IT6263 Reference Manual or Register Programming Manual. Could you please share the detailed register descriptions (register map with bit-level definitions) for the IT6263 HDMI bridge, or let me know how I can obtain this documentation? Note: I am specifically looking for the chip-level register documentation itself, not the Linux kernel driver source. Thank you, Karthikeyan M

组合固件下载后，i.MX95 上的 IW612 蓝牙 UART 无响应 你好， 我们正在Verdin i.MX95 WB上运行NXP Android 15 BSP (Linux 6.6.58)来启用蓝牙。板载无线模块为基于 NXP IW612 的 u-blox MAYA-W260 。 Wi-Fi 通过 SDIO 正常工作，并且组合固件已成功加载： Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active 蓝牙似乎无法正常工作。无论何时我们在 Android 设置中启用该功能，UI 开关都会卡住，并且找不到蓝牙设备。 蓝牙已连接到LPUART6 (/dev/ttyLP5)。NXP厂商HAL成功打开UART。 我们最初发现硬件流控制阻止了传输；在暂时禁用 CRTSCTS 后，HAL 发送了 4 字节的 HCI 重置命令： 01 03 0c 00 UART 计数器随后显示： tx:4 rx:0 IW612 没有响应。直接手动进行 UART 测试，波特率为 115200，8N1，没有硬件流控制，也会出现同样的结果。 我们目前的配置是： mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 由于 Wi-Fi 驱动程序已经下载了组合固件，因此 enable_download_fw 保持禁用状态。 请问您能否澄清一下： 通过 SDIO 加载 sduart_nw61x_v1.bin.se 后，IW612 蓝牙 UART 是否应该直接响应波特率为 115200 的 HCI RESET？ 是否需要先执行启动睡眠触发器、唤醒命令、供应商命令或其他初始化序列？ IW612 是否必须进行硬件流控制？固件初始化后，CTS 的预期状态应该是什么？ 我们是否应该使用 UART 固件下载路径（uartspi_n61x_v1.bin.se）而不是依赖 Wi-Fi 加载的组合固件？ 对于 i.MX95 上的 IW612，是否有推荐的 bt_vendor.conf 文件？ 任何参考配置或预期的UART跟踪信息都将非常有帮助。 顺祝商祺！ Android Linux