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

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+ 、低速モード Sid_Zhou_5-1784193940847.png テスト2：入力電圧V+、バンドギャップV- 、低速モード Sid_Zhou_6-1784193974436.png 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があります。 IncreaseInput_FixedVOSEL.PNG 5) ヒステリシス 低速モードでのヒステリシスに関するテストデータはあります。 ここでのテストデータは、入力電圧を固定し、VOSELを増加させるものです。 Hysteresis_LowSpeedMode.PNG 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に変更できるかはわかりません。

登録: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レジスタも確認できます PetrS_0-1784696552579.png 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 电路板支持包。不包含导航应用程序。请提供测试应用程序和测试说明。 此致， 志明

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 がタスクスタックを作成する際にタスクスタックを埋めるために使用されます。 danielmartynek_0-1784709240297.png したがって、LRが0xA5A5A5A5になった場合、コンテキストは有効なレジスタ値ではなく、元のスタックフィルパターンが残っている場所から復元されます。 SPが破損した場合に起こり得ます。その場合、PendSV_Handler()はRAM内の誤った場所からタスクコンテキストを復元します。 スタックポインタのアドレスからSRAM領域を特定できるはずです。 MPUとXRDCを使用して、その領域を適切に保護することをお勧めします。 また、FreeRTOS APIを呼び出す割り込み処理はありますか？もしそうなら、FromISR()のバリアントを使っているのか、configMAX_SYSCALL_INTERRUPT_PRIORITYに関して優先順位は正しく設定されているのか? よろしくお願いいたします。 ダニエル

PN7642 SPIコントローラインターフェース SPIコントローラインターフェースはPN7642の文書およびPN7642.hで言及されています。OM27642EVK（SPIMとして）にも搭載されていますが、それだけです。 そのSPIコントローラーの例やドライバーが見つかりません(ホストSPIのことではありません)。 AI検索では、特定のSPI関数呼び出し、phhalSpi.h、phhalSpi.c.があると言われていますが、似たようなものは見つかりません。 存在するのか、そしてどうやって見つければいいのか? 助けてくださってありがとうございます。 Re: PN7642 SPI controller interface こんにちは、当社の製品にご関心をお寄せいただきありがとうございます。 PN7642にはSDKの例セットがあります。既にいくつかインポート済みかどうかは分かりません。     Fabian_R_1-1784755580455.png   ご覧の通り、クイックスタートパネルからサンプルをインポートするだけで済みます。> Import SDKのサンプルを画像のように検索できます。 OM27642EVKにはフォロワーピンとリーダーピンがあることにご注意ください。クイックスタートガイドのドキュメントの7節にもご注意ください。

ARM 2018.R1用のS32 Design Studioは期限切れです。 ARM 2018.R1用のS32 Design Studioのライセンスは期限切れです。 ライセンスの更新または再有効化に関する別の手続きがある場合は、その旨もお知らせください。 Re: S32 Design Studio for ARM 2018.R1 has expired. 以前のライセンス認証コードと同じです。 そして、それでもまだ可決されない。 Re: S32 Design Studio for ARM 2018.R1 has expired. こんにちは、 お客様のS32DSライセンスが延長されました。

LX2160ARDB デフォルトブートイメージ こんにちは、 LX2160A-RDB-Bボードで デフォルトのブートイメージを使う方法をご存 知の方はいませんか? 評価ボード Re: LX2160ARDB Default boot images 最新のLayerscape Yocto BSP v26.06を使うこともできます 以下のプリコンパイル済みイメージは、 https://www.nxp.com/lgfiles/llsdk/walnascar/ にホストされています。 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img LX2160ARDB eMMCブート用BSPファームウェアイメージ 15 firmware_lx2160ardb-rev2_uboot_sdboot.img LX2160ARDB SDブート用BSPファームウェアイメージ 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img LX160ARDB xSPIブート用BSPファームウェアイメージ 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfsは基本的なネットワーク機能をサポートしていますLX2160ARDB 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfsはLX2160ARDB上で完全なネットワーク機能をサポートしています 25 フレックスインストーラー ツールの展開 4 boot_lx2160ardb-rev2_lts_6.12.tgz LX2160ARDBのブートパーティションイメージ Yocto用レイヤースケープソフトウェア開発キットユーザーガイド: UG10374.pdf Layerscape Linux SDK ユーザーガイド: UG10381.pdf

S32 Design Studio for ARM 2018.R1 has expired. The license for S32 Design Studio for ARM 2018.R1 has expired. Please also let us know if there is a separate procedure for renewing or reactivating the license. Re: S32 Design Studio for ARM 2018.R1 has expired. Hi,  your S32DS license has been extended.  Re: S32 Design Studio for ARM 2018.R1 has expired. It is the same as the previous license activation code, and it still does not pass.

i.MX93 FRDM: 「imx93-11x11-frdm-waveshare-7inch-c-panel.dtb」はどこにありますか？ 「 FRDM-IMX93 ボードユーザーマニュアル 」 UM12181 - Rev 3.0、2026年1月23 日の指示に従っています。 説明書に従って、 i.MX93 FRDMボードをWaveshare LCDに接続しようとしています。 セクション3.1.3「ソフトウェア構成アップデート」 28ページには、以下を実行すると書かれています: $setenv fdtfile imx93-11x11-frdm-waveshare-7inch-c-panel.dtb しかし、この dtb ファイル ( imx93-11x11-frdm-waveshare-7inch-c-panel.dtb ) は私のイメージには含まれておらず、参照イメージ ( LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ) にも含まれていません。 imx93-11x11-frdm-waveshare-7inch-c-panelデバイスツリーのソースはどこで見つけられますか? どうもありがとうございました！ FRDM-i.MX93 Re: i.MX93 FRDM: Where is "imx93-11x11-frdm-waveshare-7inch-c-panel.dtb"? こんにちは、 @TomFoy1 さん。 NXPサポートまでご連絡いただきありがとうございます。 このボード向けに最初に公開されたイメージでは、デバイスツリーはimx93-11x11-frdm-dsi.dtbという名前でした。後のリリースでは、 imx93-11x11-frdm-waveshare-7inch-c-panel.dtbに名前が変更されました。 imx93-11x11-frdm-dsi.dtb をお試しください。 よろしくお願いします、 チャビラ  

i.MX93 FRDM：'imx93-11x11-frdm-waveshare-7inch-c-panel.dtb'在哪里？ 我正在按照UM12181 《 FRDM-IMX93 板用户手册》- Rev 3.0，2026 年 1 月 23 日中的说明进行操作。 我正在尝试按照说明将i.MX93 FRDM板连接到Waveshare LCD 。 第3.1.3节“软件配置更新”（第 28 页）指出，请执行以下操作： $setenv fdtfile imx93-11x11-frdm-waveshare-7inch-c-panel.dtb 然而，我的镜像中缺少这个 dtb 文件（ imx93-11x11-frdm-waveshare-7inch-c-panel.dtb ），参考镜像（ LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ）中也缺少这个文件。 我可以在哪里找到imx93-11x11-frdm-waveshare-7inch-c-panel设备树的源代码？ 非常感谢！ FRDM-i.MX93 Re: i.MX93 FRDM: Where is "imx93-11x11-frdm-waveshare-7inch-c-panel.dtb"? 嗨@TomFoy1 ， 感谢您联系恩智浦技术支持。 在该板最初发布的镜像中，设备树被命名为imx93-11x11-frdm-dsi.dtb在后来的版本中，它被重命名为imx93-11x11-frdm-waveshare-7inch-c-panel.dtb 请尝试使用 imx93-11x11-frdm-dsi.dtb 此致， 查维拉  

i.MX93 FRDM: Where is "imx93-11x11-frdm-waveshare-7inch-c-panel.dtb"? I'm following the instructions in UM12181 "FRDM-IMX93 Board User Manual" - Rev 3.0, 23 January 2026. I'm trying to connect the i.MX93 FRDM board to a Waveshare LCD, as per the instructions. Section 3.1.3 "Software configuration update", page 28, says perform the following: $setenv fdtfile imx93-11x11-frdm-waveshare-7inch-c-panel.dtb However, this dtb file (imx93-11x11-frdm-waveshare-7inch-c-panel.dtb) is missing from my image, and also missing from the reference images (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93). Where can I find the source for the imx93-11x11-frdm-waveshare-7inch-c-panel device tree? Many thanks! FRDM-i.MX93  Re: i.MX93 FRDM: Where is "imx93-11x11-frdm-waveshare-7inch-c-panel.dtb"? HI @TomFoy1, Thank you for contacting NXP Support. In the first images released for this board, the device tree was named imx93-11x11-frdm-dsi.dtb In later releases, it was renamed to imx93-11x11-frdm-waveshare-7inch-c-panel.dtb  Please try with imx93-11x11-frdm-dsi.dtb Best regards, Chavira  

AEC-Q100 Is the MFS2613HMDA2AD AEC-Q100 qualified? Are all FS26 part numbers AEC-Q100 qualified? Thanks,  Enrico Re: AEC-Q100 Hello ESof Good day! Yes, the entire FS26 family is AEC-Q100 qualified. The documentation verifying this is classified as confidential, so if you require it, I would recommend opening a case directly with us to see what we can do and begin the NDA process. I hope this information has helped you, please let me know if you need help with anything else. We apologize for any inconvenience this may cause you. Have a great day and best of luck.

LX2160ARDB 默认启动映像 您好， 请问有人知道如何获取 LX2160A-RDB-B 开发板使用的默认启动映像吗？ 评估板 Re: LX2160ARDB Default boot images 您可以使用最新的Layerscape Yocto BSP v26.06。 以下预编译镜像托管在https://www.nxp.com/lgfiles/llsdk/walnascar/ 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img LX2160ARDB eMMC 启动的 电路板支持包。 固件映像 15 firmware_lx2160ardb-rev2_uboot_sdboot.img LX2160ARDB SD 启动 的 电路板支持包 固件映像 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img LX2160ARDB xSPI 启动的 电路板支持包 固件映像 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfs 支持 LX2160ARDB 上的基本网络功能 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfs 在 LX2160ARDB 上支持完整的网络功能 25 弹性安装程序 部署工具 4 boot_lx2160ardb-rev2_lts_6.12.tgz LX2160ARDB 的启动分区映像 Layerscape Yocto软件开发工具包用户指南： UG10374.pdf Layerscape Linux SDK 用户指南： UG10381.pdf

S32 Design Studio for ARM 2018.R1 已过期。 S32 Design Studio for ARM 2018.R1 的许可证已过期。 另外，请与我们联系是否有单独的许可证续期或重新激活程序。 Re: S32 Design Studio for ARM 2018.R1 has expired. 你好， 您的S32DS许可证已延期。 Re: S32 Design Studio for ARM 2018.R1 has expired. 它与之前的许可证激活码相同。 但它仍然没有通过。

PN7642 SPI 控制器接口 PN7642 文档和 PN7642.h 文件中提到了 SPI 控制器接口。以及在 OM27642EVK（作为 SPIM）上，但仅此而已。 我找不到该SPI控制器的示例或驱动程序（我指的不是主机SPI）。AI搜索显示有特定的SPI函数调用，例如phhalSpi.h和phhalSpi.c，但我找不到任何类似的内容。 它存在吗？我该如何找到它？ 感谢您的帮助。 Re: PN7642 SPI controller interface 您好，感谢您对我们产品的关注。 PN7642 确实提供了一套 SDK 示例。我不确定你是否已经导入了其中一些。     Fabian_R_1-1784755580455.png   如您所见，您可以直接从“快速入门”面板 -> “导入 SDK 示例”导入示例，然后搜索 SPI，如图所示。 请注意，OM27642EVK 具有从动引脚和引导引脚。另请参阅快速入门指南文档的第 7 部分。

AEC-Q100 MFS2613HMDA2AD 是否符合 AEC-Q100 标准？所有 FS26 零件编号都符合 AEC-Q100 标准吗？ 谢谢， 恩里科 Re: AEC-Q100 你好 ESof 再会！ 是的，整个 FS26 系列产品均符合 AEC-Q100 标准。证明这一点的文件属于机密文件，因此如果您需要该文件，我建议您直接与我们联系，看看我们能做些什么并开始签署保密协议的流程。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 由此给您带来的不便，我们深表歉意。 祝你今天过得愉快，一切顺利。