Generative AI Adoption: Transforming Businesses Through Intelligent Innovation Generative Artificial Intelligence (GenAI) is rapidly changing how businesses operate, innovate, and interact with customers. From automated content creation and intelligent chatbots to advanced data analysis and AI-powered applications, Generative AI is becoming an important part of modern digital transformation. However, successful AI adoption is not simply about implementing new technology. It is about identifying the right business opportunities, understanding organizational challenges, and creating measurable value. The Growing Adoption of Generative AI Organizations across industries are exploring Generative AI to improve productivity, reduce operational costs, accelerate decision-making, and deliver personalized customer experiences. According to EY's 2025 India C-suite survey, 47% of organizations reported having multiple Generative AI use cases in production. This indicates a shift from initial experimentation towards practical business implementation. Some of the key areas of adoption include: Business Automation: Automating repetitive tasks, workflows, and operational processes. Customer Experience: Developing intelligent virtual assistants and personalized customer interactions. Content Generation: Creating marketing content, reports, product descriptions, and business communications. Data Intelligence: Extracting insights from large datasets and supporting informed decisions. Software Development: Accelerating coding, testing, documentation, and application development. The Challenges Behind AI Adoption Despite its potential, businesses face several challenges when adopting Generative AI. Data privacy, model accuracy, integration complexity, infrastructure costs, and responsible AI governance remain important considerations. Organizations must also ensure that AI-generated outputs are reliable, transparent, and aligned with business requirements. Human oversight and continuous evaluation are essential for building trust in AI-powered systems. Research-Driven Generative AI Adoption At Enaviya, we believe successful Generative AI adoption begins with research, business understanding, and the right technology strategy. From a research and technology perspective, it is important to study how emerging AI models can address real-world business problems. This includes evaluating large language models (LLMs), exploring domain-specific AI applications, understanding automation opportunities, and assessing the practical impact of AI integration. Enaviya focuses on translating these opportunities into scalable business solutions through Generative AI development, LLM integration, AI agents, custom AI applications, and intelligent automation. A research-driven approach helps organizations move beyond experimenting with AI tools and focus on solutions that deliver measurable business outcomes. Please share your feedback in this thread.

更新和构建 S32K344 应用程序代码中心示例时出错 我正在尝试按照这个演示教程操作 FRDM S32K344 板： https://mcuxpresso.nxp.com/appcodehub?search=dm-adc-profiling-freemaster-s32k344 我已经安装了正确的软件依赖项，但是当我尝试点击“更新代码并版本项目”时，出现以下错误。我已经尝试重启我的电脑和S32DS，重新创建一个新的工作区，并检查了其他扩展程序，但都无法解决这个错误。非常感谢您的支持！ Re: Errors Updating & Building S32K344 App Code Hub Example 您好， 示例说明指出，此示例是使用 FRDM Automotive Bundle for S32K3 + S32M27 开发的。 以下列出的驱动程序并非全部都在本示例中使用。但是，至少以下两个软件包必须正确安装在 S32DS 3.6.8 中。加载演示之前： S32K3 实时驱动程序 AUTOSAR 4.9，版本 7.0.1 S32K3 FreeMASTER 驱动程序 请确保这些软件包已正确安装在您的 S32DS 3.6.x 版本中。环境。 驱动程序安装成功后，即可从 ACH 正常加载给定的示例，并执行 UpdateCode 和版本命令。 BR，彼得   Re: Errors Updating & Building S32K344 App Code Hub Example 更正我之前的回复。为了使 S32K344 演示环境正常运行，需要进行以下设置更改： 下载所需的软件包和 Design Studio 更新站点 ZIP 文件。 在 S32DS 3.6.x 中，打开扩展和更新 → 添加更新站点。 添加每个 ZIP 文件，关闭“添加更新站点”对话框，选择可用元器件，然后单击“安装” 。 安装完成后重启S32DS。 在安装任何 RTD 相关软件包之前，请先安装完整的 S32K3/S32M27x RTD 7.0.1 基本软件包。 创建项目时请使用 GCC 10.2 工具链。 工作包内含： S32K3xx 开发包 S32K3 FreeMASTER 串行通信驱动程序 S32K3 RTD AUTOSAR R23-11 版本 7.0.1 S32K3_S32M27x RTD AUTOSAR R23-11 版本 7.0.1 S32K3XX RTD AUTOSAR R23-11 版本 7.0.1 AMMCLIB 适用于 S32K3xx/S32M27x，RTD 相关 适用于 S32K3xx 的 FreeRTOS 重要提示： QLP06/P02 是一个附加软件包，而不是完整的 RTD。请勿单独安装 QLP06/P02。首先安装基本 RTD 软件包，然后仅在需要时才安装 QLP06/P02。单独安装会产生以下结果： 缺少必需依赖项：com.nxp.RTD.S32K3_S32M27X 0.0.0 对于这个特定的 S32K344 演示，所需的最低软件包是基本的 S32K3 RTD 7.0.1 软件包和 S32K3 FreeMASTER 驱动程序。其他软件包是更大软件包的一部分，或者可能是项目依赖项所必需的。本 S32K344 演示不需要 K39xx RTD 软件包。 Re: Errors Updating & Building S32K344 App Code Hub Example 你好，彼得。 非常感谢您的回复。我按照您的指示操作，但在 K39xx R23-11 RTD 软件包上收到以下错误： 演示真的需要这个吗？因为软件包里只提到了 S32K3 9 x，而没有提到 S3K3 4 x。 最好的， Andrew Re: Errors Updating & Building S32K344 App Code Hub Example 您好， 我理解您对RTD包装编号和描述的疑虑。 您也说得对，7.0.1.QLP5/6/P02 是包含加密驱动程序的附加软件包。这些软件包必须安装在基础 S32K3 RTD 7.0.1 软件包之上。 但是，ACH 演示会引导您使用汽车软件包管理器和FRDM 汽车 S32K3 + S32M27 板安装包。如果您选择实时驱动程序 7.0.1 ，你可以看到它所代表的确切文件。 如果允许软件包管理器生成捆绑安装程序，它将选择正确的软件包进行安装。没错，并非所有这些软件包对于这个特定示例都是必需的；如前所述，只需要 RTD 和 FreeMASTER 驱动程序。 如果在软件库中找到了所需的文件，请在软件包管理器中搜索显示的确切名称，以识别正确的软件包。 关于 S32K3 RTD 7.0.1 软件包的安装，它包含四个驱动程序。本 S32K344 ADC 示例不需要 S32K39x 和 S32M27x 驱动程序。但是，强烈建议安装所有四个驱动程序，主要是因为未来的更新可能取决于基础软件包。 BR，彼得  

生成型AIの導入：インテリジェントなイノベーションを通じてビジネスを変革する 生成型AI、マシン・ラーニング（機械学習）(GenAI)は、企業の運営方法、イノベーション、お客様との関わり方を急速に変えています。自動コンテンツ作成やインテリジェントチャットボットから高度なデータ分析、AI搭載アプリケーションに至るまで、生成AIは現代のデジタルトランスフォーメーションにおいて重要な一部となりつつあります。 しかし、AIの導入を成功させるには、単に新テクノロジを導入することだけではありません。それは、適切なビジネスチャンスを見極め、組織的な課題を理解し、測定可能な価値を創造することに関わる。 生成型AIの普及拡大 業界の組織が生産性向上、運用コスト削減、意思決定の迅速化、パーソナライズされたお客様体験の提供のために生成AIを模索しています。 EYの2025年インドCスイート調査によると、47%の組織が複数の生成AIのユースCASEを本環境で抱えていると報告しています。これは、初期の実験段階から、実際のビジネスへの導入へと移行していることを示している。 導入の主な分野には以下のようなものがあります。 ビジネスオートメーション:繰り返しの作業、ワークフロー、運用プロセスの自動化。 お客様体験:インテリジェントなバーチャルアシスタントとパーソナライズされた顧客対応の開発。 コンテンツ生成:マーケティングコンテンツ、レポート、製品説明、ビジネスコミュニケーションの作成。 データインテリジェンス：大規模データセットから洞察を抽出し、情報に基づいた意思決定を支援する。 ソフトウェア開発: コーディング、テスト、ドキュメント作成、アプリケーション開発の加速。 AI導入における課題 潜在能力は高いものの、企業が生成型AIを導入する際には、いくつかの課題に直面する。データプライバシー、モデルの精度、統合の複雑さ、インフラストラクチャコスト、責任あるAIガバナンスは依然として重要な考慮事項です。 組織はまた、AIが生成する出力が信頼性が高く、透明性があり、ビジネス要件に合致していることを確保しなければならない。AI搭載システムにおける信頼構築には、人間の監督と継続的な評価が不可欠です。 研究主導型生成AIの導入 Enaviyaでは、生成AIの成功はリサーチ、ビジネス理解、そして適切なテクノロジ戦略から始まると信じています。 研究およびテクノロジの観点からは、新興のAIモデルが現実世界のビジネス課題にどのように対応できるかを研究することが重要です。これには、大規模言語モデル(LLM)の評価、ドメイン特化したAIアプリケーションの探求、オートメーションの機会の理解、AI統合の実用的影響の評価が含まれます。 Enaviyaは、生成AI開発、LLM統合、AIエージェント、カスタムAIアプリケーション、インテリジェントオートメーションを通じて、これらの機会をスケーラブルなビジネスソリューションへと転換することに注力しています。 研究主導型のアプローチは、組織がAIツールの実験段階を超え、測定可能なビジネス成果をもたらすソリューションに焦点を当てるのに役立ちます。 ぜひこのThreadでご意見をお寄せください。

Using CLRC663 as P2P device Hello, We would like to use the CLRC663 plus as a Peer-to-peer (P2P) device. According to the datasheet the CLRC663 supports P2P mode according to the ISO/IEC 18092 in Passive Initiator mode. This however brings up a multitude of questions: Is it possible to have two CLRC663 devices communicate with each other? If not, should the CLRC663 be combined with another device? Which is recommended? How to activate the ISO 18092 protocol? For other protocols I have found AN12657 at least describes how to activate some other protocols using the LoadProtocol functionality on the CLRC633, but the datasheet lacks any information on the ISO 18092 protocol. How these other two are activated is entirely unclear from the datasheet as well but can be inferred from this Application Note. Can two devices communicate in Passive Initiator mode? I have looked at probably all posts already on the forum related to this but found nothing of use. I have also seen the NFC Reader Library but am unable to find anything useful regarding P2P. Kind regards Re: Using CLRC663 as P2P device Hello, Thank you for your interest in NXP Semiconductors products and for the opportunity to support you CLRC663 is not fully NFC Forum compliant and it is intended for Reader/Writer mode. A CLRC663 can therefore be used with a different NFC device that supports the required target mode (i.e. HCE). For a standard ISO/IEC 18092 P2P connection, you could consider evaluating the PN5190. However, this hardware consideration must also be evaluated together with the available support. Please notice that the NXP NFC Reader Library states that maintenance of its P2P functionality is being discontinued. Although earlier library releases include legacy P2P support, P2P functionality is not supported in our current software baseline. Best regards,  Alondra Re: Using CLRC663 as P2P device Hello, Thanks for your response. We will look into the PN5190 as well. We have a Mikroe USB Dongle which uses the PN7150, could this be used to test this functionality too? My main concern is with setting the ISO 18092 standard on the CLRC663. For other protocols I have found the settings to enable this, but not for ISO 18092. Would it be possible or perhaps easier to use two PN5190 ICs to let them communicate together?  As a sidenote, it seems NFC P2P is sort of 'old school', Android stopped supporting it about 7 versions ago, and NXP it seems also treats it as legacy. Is this even worth trying?  Kind regards Re: Using CLRC663 as P2P device Hello,  Please note that the Mikroe USB Dongle is not an NXP product. Therefore, application implementation and compatibility will depend entirely on the capabilities and support provided by the dongle manufacturer. Additionally, the PN7150 is not recommended for new designs. NXP has discontinued Android maintenance for the PN7150 and does not plan to provide support for newer Android versions. P2P communication based on ISO/IEC 18092 is being discontinued and is no longer supported by NXP. A similar situation applies when considering two PN5190 devices. Since P2P is no longer supported, the recommended approach would be to configure one PN5190 as the NFC reader and the second device in card emulation mode, rather than implementing a P2P configuration. For new designs, we recommend using currently supported NFC operating modes and solutions. Best regards

CLRC663をP2Pデバイスとして使用する こんにちは、 CLRC663 plusをピアツーピア（P2P）デバイスとして使用したいと考えています。データシートによると、CLRC663はISO/IEC 18092に準拠したパッシブイニシエータモードのP2Pモードをサポートしています。 しかし、これによって多くの疑問が生じる。 2台のCLRC663デバイスを相互に通信させることは可能ですか？ そうでない場合、CLRC663は別のデバイスと組み合わせるべきでしょうか？どちらがお勧めですか？ ISO 18092プロトコルを有効化するにはどうすればよいですか？他のプロトコルについては、 AN12657にCLRC633のLoadProtocol機能を使用して他のプロトコルをアクティブ化する方法が少なくとも記載されていることがわかりましたが、データシートにはISO 18092プロトコルに関する情報が一切ありません。これら2つの起動方法もデータシートからは全く不明ですが、このアプリケーションノートから推測できます。 パッシブイニシエーターモードで2台のデバイスが通信できますか? この件に関してフォーラムに投稿されている記事はほぼ全て確認しましたが、役に立つ情報は何も見つかりませんでした。NFCリーダ Libraryも見ましたが、P2Pに関して有益な情報は見つかりませんでした。 敬具 Re: Using CLRC663 as P2P device こんにちは、 NXPセミコンダクターズ製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます CLRC663はNFCフォーラムの規格に完全に準拠しておらず、リーダー/ライターモードでの使用を想定しています。したがって、CLRC663は必要なターゲットモードをサポートする(すなわちHCE）。標準的なISO/IEC 18092のP2P接続については 、PN5190の評価を検討してみてください。 しかし、このハードウェアの考慮も利用可能なサポートと併せて評価する必要があります。NXP NFCリーダライブラリでは、P2P機能の維持管理が中止されることにご注意ください。以前のライブラリリリースにはレガシーP2Pサポートが含まれていますが、現在のソフトウェアベースラインではP2P機能はサポートされていません。 よろしくお願いします、 アロンドラ Re: Using CLRC663 as P2P device こんにちは、 なお、Mikroe USBドングルはNXP製品ではありません。したがって、アプリケーションの実装と互換性は、ドングルメーカーが提供する機能とサポートに完全に依存します。 さらに、PN7150は新しいデザインには推奨されていません。NXPはPN7150のAndroidメンテナンスを中止しており、新しいAndroidバージョンのサポートを提供する予定はありません。 ISO/IEC 18092に基づくP2P通信は廃止され、NXPによるサポートは終了しました。 2つのPN5190デバイスを検討する場合にも、同様の状況が当てはまります。P2Pはもはやサポートされていないため、推奨される方法は、P2P構成を実装するのではなく、1台のPN5190をNFCリーダとして、もう1台をカードエミュレーションモードに設定することです。 新しいデザインについては、現在サポートされているNFC動作モードやソリューションの使用を推奨します。 よろしくお願いいたします。 Re: Using CLRC663 as P2P device こんにちは、 ご回答ありがとうございます。 PN5190についても調査します。 私たちはPN7150を使う Mikroe USBドングル を持っていますが、これを使ってこの機能もテストできますか? 私の主な懸念はCLRC663にISO 18092規格を設定することです。他のプロトコルではこれを有効にする設定を見つけましたが、ISO 18092では見つかりませんでした。 PN5190 ICを2つ使用して通信させることは可能でしょうか？あるいは、その方が簡単でしょうか？ ちなみに、NFC P2Pはどこか"昔ながら"のもののようです。Androidは約7バージョン前にサポートを終了し、NXPもこれをレガシーとして扱っているようです。これって試してみる価値があるの？ 敬具

MCXA156VLH ISP PIN wise query We have designed a custom board using MCXA156VLH - LQFP-64, we have considered latest version of datasheet in which PIN3_29 is ISP Pin, but during our testing we found that PIN0_6 is ISP pin.  The date of manufacturing on IC is 2025 year. As per Errata on 2025 year, PIN0_6 is ISP pin. So which one should I consider in design PIN0_6 or PIN3_29 for ISP for future production ? MCXA Package and IO|GPIO Re: MCXA156VLH ISP PIN wise query Hello @TEMCEFF , Thank you for the clarification. I understand your question now. This erratum is specific to the 0P29K mask set, which can be identified from the device marking. Therefore, all MCXA156VLH devices with this mask set require the recommended workaround. Currently, there is no plan for a new revision to fix this issue. Hope it helps. BR Celeste Re: MCXA156VLH ISP PIN wise query Dear Celeste_Liu, Thank you for clarifying, we have tried the suggested solution and is working for existing parts. But, I also want to know for parts ordered from now which pin is to be considered for ISP -> P0_6 or P3_29 ? As I need to release the design to production now, confirmation on which pin to be considered for ISP is crucial. Re: MCXA156VLH ISP PIN wise query Hello @TEMCEFF , Thanks for your post. Yes,  your observation is consistent with the erratum ERR053147. For the affected silicon, P0_6 is the ISP pin during POR, while P3_29 is the ISP pin during a warm reset. Therefore, for the current affected devices, please take P0_6 into account in the hardware design to ensure that its state during power-on does not unintentionally trigger ISP mode. In short, P0_6 must be high during boot. If P3_29 needs to be used for ISP entry, the workaround described in the errata is to trigger a warm reset at the beginning of the user code after POR. In detail, please add the following code to SystemInitHook. __attribute__ ((weak)) void SystemInitHook (void) { /* Void implementation of the weak function. */ uint32_t s_CMCSRS = 0; s_CMCSRS = CMC->SRS; if(s_CMCSRS ==0x06) { NVIC_SystemReset(); } }   Hope it helps.   Regards, Celeste

MCXA156VLH ISP PIN 码查询 我们使用MCXA156VLH（LQFP-64封装）设计了一款定制板。我们参考了最新版本的数据手册，其中PIN3_29是ISP引脚，但在测试过程中我们发现PIN0_6才是ISP引脚。 该集成电路的生产日期为2025年。根据 2025 年的勘误表，PIN0_6 是 ISP 密码。那么，在未来的生产中，我应该在ISP设计中考虑使用PIN0_6还是PIN3_29呢？ MCXA 封装和 I/O|GPIO Re: MCXA156VLH ISP PIN wise query 你好@TEMCEFF ， 谢谢你的解释。我现在明白你的问题了。 此勘误专门针对 0P29K 掩模组，可通过设备标记识别。因此，所有使用此掩码集的 MCXA156VLH 设备都需要推荐的解决方法。 目前还没有计划通过新的修订来解决这个问题。 希望对您有所帮助。 BR 塞莱斯特 Re: MCXA156VLH ISP PIN wise query 亲爱的 Celeste_Liu， 感谢您的澄清，我们已经尝试了您建议的解决方案，并且对现有部件有效。 但是，我还想知道从现在开始订购的零件，ISP 应该使用哪个引脚——P0_6 还是 P3_29？ 由于我现在需要将设计版本投入生产，因此确认哪个引脚适合用作ISP至关重要。 Re: MCXA156VLH ISP PIN wise query 你好@TEMCEFF ， 感谢您的帖子。 是的，您的观察结果与勘误表 ERR053147 一致。 对于受影响的芯片， P0_6 是上电时的 ISP 引脚，而P3_29 是热 RESET 时的 ISP 引脚。因此，对于当前受影响的设备，请在硬件设计中考虑 P0_6 的状态，以确保其在上电期间不会意外触发信号 ISP 模式。简而言之，P0_6 在启动期间必须为高电平。 如果需要使用 P3_29 作为 ISP 入口，勘误表中描述的解决方法是在 POR 之后，在用户代码的开头触发一次热RESET。 具体来说，请将以下代码添加到 SystemInitHook 中。 __attribute__ ((weak)) void SystemInitHook (void) { /* Void implementation of the weak function. */ uint32_t s_CMCSRS = 0; s_CMCSRS = CMC->SRS; if(s_CMCSRS ==0x06) { NVIC_SystemReset(); } }   希望对您有所帮助。   此致， 塞莱斯特

使用 CLRC663 作为 P2P 设备 你好， 我们希望将 CLRC663 plus用作点对点 (P2P) 设备。根据数据表，CLRC663 支持符合 ISO/IEC 18092 标准的被动启动器模式下的 P2P 模式。 但这又引发了一系列问题： 两个 CLRC663 设备之间可以相互通信吗？ 如果不行，CLRC663 是否应该与其他设备组合使用？哪种更推荐？ 如何激活 ISO 18092 协议？对于其他协议，我发现AN12657至少描述了如何使用 CLRC633 上的LoadProtocol功能激活一些其他协议，但数据手册缺少有关 ISO 18092 协议的任何信息。从数据手册中也完全不清楚另外两个功能的激活方式，但可以从本应用说明中推断出来。 两个设备能否在被动启动器模式下通信？ 我几乎已经查看了论坛上所有与此相关的帖子，但没有找到任何有用的信息。我也看过 NFC读取器库，但找不到任何关于 P2P 的有用信息。 亲切的问候 Re: Using CLRC663 as P2P device 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 CLRC663 不完全符合 NFC Forum 标准，并且是为读写器模式设计的。因此，CLRC663 可以与支持所需目标模式的不同 NFC 设备一起使用（即 ）。HCE）。对于标准的 ISO/IEC 18092 P2P 连接，您可以考虑评估PN5190 。 但是，这种硬件方面的考虑也必须与可用的支持结合起来评估。请注意， NXP NFC读取器库声明其 P2P 功能维护已停止。虽然早期的库版本包含对传统 P2P 的支持，但我们当前的软件基线不支持 P2P 功能。 此致， 阿隆德拉 Re: Using CLRC663 as P2P device 你好， 谢谢你的回复。 我们也会研究一下PN5190。 我们有一个使用PN7150芯片的Mikroe USB Dongle ，它是否也可以用来测试这项功能？ 我主要关心的是在 CLRC663 上设置 ISO 18092 标准。对于其他协议，我已经找到了启用此功能的设置，但对于 ISO 18092 却没有。 是否可以使用两个PN5190集成电路来实现它们之间的通信？或者说，使用两个PN5190集成电路或许会更容易一些？ 顺便提一下，NFC P2P 似乎有点“过时”了，Android 大约在 7 个版本前就停止支持它了，NXP 似乎也把它视为过时的技术。这真的值得一试吗？ 亲切的问候 Re: Using CLRC663 as P2P device 你好， 请注意，Mikroe USB Dongle 不是 NXP 的产品。因此，应用程序的实现和兼容性将完全取决于加密狗制造商提供的功能和支持。 此外，不建议在新设计中使用 PN7150。NXP 已停止对 PN7150 的 Android 维护，并且不打算为更新的 Android 版本提供支持。 基于 ISO/IEC 18092 的 P2P 通信正在停止，NXP 不再提供支持。 当考虑两个 PN5190 设备时，情况也类似。由于不再支持 P2P，建议将一个 PN5190 配置为 NFC 读卡器，并将第二个设备配置为卡模拟模式，而不是实现 P2P 配置。 对于新设计，我们建议使用当前支持的 NFC 操作模式和解决方案。 顺祝商祺！

MCXA156VLH ISP PIN 別クエリ MCXA156VLH - LQFP-64を使用したカスタムボードを設計しましたが、データシートの最新版ではPIN3_29がISPピンとされていました。しかし、テストの結果、PIN0_6がISPピンであることが判明しました。 ICの製造開始日は2025年です。2025年の正誤表によると、PIN0_6はISP PINです。SO、FUTUREの 生産のためにISPのデザインPIN0_6やPIN3_29でどちらを検討すべきでしょうか? MCXA パッケージとIO|GPIO Re: MCXA156VLH ISP PIN wise query こんにちは、 @TEMCEFF さん、 ご説明いただきありがとうございます。あなたの質問の意味が分かりました。 この訂正は、デバイスのマーキングから識別可能な0P29Kマスクセットに特有のものです。したがって、このマスクセットを搭載したすべてのMCXA156VLHデバイスは、推奨される回避策を適用する必要があります。 現時点では、この問題を修正するための新たな改訂版をリリースする予定はありません。 お役に立てば幸いです。 BR セレステ Re: MCXA156VLH ISP PIN wise query Celeste_Liu様、 ご説明いただきありがとうございます。ご提案いただいた解決策を試したところ、既存の部品では正常に動作しています。 しかし、今後注文する部品については、ISP のピンとして P0_6 または P3_29 のどちらを考慮すべきかも知りたいです。 今すぐデザインを本番環境に公開する必要があるので、どのピンをISPに検討するかの確認が非常に重要です。 Re: MCXA156VLH ISP PIN wise query こんにちは、 @TEMCEFF さん、 投稿ありがとうございます。 はい、あなたの指摘は正誤表ERR053147と一致しています。 影響を受けるシリコンの場合、 P0_6はPOR時のISPピン、 P3_29はウォームリセット時のISPピンです。したがって、現在影響を受けるデバイスについては、ハードウェア設計でその状態が電源オン時に意図せずISPモードをトリガーしないよう、P0_6を考慮してください。要するに、起動時にP0_6が高い状態である必要があります。 ISP入力にP3_29を使う必要がある場合、訂正表に記載されている回避策は、POR後のユーザーコードの冒頭でウォームリセットをトリガーすることです。 具体的には、SystemInitHookに以下のコードを追加してください。 __attribute__ ((weak)) void SystemInitHook (void) { /* Void implementation of the weak function. */ uint32_t s_CMCSRS = 0; s_CMCSRS = CMC->SRS; if(s_CMCSRS ==0x06) { NVIC_SystemReset(); } }   お役に立てば幸いです。   よろしくお願いいたします。 セレステ

i.MX 8ULP uSDHC - HS400 Enhanced Strobe: validation and CMD response sampling Hi, We use the on-board eMMC (JEDEC 5.1) on i.MX 8ULP (uSDHC0) in HS400 Enhanced Strobe (200 MHz, 8-bit, 1.8 V). Our U-Boot eMMC host and card-switching code is identical to NXP lf-6.1.55-2.2.1, and the EVK device tree also enables mmc-hs400-enhanced-strobe. During evaluation we have occasionally seen a data CRC error or no response to CMD12/CMD13 during eMMC reads in U-Boot. In our tests, only a host reset or a card re-initialization recovered it. 1. Is HS400 Enhanced Strobe validated and recommended on i.MX 8ULP? The datasheet (IMX8ULPIEC Rev.1) does not mention it. If it is not, is standard HS400 the recommended configuration? Also, which AC timing applies to the CMD response at the SoC pins in HS400 / Enhanced Strobe? 2. In Enhanced Strobe, where no tuning is performed, what samples the CMD response: the data strobe or the internal sampling clock? The reference manual's "Switch to HS400 mode" requires HS200 tuning "to synchronize the command response on the CMD line to CLK" and writes the result back with MIX_CTRL[SMP_CLK_SEL] = 1 (steps 6, 10-12). "Switch to HS400 enhanced mode" has no such step. The i.MX 93 reference manual (38.3.10.5) has the same flow and no description either. Thank you in advance. Best regards, mio i.MX8ULP

s32k31XEVB-Q100評価ボード上でS32K311およびFS23用のSPIを設定 こんにちは、 私はs32k31XEVB-Q100評価ボード上のS32K311とFS23間の通信用にSPIを設定しようとしています。 そこで、LPSPI0のピンを設定しました。 データシートによると、まずCLKが起動し、次にCSがLOWになる必要がある。 S32DSでこの動作をどのように設定すればよいですか? しかし、SPIデータを見ると、まずCSがLOWになり、次にCLKがトグルし始めることがわかります。 Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board こんにちは、 @john_2 図中のSCLK信号の開始位置に関して、若干の誤解があるかもしれません。図には、CSがLOWになる前にSCLKがトグルを開始する必要があるとは示されていません。むしろ、CSがアサートされる前にSCLKがすでにアイドル状態のLOWレベルになっている必要があることを示している。 CS信号がLOWになると、最初のSCLKエッジは、指定されたPCS-SCK遅延時間の後に発生します。したがって、LPSPI0をSCLKアイドルLOW（CPOL = 0）に設定し、FS23のタイミング要件に従ってPCS-to-SCK遅延を設定する必要があります。 BR、VaneB Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board 情報ありがとうございます 😄 これらが必要だったんです。 しかし、通信はまだ正常に機能していません。 私はLpspiとSbc_fs23_Ipドライバを使っています。 M_DEV_PROG_IDを読み取りたい でも、部品の順番自体が間違っていると思うのですが？ つまり、最初のバイトは00000010であるべきでしょうか？ 私が設定した構成では Lpspiドライバー データシートを正しく理解していれば、SpiTransferStartはMSBであるべきですよね？しかし、ロジックアナライザでは、CRCは最初のバイトに、アドレスは最後のバイトに表示されます。 スピジェネラル および Sbc_fs23_Ip-GeneralConfig

The problem of long negotiation time in Ethernet. I am using version ATF35.0 and have referenced the , but I have only built fig.s32(ATF + uboot). I hope to launch my self-developed OS application through ATF+uboot. My self-developed OS requires a normal Ethernet connection during startup, but the Ethernet negotiation/connection time to the PC in uboot is very long，although it was ultimately able to ping successfully. Could you please help me solve this problem？ Thank you. Here is my startup log： NOTICE: Reset status: Power-On Reset NOTICE: BL2: v2.5(release):bsp35.0-2.5-dirty NOTICE: BL2: Built : 14:24:22, Nov 5 2026 NOTICE: BL2: Booting BL31 U-Boot 2020.04-dirty (Nov 05 2026 - 14:22:13 +0800) CPU: NXP S32G274A rev. 2.1 Model: NXP S32G274A-RDB2 DRAM: 3.5 GiB Ignore unsupported SCMI protocol 19 MMC: FSL_SDHC: 0 Loading Environment from SPI Flash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to lock PCIe phy Failed to power on 'serdes_lane0' PHY In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: RDB2/GLDBOX Revision C Net: EQOS phy: rgmii @ 1 Warning: eth_eqos MAC addresses don't match: Address in ROM is 02:00:00:00:00:01 Address in environment is 32:94:1b:e9:59:d7 eth0: eth_eqosFailed to set the frequency of mac2_rx_rgmii Failed to enable mac2_rx_rgmii clock PFE: emac0: sgmii emac1: none emac2: rgmii SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB ## No elf image at address 0xffdc8178 PFEng firmware file ' @0x03000000: ' loading failed: -22 Hit any key to stop autoboot: 0 => setenv ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => setenv gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "run initnet; run bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => saveenv Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done OK => reset resetting ▒NOTICE: Reset status: Destructive Reset (RUN) NOTICE: BL2: v2.5(release):bsp35.0-2.5-dirty NOTICE: BL2: Built : 14:24:22, Nov 5 2026 NOTICE: BL2: Booting BL31 U-Boot 2020.04-dirty (Nov 05 2026 - 14:22:13 +0800) CPU: NXP S32G274A rev. 2.1 Model: NXP S32G274A-RDB2 DRAM: 3.5 GiB Ignore unsupported SCMI protocol 19 MMC: FSL_SDHC: 0 Loading Environment from SPI Flash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to lock PCIe phy Failed to power on 'serdes_lane0' PHY In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: RDB2/GLDBOX Revision C Net: EQOS phy: rgmii @ 1 Warning: eth_eqos MAC addresses don't match: Address in ROM is 02:00:00:00:00:01 Address in environment is 32:94:1b:e9:59:d7 eth0: eth_eqosFailed to set the frequency of mac2_rx_rgmii Failed to enable mac2_rx_rgmii clock PFE: emac0: sgmii emac1: none emac2: rgmii SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB ## No elf image at address 0xffdc8178 PFEng firmware file ' @0x03000000: ' loading failed: -22 Hit any key to stop autoboot: 0 eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive Using eth_eqos device ARP Retry count exceeded; starting again ping failed; host 202.100.0.1 is not alive Using eth_eqos device host 202.100.0.1 is alive Using eth_eqos device host 202.100.0.1 is alive SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x1f0000, size 0x200000 SF: 2097152 bytes @ 0x1f0000 Read: OK ## Starting application at 0x80024000 ... 回复： The problem of long negotiation time in Ethernet. Hello, @Zzzz1  Thanks for your post. According to the log shown and test results you shared, from my experience, it is possibly related with the network negotiation,  the link establishment time when connecting with switch may be longer than the wait time of u-boot, which caused the issue. You may try increasing the timeout value in uboot or use the fixed link with switch to have a test. BR Chenyin 回复： The problem of long negotiation time in Ethernet. Sorry, I tried and encountered issues with slow negotiation or errors when connecting the development board to the switch. However, when connecting the development board directly to the PC, there is no such problem. Have you ever encountered this situation?

イーサネットでの交渉時間が長い問題です。 私はバージョンATF35.0を使用しており、 を参照しましたが、実際にビルドしたのはfig.s32(ATF + uboot)だけです。ATF+ubootを通じて自作のOSアプリケーションを立ち上げたいと考えています。私が自作したOSは起動時に通常のイーサネット接続が必要ですが、ubootでのPCへのイーサネット交渉や接続時間は非常に長いものの、最終的には正常にpingを送ることができました。この問題を解決するのを手伝ってもらえますか? ありがとうございます。 以下は私の起動ログです。 注意：リセット状態：電源オンリセット お知らせ：BL2：v2.5（リリース）：bsp35.0-2.5-dirty お知らせ：BL2：ビルド日時：2026年11月5日 14:24:22 通知: BL2: BL31を起動しています U-Boot 2020.04-dirty(2026年11月5日 14:22:13 +0800) CPU: NXP S32G274A rev.2.1 モデル:NXP S32G274A-RDB2 DRAM:3.5 GiB サポートされていないSCMIプロトコル19を無視してください MMC: FSL_SDHC: 0 SPIフラッシュからの読み込み環境...SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 わかった PCIe物理ロックに失敗しました 『serdes_lane0』PHYの電源が入らなかった 収録:serial@401c8000 アウト:serial@401c8000 えっと:serial@401c8000 ボードリビジョン:RDB2/GLDBOX リビジョンC ネット:EQOS phy: rgmii @ 1 警告: eth_eqos の MAC アドレスが一致しません: ROM内のアドレスは02:00:00:00:00:01です 環境内のアドレスは 32:94:1b:e9:59:d7 です eth0: eth_eqos mac2_rx_rgmii の周波数設定に失敗しました mac2_rx_rgmiiクロックの有効化に失敗しました PFE: emac0: sgmii emac1: none emac2: rgmii SF: mx25uw51245gを検出しました。ページサイズは256バイト、消去サイズは64 KiB、合計は64 MiBです。 ## アドレス 0xffdc8178 に ELF イメージがありません PFEngファームウェアファイル「 @0x03000000: 」の読み込みに失敗しました: -22 自動起動を停止するには、任意のキーを押してください: 0 => setenv ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => setenv gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "run initnet; run bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => saveenv 環境情報をSPIフラッシュに保存しています... SPIフラッシュを消去しています... SPIフラッシュに書き込み中です...完了 わかりました => リセット リセット中 ▒注意: リセット状態: 破壊的リセット (実行) お知らせ：BL2：v2.5（リリース）：bsp35.0-2.5-dirty お知らせ：BL2：ビルド日時：2026年11月5日 14:24:22 通知: BL2: BL31を起動しています U-Boot 2020.04-dirty(2026年11月5日 14:22:13 +0800) CPU: NXP S32G274A rev.2.1 モデル:NXP S32G274A-RDB2 DRAM:3.5 GiB サポートされていないSCMIプロトコル19を無視してください MMC: FSL_SDHC: 0 SPIフラッシュからの読み込み環境...SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 わかった PCIe物理ロックに失敗しました 『serdes_lane0』PHYの電源が入らなかった 収録:serial@401c8000 アウト:serial@401c8000 えっと:serial@401c8000 ボードリビジョン:RDB2/GLDBOX リビジョンC ネット:EQOS phy: rgmii @ 1 警告: eth_eqos の MAC アドレスが一致しません: ROM内のアドレスは02:00:00:00:00:01です 環境内のアドレスは 32:94:1b:e9:59:d7 です eth0: eth_eqos mac2_rx_rgmii の周波数設定に失敗しました mac2_rx_rgmiiクロックの有効化に失敗しました PFE: emac0: sgmii emac1: none emac2: rgmii SF: mx25uw51245gを検出しました。ページサイズは256バイト、消去サイズは64 KiB、合計は64 MiBです。 ## アドレス 0xffdc8178 に ELF イメージがありません PFEngファームウェアファイル「 @0x03000000: 」の読み込みに失敗しました: -22 どのキーを押してもオートブートを止める:0 eth_eqos PHY自動交渉完了を待っています.................タイムアウト! phy_startup()失敗:-110 失敗:-110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## アドレス0xffdc7ae8にエルフ画像がない PFEng ファームウェアファイル ' @0x03000000: ' ロード失敗:-22 pingが失敗しました;ホスト202.100.0.1は生きていません eth_eqos装置の使用 ARP再試行回数を超えた;再開 pingが失敗しました;ホスト202.100.0.1は生きていません eth_eqos装置の使用 ホスト202.100.0.1は生きている eth_eqos装置の使用 ホスト202.100.0.1は生きている SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 デバイス0オフセット0x1f0000、サイズ0x200000 SF: 2097152バイト @ 0x1f0000 読み込み: OK ## アプリケーション 0x80024000 ... 回复： The problem of long negotiation time in Ethernet. こんにちは、 @Zzzz1 投稿ありがとうございます。 あなたが共有してくれたログとテスト結果によると、私の経験ではネットワーク交渉に関連している可能性があり、スイッチ接続時のリンク確立時間が起動時の待ち時間よりも長くなっている可能性があり、それが問題の原因でした。 uBootでタイムアウト値を上げるか、スイッチの固定リンクを使ってテストしてみるのも良いでしょう。 BR チェイン 回复： The problem of long negotiation time in Ethernet. すみません、開発ボードとスイッチを接続する際に交渉が遅いかエラーの問題に遭遇しました。しかし、開発ボードを直接PCに接続した場合は、そのような問題はありません。あなたはこのような状況に遭遇したことがありますか？

在 s32k31XEVB-Q100 评估板上配置 S32K311 和 FS23 的 SPI 你好， 我正在尝试配置 s32k31XEVB-Q100 评估板上的 S32K311 和 FS23 之间的 SPI 通信。 因此，我配置了 LPSPI0 上的引脚。 根据数据手册，首先 CLK 必须启动，然后 CS 必须变为低电平。 如何在S32DS中配置此行为？ 但是当我查看SPI数据时，我发现首先CS变为低电平，然后CLK开始切换。 Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board 嗨@john_2 图中 SCLK 信号的起始位置可能存在一些误解。图表并未表明 SCLK 需要在 CS 变为低电平之前开始切换。相反，这表明在 CS 被钳位之前，SCLK 必须已经处于空闲的低电平。 CS 变为低电平后，第一个 SCLK 边沿会在指定的 PCS 到 SCK 延迟后出现。因此，您应该将 LPSPI0 配置为 SCLK 空闲低电平 (CPOL = 0)，并根据 FS23 时序要求配置 PCS 到 SCK 的延迟。 BR，VaneB Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board 谢谢你提供的信息 😄 我需要这些。 但是通讯仍然无法正常工作。 我正在使用Lpspi和Sbc_fs23_Ip驱动程序。 我想读取 M_DEV_PROG_ID 但我认为这些部件的顺序错了？ 也就是说，第一个字节应该是 00000010 吗？ 在我的配置中 Lpspi驱动程序 如果我理解数据表没错，SpiTransferStart 应该是 MSB 吗？但是，在逻辑分析仪中，CRC校验值显示在第一个字节，地址显示在最后一个字节。 SpiGeneral 和 Sbc_fs23_Ip-通用配置

以太网中协商时间过长的问题。 我正在使用 ATF35.0 版本，并参考了《Linux 电路板支持包。 35.0 S32G2 平台用户手册》，但我只构建了 fig.s32（ATF + uboot）。我希望通过 ATF+uboot 启动我自行开发的操作系统应用程序。我自行开发的操作系统在启动时需要正常的以太网连接，但是 uboot 中与 PC 的以太网协商/连接时间非常长，尽管最终能够成功 ping 通。请问您能帮我解决这个问题吗？ 谢谢。 以下是我的启动日志： 注意：重置状态：上电复位 注意：BL2：v2.5（版本）：bsp35.0-2.5-dirty 通知：BL2：版本：2026年11月5日 14:24:22 注意：BL2：正在启动 BL31 U-Boot 2020.04-dirty（2026年11月5日 14:22:13 +0800） CPU：NXP S32G274A rev.2.1 型号：NXP S32G274A-RDB2 动态随机存取存储器(DRAM)：3.5 GiB 忽略不支持的 SCMI 协议 19 MMC：FSL_SDHC：0 正在从 SPI Flash 加载环境... SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 好的 PCIe PHY 锁定失败 无法为“serdes_lane0”PHY供电。 输入：serial@401c8000 输出：serial@401c8000 错误：serial@401c8000 板版本：RDB2/GLDBOX 版本 C 网络：EQOS phy：rgmii @ 1 警告：eth_eqos MAC 地址不匹配： ROM中的地址是02:00:00:00:00:01 环境地址为 32:94:1b:e9:59:d7 eth0：eth_eqos 无法设置 mac2_rx_rgmii 的频率 启用 mac2_rx_rgmii 时钟失败 PFE：emac0：sgmii emac1：无 emac2：rgmii SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB ## 地址 0xffdc8178 处没有 ELF 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 按任意键停止自动启动：0 => 设置环境变量 ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => 设置环境变量 gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "运行 initnet; 运行 bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => 保存环境 正在将环境数据保存到 SPI Flash... 正在擦除 SPI Flash... 正在写入 SPI Flash... 完成 好的 => 重置 重置 ▒注意：重置状态：破坏性重置（运行） 注意：BL2：v2.5（版本）：bsp35.0-2.5-dirty 通知：BL2：版本：2026年11月5日 14:24:22 注意：BL2：正在启动 BL31 U-Boot 2020.04-dirty（2026年11月5日 14:22:13 +0800） CPU：NXP S32G274A rev.2.1 型号：NXP S32G274A-RDB2 动态随机存取存储器(DRAM)：3.5 GiB 忽略不支持的 SCMI 协议 19 MMC：FSL_SDHC：0 正在从 SPI Flash 加载环境... SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 好的 PCIe PHY 锁定失败 无法为“serdes_lane0”PHY供电。 输入：serial@401c8000 输出：serial@401c8000 错误：serial@401c8000 板版本：RDB2/GLDBOX 版本 C 网络：EQOS phy：rgmii @ 1 警告：eth_eqos MAC 地址不匹配： ROM中的地址是02:00:00:00:00:01 环境地址为 32:94:1b:e9:59:d7 eth0：eth_eqos 无法设置 mac2_rx_rgmii 的频率 启用 mac2_rx_rgmii 时钟失败 PFE：emac0：sgmii emac1：无 emac2：rgmii SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB ## 地址 0xffdc8178 处没有 ELF 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 按任意键停止自动启动：0 eth_eqos 等待 PHY 自动协商完成................. 超时！ phy_startup() 失败：-110FAILED：-110 ## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110##地址 0xffdc7ae8 处没有 elf 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 ping 失败；主机 202.100.0.1 已关闭 使用 eth_eqos 设备 ARP 重试次数已超过限制；重新开始 ping 失败；主机 202.100.0.1 已关闭 使用 eth_eqos 设备 主机 202.100.0.1 处于活动状态 使用 eth_eqos 设备 主机 202.100.0.1 处于活动状态 SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 设备 0 偏移量 0x1f0000，大小 0x200000 SF：2097152 字节 @ 0x1f0000 读取：成功 ## 应用程序从 0x80024000 开始... 回复： The problem of long negotiation time in Ethernet. 你好， @Zzzz1 感谢您的帖子。 根据您提供的日志和测试结果，以我的经验来看，这可能与网络协商有关，连接交换机时的链路建立时间可能比 u-启动 的等待时间长，从而导致了这个问题。 您可以尝试增加 uboot 中的超时值，或者使用带开关的固定链路进行测试。 BR 陈银 回复： The problem of long negotiation time in Ethernet. 抱歉，我尝试连接开发板到交换机时遇到了协商缓慢或出错的问题。但是，当将开发板直接连接到电脑时，就不会出现这样的问题。你遇到过这种情况吗？

i.MX 8ULP uSDHC - HS400拡張ストロボ：検証およびCMD応答サンプリング こんにちは、 私たちは搭載のeMMC(JEDEC 5.1)を、HS400エンハンストロボ(200MHz、8ビット、1.8V)の8ULP(uSDHC0)i.MX 使用しています。当社のU-Boot eMMCホストおよびカード切り替えコードはNXP lf-6.1.55-2.2.1と同一であり、EVKデバイスツリーではmmc-hs400-enhanced-strobeも有効になっています。評価中に、U-BootでのeMMC読み取り時に、データCRCエラーやCMD12/CMD13への応答がないことが時折発生しました。我々のテストでは、ホストのリセットまたはカードの再初期化によってのみ復旧できた。 1. HS400 Enhanced Strobeはi.MX 8ULPで検証済みで推奨されていますか？データシート（IMX8ULPIEC Rev.1）にはその記載はありません。そうでない場合、標準のHS400が推奨構成ですか？また、HS400 / Enhanced Strobe の SoC ピンにおける CMD 応答には、どの AC タイミングが適用されますか？ 2. チューニングを行わない拡張ストローブでは、CMD応答をサンプリングするのはデータストローブですか、それとも内部サンプリングクロックですか？リファレンス・マニュアルの「HS400モードへの切り替え」では、HS200のチューニングが「CMDラインのコマンド応答をCLKに同期させる」必要があり、結果はMIX_CTRL[SMP_CLK_SEL] = 1(ステップ6、10-12)で書き戻されます。「HS400エンハンストモードに切り替える」にはそのようなステップはありません。i.MX 93のリファレンスマニュアル(38.3.10.5)も同じ流れで、説明はありません。 事前に感謝いたします。 よろしくお願いします、 ミオ i.MX8ULP

Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Hello, I am trying to configure the SPI for the communication between a S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board. Therefore I configured the pins on LPSPI0. According to the Datasheet first the CLK has to start and then the CS has to go LOW. How can I configure this behavior in S32DS? But When I see the SPI Data I see that first the CS goes to LOW and then the CLK starts toggling Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Hi @john_2  There may be a small misunderstanding regarding the beginning of the SCLK signal in the diagram. The diagram does not indicate that SCLK needs to start toggling before CS goes LOW. Instead, it shows that SCLK must already be at its idle LOW level before CS is asserted. Once CS goes LOW, the first SCLK edge occurs after the specified PCS-to-SCK delay. Therefore, you should configure LPSPI0 with SCLK idle LOW (CPOL = 0) and configure the PCS-to-SCK delay according to the FS23 timing requirement. BR, VaneB Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Thanks for the Information 😄 I needed these. But the Communication is still not working correctly. I am using the Lpspi and Sbc_fs23_Ip driver. I want to read the M_DEV_PROG_ID But I think the bits itself are in the wrong order? I.e. the first Byte should be 00000010 ? In the configuration I have  LpspiDriver If I understood the Datasheed correct, the SpiTransferStart should be MSB? But then the CRC is shown in the first Byte and the Address in the last Byte (in the LogicAnalyzer) SpiGeneral and Sbc_fs23_Ip- GeneralConfig

i.MX 8ULP uSDHC - HS400 增强型频闪：验证和 CMD 响应采样 您好， 我们在 HS400 增强型选通（200 MHz，8 位，1.8 V）中使用 i.MX 8ULP (uSDHC0) 上的板载 eMMC (JEDEC 5.1)。我们的 U-Boot eMMC 主机和卡切换代码与 NXP lf-6.1.55-2.2.1 完全相同，并且 EVK 设备树也启用了 mmc-hs400-enhanced-strobe。在评估过程中，我们偶尔会发现 U-Boot 读取 eMMC 时出现数据 CRC 错误或对 CMD12/CMD13 没有响应。在我们的测试中，只有 RESET 主机或重新初始化卡才能恢复它。 1. HS400增强型频闪灯是否已在i.MX 8ULP上得到验证和推荐？数据手册（IMX8ULPIEC Rev.1）中没有提到这一点。如果不是，那么标准 HS400 是推荐配置吗？另外，HS400 / 增强型选通模式下，SoC 引脚上的 CMD 响应采用哪种交流时序？ 2. 在增强型选通模式下，不进行任何调谐，CMD 响应采样的是数据选通还是内部采样时钟？参考手册中的“切换到 HS400 模式”需要 HS200 调谐“将 CMD 线上的命令响应与 CLK 同步”，并将结果写回 MIX_CTRL[SMP_CLK_SEL] = 1（步骤 6、10-12）。“切换到 HS400 增强模式”并没有这样的步骤。i.MX 93 参考手册 (38.3.10.5) 的流程相同，也没有描述。 提前谢谢您。 此致， mio i.MX8ULP

Re: lx2080(yocto image and debug)   i want answers below quiries: explain SD card image flash .using flex installer tool and other methods flash code  in SD card . in temp/deploy/lx2160ardb  i have n number of bin files which files should select and how to flash in sd card, how to get bootable image . QorIQ LS1 Devices QorIQ LS2 Device Re: lx2080(yocto image and debug) Hi @jagannathr  , flex-installer method uses three part: SD-boot composite firmware, a boot-partition archive, and a root-filesystem archive  In the */tmp/deploy/images/lx2160ardb-rev2 1. SD-boot composite firmware firmware_lx2160ardb...sdboot.img 2. a boot-partition archive boot_lx2160ardb...tgz 3. Yocto root-filesystem archive fsl-image-networking-...lx2160ardb....rootfs.tar.gz The command would be : flex-installer -b -r -f -d Thanks June

imx95 CRA こんにちは、NXPさん EUのCRA（感染症証明書）を移植する必要があります。移植に関する公式文書はどこで入手できますか？（リンクを教えていただけますか？） Linux Re: imx95 CRA こんにちは、 @yrj さん CRAは直接移植可能なソフトウェアコンポーネントではなく、製品が遵守しなければならないサイバーセキュリティ規制です。 i.MXプラットフォーム上でCRA（カナダ歳入庁）の要件を実装する場合は、以下のリソースを優先的に活用することをお勧めします。 1. NXP公式CRA特別ページへのエントリー このページにある「ドキュメント」セクションには、アプリケーションノート、ホワイトペーパー、トレーニング資料が掲載されているほか、セキュアブート、セキュアアップデート、鍵管理などのセキュリティ機能と規制要件との関連性についても説明されています。   2. i.MXプラットフォーム アプリケーションノート このドキュメントでは、i.MX 93 を活用して OEM が CRA 要件を満たすことを支援する方法について説明します。 3.製品全体のコンプライアンス実施に関するホワイトペーパー このセクションでは、セキュリティ製品の設計とライフサイクルに関するコンプライアンス要件を紹介します。BSPや特定のセキュリティ機能だけに焦点を当てるのではなく、まず製品レベルの実装フレームワークを確立するのに適しています。 4. EU公式実施ガイドライン 規制発行機関による実施ガイドラインには、欧州委員会のガイダンス、よくある質問（FAQ）、製造業者の義務、適合性評価、脆弱性報告義務などが含まれます。製品が満たすべき要件を判断する際には、これらのEU公式文書に基づいて判断する必要があります。 よろしくお願いします、 志明 Re: imx95 CRA こんにちは@Zhiming_Liu おっしゃる通りです。私の説明は単純すぎました。 ドキュメントに従って、uboot、イメージ、およびimx95-xxx.dtbに署名と検証を行いました。 私の質問は、rootfsも署名する必要があるかどうかです。rootfsの署名に関する情報はまだ見つかっていません。これは、rootfsは署名する必要がないということでしょうか？ Re: imx95 CRA こんにちは、 @yrj さん 以下のドキュメントを参照してください：10.5.5 CAAMハードウェアIPのないi.MXプラットフォームでのDM-Cryptの使用 https://www.nxp.com/docs/en/user-guide/UG10163.pdf よろしくお願いします、 志明 Re: imx95 CRA こんにちは、 @yrj さん ファイルシステムは通常、dm-verityを使用します。ファイルシステムの保護を有効にするには、次のドキュメントを参照してください。https ://www.nxp.com/docs/en/application-note/AN15078.pdf よろしくお願いします、 志明 Re: imx95 CRA こんにちは@Zhiming_Liu dm-verityは読み取り専用ですが、 dm-cryptのドキュメントはありますか？