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 标准。证明这一点的文件属于机密文件，因此如果您需要该文件，我建议您直接与我们联系，看看我们能做些什么并开始签署保密协议的流程。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 由此给您带来的不便，我们深表歉意。 祝你今天过得愉快，一切顺利。

LX2160ARDB Default boot images Hi, Can anyone please suggest a way to get the default boot images been used in LX2160A-RDB-B board. Evaluation Board Re: LX2160ARDB Default boot images You could use the latest Layerscape Yocto BSP v26.06 The following precompiled images are hosted on https://www.nxp.com/lgfiles/llsdk/walnascar/ > 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img BSP firmware image for LX2160ARDB eMMC boot 15 firmware_lx2160ardb-rev2_uboot_sdboot.img BSP firmware image for LX2160ARDB SD boot 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img BSP firmware image for LX2160ARDB xSPI boot 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfs supports basic networking functionality on LX2160ARDB 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfs supports full networking functionality on LX2160ARDB 25 flex-installer Deploy tools 4 boot_lx2160ardb-rev2_lts_6.12.tgz Bootpartition image for LX2160ARDB Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf

PN7642 SPI controller interface SPI controller interface is mentioned in the PN7642 documents and PN7642.h, as well as on OM27642EVK (as SPIM) but that's all. I can't find an example or driver for that SPI controller (I don't mean Host SPI). AI search says that there are specific SPI function calls ,phhalSpi.h ,phhalSpi.c. , but I can't find anything even similar. Does it exist and how can I find it? Thanks for the help. Re: PN7642 SPI controller interface Hello, thank you for your interest in our products. PN7642 does have a set of SDK examples. I'm not sure if you have already imported some of them.     Fabian_R_1-1784755580455.png   As you are able to see, you can just import the examples from the Quick Start panel -> Import SDK examples and search for the SPI as shown in the image. Please keep in mind that OM27642EVK has Follower Pins and Leader Pins. Please also mind section 7 of the Quick Start Guide documentation.

AEC-Q100 MFS2613HMDA2ADはAEC-Q100規格に適合していますか？FS26のすべての部品番号はAEC-Q100規格に適合していますか？ ありがとう、 エンリコ Re: AEC-Q100 こんにちはESof 良い一日！ はい、FS26ファミリ全体がAEC-Q100の資格を持っています。これを証明するドキュメントは機密扱いなので、必要なら直接私たちにケースを開いて、何ができるか確認し、NDAの手続きを開始することをお勧めします。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 ご迷惑をおかけして申し訳ございません。 良い一日をお過ごしください。幸運を祈ります。

S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi Team, I am facing a random HardFault issue on an S32K358 running FreeRTOS. The application runs normally for a long duration and then suddenly hangs. After the system stops executing, the Software Watchdog (SWT) is not serviced and eventually resets the controller. The failure is not immediate—it occurs after approximately 1 to 2 hours of continuous execution When halted after the failure, the call stack shows: PendSV_Handler() ↓ HardFault_Handler() Register values: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5 looks like a memory initialization pattern rather than a valid return address. Other registers: R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 Any suggestions or debugging recommendations would be greatly appreciated. Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi @nirmal_masilamani, It looks like the task context saved during the FreeRTOS context switch has been corrupted. PendSV is used by FreeRTOS for context switching, therefore, if the HardFault occurs inside PendSV_Handler(), it often means the scheduler is attempting to restore an invalid task context. One possible root cause is a task stack overflow. I would recommend increasing the stack size of the tasks and enabling FreeRTOS stack overflow detection: configCHECK_FOR_STACK_OVERFLOW Implement: vApplicationStackOverflowHook(). Additionally, you can periodically monitor the remaining stack space of each task using uxTaskGetStackHighWaterMark(). This can help identify tasks that are running close to their stack limits before the fault occurs. Regards, Daniel Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hello @danielmartynek , Thank you for response, I already tried increased stack size, enabled stack overflow hook. Added debug CAN msg in overflow hook, I am not receiving that message when fault occur. Also monitoring uxTaskGetStackHighWaterMark(), when fault occur Task 1 : 1977 × 4 ≈ 7908 bytes free Task 2: 1971 × 4 ≈ 7884 bytes free Task 3: 3988 × 4 ≈ 15952 bytes free Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi @nirmal_masilamani, So we can probably exclude a stack overflow as the root cause. However, the task context is still getting corrupted. The processor is restoring LR = 0xA5A5A5A5, which results in a UsageFault. 0xA5A5A5A5 is the pattern generated from tskSTACK_FILL_BYTE (0xA5U) and is used by FreeRTOS to fill task stacks when they are created. danielmartynek_0-1784709240297.png Therefore, if LR becomes 0xA5A5A5A5, the context is restored from a location that still contains the original stack fill pattern rather than a valid register value. This could happen if the SP gets corrupted. In that case, PendSV_Handler() would restore the task context from a wrong location in RAM. You should be able to identify the SRAM region from the stack pointer address.  I would recommend that you properly protect the region by MPUs and XRDC.  Also, are any interrupts calling FreeRTOS APIs? If so, are they using the FromISR() variants, and are their priorities configured correctly with respect to configMAX_SYSCALL_INTERRUPT_PRIORITY? Regards, Daniel

S32K358 + FreeRTOS：PendSV_Handler 期间出现随机硬故障 大家好， 我在运行 FreeRTOS 的S32K358上遇到了随机硬故障问题。 应用程序长时间正常运行后突然卡死。系统停止运行后，软件看门狗（SWT）得不到服务，最终导致控制器重置。 故障并非立即发生，而是在连续执行约1 至 2 小时后出现。 故障停止后，调用堆栈显示： PendSV_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 ， 感谢您的回复。 我已经尝试过增加堆栈大小，启用堆栈溢出钩子。 我在溢出钩子中添加了调试 CAN 消息，但发生故障时没有收到该消息。 同时监控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，则上下文将从仍然包含原始堆栈填充模式的位置恢复，而不是从有效的寄存器值恢复。 如果存储过程损坏，就可能发生这种情况。在这种情况下，PendSV_Handler() 会从 RAM 中的错误位置恢复任务上下文。 你应该能够根据堆栈指针地址识别出 SRAM 区域。 我建议您使用 MPU 和 XRDC 对该区域进行适当保护。 另外，是否有任何中断调用 FreeRTOS API？如果是这样，他们是否使用了 FromISR() 变体，并且他们的优先级是否根据 configMAX_SYSCALL_INTERRUPT_PRIORITY 正确配置？ 此致， 丹尼尔