Hands-On: Real-Time Control, Sensing, and Visualization with FRDM-A-S32K344 Attached is hands-on presentation Real-Time Control, Sensing, and Visualization with FRDM-A-S32K344 used during Electronica 2026 edge lab LIVE! event The presentation is designed for ​FRDM-A-S32K344 board, but might be reused also for different MCUs/boards with consideration board and pins specification. Brief Content: FRDM-A-S32K344 Board Overview​ Hands-On Application Code Hub (ACH) project Add Timer, GPIO and ADC pins Clock Configuration tips Push buttons Periodic Interrupt FreeMASTER Data Recording FreeMASTER Recorder Tips and Tricks​ As Initial example code we used "Real-Time ADC Monitoring and LED Dimming Using FreeMASTER" example from Application Code Hub. The content is Public: Free to use, modify, extend and share. We would be happy if you share with us significant improvements, modifications or porting to other boards/derivatives.   S32K3 , #FRDM-A-S32K344, S32DS-S32PLATFORM , FREEMASTER 

Unable to detect S32K344 HMS Board in S32DS application. In S32DS I am able to build my project but during debug or flashing in S32k3 board I am unable detect this S32K3 board in PEMicro debbuger option in port option. Even in normal way I checked by connecting through USB cable whether it showing connected or not device manager but there also unable to detect this S32K344 HMS board. #S32k344             Re: Unable to detect S32K344 HMS Board in S32DS application. Hi @Amit8863  The onboard LED appears to be functioning normally. Could it be that another instance of S32DS or another IDE is currently using this debugger? However, the onboard debugger(PEMicro OpenSDA Debug Driver ) does not appear in Device Manager. Please take a look at my Device Manager after the USB cable has been plugged in. Please use a USB cable that includes D+ and D- signal lines. The onboard debugger is provided by PEMicro, it is recommended to download the latest "USB Multilink Resources Installer" from the "Support & Downloads" category of the "Multilink Debug Probes". After installation, open PEFirmwareConfig.exe located in C:\PEMicro\Multilink_Resources to check the firmware version. Select Hardware Type: Multilink ACP Embedded - OnBoard ARM Debug Interface  Then, check for available updates. Then, "Embedded Multilink Rev A" should be detected in the Port field under S32DS PEMicro Interface Settings. Best Regards, Robin

エラーの更新とアプリコードハブS32K344ビルディング例 FRDM S32K344ボード用のこちらのデモを参考にしています： https://mcuxpresso.nxp.com/appcodehub? search=dm-adc-profiling-freemaster-s32k344 正しいソフトウェア依存関係をインストールしましたが、「コードの更新とプロジェクトのビルド」をクリックしようとすると、次のエラーが発生します。PCとS32DSを再起動したり、新しいワークスペースを作成したり、他の拡張機能を確認したりしてみましたが、このバグは解消されませんでした。サポートに心より感謝いたします! Re: Errors Updating & Building S32K344 App Code Hub Example こんにちは、 例の説明はTと述べています。彼の例はFRDMオートモーティブバンドルを用いてS32K3 + S32M27を用いて開発されました。 以下に挙げるすべてのドライバがこの例で使われているわけではありません。ただし、少なくとも以下の2つのパッケージはS32DS 3.6.8に正しくインストールされている必要がありますデモを読み込む前に： S32K3 リアルタイム・ドライバ AUTOSAR 4.9、バージョン7.0.1 S32K3 FreeMASTERドライバ これらのパッケージがS32DS 3.6.xに正しくインストールされているか必ず確認してください環境。 成功したドライバーインストール後、通常はACHからこの例を読み込み、UpdateCodeとBuildを実行します。 BR、ペトル  

S32DSアプリケーションでHMSボードS32K344検出できません。 S32DSではプロジェクトをビルドできますが、S32k3ボードでのデバッグまたはフラッシュ中に、ポートオプションのPEMicroデバッガーオプションでこのS32K3ボードを検出できません。通常通りUSBケーブルで接続してデバイスマネージャの表示を確認しましたが、HMSボードS32K344コネクテッド検出できませんでした。#S32k344             Re: Unable to detect S32K344 HMS Board in S32DS application. こんにちは、 @Amit8863さん 搭載されているLEDは正常に動作しているようです。 もしかすると、別のS32DSやIDEのインスタンスが現在このデバッガを使っている可能性はありますか? しかし、オンボードのデバッガ(PEMicro OpenSDA Debug ドライバ )は デバイスマネージャには表示されません。USBケーブルを差し込んだ後、デバイスマネージャーをご覧ください。D+とD-の信号線を含むUSBケーブルを使用してください。 オンボードデバッガはPEMicroによって提供されており、最新の「USB Multilink Resources Installer」を、「Multilink Debug Probes」の「サポート & Downloads」カテゴリからダウンロードすることを推奨します。インストール後、PEFirmwareConfig.exe C:\PEMicro\Multilink_Resourcesにあるファイルを開き、ファームウェアのバージョンを確認してください。ハードウェアタイプを選択し:Multilink ACP Embedded - OnBoard Arm Debug インターフェース。次に、利用可能なアップデートを確認してください。 その後、S32DS PEMicroインターフェース設定のポートフィールドで「Embedded Multilink Rev A」が検出されるはずです。 よろしくお願いいたします ロビン

S32DS 应用中无法检测到 S32K344 HMS 板。 在 S32DS 中，我能够构建我的项目，但在 S32k3 板上进行调试或烧录时，我无法在 PEMicro 调试器的端口选项中检测到该 S32K3 板。即使按照正常方式，我通过 USB 电缆连接检查设备管理器是否显示已连接，但设备管理器也无法检测到这块 S32K344 HMS 板。#S32k344             Re: Unable to detect S32K344 HMS Board in S32DS application. 你好@Amit8863 板载LED指示灯似乎工作正常。 会不会是另一个 S32DS 实例或其他 IDE 当前正在使用此调试器？ 然而，板载调试器（ PEMicro OpenSDA 调试驱动程序） ）未出现在设备管理器中。请在插入USB线缆后查看我的设备管理器。请使用带有 D+ 和 D- 信号线的 USB 数据线。 板载调试器由 PEMicro 提供，建议下载最新的“USB 多链路资源安装程序”，该安装程序可从“支持与下载”类别下的“多链路调试探针”页面获得。安装完成后，打开PEFirmwareConfig.exe文件，该文件位于 C:\PEMicro\Multilink_Resources 目录下，用于检查固件版本。选择硬件类型：Multilink ACP Embedded - OnBoard Arm 调试接口然后检查是否有可用更新。 然后，应在 S32DS PEMicro 接口设置的端口字段中检测到“嵌入式多链路 Rev A ”。 此致敬礼， Robin

Errors Updating & Building S32K344 App Code Hub Example I am trying to follow this demo for the FRDM S32K344 board: https://mcuxpresso.nxp.com/appcodehub?search=dm-adc-profiling-freemaster-s32k344  I installed the correct SW dependencies but once I try to click "Update Code and Build Project" I get the following errors. I've tried restarting my PC and S32DS, recreate a new workspace, and check other extensions and nothing has gotten rid of this bug. Thank you kindly in advance for your support! Re: Errors Updating & Building S32K344 App Code Hub Example Hi, the example description states this example was developed using the FRDM Automotive Bundle for S32K3 + S32M27.  Not all the drivers listed below are used in this example. However, at least the following two packages must be properly installed in S32DS 3.6.8 before loading the demo: S32K3 Real-Time Drivers AUTOSAR 4.9, Version 7.0.1 S32K3 FreeMASTER Driver Please make sure that these packages are correctly installed in your S32DS 3.6.x environment. After succesfull drivers installation, the given example can be normally loaded from ACH and execute UpdateCode and Build. BR, Petr  

生成式人工智能的应用：通过智能创新变革企业 生成式人工智能（GenAI）正在迅速改变企业的运营方式、创新方式以及与客户互动的方式。从自动化内容创作和智能聊天机器人到高级数据分析和人工智能驱动的应用，生成式人工智能正在成为现代数字化转型的重要组成部分。 然而，成功应用人工智能不仅仅是实施新技术。它关乎识别正确的商业机会、了解组织面临的挑战以及创造可衡量的价值。 生成式人工智能的日益普及 各行各业的组织都在探索生成式人工智能，以提高生产力、降低运营成本、加快决策速度并提供个性化的客户体验。 根据安永会计师事务所发布的《2025 年印度高管调查报告》，47% 的组织表示在生产环境中拥有多个生成式人工智能用例。这标志着从最初的实验阶段转向了实际的商业实施阶段。 一些关键的采用领域包括： 业务自动化：自动化重复性任务、工作流程和运营流程。 客户体验：开发智能虚拟助手和个性化客户互动。 内容创作：创建营销内容、报告、产品描述和商业沟通材料。 数据智能：从大型数据集中提取洞见，为明智的决策提供支持。 软件开发：加速编码、测试、文档编写和应用程序开发。 人工智能应用面临的挑战 尽管生成式人工智能具有巨大潜力，但企业在采用该技术时仍面临诸多挑战。数据隐私、模型准确性、集成复杂性、基础设施成本和负责任的人工智能治理仍然是重要的考虑因素。 组织还必须确保人工智能生成的输出结果可靠、透明，并符合业务需求。人工监督和持续评估对于建立人们对人工智能系统的信任至关重要。 研究驱动的生成式人工智能应用 Enaviya 认为，成功采用生成式人工智能始于研究、业务理解和正确的技术战略。 从研究和技术的角度来看，研究新兴人工智能模型如何解决现实世界的商业问题非常重要。这包括评估大型语言模型（LLM）、探索功能域特定的 AI 应用、了解自动化机会以及评估 AI 集成的实际影响。 Enaviya 致力于通过生成式人工智能开发、LLM 集成、人工智能代理、定制人工智能应用程序和智能自动化，将这些机遇已翻译为可扩展的业务解决方案。 研究驱动的方法可以帮助组织摆脱对人工智能工具的试验，专注于能够带来可衡量的业务成果的解决方案。 请在本帖中分享您的反馈意见。

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，彼得  

生成型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

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に関して有益な情報は見つかりませんでした。 敬具

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 的有用信息。 亲切的问候

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

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に接続した場合は、そのような問題はありません。あなたはこのような状況に遭遇したことがありますか？