Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
NXP "Power Supply" Summary Page (Japanese blog) Did you know that NXP has power supply products? We have compiled articles on the benefits of using power supply products and the basics of power supplies on this site, so be sure to bookmark it! KeitaNaga_1-1744593225378.png ★If you are looking for a power supply for a microcontroller/processor, click here★ Benefits of using NXP power supply products ・Advantages of using NXP's power management IC (PMIC) for i.MX application processors (MPU) ・Why are NXP's power management ICs (PMIC/SBC) ideal for automotive microcontrollers (S32 series)? ■If you are looking for a power supply for i.MX 8/i.MX 9, click here first! i.MX Target PMIC Introduction to PMIC and Simple usage example More detailed explanation i.MX 8M Plus PCA9450C PCA9450C Introduction Powering Guide AN14246 i.MX 8ULP PCA9460 PCA9460 Introduction Powering Guide AN14468 i.MX 93 PCA9451A PCA9451A Introduction Powering Guide AN14413 i.MX 95 PF09 + PF53 Coming soon Coming soon ★Recommended for beginners ~Power Supply Basics Course Series~★ ■ " How to Select a Power Supply IC - 3 Steps " How to Choose a Power Supply IC? [Part 1] : Step 1 - Selecting a Power Supply IC How to Choose a Power Supply IC? [Part 2] : Step 2 - Check the mounting area How to Choose a Power Supply IC? [Part 3] : Step 3 - Checking the Thermal Design ■ "What is a power supply? - The first step" ・First lesson: Linear regulators ・Part 2: Switching Regulators ・Third Voltage Tracker ・4th Ratiometric Measurement ・5th PMIC and SBC We plan to continue expanding our content! ■ Related information Power management ICs (PMICs) and system basis chips (SBCs) ・Power Management Integrated Circuit (PMIC) ・System Base Chip (SBC) If you have any requests or suggestions for improvements regarding power-related content, please feel free to contact us using the information below. NXP Japan Technical Blog (Japanese) Content Request/Improvement Survey – Fill out the form ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but if you have any inquiries, please contact your NXP distributor or NXP directly. Did you know that NXP has power supply products? We have compiled articles on the benefits of our power supply products and the basics of power supplies on this site, so be sure to bookmark it! i.MX Processors introduction PMIC Japanese blog
記事全体を表示
NXPのモーター制御 ~まとめページ~ (日本語ブログ) NXPのモーター制御に関わる記事をまとめたページです。 MCXマイコンをベースに、モーター制御の基礎から、実際の動かし方まで丁寧に解説しています。   NXPマイコン「MCX A156」を使用したモーター制御 順次公開予定 カテゴリ 記事 基礎編 【基礎編①】開発環境をまるっと解説!これ読めば迷わない! 【基礎編②】永久磁石モータの仕組みと制御 【基礎編③】永久磁石同期モータの仕組みと制御方法 【基礎編④】実践!ベクトル制御の仕組みをブロック図で見てみよう! 【基礎編⑤】モータってどうやって賢く動いてるの?その頭脳を覗いてみよう! 【基礎編⑥】モータパラメータのすべて~PMSMセンサレス制御編~ 【基礎編⑦】たった1個の抵抗で電流を測る「シングルシャント」技術の謎を解く! 実践編 【実践編①】永久磁石同期モータの仕組みと制御方法 【実践編②】永久磁石同期モータの仕組みと制御方法 【実践編③】TBD NXPでは、モーター制御を行うためのソフトウェアを上記のMCX A156以外にも展開しており、様々なマイコンでモーター制御を行うことができます。 以下のサイトにモーター制御ができるマイコンがまとまっているので、ご参照ください。 モータ制御向けのMCUXpresso SDK モーター制御に関連するコンテンツの要望や改善点などございましたら、以下よりお気軽にお問い合わせください。 NXPジャパン 技術ブログ(日本語) コンテンツ要望・改善アンケート – フォーム​に記入する =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。)​ NXPのモーター制御に関わる記事をまとめたページです。 MCXマイコンをベースに、モーター制御の基礎から、実際の動かし方まで丁寧に解説しています。 是非、ブックマークを! MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX Motor Control SW | Downloads 日本語ブログ
記事全体を表示
NXP Zephyr OS - 概述页面(日语博客) 最近,一款相对较新的实时操作系统引起了人们的关注。它名为“Zephyr ® OS”,发音为“Zephyr”。 Zephyr OS 是一款开源实时操作系统,其开发合作和支持得到了世界知名公司的大力支持,而 NXP 自 Zephyr 诞生以来一直是其白金会员。 本页面汇总了使用 Zephyr OS 的实用信息,请充分利用。 Zephyr ®系列(Zephyr OS 入门步骤) 步 文章 1 【Zephyr ®系列】第一部分:最近流行的 Zephyr OS 究竟是一款怎样的操作系统?(日语博客) →首先,让我们来了解一下 Zephyr OS 本身的功能特性。 2 【Zephyr ®系列】第二部分:首次构建与测试(日语博客) →接下来我们实际构建并运行 Zephyr OS。我们将以 FRDM-MCXA153 为例,但同样的步骤也适用于其他开发板。 3 【Zephyr ®系列】第三部分:LED 闪烁和软件复用的第一步(日语博客) →以 LED 闪烁程序为例,体验“传统的硬件相关编码”与“Zephyr 推荐的硬件无关(可扩展)编码”之间的区别。 4 [Zephyr ®系列] 第 4 部分:Kconfig 和设备树的概述及实际应用(日语博客) →对于传统的MCU软件工程师来说,“Kconfig”和“设备树”是Zephyr操作系统中比较陌生的概念。本文将通过实际示例进行解释。 Zephyr实用信息☕ 概述 文章 我使用 NXP 的 GUI 生成工具“GUI Guider”(支持用于微控制器的轻量级 GUI 库“LVGL”)生成了一个示例 GUI 代码,然后在 Zephyr OS 上运行了它。 试用 UI:Zephyr OS 上的 GUI Guider 示例代码(日本博客) *有关如何使用 GUI Guider 的说明,请参阅以下文章。 GUI Guider入门指南(Nexty Electronics Co., Ltd.) Zephyr 附带丰富的示例代码,其中包括一个易于运行的 HTTP 服务器示例。本指南提供了在 NXP 评估板“ FRDM-MCXN947 ”上运行该示例的分步说明。运行此示例后,您可以通过 PC 的 Web 浏览器访问 FRDM-MCXN947,并使用页面上的按钮打开/关闭板上的 LED 灯。 我尝试在 FRDM-MCXN947 上运行 Zephyr HTTP 服务器(日本博客) 截至2026年3月23日,NXP工程师发现安装最新版Zephyr环境后,调试器无法启动。本文档详细介绍了该问题及其解决方案。 使用 Zephyr OS(4.3.99 开发版)和 MCUXpresso for VSC 时,调试器是否无法启动?本文将解释如何避免调试器启动错误。(日语博客) 合作伙伴 Zephyr 相关信息 合作伙伴/概览 文章 Lineo Solutions Co., Ltd. 本文分两部分发表了使用 NXP 评估板“ MIMXRT1170-EVKB ”的说明文章:第 1 部分和第 2 部分。 在第一部分中,我们对 Zephyr 进行了基本解释,并介绍了源代码树结构以及用于验证本文运行情况的 NXP MIMXRT1170-EVKB 评估板。 在第二部分中,我们将从准备 Zephyr 环境开始,并解释构建和运行 Zephyr 应用程序的步骤。 第三部分还包括在液晶屏幕上实际显示信息的示例。   Zephyr博客,第一部分:我的第一辆Zephyr(第一部分) Zephyr博客,第二部分:我的第一辆Zephyr(第二部分) Zephyr博客,第三部分:“试用液晶显示屏” IT Access有限公司 本文档清晰地阐述了 Zephyr OS 的基本特性、与传统实时操作系统 (RTOS) 和 Linux 的区别,以及其适用的应用场景。随后,以恩智浦 (NXP) 的高性能微控制器评估板“ MIMXRT1060-EVKC ”为例,介绍了将 Zephyr 与安全引导加载程序“MCUboot”相结合的实际开发流程。通过实际硬件上的构建、烧录和固件更新等步骤,您可以了解使用 Zephyr 进行安全嵌入式系统开发的具体步骤。 什么是 Zephyr OS?本文将解释其特性、优势以及与其他实时操作系统和 Linux 的区别。 在 NXP ® MIMXRT1060-EVKC 上使用 Zephyr ®和 MCUboot 入门:安全启动 IAR Systems Co., Ltd. 我们经常收到用户关于无法配置 IAR 工具链的咨询。右侧链接提供了基于 NXP MCU 的“Zephyr x IAR 工具链”的详细日语配置步骤说明。 Zephyr 项目文档(英文版)中也包含了如何使用 IAR ARM 工具链的说明。   在 NXP 的 FRDM_MCXN947 上运行 ZephyrOS! 在 NXP 的 FRDM-MCXA153 上运行 Zephyr OS! 在 NXP 的 MIMXRT1020-EVK 上运行 Zephyr OS! 如果您对 Zephyr OS 相关内容有任何改进要求或建议,请随时使用以下信息与我们联系。 NXP日本技术博客(日语)内容请求/改进调查——请填写表格 =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便,我们深表歉意,但 在进行咨询时, 请 参考“ NXP 技术问题 - 如何联系我们 ( 日语博客 ) ” 。 (如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ,您可以直接咨询您的代表。 ) 最近,一款相对较新的实时操作系统引起了人们的关注。它名为“Zephyr ® OS”,发音为“Zephyr”。 Zephyr OS 是一款开源实时操作系统,其开发合作和支持得到了世界知名公司的大力支持,而 NXP 自 Zephyr 诞生以来一直是其白金会员。 本页面汇总了使用 Zephyr OS 的实用信息,请充分利用。 i.MX RT 处理器 i.MX 处理器 MCX SW | 下载 日本博客
記事全体を表示
NXP电机控制 - 概要页面 - (日语博客) 本页面汇总了与恩智浦半导体电机控制相关的文章。 本书以MCX微控制器为基础,详细解释了从电机控制基础知识到实际操作方法的所有内容。   使用NXP微控制器“ MCX A156 ”进行电机控制 计划发布 类别 文章 基础知识 【基础知识(一)】开发环境的完整讲解!阅读本文,您就不会迷路! 【基础知识(二)】永磁电机的机理与控制 【基础知识(三)】永磁同步电机的机理及控制方法 【基础知识 第4部分】练习!让我们用框图来了解矢量控制的工作原理! 【基础知识 第5部分】电机是如何如此智能地工作的?让我们来看看它们的“大脑”! 【基础知识 第6部分】电机参数详解 - 永磁同步电机无传感器控制 【基础知识 第 7 部分】揭开“单分流”技术的神秘面纱,只需一个电阻即可测量电流! 实用版 【实践部分1】永磁同步电机的机理及控制方法 【实践部分2】永磁同步电机的机理及控制方法 【练习第三部分】待定 NXP 提供的电机控制软件不仅限于上面提到的 MCX A156,还支持使用各种微控制器进行电机控制。 以下网站列出了能够进行电机控制的微控制器;请参考该网站。 MCUXpresso 电机控制 SDK 如果您对运动控制相关内容有任何改进要求或建议,请随时使用以下信息与我们联系。 NXP日本技术博客(日语)内容请求/改进调查——请填写表格 =========================== 我们目前无法 回复 此帖子“ 评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问, 请 参考“ 如何就 技术问题 联系 NXP ( 日语 博客 ) ” 。 (如果您已经是 恩智浦的 分销商或 与 恩智浦 有业务往来 ,您可以直接联系负责人。 ) 本页面汇总了与恩智浦半导体电机控制相关的文章。 本书以MCX微控制器为基础,详细解释了从电机控制基础知识到实际操作方法的所有内容。 请收藏! MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX 电机控制 SW | 下载 日本博客
記事全体を表示
NXP's Zephyr OS - Summary Page (Japanese Blog) There's a relatively new RTOS that's been attracting attention recently. It's called "Zephyr ® OS," pronounced "Zephyr." Zephyr OS is an open-source RTOS that has seen a surge in development cooperation and support from world-renowned companies, and NXP has been a platinum member since Zephyr's inception. This page compiles helpful information for using Zephyr OS, so please make use of it. Zephyr ® Series (Steps to get started with Zephyr OS) Step article 1 [Zephyr ® Series] Part 1: What kind of OS is the recently popular Zephyr OS? (Japanese Blog) →First, let's learn about the features of Zephyr OS itself. 2 [Zephyr ® Series] Part 2: First Build and Testing (Japanese Blog) →Let's actually build and run Zephyr OS. We'll use FRDM-MCXA153 as an example, but the same procedure can be used with other boards. 3 [Zephyr ® Series] Part 3: First Steps in Blinking an LED and Software Reusability (Japanese Blog) →Using an LED blinking program as an example, experience the difference between "traditional hardware-dependent coding" and "Zephyr's recommended hardware-independent (scalable) coding." 4 [Zephyr ® Series] Part 4: Overview and Practical Applications of Kconfig and Device Trees (Japanese Blog) →For traditional MCU software engineers, "Kconfig" and "device tree" are unfamiliar aspects of Zephyr OS. These will be explained with practical examples. Zephyr Useful Information☕ overview article I used NXP's GUI generation tool "GUI Guider," which supports the lightweight GUI library "LVGL" for microcontrollers, to generate a sample GUI code, and then ran it on Zephyr OS. Trying out UI: GUI Guider sample code on Zephyr OS (Japanese blog) *For instructions on how to use GUI Guider itself, please refer to the following article. Getting Started with GUI Creation Using GUI Guider (Nexty Electronics Co., Ltd.) Zephyr comes with a wealth of sample code, including an HTTP server sample that is easy to run. This guide provides step-by-step instructions on how to run it on the NXP evaluation board " FRDM-MCXN947 ". Running this sample will allow you to access the FRDM-MCXN947 from your PC's web browser and turn the LEDs on the board ON/OFF using buttons on the page. I tried running Zephyr HTTP Server on FRDM-MCXN947 (Japanese blog) As of March 23, 2026, NXP engineers encountered an issue where the debugger could not be launched after installing the latest Zephyr environment. This document details the problem and its solution. Is the debugger failing to start when running Zephyr OS (4.3.99 development version) with MCUXpresso for VSC? This article explains how to avoid the debugger startup error. (Japanese blog) Partner Zephyr-related information Partners / Overview article Lineo Solutions Co., Ltd. An explanatory article using NXP's evaluation board " MIMXRT1170-EVKB " has been published in two parts: Part 1 and Part 2. In the first part, we provide a basic explanation of what Zephyr is, as well as introducing the source tree structure and the NXP MIMXRT1170-EVKB evaluation board used to verify the operation of this article. In the second part, we will start with preparing the Zephyr environment and explain the procedures for building and running applications for Zephyr. The third installment also includes examples of actually displaying information on an LCD screen.   Zephyr Blog, Part 1: My First Zephyr (Part 1) Zephyr Blog, Part 2: My First Zephyr (Part 2) Zephyr Blog, Part 3: "Trying out an LCD display" IT Access Co., Ltd. This document clearly explains the basic features of Zephyr OS, its differences from conventional RTOSs and Linux, and the use cases it is suitable for. It then introduces practical development procedures combining Zephyr with the secure bootloader "MCUboot," using NXP's high-performance microcontroller evaluation board " MIMXRT1060-EVKC " as an example. Through the process from building and flashing to firmware updates using actual hardware, you can understand the concrete steps of secure embedded system development using Zephyr. What is Zephyr OS? An explanation of its features, advantages, and differences from other RTOSs and Linux. Getting started with Zephyr ® and MCUboot on NXP ® MIMXRT1060-EVKC: Secure Boot IAR Systems Co., Ltd. We often receive inquiries from users who are unable to configure the IAR Toolchain. The link on the right provides a clear explanation in Japanese of the procedure using "Zephyr x IAR Tool Chain" based on an NXP MCU. Instructions on how to use the IAR ARM Toolchain are also included in the Zephyr Project Documentation (in English) .   Running ZephyrOS on NXP's FRDM_MCXN947! Running Zephyr OS on NXP's FRDM-MCXA153! Running Zephyr OS on NXP's MIMXRT1020-EVK! If you have any requests or suggestions for improvements regarding content related to Zephyr OS, please feel free to contact us using the information below. NXP Japan Technical Blog (Japanese) Content Request/Improvement Survey – Fill out the form =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) There's a relatively new RTOS that's been attracting attention recently. It's called "Zephyr ® OS," pronounced "Zephyr." Zephyr OS is an open-source RTOS that has seen a surge in development cooperation and support from world-renowned companies, and NXP has been a platinum member since Zephyr's inception. This page compiles helpful information for using Zephyr OS, so please make use of it. i.MX RT Processors i.MX Processors MCX Victoria | Downloads Japanese Blog
記事全体を表示
NXP Motor Control - Summary Page - (Japanese blog) This page compiles articles related to NXP's motor control. Based on the MCX microcontroller, this book provides a detailed explanation of everything from the basics of motor control to how to actually operate it.   Motor control using NXP microcontroller " MCX A156 " Planned release category article Basics [Basics Part 1] A complete explanation of the development environment! Read this and you won't get lost! [Basics Part 2] Mechanism and control of permanent magnet motors [Basics Part 3] Mechanism and control method of permanent magnet synchronous motor [Basics Part 4] Practice! Let's see how vector control works using a block diagram! [Basics Part 5] How do motors work so intelligently? Let's take a look at their brains! [Basics Part 6] All about motor parameters - PMSM sensorless control [Basics Part 7] Unraveling the mysteries of "single shunt" technology that measures current with just one resistor! Practical Edition [Practical Part 1] Mechanism and control method of permanent magnet synchronous motor [Practical Part 2] Mechanism and control method of permanent magnet synchronous motor [Practice Part 3] TBD NXP offers motor control software for more than just the MCX A156 mentioned above, allowing motor control with a variety of microcontrollers. The following website lists microcontrollers capable of motor control; please refer to it. MCUXpresso SDK for Motor Control If you have any requests or suggestions for improvements regarding motor control-related content, please feel free to contact us using the information below. NXP Japan Technical Blog (Japanese) Content Request/Improvement Survey – Fill out the form =========================== We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may contact the person in charge directly. ) This page compiles articles related to NXP's motor control. Based on the MCX microcontroller, this book provides a detailed explanation of everything from the basics of motor control to how to actually operate it. Please bookmark it! MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX Motor Control SW | Downloads Japanese blog
記事全体を表示
NXPのZephyr OS ~まとめページ~ (日本語ブログ) 最近注目を集める比較的新しいRTOSがあります。それが「Zephyr® OS」です。読み方は、「ゼファー」です。 このZephyr OSは、世界の名だたる有名企業がこぞって開発協力やサポートを強化しているオープンソースのRTOSで、NXPはこのZephyr設立当初からのプラチナメンバーとして活動しています。 本ページでは、Zephyr OSを使うためのお役立ち情報をまとめていますので、是非ご活用ください。 Zephyr® シリーズ (Zephyr OSを始めるためのステップ)  ステップ 記事 1 [Zephyr® シリーズ] 第1回 最近流行りのZephyr OSってどんなOS?(日本語ブログ) →先ずはZephyr OS自体の特長を知ろう。 2 [Zephyr® シリーズ] 第2回 はじめてのビルドと実機動作(日本語ブログ) →実際にZephyr OSをビルドして動かしてみよう。FRDM-MCXA153を例にしていますが、他のボードでも同様の手順で動作できます。 3 [Zephyr® シリーズ] 第3回 初めてのLチカとソフトウェアの再利用性(日本語ブログ) →Lチカプログラムを例に、「従来のハードウェア依存のコーディング」と「Zephyrが推奨するハードウェア非依存(スケーラブル)なコーディング」の違いを体感。 4 [Zephyr®シリーズ] 第4回 Kconfigとデバイスツリーの概要と実践的活用法 (日本語ブログ) →従来のMCUソフトウェアエンジニアにとってZephyr OSの慣れない要因として、「Kconfig」、「デバイスツリー」が挙げられます。これらを実例を交えながら解説。 Zephyr お役立ち情報☕ 概要 記事 マイコン向け軽量GUIライブラリ「LVGL」に対応したNXP製GUI生成ツール「GUI Guider」を用いて、生成したGUIサンプルコードをZephyr OS上で実行してみました。 Zephyr OSでUI: GUI Guiderサンプルコードを実行してみる (日本語ブログ) *GUI Guider自体の使い方については、以下の記事もご参考ください。 GUI Guiderを用いたGUI作成のはじめかた (株式会社ネクスティエレクトロニクス) Zephyrで用意されている豊富なサンプルコードの中には、HTTPサーバーのサンプルも含まれており、簡単に動かすことができます。NXPの評価ボード「FRDM-MCXN947」で動作させる手順をステップ・バイ・ステップで解説します。このサンプルを実行するとPCのWebブラウザからFRDM-MCXN947にアクセスして、ページ上のボタンでボード上のLEDをON/OFFできるようになります。 Zephyr HTTP ServerをFRDM-MCXN947で動かしてみた (日本語ブログ) 2026年3月23日現在、NXPのエンジニアが最新のZephyr環境をインストールした際、デバッガを起動できなかったため、その問題と解決策を掲載。 MCUXpresso for VSCでZephyr OS (4.3.99開発中バージョン)を動かすとデバッガが起動しない?デバッガ起動エラーの回避手順を解説 (日本語ブログ) パートナー様 Zephyr関連情報 パートナー様 / 概要 記事 リネオソリューションズ株式会社 NXPの評価ボード「MIMXRT1170-EVKB」を用いた解説記事が、前編・後編の2回に分けて掲載されています。 前編では、Zephyrとは何かという基本的な解説に加え、ソースツリー構成や、本記事の動作確認に使用した NXP MIMXRT1170-EVKB 評価ボードを紹介しています。 後編では、Zephyr環境の準備から始め、Zephyr用アプリケーションの構築および実行手順を解説。 第三回では、実際にLCDに表示を行う例も紹介されています。   Zephyrブログ 第一回 はじめての Zephyr(前編) Zephyrブログ 第二回 はじめての Zephyr(後編) Zephyrブログ 第三回 「LCD に表示してみる」 アイティアクセス株式会社 Zephyr OSの基本的な特徴や、従来のRTOSやLinuxとの違いを整理し、どのようなユースケースに適しているのかを分かりやすく解説されています。続いて、NXPの高性能マイコン評価ボード「MIMXRT1060-EVKC」を例に、Zephyrとセキュアブートローダ「MCUboot」を組み合わせた実践的な開発手順を紹介しています。実機を用いたビルドから書き込み、ファームウェア更新までの流れを通じて、Zephyrを用いたセキュアな組込みシステム開発の具体像を理解できます。 Zephyr OSとは?特徴・利点・他のRTOSやLinuxとの違いを解説 NXP® MIMXRT1060-EVKCで始めるZephyr®と MCUbootによるセキュアブート IARシステムズ株式会社 IAR Toolchainを設定できないといった相談をユーザーからいただきますが、右のリンクにて、NXP MCUをベースに「Zephyr x IAR Tool Chain」を用いた手順を分かりやすく日本語で解説されています。 Zephyr Project DocumentにもIAR ARM Toolchainの使用方法(英語)が掲載されています。   NXPのFRDM_MCXN947でZephyrOSを動かす! NXPのFRDM-MCXA153でZephyr OSを動かす! NXPのMIMXRT1020-EVKでZephyr OSを動かす! Zephyr OSに関連するコンテンツの要望や改善点などございましたら、以下よりお気軽にお問い合わせください。 NXPジャパン 技術ブログ(日本語) コンテンツ要望・改善アンケート – フォーム​に記入する =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。)​ 最近注目を集める比較的新しいRTOSがあります。それが「Zephyr® OS」です。読み方は、「ゼファー」です。 このZephyr OSは、世界の名だたる有名企業がこぞって開発協力やサポートを強化しているオープンソースのRTOSで、NXPはこのZephyr設立当初からのプラチナメンバーとして活動しています。 本ページでは、Zephyr OSを使うためのお役立ち情報をまとめていますので、是非ご活用ください。 i.MX RT Processors i.MX Processors MCX SW | Downloads 日本語ブログ
記事全体を表示
Visualize and control variables in FreeMASTER 1 Table of Contents • Overview • Context • Connecting to the Board • Handling Project Variables • Setting Up the Oscilloscope • Setting Up the Recorder • References • Conclusion 2 Overview This article explains how to use the FreeMASTER desktop application to connect to a running embedded target, browse and add application variables, monitor their values in real time, and visualize signals using the Oscilloscope and Recorder features. Why Is This Important? FreeMASTER provides a non-intrusive way to interact with a running embedded application. Variables can be read and modified while the application continues to run, making the tool useful for parameter tuning, system validation, debugging, and building interactive dashboards. Who Is This Article For? This article is intended for: Embedded developers who need to monitor and tune application variables while their application is running. Users who have an embedded application running on a target board and want to interact with it using FreeMASTER. Note: It is assumed that the application includes the FreeMASTER Driver — this part was covered in Using FreeMASTER block in Simulink. After reading this article, you will be able to: Connect the FreeMASTER desktop application to a target board. Add and manage application variables. Monitor variable values in real time. Use the Oscilloscope and Recorder features to visualize and analyze signal data. 3 Context FreeMASTER is a Windows-based desktop application that communicates with an embedded target through a serial interface. It uses a proprietary master-slave communication protocol, where the PC application issues requests and the target returns responses without disrupting the execution of the embedded firmware. FreeMASTER identifies application variables using the ELF file generated during the build process. When DWARF debug information is included, the ELF file contains symbolic information, including variable names, data types, and memory addresses. FreeMASTER uses this information to automatically locate and access application variables on the target system. 4 Connecting to the Board When FreeMASTER is launched, a new project is created automatically. Soft_Big_Screen.png To configure the communication interface, navigate to Tools → Connection Wizard. 3.1 Selecting the Communication Port Type The first page of the wizard asks you to select the communication port type. Choose the option that matches the interface configured in your embedded application. FM_Article_Img1.png For applications built with NXP's Model-Based Design Toolbox, such as the one described in the previous article, the FreeMASTER Driver is typically configured to use LPUART over USB-CDC. In this case, select "Use direct connection to on-board USB port", which is the most common connection method for NXP evaluation boards. 3.2 Selecting the COM Port and Baud Rate On the next page, select the COM port assigned to the board and the baud rate configured in the embedded application. Click Next to complete the wizard. Communication starts automatically once the wizard is finished. FM_Article_Img2.png Note: The baud rate must match the value configured on the target. If the values do not match, communication cannot be established. 3.3 Loading the ELF File After the connection is established, FreeMASTER prompts you to load an ELF or MAP file to resolve application symbols. Click Yes and browse to the .elf file generated during the build process. FM_Article_Img3.png If you dismiss the prompt or need to update the file later, navigate to Project → Options → MAP Files, click New, and select the appropriate ELF file. FM_Article_Img4.png Note: The ELF file must be built with DWARF debug information enabled. Without DWARF information, FreeMASTER cannot resolve variable names, addresses, nor data sizes. 5 Handling Project Variables 4.1 Adding Variables Variables are added through Project → Variables. In the Variables List dialog, click New to open the Variable Definition dialog. Enter the variable name in the Address field. FreeMASTER searches the symbols loaded from the ELF file and displays matching variable names in a dropdown list. Select the desired variable, configure the sampling period, and click OK. FM_Article_Img5.png Variables are read-only by default. To enable write access, open the Variable Definition dialog, switch to the Modifying tab, and enable the write option. Once write access is enabled, the variable value can be edited directly from the Variable Watch panel while the application is running. 4.2 Variable Watch The Variable Watch panel displays the current values of selected variables in real time. To choose which variables are displayed, right-click the Variable Watch panel and select Watch Properties. In the Project Block Properties dialog, open the Variable Watch tab. All variables defined in the project are listed under Available variables. Select the variables you want to monitor and click Add to move them to the Watched variables list. FM_Article_Img6.png Once configured, the Variable Watch panel continuously reads the selected variables from the target and updates their values in real time. For variables with write access enabled, you can modify their values directly from the panel by clicking the value field and entering a new value. 6 Setting Up the Oscilloscope The Oscilloscope displays application variables as live waveforms. As new data is received from the target, the display updates continuously, making it useful for monitoring signal changes and system behavior over time. To create an Oscilloscope view, right-click the project node in the Project Tree and select Create Oscilloscope. FM_Article_Img7.png In the Variables tab, click Add Variable and select the variables you want to display. Each variable is assigned a color and can be configured with its own Y-axis range and trigger settings. FM_Article_Img8.png Once configured, the Oscilloscope displays a live waveform for each selected variable, allowing you to monitor signal behavior in real time. FM_Article_Img9.png 7 Setting Up the Recorder The Recorder captures variable data directly on the MCU using a dedicated RAM buffer. Unlike the Oscilloscope, which receives data through periodic polling from the PC, the Recorder samples variables at the application's execution rate. Because sampling is controlled by the MCU, all samples are evenly spaced and deterministic. This makes the Recorder particularly useful for capturing fast-changing signals and time-critical events where sample accuracy is important. To create a Recorder, right-click the project node in the Project Tree and select Create Recorder. FM_Article_Img7.png In the Variables tab, click Add Variable to select the variables you want to record and configure their Y-axis ranges. The Variable Trigger Properties section allows you to configure a trigger condition to start a capture when a specific event occurs. You can select the trigger threshold value, and edge type (rising or falling). More advanced triggering settings can be set in the Recorder Trigger tab.  FM_Article_Img10.png After configuration, the Recorder monitors the selected trigger condition. Until the trigger event occurs, no data is displayed. Once triggered, the complete dataset is retrieved from the board and plotted as a line chart. FM_Article_Img11.png Note: Auto run is enabled by default and re-arms the recorder automatically after each download for continuous captures. 8 References FreeMASTER Home Page FreeMASTER User Guide Using FreeMASTER block in Simulink 9 Conclusion In this article, you learned how to connect FreeMASTER to an embedded target, load application symbols from an ELF file, monitor variables using the Variable Watch panel, and visualize signal data with the Oscilloscope and Recorder. These features provide a powerful and non-intrusive way to observe and tune a running application without stopping firmware execution. In the next article, we will explore FreeMASTER Lite and the JSON-RPC API, showing how to build custom web-based dashboards that communicate directly with an embedded application from a browser. Plot embedded data in a Chart or Gauge in a Web Browser
記事全体を表示
Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. 1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. _MBDT_One_Slider_2026.jpg Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. [02.16]NXP AutoWorks Tools Suite 26.jpg Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Front & Rear Lights System Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control Architecture (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Other Guides Getting Started with FRDM-A-S32K312 using Model-Based Design  A1: Interacting with Digital Inputs Outputs on MR-CANHUBK344 A2: Sending data via UART and monitoring signals with FreeMASTER A3: Controlling LED intensity with ADC and PWM A4: Communicating over the CAN Bus   Note: This index is updated as new articles are published.
記事全体を表示
MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hi, I am working with the MR-CANHUBK344 and want to use its 100BASE-T1 Automotive Ethernet interface. My first goal is simply to get a working Automotive Ethernet example running on the board before modifying it for my application. I downloaded the official MR_CANHUBK3_IEEE1722 example. This looks suitable because it demonstrates MR-CANHUBK344, 100BASE-T1, TJA1103, GMAC, IEEE 1722 ACF-CAN, CAN/CAN-FD to Ethernet conversion, and FreeRTOS. However, I am facing a toolchain/version compatibility issue. My available environments are: S32 Design Studio 3.5 with S32K3 RTD 3.0.0 S32 Design Studio 3.6.7 with S32K3 RTD 7.0.1 When I import the original MR_CANHUBK3_IEEE1722 project, I can see the source files, but when I try to open the .mex configuration I receive this error: Processor S32K344, the PlatformSDK_S32K3_2022_03 version is not supported by the current version of the tool. For example, FreeRTOS_Toggle_Led_Example_S32K344.mex cannot be opened because it expects PlatformSDK_S32K3_2022_03. I understand that the original MR_CANHUBK3_IEEE1722 demo was developed using an older S32DS/RTD environment. I also tried installing S32 Design Studio 3.4 and downloaded SW32K3_S32DS_3.4.3_D2112.zip. However, I currently cannot activate S32DS 3.4 because my NXP account does not show a v3.4 license entitlement. Could you please help me with one of the following? Is there a working MR-CANHUBK344 IEEE1722 project for S32DS 3.5 and RTD 3.0.0? Is there an updated MR-CANHUBK344 Automotive Ethernet example for S32DS 3.6.x and a newer RTD version? For now, I only need a simple Automotive Ethernet demonstration where two MR-CANHUBK344 boards establish a 100BASE-T1 link and transmit/receive basic Ethernet frames using the S32K344 GMAC and TJA1103. I do not need SOME/IP, TSN, or a complex TCP/IP application at this stage. If there is a working S32DS 3.5 port of MR_CANHUBK3_IEEE1722, an updated project, or a migration guide, please share it. Or, If you could help me in activating the license. I clicked on the download and didn't receive any e-mail for the version 3.4. I got one e-mail for 3.6 though.  Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hello @Aaditya773 , The original MR_CANHUBK3_IEEE1722 demo was released for an older S32DS / RTD environment, so the .mex incompatibility with newer S32DS 3.5 / 3.6.x versions is expected. I cannot confirm that an officially released migrated version of this exact IEEE1722 ACF-CAN demo is available for S32DS 3.5 or S32DS 3.6.x / RTD 7.0.1. For your current goal, which is to bring up the 100BASE-T1 Ethernet interface first, I would recommend starting from a newer Ethernet example rather than directly migrating the old IEEE1722 project. There is an MR-CANHUBK344 lwIP example available on NXP Community: Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600. This example is based on lwip_FreeRTOS_s32K344, was adapted for the MR-CANHUBK344 board and demonstrates pinging the lwIP stack. However, this example was prepared for an RTD 6.0.0-based setup. Therefore, for RTD 7.0.1 I would use it mainly as a reference, not as a project to be imported directly. A cleaner approach is to start from the current lwip_FreeRTOS_s32k344 example delivered with your installed TCP/IP stack and then adapt the MR-CANHUBK344-specific parts from the community example, mainly the GMAC / MII port mapping, pin configuration, clocks, interrupts, and TJA1103-related setup. As another reference, you may also use the S32K344_gptp_ds example from package SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip I have made a quick check with the following software configuration: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip After a few small fixes in the S32 Configuration Tools configuration, the S32K344_gptp_ds example can be built in this environment. Please note that this is not a direct port of the original IEEE1722 ACF-CAN demo. It is rather a practical path for basic 100BASE-T1 Ethernet bring-up on MR-CANHUBK344 using a newer software environment. To make the discussion easier to follow and useful for other users as well, let us keep this thread focused on the MR-CANHUBK344 Ethernet / 100BASE-T1 bring-up topic. If you need support for any other issue, please kindly create a separate Community thread.   Best regards, Pavel
記事全体を表示
S32K3 STANDBY + FIRC + Watchdog Hello, I am trying to implement standby mode for the S32K3 series (K312) following the examples provided in the community posts by NXP. My project uses an external clock source during regular operation and configures the watchdog timer. It is my understanding from the documentation/examples that before entering STANDBY mode I must switch to using the FIRC. If I switch to FIRC before entering STANDBY, the watchdog timer triggers, resetting the MCU. Is this expected behaviour? Additionally, if I disable the watchdog, the MCU does go into a low-power state, but will not not reset from a wakeup source. Meanwhile, if I directly enter STANDBY without switching to FIRC, the watchdog does not trigger a reset and the MCU goes into a low-power state and will reset from a wakeup source, as one would expect from STANDBY. Evidently, it seems at first glance that approach 2 (not switching to FIRC) works, but I would like to clarify as I am witnessing peculiar behaviour with pad keeping. If I toggle a pad high before entering STANDBY(approach 2), regardless of whether pad keeping is enabled or disabled for the pad, it remains high after the MCU has entered STANDBY. This has me questioning if the MCU is truly entering STANDBY, or is in some intermediary state. I realize this post is rather vague - do let me know what additional context I can provide. With regards, Hareesh Re: S32K3 STANDBY + FIRC + Watchdog Hello @Hareesh_S, Firstly, before entering Standby, the system clock source must be changed to FIRC at 48 MHz because PLLDIG is not available in Standby mode. If this sequence is not followed, this may result in unexpected/undefined clock behavior.  If I switch to FIRC before entering STANDBY, the watchdog timer triggers, resetting the MCU. Is this expected behaviour? Additionally, if I disable the watchdog, the MCU does go into a low-power state, but will not not reset from a wakeup source. By default, POR_WDG is enabled for standby entry/exit sequence monitoring for stuck scenarios: Julin_AragnM_0-1785518283148.png Does this behavior happen with the provided examples in community? Are you using RTD APIs to change clock source?  S32K3 Low Power Management AN and demos Example S32K312 STANDBY wake up using CAN-0-RX and GPIO Switch DS3.5 RTD300 [RTD600 IP] S32K312EVB-Q172 Standby RAM GPIO Wake-up If I toggle a pad high before entering STANDBY(approach 2), regardless of whether pad keeping is enabled or disabled for the pad, it remains high after the MCU has entered STANDBY. This has me questioning if the MCU is truly entering STANDBY, or is in some intermediary state. 1. All pins will retain its last set states in run mode during standby mode. 2. All pins will be placed to its default states after reset event by default. PadKeeping configuration affects pin state after Standby exit sequence, in between K3's wake-up reset, and user's port initialization, in which pins may enter an uncontrollable state: Julin_AragnM_2-1785519093000.png Best regards, Julián Re: S32K3 STANDBY + FIRC + Watchdog Hello @Julián_AragónM , Apologies for my delayed response. Regarding the pad keeping behaviour - it seems I had misunderstood the intended functionality of padkeeping. I appreciate you clarifying the same. Regarding STANDBY entry - This behaviour is not replicable for the unmodified community examples. The sequence works as expected with the community examples. Additionally, I can now confirm that when switching to FIRC in my project, the MCU hardfaults, and that is why the watchdog triggers a reset. I have managed to replicate this behaviour in a blank project, but cannot figure out what the root cause is. I am attaching the project, could you please check the same and let me know what I am missing? With regards, Hareesh S Re: S32K3 STANDBY + FIRC + Watchdog Hello @Hareesh_S, I'm glad PadKeeping functionality has been cleared up. Regarding your project, after calling Clock_Ip_Init(), I can see a hardfault at Clock_Ip_SetRtcRtccClksel_TrustedCall(). After enabling PRTN1_COFB1_CLKEN[REQ34], I can change clock source through Clock_Ip_Init() API as expected.  Can you try this fix in your project?  Julin_AragnM_0-1786382290784.png Julin_AragnM_1-1786382522241.png Julin_AragnM_2-1786382602253.png Best regards, Julián Re: S32K3 STANDBY + FIRC + Watchdog Hello @Julián_AragónM  After enabling the RTC module/peripheral in the RUN domain switching to the FIRC works as expected and does not trigger a hardfault. I was not expecting RTC to be enabled mandatorily, but nevertheless, much thanks for the quick resolution!
記事全体を表示
So little talk about NXP MCX family Mcus How comes? At the start of the year we have ported some products from obsolete microcontrollers to the NXP MCXA family of microcontrollers. Main motivation for this choice was the long time availability. So I had a few month working with that chip and it's infrastructure. And what can I say: They are pretty good. Price is okay. Dev-Board availability is good. The software stack works. Integration into their Eclipse based IDE is fine (and you are not forced to use it). Yes, there are some warts in the software here and there, but nothing out of the ordinary. Hardware features: Pretty cool. It does all the basics and more. I especially like that they have fifos worth speaking of for nearly all peripherials. Found no silicon bugs so far, even when I used the more obscure features of the chip. Performance is good as well. And yet - you find nearly to no posts about these chips. How comes? MCXC Re: So little talk about NXP MCX family Mcus Hi @naofomi  Thanks for your interest in the MCXA product family. Since MCXA is a relatively new MCU series, there is naturally less community content and fewer forum discussions available compared to mature product families such as LPC and Kinetis. Customers also receive support through other NXP channels, including DFAEs and private support cases. If you have any questions, please feel free to post them here. We will be glad to help and support your development. Thank you. BR Alice
記事全体を表示
Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The compilation logs are attached below. Please advise on how to resolve this issue. DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] NOTE: Installed into sysroot: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g' /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g' -e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image -p -S . | tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/ocxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/pvpanic.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/xilinx_sdfec.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/cxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/fastrpc.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce/uacce.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Okay, thank you very much. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi, @zhijie  Thanks for your reply. I have reproduced the issue, it does not related with current BSP, but from the building system changes I am looking into it and will reply you later once any progress made? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Thanks, @zhijie  Could you also help to share the result of uname -a? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your post. May I know the details of your building environment? It is the first time you built the BSP46? or previously it is correct? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi  @zhijie  I am also facing the same issue, if you ressolved it kindly let us know. ERROR: zlib-1.3.1-r0 do_package: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.12/subprocess.py', lineno: 466, function: check_output 0462: else: 0463: empty = b'' 0464: kwargs['input'] = empty 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): File: '/usr/lib/python3.12/subprocess.py', lineno: 571, function: run 0567: # We don't call process.wait() as .__exit__ does that for us. 0568: raise 0569: retcode = process.poll() 0570: if check and retcode: *** 0571: raise CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image -p -S . | tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/libz.so.1: Cannot create symlink to ‘libz.so.1.3.1’: No such file or directory Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello chenyin:     Is there any update on this build failure issue?     Wait for good news, much appreciated. BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello Chenyin     The problem is resolved, Thanks! BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your reply By checking the logs of the building failure, it seems related with the program changes of the building machine. Would you mind trying the following way? On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3" to make a change of tar version used, the clean the BSP and rebuild it again   BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I was having the same issue and I've figured out the issue is with the tar version build 4 and the downgrading did resolve the error, but the actual issue is the tar and pseudo using openat2() instead of openat for the system call. The poky has already given the patch as far as I've seen, does the NXP has any update on it? I'm currently using LLDP 6.1.22 SDK on the LX2160ARDB_REV2 Board and the same error appears when i try to build rcw using bitbake.  If NXP has upated the pseudo_git.bb to use openat2() instead of openat() as per tar's latest build 4., it will be useful for us as we can update tar to the latest version. Attached the logs for your reference. The bug from yocto-project link is added here  https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 Regards, PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @pvsnsubhash  Thanks for your reply, after my workaround fix for the issue, I had also noticed the pseudo issue and then reported it to our internal team. The corresponding team would review the issue and arrange the schedule for the formal fix. Thanks again for your valuable inputs. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. 1. OK, I understand you are currently using i.MX instead of S32G products 2. You may have a try with the following method:  "sudo apt install tar=1.34+dfsg-1build3" and then clean/rebuild with your Yocto setup 3. If still issues, I suggest waiting for the feedback from your original link, I believe my colleague would help you to solve it based on you i.MX setup BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h  Have you found anything that could help resolve it? This issue is currently blocking our progress, We would really appreciate any update or guidance you can provide. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The issue is because of the tar package in linux getting upgraded to build4 from build3. Downgrade the tar package using the below steps and hold the apt upgrade for that package for now and proceed with your compilation. wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb  sudo apt-mark hold tar After the above steps, you can proceed with your compilation and no such errors will be seen. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h   I am still facing the same issue. I have already raised a query on the forum, but I haven't received any response yet.Link I am attaching the log below for your reference. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. May I know if you met the same issue? would you mind creating a new post with your details logs, we would directly support it ASAP. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I solved this issue in NXP iMX BSP 6.6.36-2.1.0 and 6.12.49-2.2.0 bumping the pseudo_git.bb to 1.9.5 and updating the older-glibc-symbols patch... both copied from the corresponding wrynose recipe (6.18.20-2.0.0). git diff... diff --git a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch index c453b5f735..f42b32b8d9 100644 --- a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch +++ b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch @@ -28,10 +28,10 @@ diff --git a/Makefile.in b/Makefile.in @@ -120,7 +120,7 @@ $(PSEUDODB): pseudodb.o $(SHOBJS) $(DBOBJS) pseudo_ipc.o | $(BIN) libpseudo: $(LIBPSEUDO) - $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_ipc.o $(SHOBJS) | $(LIB) + $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o $(SHOBJS) | $(LIB) - $(CC) $(CFLAGS) $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ + $(CC) $(CFLAGS) -Lprebuilt/$(shell uname -m)-linux/lib/ $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ - pseudo_client.o pseudo_ipc.o \ + pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o \ $(WRAPOBJS) $(SHOBJS) $(LDFLAGS) $(CLIENT_LDFLAGS) diff --git a/pseudo_wrappers.c b/pseudo_wrappers.c diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb index 5f32b3777a..c491f0c97f 100644 --- a/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -1,8 +1,6 @@ require pseudo.inc SRC_URI = "git://git.yoctoproject.org/pseudo;branch=master;protocol=https \ - file://0001-configure-Prune-PIE-flags.patch \ - file://glibc238.patch \ file://fallback-passwd \ file://fallback-group \ " @@ -14,9 +12,9 @@@ SRC_URI:append:class-nativesdk = " file://older-glibc-symbols.patch" SRC_URI[prebuilt.sha256sum] = "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" -SRCREV = "e11ae91da7d0711f5e33ea9dfbf1875dde3c1734" +SRCREV = "0bad85523ff71f1a84cea5fdf72e7f560c4aeed4" S = "${WORKDIR}/git" -PV = "1.9.0+git" +PV = "1.9.5+git" # largefile and 64bit time_t support adds these macros via compiler flags globally # remove them for pseudo since pseudo intercepts some of the functions which will be
記事全体を表示
how to use FLEXPWM on IMXRT1170 using Zephyr? Hi all, I am planning to use Zephyr with IMXRT1176 and use the FLEXPWM to generate PWM signal output. I have read through some of the previous post regard FLEXPWM and XBAR. Needing to init the XBARA for routing FLEXPWM to output for the bare metal codes. Now I am wondering, how does this work in Zephyr? What do I need to define in the device tree? Do I still simply define the FLEXPWM group and the build system handle the XBARA configuration? From my understanding, zephyr uses generic API to set output for PWM, but with such hardware dependencies in the IMXRT117X MCU, how does this work? Manual setup? Is there any example or notes to help clarify on this area? Re: how to use FLEXPWM on IMXRT1170 using Zephyr? Hi @TomC818 , Thanks for your interest in NXP MIMXRT series! In Zephyr, if the selected pin is a normal FLEXPWM alternate function, you only need to enable the corresponding FLEXPWM submodule in devicetree and provide the correct pinctrl. Zephyr’s MCUX PWM driver will apply pinctrl and configure the FLEXPWM through the generic PWM API. The MIMXRT1170 EVK already has such an example using flexpwm1_pwm2 and GPIO_AD_04 as FLEXPWM1_PWM2_A. However, if your design requires routing a FLEXPWM signal through XBARA to an XBAR output pin, the current Zephyr PWM driver does not automatically configure XBARA for PWM. You need to manually configure XBARA in board/application initialization using MCUX SDK APIs, or add a small custom driver/init function to consume an xbar-maps property. Zephyr has an nxp,mcux-xbar binding and some drivers, such as QDEC, use it, but the PWM driver itself does not currently consume xbar-maps. Please refer to the following two key drivers: 1. https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pwm/pwm_mcux.c 2. https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/nxp/qdec_mcux/qdec_mcux.c Best regards, Gavin Re: how to use FLEXPWM on IMXRT1170 using Zephyr? Could you expand on this answer further? The only in-tree use of `xbar-maps` seems to be in /zephyr/samples/sensor/qdec/boards/mimxrt1050_evk_mimxrt1052_hyperflash.overlay Would this be something like using the numerical values of  kXBARA1_InputFlexpwm1Pwm0OutTrig0 -> kXBARA1_OutputFlexpwm1Pwm0Exta ?
記事全体を表示
Compilation Error on imx-95-FRDM unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/xen/gntdev.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/xen/evtchn.h: Cannot open: No such file or directory Re: Compilation Error on imx-95-FRDM Hi @Asadeds  What is your BSP version? I checked it on my Imx95 FRDM and there are no problems. pengyong_zhang_0-1786413970033.png B.R
記事全体を表示
ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi, i tried to run the adt7420 sample demo with frdm_mcxw board, but the print message is "sensor: device not ready.“ after i flashed the image into the target . the hardware setup like below picture for reference  anliu114036_0-1786010612902.png i think the hardware wiring is ok which i followed below description. anliu114036_1-1786010728607.png and you can find the overlay file which i added the board folder like below anliu114036_2-1786010818065.png i also attached the build log file which can help get more information from it.  can you check it and help solve the issue Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hello, hope you are doing well.   From the image you shared, it looks like you are working with a KW47-LOC board, could you please confirm this is the right device? Which Zephyr repo and version you are working with? As you may know, the KW47-LOC board is not directly supported on Zephyr, only the frdm-mcxw72 is. That said, since the chips are compatible, you can work with the frdm-mcxw72 examples and modify the overlay file to adapt it to the KW47-LOC board pins. Checking your overlay configuration, the KW47-LOC board only supports the LPI2C1 module, so you will have to enable the lpi2c1 node in your overlay instead. For the SCL and SDA pins, these are defined in frdm_mcxw72-pinctrl.dtsi as PTB4 and PTB5 for I2C1, I would recommend keeping those since they match the KW47-LOC pins. In order for J2 pin 6 to connect to the target MCU pin PTB4, place J24 2-3 shorted.   Refer to UM12114 for the MikroBUS I2C pinout: Pin 2: INT (Hardware interrupt) on WUU0_P12/PTC7 Pin 5: SCL (I2C clock) on I2C1_SCL Pin 6: SDA (I2C data) on I2C1_SDA   Please also confirm that you have the following configurations enabled in your prj.conf file: CONFIG_I2C=y CONFIG_SENSOR=y CONFIG_ADT7420=y   Best regards, Ana Sofia. Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi Ana Thanks for your support.  Yes, I did work with a KW47-LOC board and try to run the frdm-mcxw72 examples on this board, the Zephyr repo version is v4.4.1. After change the overlay file from I2C0 into I2C1,  it looks the ADT7420 device initialize is ok, but this sensor is still can't read out the right temperature , you can see  below print message from the serial monitor.  anliu114036_0-1786427779708.png here is the latest overlay file and prj.conf file content. anliu114036_1-1786427965565.png anliu114036_3-1786428011874.png Best regards Liu Wei
記事全体を表示
iMX8 Nano Kernel updation from 5.15 to 6.18 Hi  While porting the kernel from 5.15 to 6.18 for the A53 core. facing an issue with rpmsg.  # dmesg -T | grep -Ei 'rpmsg|rproc' [Tue Oct 8 15:42:28 2024] imx rpmsg driver is registered. [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: error -ENOENT: Failed to enable clock [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: probe with driver imx-rproc failed with error -2 [Tue Oct 8 15:42:29 2024] remoteproc remoteproc0: releasing imx-rproc I am getting this error.When i searched this error online i was asked to add dummy clock in the dts as below  imx8mn-cm7 {     compatible = "fsl,imx8mn-cm7";     rsc-da = <0xb8000000>;     clocks = <&clk IMX8MN_CLK_DUMMY>;     mbox-names = "tx", "rx", "rxdb";     mboxes = <μ 0 1                                    μ 1 1                                    μ 3 1>;     memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;     status = "okay";   } Could u please let me is this the only the change required. What is the reason for this change. Regards Yadunath R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 No — I would not treat clocks = <&clk IMX8MN_CLK_DUMMY>; as the only required change. It may be enough to get past the immediate -ENOENT: Failed to enable clock probe failure, but for i.MX8M Nano the important requirement is that the Cortex-M7 root clock must remain enabled when Linux loads/starts the M7 firmware. Reason: The imx-rproc node is expected to have a clock entry; AN5317 shows the i.MX8M remoteproc DTS node with compatible = "fsl,imx8mn-cm7" and a clocks = <...> property, plus mailbox and memory-region entries. Your error means the kernel 6.18 imx-rproc driver tried to get/enable the clock from that node and the clock lookup failed with -ENOENT , so probe aborted before remoteproc0 stayed registered. NXP’s AMP guidance says: “For i.MX 8M platforms, the root clock for M7/M4 must be kept always enabled by Linux to load the firmware code and start Cortex M7/M4.” It also says NXP Linux BSP keeps this root clock enabled when the M core is started from U-Boot; otherwise, if the M core is first started from Linux boot, drivers/clk/imx/clk-composite-8m.c must be updated to skip gate registration for the M core clock. So the change has two possible meanings: Dummy clock as compatibility workaround If kernel 6.18 imx-rproc requires a clocks property but the real M7 clock is intentionally not controlled through common clock framework, adding IMX8MN_CLK_DUMMY can satisfy the driver’s clock handle requirement and avoid -ENOENT . Real clock-control fix If Linux is actually responsible for loading/starting the M7, a dummy clock alone may hide the probe error but not guarantee the M7 clock is enabled. In that case you must ensure the M7/M4 root clock is kept on, either by the NXP BSP clock-driver handling or by the clk-composite-8m.c change described in AN5317. Also verify the rest of the remoteproc/rpmsg DTS, not only the clock line: imx8mn-cm7 {         compatible = "fsl,imx8mn-cm7";         rsc-da = <...>;         clocks = <&clk IMX8MN_CLK_DUMMY>;   /* or the correct M7 clock used by your BSP */         mbox-names = "tx", "rx", "rxdb";         mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;         memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;         status = "okay"; }; The memory-region list is important because AN5317 states that this property must contain the memory sections used by the firmware ELF so remoteproc can reload it from sysfs. Recommended check path: If you start M7 from U-Boot , use the NXP flow such as prepare_mcore / bootaux , then boot Linux; AN5317 says this is the path where the BSP keeps the M core root clock enabled. If you start M7 from Linux remoteproc , confirm your 6.18 clock driver includes the NXP handling to keep the M core root clock always enabled; otherwise the dummy clock may only fix probe, not runtime start/load. Compare your DTS against the NXP imx8mn-*-rpmsg.dts for the same BSP release, especially clocks , mboxes , rsc-da , and reserved-memory layout. The dummy clock explains the immediate -ENOENT probe failure, but the real design requirement is to keep the i.MX8MN M7 root clock enabled; whether DTS alone is sufficient depends on whether your 6.18 BSP clock driver already preserves that clock.
記事全体を表示
ddr_stress_tester cannot work on some DDRs I have been using  ddr_stress_tester tools for many years, this year, I found the tool cannot work well on some newer manufacturing process DDRs, (20nm or 25nm DDRs),  we found that the binary will hang when I select cpu frequency. For example, winbond  w631gu6rb and ISSI IS43TR166640C-125JBLI-TR. by the way  CPU model is mx6solo/dl i.MX6DL Re: ddr_stress_tester cannot work on some DDRs The symptom is more likely tied to the DDR initialization/MMDC setup or board-level margin than to the DDR die process node itself. I could not find an NXP-documented issue that says the i.MX6Solo/DL ddr_stress_tester hangs specifically because the DDR3 is 20 nm/25 nm, nor anything specific to Winbond W631GU6RB or ISSI IS43TR166640C after checking NXP library/community paths by part number, process node, and “CPU frequency” hang wording. What I would check first: Use the i.MX6/7 DDR Tool flow, not an old fixed script The i.MX6/7 DDR tools are intended to generate and test a custom DRAM initialization based on the actual device configuration — density, chip-selects, bus width, board layout/swizzling, etc. — and they explicitly cover i.MX6DL/S devices. If you changed DDR vendors or DDR geometry/timing, regenerate the .inc initialization script using the DRAM Register Programming Aid / DDR tool flow; NXP notes that scripts “may need to be modified for your custom board and memory.” Do not assume old calibration values still apply The stress tool performs write leveling, DQS gating, read/write delay calibration, and stress testing on i.MX6 boards. If it hangs right after selecting frequency, the DDR may already be marginal before calibration can complete. NXP community guidance for similar i.MX6 DDR stress hangs points to incorrect MMDC parameters, power brownout, board noise, or layout issues. Check DDR voltage/mode and frequency selection i.MX6Solo/DualLite DDR pads support LPDDR2 and DDR3/DDR3L modes. For DDR3/DDR3L I/O supply, the i.MX6Solo/DL datasheet excerpt gives OVDD as 1.425–1.575 V for DDR3 and 1.283–1.45 V for DDR3L . The i.MX6 DDR stress tool supports DDR stress testing between 135 MHz and 672 MHz ; select a conservative DDR frequency first, then work upward after calibration passes. Review refresh timing There is an i.MX6 case where low-frequency hang was resolved by correcting MMDC0_MDREF , changing tREFI from 3.9 µs to 7.8 µs . NXP documentation also points to MMDCx_MDREF as the register controlling DDR refresh behavior, and notes that some DDR3 devices require temperature-dependent refresh changes, e.g. 64 ms refresh period at ≤85 °C and 32 ms above 85 °C. Eliminate known tool-environment hang causes If running from U-Boot, disable splash screen / IPU or any DMA that may still access DRAM; NXP notes that active IPU/splash access can make the system hang during the DDR stress flow. Check whether the watchdog fuse/configuration is enabled; NXP notes that on i.MX6Solo the watchdog can reset the device while DDR_Stress_Tester is doing calibration or stress test. If you are using the JTAG version, one reported i.MX6 case stopped after DDR frequency selection, and the guidance was to check JTAG mode/connection and use simple SDK DDR tests plus signal/power probing. My recommendation: regenerate the DDR init script for each new DDR part, start with a lower MMDC/DDR frequency, verify MDREF /timing values against the DDR datasheet, then rerun calibration. If it still hangs at CPU/DDR frequency selection, scope DDR power rails and clocks during that transition and compare MMDC register values between the old working DDR and the new Winbond/ISSI parts. The issue should be treated as an i.MX6Solo/DL DDR initialization and margin problem first; I did not find evidence that NXP identifies 20 nm/25 nm DDR3 process itself as a ddr_stress_tester incompatibility.
記事全体を表示
S32K358 SEMA42 demo 你好!我要使用 SEMA42 模块中的 Gate 寄存器,去写其 GTFSM 字段。需要在 mcal 中去进行使能 SEMA42 操作,目的为在使用的过程中保证对 GTFSM 字段可以正常写入与读取。请帮忙提供一份使用SEMA42的核间通信的demo给我,谢谢!
記事全体を表示
Battery Management System - SW & HW Environment Battery Management System Software and Hardware Environment 0 Table of Contents •Introduction •Software •Hardware •References •Conclusion 1 Introduction This article presents a comprehensive overview of the hardware and software components required to design and implement a high-voltage Battery Management System (BMS). It focuses on solutions based on NXP hardware platforms, combined with the integrated development ecosystems provided by NXP and MathWorks. The objective is to highlight how these technologies work together to streamline system development, deployment, and validation. 2 Software The software environment provides the modeling, simulation, communication, code generation, and deployment capabilities required by the Battery Management System. 2.1 Deep Learning Toolbox SorinIBancila_0-1786527787490.png Deep Learning Toolbox brings artificial intelligence into the model-based workflow. It provides MATLAB functions, apps, and Simulink blocks for designing, training, simulating, and analyzing deep neural networks. This makes AI-based behavior easier to develop, understand, and validate before deployment. In the Battery Management System, deep learning can support battery state estimation, fault detection, and operating-condition classification. The toolbox can create and evaluate neural networks, import pretrained models from PyTorch, TensorFlow, and ONNX, and integrate trained networks into Simulink for system-level simulation. Artificial intelligence is not treated as a separate development activity. Neural network behavior can be simulated and verified together with the battery control model. Networks can also be optimized through quantization, projection, or pruning, and prepared for embedded deployment through automatic code generation. This reduces integration risk and makes AI-based BMS functions easier to validate within the complete system. For more information, see the Deep Learning Toolbox documentation in the References chapter. 2.2 Vehicle Network Toolbox SorinIBancila_1-1786527804953.png Vehicle Network Toolbox brings CAN communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding CAN messages, making network behavior visible and testable before deployment. In the Battery Management System, commands, feedback, and status information are exchanged over CAN, linking the ECU with the surrounding vehicle architecture. The toolbox helps define signal interfaces, pack and unpack CAN messages, simulate bus traffic, and validate communication before target execution. Communication is not treated as a late integration step. CAN interaction can be simulated and verified together with the control model. This reduces integration risk and makes ECU behavior easier to validate end to end. For more information, see the Vehicle Network Toolbox documentation in the References chapter. 2.3 NXP Model-Based Design Toolbox for BMS SorinIBancila_2-1786527835753.png The NXP Model-Based Design Toolbox for BMS extends the NXP Model-Based Design Toolbox for S32K3 with BMS support. It enables configuration and integration of the MC33775A, MC33774A, MC33772C, MC33665A, and MC33664. The S32K3 toolbox includes peripheral blocks that provide access to key microcontroller resources such as ADC, PWM, CAN, SPI, UART, timers, and interrupts. These interfaces facilitate communication between the S32K3 microcontroller and the supported BMS integrated circuits. Together, the toolboxes support the development and deployment of BMS applications on the S32K3 platform, leveraging the underlying S32K3 and BMS software stack. The workflow also integrates with NXP configuration tools and supports real-time monitoring and visualization through FreeMASTER, simplifying application development, validation, and debugging. 3 Hardware The central hardware platform is the 800 V Battery Management System Reference Design using ETPL. The kit contains: RD-K358BMU - Battery Management Unit RD33774CNTEVB - Cell Monitoring Unit RD772BJBTPL8EVB - Battery Junction Box BATT-18EMULATOR - 18-cell battery pack emulator SorinIBancila_3-1786527864628.png 3.1 RD-K358BMU The RD-K358BMU is an NXP reference Battery Management Unit (BMU) designed for evaluation, development, and rapid prototyping of 800 V high-voltage Battery Management System (HVBMS) hardware and software. It provides a representative automotive-grade BMU platform built around the S32K358 microcontroller, enabling developers to evaluate battery-management architectures, safety concepts, communication interfaces, diagnostics, and control strategies in a realistic system environment. The board integrates several NXP components, including the S32K358, FS26, MC33665A, HB2000, TJA1145A, PCA2131, NBP8 and MC12XS6. Together, these components provide the processing, power management, communication, sensing, actuation, diagnostics, and safety capabilities required in a high-voltage BMS application. SorinIBancila_4-1786527890248.png 3.2 Cell Monitoring Unit: MC33774A The RD33774CNT3EVB is a centralized Cell Monitoring Unit (CMU) reference design intended for the development and evaluation of 800 V high-voltage Battery Management System (HVBMS) applications. It uses Electrical Transport Protocol Link (ETPL) communication to connect with the broader BMS architecture and support reliable data exchange within the battery system. The board includes three MC33774 Analog Front End (AFE) devices arranged in a daisy-chain configuration. These AFEs are responsible for measuring and monitoring battery cell parameters, helping developers evaluate cell supervision, diagnostics, and communication strategies in a centralized BMS topology.   SorinIBancila_5-1786527906947.png 3.3 Battery Junction Box: MC33772C The RD772BJBTPL8EVB is a Battery Junction Box (BJB) reference design developed for 800 V high-voltage Battery Management System (HVBMS) applications. It leverages Electrical Transport Protocol Link (ETPL) communication to ensure robust and isolated data exchange within the battery system. The board features two MC33772C battery sensor ICs configured to deliver redundant measurements of voltage and current, improving diagnostic coverage and supporting functional safety requirements. It also performs isolation measurements, which are essential for monitoring insulation integrity and detecting potential fault conditions in high-voltage environments. SorinIBancila_6-1786527924913.png 3.4 18-Cell Battery Pack Emulator The BATT-18EMULATOR board is designed to emulate a multi-cell battery pack and is easily interfaced with MC33774 battery cell controller evaluation boards. It enables quick evaluation of NXP Battery Cell Controller (BCC) ICs and supports software development by providing a controlled and flexible test environment. The board allows users to intuitively adjust the voltage of each of the 18 emulated cells, as well as the voltage levels on selected analog inputs typically used for temperature sensing. This capability makes it particularly useful for validating measurement accuracy, system behavior, and control algorithms without requiring a physical battery pack. Additionally, the BATT-18EMULATOR provides three independent outputs, allowing up to three BCC ICs to be connected simultaneously to a single emulator board. 4 References Deep Learning Toolbox Documentation Vehicle Network Toolbox Documentation NXP Model-Based Design Toolbox 800 V Battery Management System Reference Designs Using ETPL 5 Conclusion This article described the software and hardware environment required for the Battery Management System. The software combines MathWorks model-based design capabilities with NXP BMS and S32K3 platform support. The hardware integrates the S32K3 with NXP battery-cell controllers, communication interfaces, and associated BMS devices. Together, these elements provide the foundation for battery monitoring, communication, algorithm development, code generation, deployment, and validation. Next article: BMS architecture and model description, including the main software components, communication interfaces, data flow, and overall application structure.
記事全体を表示