Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
初心者が色選別カメラの製作に挑戦 私はより大きなプロジェクトのために色分け装置を作ろうとしていますが、この分野に関しては全くの初心者です。私はESP32-S3R8マイクロプロセッサを持っていて、互換性のあるカメラに接続して、最終的には特定の色の物体が視界に入っているかどうかを検出したいと考えています。 主にどのカメラがこの用途に最適かを知りたいのですが、このプロジェクトに必要なことを学ぶためのヒントがあれば、ぜひ教えていただけると大変ありがたいです。 Re: Novice Trying to Make a Colour Sorting Camera こんにちは、 NXPポートフォリオを活用すれば、MCUとカメラインターフェースの使い方を指針として得られます。カメラインターフェースの導入を始めるための参考になります。 私が提示した選択肢の中で、OV7670カメラモジュール/カメラインターフェースを使っています。これは非常に頻繁に使われるカメラです。カメラインターフェースは色認識にも使えます。この情報は入門の導入として役立ちます。 このドキュメントでは、カメラソリューションの使い方、インターフェース、API設定、そしてデモを紹介しています。 MCX-N オプション: SmartDMAを用いてカメラインターフェースをMCXN236実装 LPC55 オプション: AN12868:LPC55(S)xxのカメラインターフェース |NXPセミコンダクターズ さらに、カメラの例に興味があれば、 Application Code Hubにカメラを使ったさまざまな検出例があります。 敬具、ルイス
記事全体を表示
GC7000 GPU ハング galcore タイムアウト 問題の概要 NavAppの実行中に、画面表示が完全にフリーズします。カーネルログの調査によると 、これは アプリケーションのクラッシュではなく 、 Vivante GC7000 GPU(Galcore)の ハム です。 観察結果: カーネルは30秒後に GPUタイムアウト を報告します(gpuTimeout = 30000)。 Galcoreは GPU状態ダンプを生成し、以下を呼び出します: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() 運転手は次のように報告します。 [ガルコア]:運転手を停止させて現場を維持しろ。 GPUの状態ダンプは複数のGPUブロックが詰まっていることを示しています: FEはアイドル状態ではない SHはアイドル状態ではありません TXはアイドル状態ではありません MCはアイドル状態ではありません DMAが停止しているようです ドライバ構成 現在のGalcore構成は以下のとおりです。 リカバリ = 0、GPUタイムアウト = 30000   GPUリカバリーが無効になっている(リカバリー=0)ため、ハングを検出するとドライバーは停止し、最後にレンダリングされたフレームだけが表示されるため、画面がフリーズする現象が確認されます。 GPUメモリの状態: GPUのメモリ統計はメモリの使い尽きを示し ません 。 総GPUメモリ:256MB 使用量:約155MB 無料:約113MB したがって、この問題はGPUのメモリ不足によるものではないようです。 GPUクライアント: GPUデータベースによると、ハング時点で NavAppだけがアクティブなGPUクライアント です。 GPUの状態ダンプは、以下の以下の人から提出された複数のコマンドバッファを参照しています: NavApp これは、NavAppが提出したレンダリングコマンドを実行している間にGPUのハングが発生したことを示しています。   応募スケジュール: アプリケーションログから、GPUがハングする直前に以下のシーケンスが観察されています。 連続的な地図のズームイン/ズームアウト操作 オフラインの地図/タイルアクセス 経路計算 ルート情報表示 GPUのタイムアウトと状態ダンプ GPUのハングは集中的なレンダリング作業の直後に発生します。 結論: 収集された証拠に基づくと: カー ネルパニック 、 OOM、 アプリケーション クラッシュ はありません。 この故障は、Galcoreのウォッチドッグによって検出された GPUコマンドプロセッシングのハング です。 ハングが発生した際はNavAppがレンダリングクライアントですが、GPUドライバー内で障害が観察されます。 GPUのメモリ使用量は制限内であり、リソースの枯渇を示しているわけではありません。 TVSチームへの調査依頼: Vivante GC7000 / Galcore GPUドライバーがレンダリング中にフリーズします。 この問題が既知のGPUドライバーかファームウェアの制限かは不明です。 GPUリカバリー(recovery=1)がこのプラットフォームでサポートされ推奨されているかどうか。 GPU状態ダンプの分析により、どのGPUコマンドまたはハードウェアブロックがタイムアウトを引き起こしたかを特定します。 BSPや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 こんにちは、 @Ram2さん EVK上でこの問題を再現するための手順を教えてください。 よろしくお願いします、 志明 Re: GC7000 GPU hang galcore timeout こんにちは@Zhiming_Liu 再現手順: 画面がフリーズする問題は、ランダムかつ断続的に発生するため、決まった再現手順はありません。しかし、利用可能なシステムメモリが非常に少なくなった場合(通常は60MiB未満)に発生する可能性が高いことが観察されています。 問題の再現性を高めるため、以下の活動を継続的に行いました。 長距離ルートを2~3本作成した。 ナビゲーションを開始し、約1分以内に終了しました。 ホーム、オフィス、ホテルのクイックアクションボタンを使って繰り返しルートを作成しました。 パン操作や頻繁なズームイン/ズームアウト操作を行い、地図上のさまざまな領域を探索した。 これらの作業中に、利用可能なメモリ容量が低レベルまで低下した際に、画面がフリーズする現象が確認された。例えば: メモリ容量:合計1709.5 MiB、空き容量55.8 MiB、使用容量1298.1 MiB、バッファ/キャッシュ容量567.2 MiB MiB スワップ: 合計 0.0、空き 0.0、使用済み 0.0、利用可能メモリ 411.4 これは、空きメモリがほぼ枯渇した状態で継続的に使用した場合に、この問題が発生する可能性が高くなることを示唆している。 Re: GC7000 GPU hang galcore timeout こんにちは@Ram2  NXPがリリースしたLinux BSPにはナビゲーションアプリは含まれていません。テスト用アプリとテスト手順書をご提供ください。 よろしくお願いします、 志明
記事全体を表示
NXPパートナーズ ウェブ検索の結果、TimeskeyはNXPのパートナー企業であることが分かった。Amazonで購入したNTAG213枚のRFIDタグステッカーは動作していましたが、NXP TagInfoのAndroidアプリでスキャンしたところ、IC製造元の情報は偽物で、おそらく偽物の製品であることが判明しました。私は使っているテクノロジの所有者をサポートしたいのです。NFCタグステッカーのような商品を購入する際、どうやって本物のNXP製品を確実に手に入れられますか? Re: NXP Partners お世話になります。 お元気でお過ごしでしょうか。偽造タグを受け取られたとのこと、大変申し訳ございません。 製品の真正性と品質を確保するために、NFCタグはNXPの認定パートナーを通じてのみ購入することを強くお勧めします。NTAG製品については、 NTAG 213/215/216 | NXP Semiconductors。 製品ページでは、エンジニアリングサービスのセクションまでスクロールすると、当社の認定パートナーおよび代理店のリストが見られます。 タグは、提携パートナーの公式ウェブサイトから直接ご購入いただくことをお勧めします。
記事全体を表示
恩智浦合作伙伴 网络查询结果显示,Timeskey 是 NXP 的合作伙伴。我在亚马逊上购买的 NTAG213 RFID 标签贴纸虽然可以正常工作,但用 NXP TagInfo 安卓应用程序扫描时显示 IC 制造商并非正品,很可能是假冒产品。我想支持我所使用的技术的拥有者。如何确保我购买的是正品 NXP 产品,例如 NFC 标签贴纸? Re: NXP Partners 您好,先生, 希望你一切都好。得知您收到了假冒标签,我深感遗憾。 为确保产品真实性和质量,我们强烈建议您仅通过恩智浦半导体授权合作伙伴购买NFC标签。有关NTAG产品,请访问NTAG 213/215/216 | 恩智浦半导体。 在产品页面上,向下滚动到“工程服务”部分,您将在那里找到我们授权合作伙伴和代理商的列表。 建议仅从我们合作伙伴的官方网站直接购买标签。
記事全体を表示
NXP Partners A web query replied that Timeskey was an NXP partner.  The NTAG213 RFID tag stickers I purchased on Amazon, while they worked, when scanned with the NXP TagInfo android app showed the IC Manufacturer to be Non-genuine, most probably counterfeit product.  I want to support the owner of the technologies I use.  How can I be sure I get genuine NXP product when purchasing items like NFC tag stickers? Re: NXP Partners Hello Sir, I hope you are doing well. I am sorry to hear that you received counterfeit tags. To ensure product authenticity and quality, we strongly recommend purchasing NFC tags only through NXP's authorized partners. For NTAG products, please visit the NTAG 213/215/216 | NXP Semiconductors. On the product page, scroll down to the Engineering Services section, where you will find a list of our authorized partners and distributors. It is recommended to only purchase the tags directly from our Partner's official websites.
記事全体を表示
Novice Trying to Make a Colour Sorting Camera I am attempting to make a colour sorter for a larger project, I am essentially a complete novice when it comes to this however. I have an ESP32-S3R8 microprocessor, and want to connect it to any compatibile camera to eventually detect when certain coloured objects are in its view. Mostly wondering what camera would be best for this, but if there are any tips for learning what I need for this project that would be greatly appreciated. Re: Novice Trying to Make a Colour Sorting Camera Hello, Using NXP portfolio we have information that could guide you in the use of camera interface with the MCUs, as for getting started in Camera Interfaces first. Between the options that I present, they use the OV7670 camera module/ Camera Interface, a very often use camera, The camera interface can be used as Color recognition, this information could be a start introduction. This documentation gives you introduction on using the camera solution, the interface and API configuration and also a demo. MCX-N option: Using SmartDMA to implement camera interface in MCXN236 LPC55 Option: AN12868: Camera Interface in LPC55(S)xx | NXP Semiconductors Additionally, if you are curious about more camera examples, there are examples for different detections using a camera in Application Code Hub, Best Regards, Luis
記事全体を表示
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
記事全体を表示
新手尝试制作颜色分类相机 我正在尝试为一个更大的项目制作一个颜色分拣器,但我在这方面基本上是个新手。我有一个 ESP32-S3R8 微处理器,想把它连接到任何兼容的摄像头,以便最终检测出某些颜色的物体何时出现在它的视野中。 我主要想知道哪种相机最适合这个项目,但如果能提供一些关于我需要哪些设备方面的建议,我将不胜感激。 Re: Novice Trying to Make a Colour Sorting Camera 你好, 利用 NXP 产品组合,我们拥有可以指导您如何使用 MCU 的摄像头接口的信息,以便您首先入门摄像头接口。 在我介绍的这些选项中,它们都使用了OV7670摄像头模块/摄像头接口,这是一款非常常用的摄像头。该摄像头接口可以用于颜色识别,这些信息可以作为初步介绍。 本文档将为您介绍如何使用摄像头解决方案、接口和 API 配置,并提供演示。 MCX-N选项:使用SmartDMA在MCXN236中实现摄像头接口 LPC55选件: AN12868:LPC55(S)xx 中的摄像头接口 | 恩智浦半导体 此外,如果您对更多摄像头示例感兴趣,可以在应用程序代码中心找到使用摄像头进行不同检测的示例。 此致敬礼,路易斯
記事全体を表示
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 电路板支持包。不包含导航应用程序。请提供测试应用程序和测试说明。 此致, 志明
記事全体を表示
サポート要件:i.MX8QXP C0 MEK – Yocto Scarthgapにおけるセキュアパーティションアクセスファイル破損問題 こんにちは、NXP チームの皆様、 i.MX8QXP C0 MEKで検出されたセキュアパーティション/ファイルシステムの問題について、皆様のサポートをお願いします。 以下のソフトウェアベースラインを使用しています。 商品詳細 プラットフォーム i.MX8QXP C0 MEK BSP Yocto Linux ヨクトリリース スカースギャップ カーネルバージョン 6.6.5 問題の説明: セキュアパーティションキーを正常に生成できました。しかし、Linuxファイルシステムからセキュアパーティションを使ったりアクセスしようとすると、アクセスが失敗します。場合によっては、アクセス/書き込み操作後にファイルが破損することもあります。 観察: エリアステータス 安全なパーティションキー生成 成功 生成されたキーを用いたファイルシステムアクセス 失敗する ファイル読み書き操作 不安定 ファイル整合性 ファイル破損が確認されました i.MX8QXPのYocto Linuxにおける安全なパーティションアクセスの推奨かつ正しい方法について教えていただけますか? 以下の点について、皆様のご意見をお聞かせください。 i.MX8QXP上でYocto Linuxでセキュアパーティションを作成、フォーマット、マウント、アクセスする推奨方法は何ですか? セキュアパーティションの使用に推奨される特定のファイルシステムの種類はありますか? カーネル設定、デバイスツリー、OP-TEE、またはYoctoレイヤーの変更は必要ですか? NXP社製のセキュアパーティション処理に関するリファレンス実装やドキュメントはありますか? 生成されたセキュアキーを使うために、ファイルシステムアクセスの失敗やファイル破損を避けて正しいフローは何でしょうか? 適切な実施方法について、ご検討の上、ご提案いただけますでしょうか。 Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart こんにちは、 BSPのドキュメントを参照してください。この特定のLinuxリリースは当社のリリースに見つからないので、最も近いものを参照することをお勧めします。 つまり、カーネル 6.6.23i.MX Linuxユーザーガイド 第10.5章 ディスク暗号化加速 ファイルシステムではテストにext4を使用しているので、この方法を使うことをおすすめします。必要なカーネル設定や実際の手順についてはドキュメントをご覧ください。 よろしくお願いいたします。 アルド。
記事全体を表示
i.MX95 FlexSPIブートイメージ用のAPPコンテナソフトウェアバージョンを更新できません こんにちは、専門家の皆様。 i.MX95プラットフォームの開発を進めており、ROLLBACK_INDEX_IN_CONTAINERを使ってロールバック保護を有効にしています。 local.confに以下の変数を追加しました。 export ROLLBACK_INDEX_IN_CONTAINER = "1" この値はビルドプロセス全体に伝播され、ビルドログにはmkimage_imx8が「1」で呼び出されたことが記録されています。 eMMCブートイメージを構築する際、生成されたイメージを解析するとコンテナソフトウェアのバージョンが正しく更新されていることが確認されます。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   しかし、FlexSPIのブートイメージ(imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi)を構築する際には、画像を解析してもデフォルトのソフトウェアバージョンが報告されます ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 iMX95/soc.mak で興味深い点に気づきました。flash_a55_flexspi のビルド時に sw_version が含まれていないのです。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 私の質問は以下のとおりです。 FlexSPIのブートイメージのソフトウェアバージョンを更新するROLLBACK_INDEX_IN_CONTAINER期待されていますか? FlexSPIイメージは、ロールバックインデックスやソフトウェアバージョンを別々に設定する必要がある別のコンテナ生成フローに従っているのでしょうか? これは、i.MX95のimx-mkimageビルドフローにおける既知の制限事項または問題でしょうか? もしi.MX95でFlexSPIブートイメージのROLLBACK_INDEX_IN_CONTAINERを成功裏に有効にした方がいれば、予想されるフローや追加設定について教えていただけますか? よろしくお願いいたします! よろしくお願いいたします。 アルン・クマール Re: Unable to update APP container software version for i.MX95 FlexSPI boot image こんにちは、@arun16598さん FlexSPIイメージはAHABフォーマットの別のバリエーションではなく、まずブートコンテナを生成し、次にU-Boot/ATFコンテナを追加するという複合的なプロセスを採用しています。あなたの-sw_version 1はu-boot-atf-container.imgに設定されています。ただし、flash_a55_flexspiが最初に作成するSM/M33、OEI、SPL、FCBを含むAPPコンテナは-sw_versionオプションを通さないため、そのコンテナは依然としてSWバージョン0を表示します。ROLLBACK_INDEX_IN_CONTAINERはセカンダリのU-Boot/ATF APPコンテナを生成するために使われますが、flash_a55_flexspiが作成したプライマリAPPコンテナには渡されません。最初のFlexSPI APPコンテナに同じソフトウェアバージョンが必要な場合は、flash_a55_flexspiのmkimage_imx8呼び出しに-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)を追加する必要があります。 真の AHAB アンチロールバックの強制が目的であれば、確認および設定すべき重要な設定はsw_versionだけでなくfuse_versionと-fuse_versionです。S PSDKのi.MX95アンチロールバックの例では、OEMアンチロールバックはAHABコンテナYAMLで指定されたfuse_versionを使用し、そのバージョンはその後ELEのOEM_FW_FUSEコミットプロセスを介して送信されることが明確に示されています。 よろしくお願いします、 志明
記事全体を表示
无法更新 i.MX95 FlexSPI 启动映像的 APP 容器软件版本 各位专家好, 我正在使用 i.MX95 平台,并启用ROLLBACK_INDEX_IN_CONTAINER 的回滚保护功能。 我在local.conf文件中引入了以下变量: export ROLLBACK_INDEX_IN_CONTAINER = "1" 该值会在整个构建过程中传递,构建日志证实mkimage_imx8被调用时使用了“1”。 构建eMMC 启动映像时,解析生成的镜像显示容器软件版本已正确更新。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   然而,在构建FlexSPI 启动镜像( imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi )时,解析该镜像仍然报告默认的软件版本。 ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 我在 iMX95/soc.mak 中注意到一个有趣的地方,因为在构建 flash_a55_flexspi 时没有包含 sw_version。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 我的问题是: ROLLBACK_INDEX_IN_CONTAINER是否预期会更新 FlexSPI 启动映像的软件版本? FlexSPI 镜像是否遵循不同的容器生成流程,需要单独配置回滚索引/软件版本? 这是 i.MX95 imx-mkimage版本流程中已知的限制或问题吗? 如果有人已成功在 i.MX95 上为 FlexSPI 启动映像启用ROLLBACK_INDEX_IN_CONTAINER ,能否分享一下预期流程或所需的任何其他配置? 提前感谢! 顺祝商祺! 阿伦·库马尔 Re: Unable to update APP container software version for i.MX95 FlexSPI boot image 你好@arun16598 FlexSPI 镜像不是 AHAB 格式的另一种变体,而是采用了一种组合过程,即先生成引导容器,然后附加 U-Boot/ATF 容器。您的-sw_version 1已在u-boot-atf-container.img上设置;但是,包含 SM/M33、OEI、SPL 和 FCB 的 APP 容器( flash_a55_flexspi首先创建)没有传递-sw_version选项,因此该容器仍然显示SW 版本:0。ROLLBACK_INDEX_IN_CONTAINER用于生成辅助 U-Boot/ATF APP 容器,但它没有传递给flash_a55_flexspi创建的主 APP 容器。如果第一个 FlexSPI APP 容器需要相同的软件版本,则还必须将-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)添加到flash_a55_flexspi中的 mkimage_imx8 调用中。 如果目标是真正实现 AHAB 防回滚强制执行,则需要验证和配置的关键设置是fuse_version和-fuse_version ,而不仅仅是sw_version 。S PSDK 的 i.MX95 防回滚示例明确指出,OEM 防回滚使用 AHAB 容器 YAML 中指定的fuse_version ,然后通过 ELE 的OEM_FW_FUSE提交过程提交该版本。 此致, 志明
記事全体を表示
Unable to update APP container software version for i.MX95 FlexSPI boot image Hello Experts, I'm working on the i.MX95 platform and enabling rollback protection using ROLLBACK_INDEX_IN_CONTAINER. I introduced the following variable in my local.conf: export ROLLBACK_INDEX_IN_CONTAINER = "1" This value is propagated through the build, and the build log confirms that mkimage_imx8 is invoked with "1" When building an eMMC boot image, parsing the generated image shows the container software version updated correctly.  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   However, when building the FlexSPI boot image (imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi), parsing the image still reports the default SW version ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 I noticed an interesting thing in iMX95/soc.mak as there is no sw_version included during the build for flash_a55_flexspi flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) My questions are: Is ROLLBACK_INDEX_IN_CONTAINER expected to update the software version for FlexSPI boot images? Does the FlexSPI image follow a different container generation flow where the rollback index/software version must be configured separately? Is this a known limitation or issue in the i.MX95 imx-mkimage build flow? If anyone has successfully enabled ROLLBACK_INDEX_IN_CONTAINER for FlexSPI boot images on i.MX95, could you please share the expected flow or any additional configuration required? Thanks in advance! Best Regards, Arun Kumar Re: Unable to update APP container software version for i.MX95 FlexSPI boot image Hi @arun16598  The FlexSPI image is not another variant of the AHAB format, but it employs a combined process of first generating the boot container, then appending the U-Boot/ATF container. Your -sw_version 1 is set on u-boot-atf-container.img; however, the APP container containing SM/M33, OEI, SPL, and FCB—which flash_a55_flexspi creates first—does not pass the -sw_version option, so that container still displays SW version: 0. ROLLBACK_INDEX_IN_CONTAINER is used to generate the secondary U-Boot/ATF APP container, but it is not passed to the primary APP container created by flash_a55_flexspi. If the same software version is required for the first FlexSPI APP container, -sw_version $(ROLLBACK_INDEX_IN_CONTAINER) must also be added to the mkimage_imx8 invocation in flash_a55_flexspi. If the goal is true AHAB anti-rollback enforcement, the key settings to verify and configure are fuse_version and -fuse_version, not just sw_version. The SPSDK’s i.MX95 anti-rollback example clearly states that OEM anti-rollback uses the fuse_version specified in the AHAB container YAML, and the version is subsequently submitted via the ELE’s OEM_FW_FUSE commit process. Best Regards, Zhiming
記事全体を表示
需要支持:i.MX8QXP C0 MEK 上的安全分区访问文件损坏问题 – Yocto Scarthgap 您好,NXP团队: 我们需要您协助解决在i.MX8QXP C0 MEK上发现的安全分区/文件系统问题。 我们采用以下软件基线: 商品详情 平台 i.MX8QXP C0 MEK BSP Yocto Linux Yocto 版本 斯卡斯盖普 内核版本 6.6.5 问题描述: 我们已成功生成安全分区密钥。但是,当我们尝试从 Linux 文件系统使用/访问安全分区时,访问失败。在某些情况下,文件在访问/写入操作后也会损坏。 观察: 区域状态 安全分区密钥生成 成功的 使用生成的密钥访问文件系统 失败 文件读/写操作 不稳定 文件完整性 发现文件损坏 请问您能否帮助我们了解在 Yocto Linux for i.MX8QXP 中处理安全分区访问的推荐和正确方法? 我们需要您就以下几点提供指导: 在 i.MX8QXP 上的 Yocto Linux 中,创建、格式化、挂载和访问安全分区的推荐方法是什么? 对于安全分区,是否有推荐的特定文件系统类型? 是否需要对内核配置、设备树、OP-TEE 或 Yocto 层进行任何更改? NXP是否有任何关于安全分区处理的参考实现或文档? 如何正确使用生成的安全密钥,才能避免导致文件系统访问失败或文件损坏? 请您审阅并提出正确的实施方案。 Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart 你好, 您可以参考我们的 BSP 文档,但我无法在我们的版本列表中找到这个特定的 Linux 版本,因此我建议您参考最接近的可用版本。 例如,内核 6.6.23 i.MX Linux 用户指南第 10.5 章磁盘加密加速 对于文件系统,我们在测试中使用 ext4,所以我建议也使用 ext4,请查看文档了解所需的内核配置和实际操作步骤。 此致敬礼/Saludos, 阿尔多。
記事全体を表示
Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scarthgap Hi NXP Team, We need your support regarding a secure partition/file system issue observed on i.MX8QXP C0 MEK. We are using the below software baseline: Item Details Platform i.MX8QXP C0 MEK BSP Yocto Linux Yocto Release Scarthgap Kernel Version 6.6.5 Issue Description: We are able to generate the secure partition key successfully. However, when we try to use/access the secure partition from the Linux file system, the access fails. In some cases, the file also gets corrupted after access/write operations. Observation: Area Status Secure partition key generation Successful File system access using the generated key Failing File read/write operation Not stable File integrity File corruption observed Could you please help us understand the recommended and correct way to handle secure partition access in Yocto Linux for i.MX8QXP? We need your guidance on the below points: What is the recommended method to create, format, mount, and access a secure partition in Yocto Linux on i.MX8QXP? Is there any specific file system type recommended for secure partition usage? Are any kernel configuration, device tree, OP-TEE, or Yocto layer changes required? Is there any NXP reference implementation or document available for secure partition handling? What is the correct flow to use the generated secure key without causing file system access failures or file corruption? Request you to please review and suggest the correct implementation approach. Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart Hello, You may refer to our BSP documentation, I cannot find this specific Linux release in our releases, so I may recommend to refer to the closest one available. i.e kernel 6.6.23 i.MX Linux User's Guide chapter 10.5 Disk encryption acceleration For the file system we use ext4 for our testing so I would recommend using this one, please have a look to the documentation for the kernel configuration needed and the actual steps to follow. Best regards/Saludos, Aldo.
記事全体を表示
Example SJA1110 FreeRTOS lwIP S32G-VNP-RDB2 S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board S32G-VNP-RDB2 * to enable ping from the command window, from all applicable ports * *ping 192.168.0.210 * *Pinging 192.168.0.210 with 32 bytes of data: *Reply from 192.168.0.210: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.210: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - SW10[1]: On, SW10[2]: Off * - SW12[1]: On, SW12[2]: Off * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Changed IP address to 192.168.0.210 * - Added DIO * - Added nvm_metadata * - MAC learning is disabled * - The example includes two flash images for Port 4 SGMII speed * configuration towards the S32G: * - flash_image_2G5.bin (tested) * - flash_image_1G.bin (not tested) * * main.c * - Updated only the header * device.c * - Added LED routines * test.c * - Removed code that shuts down the TCP/IP stack after its predefined timeout * - Added debug stuff * - Commented out the code that initializes 2nd switch * * ----------------------------------------------------------------------------- * Test HW: S32G-VNP-RDB2 REV E * MCU: SJA1110A * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
[i.MX95/AAOS16]ブリングアップ支援 ハードウェア: i.MX95 15x15 SW: AAOS16_1.3.0 ほぼすべてのファイルにパッチを適用しました。 しかし、カーネル起動の問題は依然として残っている。 リチャード・キムのサポートが必要です。 Re: [i.MX95/AAOS16] Bringup support こんにちは、 @Jaeheon-Sim_Mobis さん、 改訂版ガイドラインを添付いたしましたのでご確認ください。 また、パッチされたすべてのファイルを正しいディレクトリ構造で添付しているので、ソースツリーで直接上書きできるようにしています。 よろしくお願いします。
記事全体を表示
MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello, I am investigating WUU wake-up behavior from Deep Power-Down mode on the FRDM-MCXA266 board. Environment: - MCU: MCXA266 - Board: FRDM-MCXA266 - SDK Example project: frdmmcxa266_power_mode_switch_ll_mcxa - SDK version: 26.6.000 - Development environment: MCUXpressoIDE_25.6.136 I added the following code near the beginning of main() to read the reset and wake-up status before BOARD_InitHardware() is called. /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); The complete relevant output is: ``` Normal Boot. ########################### Power Mode Switch Demo ########################### Core Clock = 240000000Hz Power mode: Active Select the desired operation Press A to enter: Active mode Press B to enter: Sleep mode Press C to enter: DeepSleep mode Press D to enter: PowerDown mode Press E to enter: DeepPowerDown mode Waiting for power mode select... Deep Power Down: The whole VDD_CORE voltage domain is power gated. Please select wakeup source: Press A to select TIMER as wakeup source; Press B to select WAKE-UP-BUTTON as wakeup source; Waiting for wakeup source select... Wakeup Button Selected As Wakeup Source. Please press SW2 to wakeup. Isolate power domains: VDD_USB. CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 Normal Boot. ``` At the initial startup, the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 I then selected Deep Power-Down mode, selected WAKE-UP-BUTTON as the wake-up source, and pressed SW2. The MCU successfully woke up, and the application restarted, but the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 My interpretation of the CMC reset status is: - 0x00004010: Software Reset + Warm Reset - 0x00004011: Software Reset + Warm Reset + Deep Power-Down Wake-up Reset If this interpretation is correct, the sticky status appears to indicate that a Deep Power-Down wake-up reset occurred first, followed by a software warm reset. I checked the application startup code, system_MCXA266.c, and the example sources, but I could not find NVIC_SystemReset(), SYSRESETREQ, or an SCB->AIRCR write. I also added a counter to SystemInitHook() using a retained NOLOAD variable. SystemInitHook() was executed only once after wake-up, so I could not find evidence of a software reset after SystemInit(). My questions are: Is SRS = 0x4010 and SSRS = 0x4011 expected after a WUU wake-up from Deep Power-Down? Does the MCXA266 Boot ROM or Extended Bootloader issue a software warm reset before the application starts? What is the recommended method for identifying which WUU pin caused the Deep Power-Down wake-up? My current interpretation of the CMC reset status is as follows, but please correct me if I have misunderstood the bit definitions: English is not my first language, so please let me know if any part of my explanation is unclear. Thank you. MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @ka-2020  Thanks for your question. I will reproduce the test on my side using the same setup and investigate the behavior. Once I have the results, I will get back to you with my findings and answers to all of your questions. Thank you for your patience and support. BR Alice
記事全体を表示
HSEをインストールしたS32K311:ソフトウェアクラッシュとMCUリセット、デバッガの接続ができません NXPチームの皆様、こんにちは。 バックグラウンド: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE FW (フルメモリ): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 詳細な調査報告書はPDFファイルで添付されています。 主な争点 ソフトウェアがクラッシュし、MCUはClock_Ip_DistributePll()でリセットされます。さらに、デバッガーが接続できない場合もあります。 デバッガをホットアタッチしようとした際、リセット理由としてHSE_CLK_FAILが報告されることがありました。 上記の手順、IVTおよびDCFの記録を確認し、この問題がなぜ起こっているのか、その解決策についてもご確認いただけますか。追加情報が必要な場合はお知らせください。 HSEの設置手順、IVTの設定、DCF記録を確認し、なぜこの問題が発生しているのか、またどのように解決できるのか教えていただけますか? 追加情報が必要な場合はお知らせください。 よろしくお願いします、 シュバム・パルデシ Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 70秒と20秒は、リセットからHSE_STATUS_INIT_OKまでの時間です。つまり、基本的に起動時間だけが含まれているということですね? どのデバイスでも同じように動作しますか? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach こんにちは、 @davidtosenovjan 当社のソフトウェアはFBLとAPPLで構成されており、どちらも同じ機能リセット機構を使用しています。 APPLがリセットを開始すると、この問題は発生しません。 FBLがリセットを開始すると、Clock_Ip_DistributePll()内でAPPL起動時にソフトウェアがクラッシュします。 当初は、Mcu_InitClock() の後、Mcu_DistributePllClock() の前に HSE_STATUS_INIT_OK のチェックを追加しました。これにより墜落は回避された。しかし、HSE_STATUS_INIT_OKが設定されるまでには約20秒かかり、その後、実際のAPPLの起動が続行されました。 本日、添付のスクリーンショットに示すように、HSE_STATUS_INIT_OK チェックを APPL の Mcu_Init() より前の段階に移動しました。 この手順を実行すると、HSE_STATUS_INIT_OKがほぼ即座に設定され、クラッシュは発生しなくなります。 以下の点を明確にしていただけますか? FBLとAPPLは同じリセットメカニズムを使用しているにもかかわらず、なぜこの問題はFBLによってリセットが開始された場合にのみ発生するのでしょうか? Mcu_InitClock() の後に HSE_STATUS_INIT_OK をチェックすると約 20 秒かかるのに、Mcu_Init() の前にチェックするとほぼすぐに利用可能になるのはなぜですか? FBLではHSE_STATUS_INIT_OKチェックが不要なのに、APPLの起動時には必要となるのはなぜですか? 明確な根本原因の説明と推奨される初期化手順を提示してください。現在のソリューションが堅牢であり、本番環境で問題を引き起こさないことを確認する必要があります。 追加の詳細情報や時計の設定に関する詳細情報が必要な場合はお知らせください。 よろしくお願いします、 シュバム・パルデシ
記事全体を表示
Regarding 8M Plus Real time Accuracy Hi,  We would like to lean more about 8M Plus capabilities regarding its real-time applications. Are there any test reports or related materials available concerning TSN or real-time performance, or jitter? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy Area Available material What it contains Real-time CPU/RTOS latency Harpoon User’s Guide Measured real-time latencies on i.MX 8M Plus / Zephyr , including IRQ latency and task latency in ns. Example results: no-load IRQ latency min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns ; task latency = 2,583 / 2,671 / 13,041 / 6,045 ns . Under Linux CPU + memory load, IRQ latency = 625 / 798 / 4,250 / 4,674 ns , and task latency = 2,583 / 2,670 / 14,333 / 10,407 ns . Real-time benchmark method Harpoon User’s Guide — rt latency application Defines the benchmark as the time delta between hardware IRQ events and software actions, measured with a hardware timer and sub-microsecond precision. TSN capability i.MX 8M Plus product / reference material i.MX 8M Plus includes dual Gb Ethernet, with one Ethernet supporting TSN, and uses the integrated 800 MHz Arm Cortex-M7 for industrial real-time control. TSN hardware standards i.MX 8M Plus Reference Manual TSN support includes IEEE 802.1Qbv Time-Aware Shaper , 802.1Qav Credit-Based Shaper , IEEE 1588v2 PTP , and the Ethernet block implements 802.1Qbv-2015 , 802.3br , and 802.1Qbu frame preemption-related TSN functions. TSN test / validation environment Real-Time Edge User Guide Describes a TSN test environment for evaluating i.MX 8M Plus TSN capabilities, including traffic generation/analysis and monitoring of latency, jitter, and synchronization accuracy. TSN jitter / latency example Real-Time Edge User Guide — TSN endpoint sample app Provides TSN endpoint statistics including traffic latency min/mean/max and notes latency around 503 µs with latency jitter around 300 ns in the shown example. TSN application demo AN13588 Demonstrates a GenAVB/TSN real-time control application. It describes a 2 ms cycle , a 400 µs reserved/guaranteed control-traffic window , and a statistics thread for scheduling, processing timing, traffic correctness, and latency. TSN 802.1Qbv demo AN13995 Demonstrates TSN 802.1Qbv using i.MX 8M Plus and explains how time-aware shaping uses fixed repeating cycles to provide deterministic latency; it also includes Linux  tc  /  taprio  configuration examples.   Re: Regarding 8M Plus Real time Accuracy @yipingwang  Thank you for providing the information. Could you also please provide us with information about the iMX8M Plus EVK? Thanks. Re: Regarding 8M Plus Real time Accuracy We understand that no public "real-time performance report" has been officially released for i.MX95 EVK. However, NXP does internally perform real-time benchmarking on i.MX95 platforms. Internal benchmark documents indicate that cyclictest and EtherCAT performance evaluations have been executed on i.MX95 LPDDR5 EVKs running Real-Time Edge software with PREEMPT_RT Linux. Reported examples include a maximum cyclictest latency of approximately 38 µs during a 6-hour stress-ng test and EtherCAT filtered maximum jitter of approximately 12 µs under the documented test conditions. Because real-time performance depends strongly on BSP version, kernel configuration, CPU isolation, workload, and network traffic, these values should be considered reference measurements rather than guaranteed application-level limits.   Please refer to https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf as supported benchmarking platforms and provide detailed cyclictest, stress, and rt_latency procedures. Re: Regarding 8M Plus Real time Accuracy Our distributor informed us that there is currently no official performance report available for the NXP i.MX95 EVK regarding real-time performance or jitter. However, they also provided documentation describing the testing methodology (e.g., cyclictest) for evaluating real-time latency. This leads to some confusion on our side. Since a standardized testing methodology exists, we assume that such tests must have been performed internally—at least on the reference EVK platform. Therefore, we would like to clarify: Has NXP conducted any internal measurements of real-time performance (e.g., latency, jitter) on the i.MX95 EVK? If so, are there any reference or baseline results that could be shared? We understand that real-time performance may vary depending on system configuration and workload. However, even a baseline result under controlled conditions (e.g., default BSP, minimal load) would be very helpful for initial evaluation. Thank you for your support. Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (Real-Time Edge Software User Guide) (https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) . Real-Time Edge Software (most relevant) NXP's Real-Time Edge Software officially supports the i.MX8M Plus EVK and includes: PREEMPT_RT Linux TSN stack IEEE 802.1AS (gPTP) synchronization TSN traffic shaping and scheduling EtherCAT, OPC-UA, CAN-related industrial protocols Heterogeneous real-time operation using Cortex-A53 + Cortex-M7 The internal document REALTIMEEDGEUG states that Real-Time Edge Software provides: Real-time networking (TSN) Real-time Linux (PREEMPT_RT) Pure RTOS/Bare-metal options Jailhouse partitioning Industrial protocol support Support for i.MX 8M Plus LPDDR4 EVK NXP Application Note AN13995 – TSN 802.1Qbv Demonstration using i.MX 8M Plus The Real-Time Edge Six Pack materials describing PREEMPT_RT + TSN support Re: Regarding 8M Plus Real time Accuracy @yipingwangThank you very much for the information you provided.
記事全体を表示