FS26 PMICのSN29500に基づくFIT率 FS26 PMICについてですが、SN29500-2に基づくFITレート値と、SN92500-2からどのテーブルが使われているかの詳細、部品カテゴリ+参照仮想Tj値などを教えていただけますか? 機能安全 Re: FIT rate based on SN29500 for FS26 PMIC これは公開されたドキュメントではありません。以下のリンクからチケットを提出してください: 家庭用

Getting started guide for NXP S32K144 - Automotive Hello, I am new to the NXP S32K144 series and need detailed instructions to set up my development environment. Could you please clarify:   Which version of S32 Design Studio is required? Whether I should install the standard SDK or the RTM/RTD drivers? What additional drivers or software packages are needed for this specific hardware series? S32K1 Re: Getting started guide for NXP S32K144 - Automotive Hi @Buddyn  We always recommend using the latest software releases and tool versions, especially if you are just getting started with the technology. For S32K1 devices, the latest software release is RTD 3.0.0, which was developed and validated with S32 Design Studio (S32DS) 3.6.6. However, based on my experience, it also works well with newer S32DS 3.6.x versions. Therefore, I would recommend downloading and using the latest available S32DS 3.6 release. This should be enough to get you started with the platform. Any additional software packages you may need will depend on your application's specific requirements. To explore other software packages and examples available for S32K1 devices, you can navigate to S32K1 Reference Software. BR, VaneB Re: Getting started guide for NXP S32K144 - Automotive For this RTD based software. Is there is any open-source firmware example for it. Does NXP has any reference or training sections for configurations (clock, pins, peripheral) in s32DS. If so, kindly share some reference link.  Thanks in advance

EB tresos error "Failed to verify license" and "The signature of file is invalid" I use EB tresos to config S32K344 base RTD version SW32K3_S32M27x_RTD_R21-11_4.0.0_P19SW32K3_S32M27x_RTD_R21-11_4.0.0_P19. But when generate, EB report error like below, about "Failed to verify license" and "The signature of file is invalid": I didn't modify the RTD files, so what might be the reason, how to solve that? Re: EB tresos error "Failed to verify license" and "The signature of file is invalid& Hi Please make sure that you didn't modify any file in the package, otherwise the modification will lead to license violation. You can also try to uninstall and install again. Also, make sure that you  are using EB Tresos Studio 29.0.0. S32K3 Standard Software -> Automotive SW - S32K3/S32M27x - Real-Time Drivers for Cortex-M -> S32K3_S32M27x Real-Time Drivers ASR R21-11 Version 4.0.0 P19 S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool -> EB tresos Studio 29.0.0 I haven't encountered any problems importing Hse_Ip_AesEncAsyncIrq_S32K344 and Wdg_Example_S32K344. Please check if the file SW32K3_S32M27x_RTD_R21-11_4.0.0_P19.link exists in the links folder under your EBTresos installation path. I have previously encountered cases where the presence of multiple versions of S32K3 RTD .link files in the links folder of certain EBTresos versions could cause errors. Best Regards, Robin

Is i.MX 9 "there yet"? I started a project in a few years ago and NXP's i.MX 9 line of MPUs were beginning to be released but they were largely unobtainable so I went with a beefy i.MX 8. At this stage, it's way more power than I need and I'd like to move to a much smaller MPU. I was planning on getting the smallest i.MX 8 but the i.MX91 is the smallest cpu they have. I was wondering if I would be better off with the 91 instead of a more mature 8. Thermals are my primary concern so I would assume new is always better, but I just don't know if they are "there yet" since they are still fairly new. A more apples to apples port moving to an 8 could also be a motivator. Re: Is i.MX 9 "there yet"? Hi @ceva156  What is the main purpose of your project? Which IMX8 series product are you currently using? B.R

VR5510：即使启用异步模式，I2C 看门狗刷新也会在 ISR 中阻塞——这是真正的非阻塞支持 您好，NXP团队， 我目前正在调试 VR5510 PMIC，遇到了与看门狗刷新相关的实时调度问题。 MCAL I2C 看门狗刷新（通过 I2C 向 VR5510 看门狗提供数据）的实现方式如下： 同步 手术。由于我们是在中断上下文中调用它，因此同步等待会阻塞 CPU，并降低其他任务的实时调度性能。 我注意到有一个 异步 驱动程序配置/代码中的选项。然而，实际上它仍然执行同步忙等待（它会阻塞并轮询，直到 I2C 传输完成），因此它实际上并没有将传输与调用者解耦。 我的问题： 是否有官方支持的方法可以刷新 VR5510 看门狗？ 真正无阻塞 （例如是否采用中断驱动或DMA驱动的I2C协议，以避免阻塞其他任务？ 如果异步选项预期是非阻塞的，那么当前的同步忙等待行为是已知的限制还是我的配置问题？ 任何指导、参考配置或示例代码都将不胜感激。 谢谢！ Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好， @Jerry_cao 感谢分享。 请问您指的是以下使用的 API 吗？ Std_ReturnType I2c_AsyncTransmit ( uint8 Channel, const I2c_RequestType ∗ RequestPtr ) “？ 使用的是哪个版本的RTD？ BR 陈银 Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好： 我的版本是：   * 项目：RTD AUTOSAR 4.4 * 平台：CORTEXM * 外设：VR5510 * 依赖项：无 * * Autosar 版本：4.4.0 * Autosar 版本：ASR_REL_4_4_REV_0000 * Autosar 配置变体： 软件版本：4.0.2 * 构建版本：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 版权所有 2020-2023 NXP 半导体 * 版权所有。 * 使用此函数 Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好： 我的版本是：   * 项目：RTD AUTOSAR 4.4 * 平台：CORTEXM * 外设：VR5510 * 依赖项：无 * * Autosar 版本：4.4.0 * Autosar 版本：ASR_REL_4_4_REV_0000 * Autosar 配置变体： 软件版本：4.0.2 * 构建版本：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 版权所有 2020-2023 NXP 半导体 * 版权所有。 * 使用此函数 Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好， @Jerry_cao 谢谢您的确认。 通过与相应代码核对，RTD5.0.0QLP04 中实现了VR5510 的 I2C 异步通信解决方案。 您可以在此版本 RTD 中查看相关代码以了解详细信息。 BR 陈银

VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking suppo Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for the post. May I know if you are referring to the following API used " Std_ReturnType I2c_AsyncTransmit (uint8 Channel,  const I2c_RequestType ∗ RequestPtr ) "?  Which version RTD is used? BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for your confirmation. By checking with the corresponding code, the VR5510 Solution for I2C asynchronous communication is implemented in RTD5.0.0QLP04 You may check the related code in this version RTD for details. BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog

i.MX 9 准备好了吗？ 几年前我开始了一个项目，当时 NXP 的 i.MX 9 系列 MPU 开始发布，但它们基本上无法获得，所以我选择了性能强大的 i.MX 8。现阶段，它的性能远远超过我的需求，我想换用性能小得多的微处理器。我原本打算买最小的 i.MX 8，但他们最小的 CPU 是 i.MX91。我一直在想，如果选择91型而不是更成熟的8型，会不会更好。散热是我最关心的问题，所以我认为新的总是更好，但我不知道它们是否已经“达到标准”，因为它们还比较新。更公平的比较，例如将港口升级到 8 级，也可能是一个激励因素。 Re: Is i.MX 9 "there yet"? 你好@ceva156 您的项目的主要目的是什么？您目前使用的是哪款IMX8系列产品？ BR

初心者が色選別カメラの製作に挑戦 私はより大きなプロジェクトのために色分け装置を作ろうとしていますが、この分野に関しては全くの初心者です。私は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 これは、空きメモリがほぼ枯渇した状態で継続的に使用した場合に、この問題が発生する可能性が高くなることを示唆している。

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

新手尝试制作颜色分类相机 我正在尝试为一个更大的项目制作一个颜色分拣器，但我在这方面基本上是个新手。我有一个 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 上重现此问题的步骤。 此致， 志明

サポート要件: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を成功裏に有効にした方がいれば、予想されるフローや追加設定について教えていただけますか? よろしくお願いいたします！ よろしくお願いいたします。 アルン・クマール

无法更新 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 ，能否分享一下预期流程或所需的任何其他配置？ 提前感谢！ 顺祝商祺！ 阿伦·库马尔

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