Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
[MCX A153] LPI2C 新手指南(日语博客) 介绍 本文面向微控制器初学者,讲解了恩智浦半导体 (NXP) MCX A153微控制器的外设功能和使用方法。您将通过实际修改恩智浦提供的 SDK 示例程序来学习基本概念和实现方法。 目录   1. 应用中的常见用法示例(I²C 版) 1.1 主要用途 1.2 使用示例 2. I²C 基础知识 2.1 首先,I²C 是什么? 2.2 微控制器 I²C 模块 3. MCX A153 I²C 模块 (LPI2C) 的主要功能和框图 3.1 概述 3.2 方框图 3.3 功能 4. 使用的设备和开发工具 4.1 评估委员会 (FRDM-MCXA153) 4.2 开发工具(适用于 VS Code 和 IDE 的 MCUXpresso) 5. 编程 5.1 检查基础示例代码的内容 5.2 引脚配置 5.3 程序代码的更改 6. 实践训练 6.1 实践培训内容 6.2 实践练习程序 6.3 在评估板上添加上拉电阻 6.4 编码更改 6.5 使用引脚配置器更改引脚设置 6.6 构建与调试、测试功能   1. 应用中的常见用法示例(I²C 版)   本章要点:我们将研究 I²C 的应用场景。   1.1 主要用途 I²C 是一种通过指定设备内部寄存器地址来读写数据的通信方式。由于它使用的信号线较少,因此适合控制单个电路板上的多个集成电路。然而,它容易受到线路电容和噪声的影响,因此通常用于短距离通信。 连接各种传感器,例如温度传感器、加速度传感器和磁传感器。 数字电位器 IO扩展器 EEPROM 实时控制器 显示设备(LCD、LED 等)的输入/输出扩展 微控制器之间的通信(包含在 FRDM-MCXA153 评估板上的示例程序中) 1.2 使用示例 实际应用包括计算机主板、嵌入式系统和移动电话。   2. I²C 基础知识   本章要点:我们将阐明 I²C 的基本术语,包括 SDA、SCL、地址、ACK/NACK 和上拉电阻。   2.1 首先,I²C 是什么? I²C是由飞利浦半导体(现为恩智浦半导体)开发的一种串行总线通信标准。目前,它被广泛用作连接电路板上传感器和外围集成电路的代表性方法。 I²C 是一种同步串行通信方法,它通过时钟信号同步发送数据。数据线称为 SDA,时钟线称为 SCL。通信通过控制 SDA 和 SCL 的时序来实现。 每个从设备都有一个唯一的地址,主设备通过指定该地址进行通信。通信开始时发送地址后,目标从设备会返回一个 ACK(确认)。如果无法收到 ACK,则不返回 ACK,这称为 NACK(非确认)。 通信采用由起始条件、地址、读/写位、ACK/NACK 和停止条件组成的协议进行。 地址可以采用 7 位模式或 10 位模式。 I²C 是一种开漏协议。上拉电阻使 SDA 和 SCL 通常保持高电平,各个器件在需要时将其拉低。因此,通信线路上必须有上拉电阻。 通常使用微控制器作为主设备。有两种方法可以确定通信是否完成:一种是使用从设备的中断,另一种是轮询方法,即主设备反复检查完成标志。使用中断时,每个从设备都必须有一个中断输出,而主设备必须有一个中断输入。使用中断可以加快响应速度,但会增加硬件资源消耗。 有关 I²C 的更多详细信息,请参阅以下文章。 I²C 总线概述(日本博客) 这次,我们将采用轮询方法来匹配评估板的接线情况。 标准模式下的典型传输速度为 100kbps,快速模式下为 400kbps。MCX A153 还支持快速模式增强版,最高通信速度可达 1Mbps。 主设备向从设备发送数据的步骤如下: 主控端发起通信。 主设备指定从设备地址。 从主站向从站发送数据 主控端终止了通信。 相反,主设备从从设备接收数据的过程如下: 主控端发起通信。 主设备指定从设备地址。 主设备从从设备接收数据。 主控端终止了通信。   2.2 微控制器 I²C 模块 下图显示了微控制器中常见的 I²C 模块的框图。 组件数量并不多。主要组件包括用于发送缓冲区的命令/TX FIFO、用于接收缓冲区的RXFIFO、配置寄存器以及控制通信的控制电路。此外,现在大多数微控制器都内置了噪声滤波器。 3. MCX A153 I²C 模块 (LPI2C) 的主要功能和框图   本章要点:我们将研究通用 I²C 和 MCX A153 的 LPI2C 模块之间的区别。   3.1 概述 到目前为止,我们已经介绍了通用 I²C 的基本原理,但本章将重点介绍 MCX A153 的 LPI2C I²C 模块。LPI2C 的功能远比上述基本 I²C 模块强大。LPI2C 支持以主设备(控制器)和从设备(目标设备)两种身份高效地与 I²C 总线连接。 主要功能如下。 支持标准、高速、高速+、HS模式(仅限目标)和超高速运行模式的逻辑。 通过 DMA 将对 FIFO 的访问卸载到 CPU,从而最大限度地减少了 CPU 开销。 LPI2C 也符合系统管理总线 (SMBus) 规范版本 3。 *注1 MCX A153 参考手册中“主站和控制器”以及“从站和目标站”这两个术语交替使用。虽然现在推荐使用“控制器”和“目标站”,但本文档将统一使用“主站和从站”。 3.2 方框图 MCX A153 的 LPI2C 模块上半部分为主控部分,下半部分为从控部分。SDA 和 SCL 模块也分为主控版和从控版,从控版型号后加“S”,因此分别为 SDAS 和 SCLS。通信也可以通过外部 HREQ 端子或内部触发信号启动。 3.3 功能 LPI2C的功能如下: 标准模式、高速模式、高速+模式、超高速模式 多控制器(包括同步和仲裁) 时钟拉伸 仲裁(当系统有多个控制器时) 7位寻址,10位寻址 软件重置、起始字节、设备 ID(还需要软件支持)。 命令和发送 FIFO(4 个字,8 位发送数据 + 3 位命令) 接收到的 FIFO(4 个字,8 位接收数据) 主机请求输入以控制 I²C 总线传输的启动时间 根据接收到的数据匹配情况生成中断,并拒绝不需要的数据。 用于重复启动条件、停止条件、仲裁丢失、意外 NACK 和命令字错误的标志和可选中断信号。 可配置总线空闲超时和引脚堆栈低电平超时。 独立的I²C目标寄存器 7位或10位寻址 支持中断或DMA请求的发送/接收数据寄存器 ACK 或 NACK 可以通过软件控制。 可以配置时钟拉伸来避免发送 FIFO 欠载和接收 FIFO 过载错误。 数据包终止标志和可选的中断、停止条件或位错误检测。 4. 使用的设备和开发工具   4.1 评估委员会 (FRDM-MCXA153) 本次实践练习将使用 Windows PC 和 MCX A153 的FRDM-MCXA153评估套件(使用 MCUXpresso 的 FRDM-MCXA153 开发板 | NXP Semiconductors)。 FRDM-MCXA153 随附一根 USB Type-C 数据线。点击网站上的“设计文件”即可获取 FRDM-MCXA153 的电路板信息和电路图。(需注册账号) FRDM-MCXA153 配备了P3T1755温度传感器。初始状态下,P3T1755 连接到 I3C0,因此这次我们将更改引脚设置,将其连接到 LPI2C,并使用 LPI2C 读取温度。 由于 P3T1755 和 LPI2C 之间没有连接中断线,因此 LPI2C 将用作轮询主控端。此外,由于 MCX A153 和 P3T1755 的信号线上没有上拉电阻,因此需要添加外部电阻。 4.2 开发工具(适用于 VS Code 和 IDE 的 MCUXpresso) 本文将指导您如何使用 MCUXpresso for VS Code 或 MCUXpresso IDE 编辑和运行 SDK 示例。开发工具是创建项目、编辑代码、配置设置和运行应用程序的环境。本文不涉及工具安装或初始设置;请参阅 NXP 官方指南,获取适用于您环境的具体说明。 5. 编程   本章的关键在于首先理解示例代码的工作原理,然后对其进行修改以使其适用于 P3T1755。   5.1 检查基础示例代码的内容 本文提供了几个 I²C 示例程序。 这次,我们将使用示例程序“lpi2c_edma_b2b_polling_master”,该程序采用轮询作为主控端。我们将修改此示例程序,使其能够通过 I²C 接口读取安装在 FRDM-MCXA153 中的 P3T1755 温度传感器的温度数据。 默认情况下,P3T1755 连接到 I3C 模块 I3C0,但我们将修改程序以切换到 LPI2C 模块,并创建一个使用 LPI2C 读取 P3T1755 温度的程序。 在 FRDM-MCXA153 中,P3T1755 和 LPI2C 之间没有连接中断线,因此必须使用 LPI2C 作为轮询主控端。此外,MCX A153 和 P3T1755 之间的连接线没有上拉电阻,因此必须添加一个上拉电阻。 在这个例子中,LPI2C 实例在一个电路板上作为主设备,在另一个电路板上作为从设备。主设备向从设备发送数据,并从从设备接收数据。本示例验证从从设备接收到的数据是否正确。 沟通流程的总体概要如下: 主控单元发送信号开始通信(启动条件)。 主控端发送从控端地址。 从设备向主设备发送信号(确认),表明它已准备好进行通信。 执行数据通信(根据要发送的数据重复执行) 主控单元发出信号结束通信(停止条件)。 进一步分析发现,控制方式有两种:写控制,用于向从设备写入信息;读控制,用于从从设备读取信息。首先执行写控制,然后执行读控制来读取温度数据。 这是使用轮询方式控制主设备的基本步骤。无论从设备是微控制器的 I²C 模块还是温度传感器等传感器 IC,步骤都相同。 [写入控制] 控制写入操作的步骤如下。所使用的函数及其说明列于下方。 ① 发送起始条件 + 从机地址 + 写位: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 此功能启动新的主模式传输。 ② 发送目标设备的注册地址和数据: LPI2C_MasterSend:I²Cバスにデータを送信。 该函数会等待缓冲区中的数据发送完毕。 ③ 发送停止条件: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 此函数会等待直到收到停止信号,然后交易才会结束。 等它完成。 [读取控件] 读取控制的步骤如下。所使用的函数及其说明也列于此处。 ① 发送起始条件 + 从机地址 + 写位: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 此功能启动新的主模式传输。 ② 发送目标设备的注册地址: LPI2C_MasterRepeatedStart:LPI2C_MasterStart を再度実行する。 该函数通常发送一个寄存器地址。 ③ 发送起始条件 + 从机地址 + 读取位: LPI2C_MasterReceive:I²Cバスからデータを受信。 该函数会等待缓冲区中的数据传输完毕。 ④ 从目标设备接收数据: LPI2C_MasterSend:I²Cバスにデータを送信。 该函数会等待缓冲区中的数据发送完毕。 ⑤ 发送停止条件: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 该函数会一直等待,直到收到停止信号并完成交易。 示例程序“lpi2c_edma_b2b_polling_master”的流程图包含在最后一章末尾的补充说明中,请参考该说明。 此外,虽然MCX A153 API 参考文档中提供了所用函数的解释,但我们已将本示例中使用的函数的解释提取到最后一章末尾的补充说明中。请同时参考该补充说明。 5.2 引脚配置 默认情况下,P3T1755 连接到 I3C 模块的 I3C0 引脚,因此您需要将其更改为 LPI2C 引脚。要更改引脚连接,您可以使用配置工具中的便捷引脚配置器功能。引脚配置器允许您通过图形用户界面 (GUI) 更改引脚分配,甚至可以自动为您生成 C 语言代码。具体操作将在实践练习章节中详细说明。 5.3 程序代码的更改 基本通信流程与示例相同,但从机地址、寄存器地址和数据长度已更改为与 P3T1755 匹配。此外,接收到的 16 位值被转换为温度值。 首先,将从地址更改为 P3T1755 的 0x48U。 示例程序处理 33 字节的数据,但 P3T1755 使用 16 位温度数据,因此我们将数据长度更改为 16 位。 我们定义一个常量来存储从 P3T1755 读取的 16 位温度数据。在这里,我们称之为“温度”。 寄存器地址由 deviceAddress 定义,其值为 0x01U,但在 P3T1755 的情况下,其值为 0x00U。 要传输的数据点数由 txCount 定义,在示例程序中为 0xFFU,但由于从 P3T1755 读取的温度数据为 2 字节(16 位),因此我们将其减少到 0x01U。 在示例程序中,主设备发送数据,从设备发送相同的数据,然后对发送的数据和接收的数据进行比较,但这个过程是不必要的。 相反,需要将从 P3T1755 接收到的数据处理成温度数据。从 P3T1755 接收到的数据为 2 字节(16 位)。接收缓冲区定义为 g_master_rxBuff[1] 和 g_master_rxBuff[0],每个缓冲区包含 1 个字节,因此 g_master_rxBuff[0] 用作高字节,g_master_rxBuff[1] 用作低字节,它们组合成 16 位。组合后的结果存储在 temp 中。 组合温度数据的每一位对应 0.0625°C,因此乘以 0.0625 即可得到温度值。幸运的是,乘以 0.0625 可以通过右移 4 位轻松计算,无需使用浮点运算。计算结果输入到“温度”字段中。 最后,使用 printf 显示主机名。     6. 实践训练   本章重点介绍必要的硬件准备工作以及需要修改 P3T1755 代码的地方,而不是详细介绍工具安装或屏幕操作。   6.1 实践培训内容 此方法使用 LPI2C 读取安装在 FRDM-MCXA153 上的 P3T1755 温度传感器。由于 P3T1755 初始连接到 I3C0,因此需要进行引脚配置才能将其连接到 LPI2C。此外,还必须在 I3C 信号线上添加一个上拉电阻。 该软件基于 LPI2C SDK 示例,对 P3T1755 的从机地址、寄存器地址、数据长度和温度数据的计算过程进行了修改。 6.2 实践培训程序(概述) 将 4.7kΩ 上拉电阻连接到评估板的 SDA 和 SCL 引脚。 在 MCUXpresso 环境下准备一个 LPI2C 示例项目。省略具体的安装和导入步骤。 将引脚设置更改为 P3T1755 所连接的 LPI2C 引脚。 将按照第 6.7 节所示进行以下代码更改。 运行程序并验证是否输出温度值。   6.3 在评估板上添加上拉电阻 P3T1755 的 I²C 总线上有两个结功率放大器 (J20, J21)。将 4.7kΩ 电阻连接到 J20 和 J21,并将 SDA 和 SCL 上拉。 重要的! 内置上拉电阻可能无法提供稳定的通信,具体取决于电路板。为确保通信可靠,请使用外部上拉电阻。 6.4 编码更改 现在我们将把编程章节中解释的概念编写成一个实际的 .c 文件。 现在我们将把“5.3 程序代码的变更”中描述的变更应用到代码中。 (1)将从地址更改为 P3T1755 的 0x48U。 [変更前]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x7EU [変更後]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U (2)将数据长度改为 16 位。 [変更前]#define LPI2C_DATA_LENGTH 33U [変更後]#define LPI2C_DATA_LENGTH 2U (3)定义一个常量“温度”来存储从 P3T1755 读取的 16 位温度数据。 [追加]uint16_t temperature; (4)将寄存器地址 deviceAddress 更改为 0x00U。 [変更前]uint8_t deviceAddress = 0x01U; [変更後]uint8_t deviceAddress = 0x00U; (5)将要传输的数据量 txCount 更改为 0x01U。 [変更前]size_t txCount = 0xFFU; [変更後]size_t txCount = 0x01U; (6)接收数据数量的调整 [変更前]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH - 1); [変更後]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); (7)删除比较发送数据和接收数据的部分。 [削除] /* Transfer completed. Check the data.*/以下のコード (8)从 P3T1755 接收的数据被合并成温度数据。g_master_rxBuff[0] 的高字节和 g_master_rxBuff[1] 的低字节被合并成一个 16 位数组,合并后的结果存储在 temp 中。 [追加] temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; (9)将温度值向右移动 4 位,并将其放入温度变量中。 [追加]temperature = temp >> 4; (10)使用 printf 显示温度。 [追加] PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); (11)最后,我们将添加一个无限循环。 [追加]while (1) {} 下面列出了目前为止所做的更改的完整代码,供您参考。   [全部代码] /* * Copyright 2017 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ /* Standard C Included Files */ #include #include #include "board.h" #include "fsl_debug_console.h" #include "fsl_lpi2c.h" #include "app.h" /******************************************************************************* * Definitions ******************************************************************************/ #define EXAMPLE_I2C_MASTER ((LPI2C_Type *)EXAMPLE_I2C_MASTER_BASE) #define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U #define LPI2C_BAUDRATE 100000U #define LPI2C_DATA_LENGTH 2U /******************************************************************************* * Prototypes ******************************************************************************/ /******************************************************************************* * Variables ******************************************************************************/ uint8_t g_master_txBuff[LPI2C_DATA_LENGTH]; uint8_t g_master_rxBuff[LPI2C_DATA_LENGTH]; uint16_t temp; /* 追加 */ uint16_t temperature; /* 追加 */ /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Main function */ int main(void) { lpi2c_master_config_t masterConfig; status_t reVal = kStatus_Fail; uint8_t deviceAddress = 0x00U; size_t txCount = 0x01U; BOARD_InitHardware(); /* Set up i2c master to send data to slave*/ /* First data in txBuff is data length of the transmiting data. */ g_master_txBuff[0] = LPI2C_DATA_LENGTH - 1U; for (uint32_t i = 1U; i < LPI2C_DATA_LENGTH; i++) { g_master_txBuff[i] = i - 1; } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH - 1U; i++) { if (i % 8 == 0) { } } /* * masterConfig.debugEnable = false; * masterConfig.ignoreAck = false; * masterConfig.pinConfig = kLPI2C_2PinOpenDrain; * masterConfig.baudRate_Hz = 100000U; * masterConfig.busIdleTimeout_ns = 0; * masterConfig.pinLowTimeout_ns = 0; * masterConfig.sdaGlitchFilterWidth_ns = 0; * masterConfig.sclGlitchFilterWidth_ns = 0; */ LPI2C_MasterGetDefaultConfig(&masterConfig); /* Change the default baudrate configuration */ masterConfig.baudRate_Hz = LPI2C_BAUDRATE; /* Initialize the LPI2C master peripheral */ LPI2C_MasterInit(EXAMPLE_I2C_MASTER, &masterConfig, LPI2C_MASTER_CLOCK_FREQUENCY); /* Send master start bit &Slave Address + Write Bit */ if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, g_master_txBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < WAIT_TIME; i++) { __NOP(); } if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { /* Check master tx FIFO empty or not */ LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } /* Check communicate with slave successful or not */ if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterRepeatedStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Read); if (reVal != kStatus_Success) { return -1; } reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH; i++) { if (i % 8 == 0) { } } temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; temperature = temp >> 4; PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); while (1) { } }   6.5 使用引脚配置器更改引脚设置   我们将把目前连接到 P3T1755 的I3C端口重新连接到LPI2C 端口。这是通过MCUXpresso 配置工具中的引脚配置器工具完成的,而不是修改程序代码。 首先,我们将禁用引脚33和34的默认设置,即LPI2C0_SDA和LPI2C0_SCL 。在“引脚”选项卡中,向下滚动以显示引脚33和34。然后,向右滚动以显示LPI2C列。单击LPI2C列中显示的引脚33和34对应的LPI2C0_SDA和LPI2C0_SCL ,即可禁用引脚33和34 。 接下来,在“引脚”选项卡中,将引脚54分配给LPI2C0_SDA 。选中引脚54的复选框将显示分配给该引脚的所有功能。从列表中选择LPI2C0:SDA 。 “引脚”选项卡中的引脚54将变为绿色。单击“完成”以完成分配。 同样,在“引脚”选项卡中,将引脚55分配给LPI2C0_SCL 。选中引脚55的复选框,然后选择LPI2C0:SCL 。“引脚”选项卡中的引脚55将变为绿色。单击“完成”以完成分配。 接下来,我们将配置引脚54和55的功能。要配置这些功能,请使用底部的“布线详情… ”选项。 在“路由详细信息”中,将引脚54 ( LPI2C0_SDA ) 和55 ( LPI2C0_SCL ) 的上拉选择 (Pull Select)设置为Pullup ,并将上拉使能 (Pull Enable)设置为Enabled 。如果将标签设置为I2C_SDA和I2C_SCL ,则需要在 board/pin_mux.h 文件中进行相应设置。它给它增加了一个定义。 引脚配置现已完成。 要反映代码中目前所做的更改,请单击“更新代码”按钮。 6.6 构建与调试、测试功能 代码修改完成后,进行编译。 将鼠标悬停在“项目”上时,会出现一个构建按钮。点击该按钮即可构建项目。 如果看到“构建成功完成”的消息,那就没问题了。 在构建按钮旁边,有一个调试按钮。点击此按钮将进入调试模式。 进入调试模式后,程序会在断点处停止,因此请点击屏幕顶部的“ |▶ ”图标。程序随后会继续运行。 温度将显示在 Tera Term 屏幕上。 总结 本文介绍了I²C通信的基本原理以及MCX A153中安装的LPI2C模块的主要功能。文章还以FRDM-MCXA153中安装的P3T1755温度传感器为例,演示了如何添加上拉电阻、使用引脚配置器配置引脚以及修改LPI2C SDK示例代码。在I²C通信中,根据连接设备的规格配置从机地址、寄存器地址和数据长度至关重要。本文中的信息可用于与各种I²C设备(例如传感器和EEPROM)进行通信。 =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便,我们深表歉意,但 在进行咨询时, 请 参考“ NXP 技术问题 - 如何联系我们 ( 日语博客 ) ” 。 (如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ,您可以直接咨询您的代表。 ) 本文重点介绍恩智浦半导体 (NXP) 微控制器 MCX A153 中包含的 LPI2C(低功耗集成电路间)控制器。在回顾 I²C 的基础知识之后,我们将解释 I²C 和 LPI2C 之间的区别,然后了解 MCX A153 上 LPI2C 的规格和用途。 (阅读时间:30分钟) MCUXpresso IDE MCUXpresso SDK MCX 日本博客
View full article
[MCX A153] LPI2C Beginner's Guide (Japanese Blog) Introduction This article is aimed at beginners in microcontrollers and explains the peripheral functions and usage of the NXP MCX A153 microcontroller. You will learn the basic concepts and implementation methods by actually modifying the SDK sample programs provided by NXP. table of contents   1. Common Usage Examples in Applications (I²C Edition) 1.1 Main Uses 1.2 Usage example 2. Fundamentals of I²C 2.1 What is I²C in the first place? 2.2 Microcontroller I²C Module 3. Main functions and block diagram of the MCX A153 I²C module (LPI2C) 3.1 Overview 3.2 Block Diagram 3.3 Functions 4. Equipment and Development Tools Used 4.1 Evaluation Board (FRDM-MCXA153) 4.2 Development Tools (MCUXpresso for VS Code and IDE) 5. Programming 5.1 Check the contents of the base sample code 5.2 Pin Configuration 5.3 Changes in the program code 6. Practical Training 6.1 Practical Training Content 6.2 Practical Exercise Procedure 6.3 Add pull-up resistors to the evaluation board 6.4 Coding the changes 6.5 Change the pin settings using the PIN configurator 6.6 Build & Debug, Test Functionality   1. Common Usage Examples in Applications (I²C Edition)   Key points of this chapter: We will examine the situations in which I²C is used.   1.1 Main Uses I²C is a communication method that reads and writes data by specifying the register address within a device. Because it uses fewer signal lines, it is suitable for controlling multiple ICs on a single circuit board. However, it is susceptible to wiring capacitance and noise, so it is generally used for short-distance communication. Connection of various sensors such as temperature, acceleration, and magnetic sensors. Digital potentiometer IO Expander EEPROM RTC Input/output expansion for display devices (LCD, LED, etc.) Microcontroller-to-microcontroller communication (included in the sample program on the FRDM-MCXA153 evaluation board) 1.2 Usage example Actual applications include computer motherboards, embedded systems, and mobile phones.   2. Fundamentals of I²C   Key points of this chapter: We will clarify the basic I²C terminology, including SDA, SCL, address, ACK/NACK, and pull-up resistor.   2.1 What is I²C in the first place? I²C is a serial bus communication standard developed by Philips Semiconductors (now NXP Semiconductors). It is now widely used as a representative method for connecting sensors and peripheral ICs on circuit boards. I²C is a synchronous serial communication method that sends data synchronized with a clock. The data line is called SDA, and the clock line is called SCL. Communication is performed by timing SDA to SCL. Each slave has a unique address, and the master communicates by specifying that address. When the address is sent at the start of communication, the target slave returns an ACK (acknowledgment). If an ACK cannot be received, no ACK is returned, which is called a NACK (non-acknowledgment). Communication is performed using a protocol consisting of start condition, address, R/W bits, ACK/NACK, and stop condition. Addresses can be in 7-bit mode or 10-bit mode. I²C is an open-drain protocol. Pull-up resistors keep SDA and SCL normally high, and each device pulls them low when needed. Therefore, pull-up resistors are required on communication lines. A microcontroller is typically used as the master. There are two ways to determine communication completion: using interrupts from the slaves, and a polling method where the master repeatedly checks a completion flag. When using interrupts, each slave must have an interrupt output and the master must have an interrupt input. Using interrupts results in faster response times, but the hardware becomes more resource-intensive. For more detailed information about I²C, please refer to the following article. Overview of the I²C Bus (Japanese Blog) This time, we will use a polling method to match the wiring conditions of the evaluation board. Typical transfer speeds are 100kbps in standard mode and 400kbps in fast mode. The MCX A153 also supports Fast Mode Plus, allowing for communication at a maximum speed of 1Mbps. The procedure for sending data from the master to the slave is as follows: Master initiated communication. The master specifies the slave address. Sending data from master to slave The master terminated the communication. Conversely, the procedure for a master receiving data from a slave is as follows: Master initiated communication. The master specifies the slave address. The master receives data from the slave. The master terminated the communication.   2.2 Microcontroller I²C Module The diagram below shows a block diagram of an I²C module typically found in microcontrollers. The number of components is not that large. The main components are the Command/TX FIFO for the transmit buffer, the RXFIFO for the receive buffer, configuration registers, and the control circuit that controls communication. Furthermore, most microcontrollers nowadays have a built-in noise filter. 3. Main functions and block diagram of the MCX A153 I²C module (LPI2C)   Key points of this chapter: We will examine the differences between general I²C and the LPI2C module of the MCX A153.   3.1 Overview Up to this point, we have explained the basics of general I²C, but in this chapter we will explain the LPI2C I²C module of the MCX A153. LPI2C is far more functional than the basic I²C mentioned above. LPI2C supports efficient interfacing to the I²C bus as both a master (controller) and a slave (target). The main features are listed below. Supports logic for Standard, High Speed, High Speed+, HS Mode (Target Only), and Ultra High Speed operating modes. CPU overhead is minimized by DMA offloading access to the FIFO. LPI2C also complies with the System Management Bus (SMBus) specification version 3. *Note 1 The MCX A153 reference manual uses the terms "master and controller" and "slave and target" interchangeably. While "controller" and "target" are now recommended, we will use "master and slave" consistently in this document. 3.2 Block Diagram The MCX A153's LPI2C module has a master section in the upper half and a slave section in the lower half. The SDA and SCL modules are also divided into master and slave versions, with the slave versions having an "S" appended to them, hence SDAS and SCLS. Communication can also be started using the external HREQ terminal or the internal Trigger signal. 3.3 Functions The functions of LPI2C are as follows: Standard, High Speed, High Speed+, Ultra High Speed Mode Multi-controller (including synchronization and arbitration) Clock stretching Arbitration (when a system has multiple controllers) 7-bit addressing, 10-bit addressing Software reset, start byte, device ID (software support is also required). Command and transmit FIFO (4 words, 8-bit transmit data + 3-bit command) Received FIFO (4 words, 8-bit received data) Host request input for controlling the start time of I²C bus transfer Interrupt generation upon data match and rejection of unwanted data based on received data matching. Flags and optional interrupt signals for repeat start conditions, stop conditions, loss of arbitration, unexpected NACK, and command word errors. configurable bus idle timeout and pin stack low timeout. Independent I²C target registers 7-bit or 10-bit addressing Send/receive data registers that support interrupts or DMA requests ACK or NACK can be controlled by software. Clock stretching can be configured to avoid transmit FIFO underrun and receive FIFO overrun errors. Packet termination flags and optional interrupt, stop condition, or bit error detection. 4. Equipment and Development Tools Used   4.1 Evaluation Board (FRDM-MCXA153) The equipment used for this practical exercise will be a Windows PC and the FRDM-MCXA153 evaluation kit for the MCX A153 (FRDM-MCXA153 Development Board using MCUXpresso | NXP Semiconductors). A USB Type-C cable is included with the FRDM-MCXA153. Board information and circuit diagrams for the FRDM-MCXA153 can be obtained by clicking "Design Files" on the website. (Account registration required) The FRDM-MCXA153 is equipped with a P3T1755 temperature sensor. In its initial state, the P3T1755 is connected to I3C0, so this time we will change the pin settings to connect it to LPI2C and read the temperature using LPI2C. Since there is no interrupt line wired from the P3T1755 to the LPI2C, the LPI2C will be used as a polling master. Also, since there are no pull-up resistors on the signal lines of the MCX A153 and P3T1755, external resistors will be added. 4.2 Development Tools (MCUXpresso for VS Code and IDE) This article will guide you through editing and running SDK samples using MCUXpresso for VS Code or the MCUXpresso IDE. Development tools are the environment for creating projects, editing code, configuring settings, and running applications. This article does not cover tool installation or initial setup; please refer to NXP's official guides for instructions specific to your environment. 5. Programming   The key point of this chapter is to first understand how the sample code works, and then modify it for the P3T1755.   5.1 Check the contents of the base sample code Several sample programs for I²C are provided. This time, we will use the sample program "lpi2c_edma_b2b_polling_master" which uses polling as the master. We will modify this sample program to create a program that reads temperature data from the P3T1755 temperature sensor installed in the FRDM-MCXA153 using I²C. By default, the P3T1755 is connected to the I3C module I3C0, but we will modify the program to switch to the LPI2C module and create a program that uses the LPI2C to read the temperature of the P3T1755. In the FRDM-MCXA153, there is no interrupt line wired from the P3T1755 to the LPI2C, so the LPI2C must be used as the polling master. Also, the wiring connecting the MCX A153 and the P3T1755 does not have a pull-up resistor, so a pull-up resistor must be added. In this example, an LPI2C instance is implemented as a master on one board and as a slave on the other board. The master sends data to the slave and receives data from the slave. This example verifies whether the data received from the slave is correct. The general outline of the communication procedure is as follows: The master unit sends a signal to begin communication (start condition). The master sends the slave address. The slave sends a signal (acknowledgment) to the master indicating that it is ready to communicate. Perform data communication (repeated depending on the data to be sent) The master unit issues a signal to end communication (stop condition). Further breakdown reveals two types of control: Write control, which writes information to the slave, and Read control, which reads information from the slave. First, Write control is performed, followed by Read control to read the temperature data. This is the basic procedure for controlling the master side using polling. It's the same whether the slave is a microcontroller's I²C module or a sensor IC such as a temperature sensor. [Write control] The procedure for controlling the write operation is as follows. The functions used and their explanations are listed below. ① Send Start condition + slave address + write bit: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 This function initiates a new master mode transfer. ② Send the register address and data of the target device: LPI2C_MasterSend:I²Cバスにデータを送信。 This function waits until the data in the buffer is sent. ③ Send Stop condition: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 This function waits until a stop signal is sent, and the transaction Wait until it finishes. [Read control] The procedure for Read control is as follows. The functions used and their explanations are also listed here. ① Send Start condition + slave address + write bit: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 This function initiates a new master mode transfer. ② Send the register address of the target device: LPI2C_MasterRepeatedStart:LPI2C_MasterStart を再度実行する。 This function typically sends a register address. ③ Send Start condition + slave address + read bit: LPI2C_MasterReceive:I²Cバスからデータを受信。 This function waits until the data in the buffer has been transferred. ④ Receive data from the target device: LPI2C_MasterSend:I²Cバスにデータを送信。 This function waits until the data in the buffer is sent. ⑤ Send Stop condition: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 This function waits until a stop signal is sent and until the transaction is completed. A flowchart for the sample program "lpi2c_edma_b2b_polling_master" is included in the supplementary explanation at the end of the last chapter. Please refer to it. Furthermore, while explanations of the functions used can be found in the MCX A153 API Reference , we have extracted the explanations of the functions used in this example into the supplementary explanations at the end of the last chapter. Please refer to this as well. 5.2 Pin Configuration By default, the P3T1755 is connected to the I3C0 pin of the I3C module, so you need to change this to the LPI2C pin. To change the pin connections, you can use the convenient Pin Configurator function within the Config Tools tool. The Pin Configurator allows you to change pin assignments via a GUI and even automatically generates C language code for you. The specific operation will be explained in detail in the practical exercises chapter. 5.3 Changes in the program code The basic communication flow is the same as the sample, but the slave address, register address, and data length are changed to match the P3T1755. Furthermore, the received 16-bit value is converted to temperature. First, change the slave address to 0x48U of P3T1755. The sample program handles 33 bytes of data, but the P3T1755 uses 16-bit temperature data, so we will change the data length to 16 bits. We define a constant to store the 16-bit temperature data read from the P3T1755. Here, we'll call it "temperature". The register address is defined by deviceAddress, which is 0x01U, but in the case of P3T1755 it is 0x00U. The number of data points to transfer is defined by txCount, which is 0xFFU in the sample program, but since the temperature data read from the P3T1755 is 2 bytes (16 bits), we reduce it to 0x01U. In the sample program, the master sends data and the slave sends the same data back, and then a comparison of the transmitted and received data is performed, but this process is unnecessary. Instead, it is necessary to process the data received from the P3T1755 into temperature data. The data received from the P3T1755 is 2 bytes (16 bits). The receive buffer is defined as g_master_rxBuff[1] and g_master_rxBuff[0], each containing 1 byte, so g_master_rxBuff[0] is used as the upper byte and g_master_rxBuff[1] as the lower byte, and they are combined into 16 bits. The combined result is stored in temp. Each bit of the combined temperature data corresponds to 0.0625°C, so multiplying by 0.0625 gives the temperature. Fortunately, multiplying by 0.0625 can be easily calculated by shifting 4 bits to the right, without using floating-point arithmetic. The calculation result is entered into the 'temperature' field. Finally, display the host using printf.     6. Practical Training   This chapter focuses on the necessary hardware preparations and the points where you need to modify the code for the P3T1755, rather than detailing tool installation or screen operations.   6.1 Practical Training Content This method reads the P3T1755 temperature sensor mounted on the FRDM-MCXA153 using LPI2C. Since the P3T1755 is initially connected to I3C0, pin configuration is required to connect it to LPI2C. Additionally, a pull-up resistor must be added to the I3C signal line. The software is based on the LPI2C SDK sample, with modifications to the calculation process for the P3T1755's slave address, register address, data length, and temperature data. 6.2 Practical Training Procedure (Overview) Connect 4.7kΩ pull-up resistors to the SDA and SCL pins of the evaluation board. Prepare a sample LPI2C project in the MCUXpresso environment. Specific installation and import procedures are omitted. Change the pin settings to the LPI2C pins to which the P3T1755 is connected. The following code changes will be made as shown in Section 6.7. Run the program and verify that a temperature value is output.   6.3 Add pull-up resistors to the evaluation board The P3T1755 has Junction PAs (J20, J21) on its I²C line. Connect 4.7kΩ resistors to J20 and J21, and pull up SDA and SCL. important! The built-in pull-up resistor may not provide stable communication depending on the board. To ensure reliable communication, please use an external pull-up resistor. 6.4 Coding the changes We will now code the concepts explained in the programming chapter into an actual .c file. We will now implement the changes described in "5.3 Changes to the Program Code" into the code. (1) Change the slave address to 0x48U of P3T1755. [変更前]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x7EU [変更後]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U (2) Change the data length to 16 bits. [変更前]#define LPI2C_DATA_LENGTH 33U [変更後]#define LPI2C_DATA_LENGTH 2U (3) Define a constant `temperature` to store the 16 bits of temperature data read from the P3T1755. [追加]uint16_t temperature; (4) Change the register address deviceAddress to 0x00U. [変更前]uint8_t deviceAddress = 0x01U; [変更後]uint8_t deviceAddress = 0x00U; (5) Change the number of data to be transferred, txCount, to 0x01U. [変更前]size_t txCount = 0xFFU; [変更後]size_t txCount = 0x01U; (6) Adjustment of the number of received data [変更前]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH - 1); [変更後]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); (7) Remove the section comparing the transmitted data and the received data. [削除] /* Transfer completed. Check the data.*/以下のコード (8) The data received from P3T1755 is combined into temperature data. The upper byte of g_master_rxBuff[0] and the lower byte of g_master_rxBuff[1] are combined into a 16-bit array, and the combined result is stored in temp. [追加] temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; (9) Shift temp to the right by 4 bits and put it into temperature. [追加]temperature = temp >> 4; (10) Display the temperature using printf. [追加] PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); (11) Finally, we'll add an infinite loop. [追加]while (1) {} The complete code reflecting the changes made so far is shown below for reference.   [All Code] /* * Copyright 2017 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ /* Standard C Included Files */ #include #include #include "board.h" #include "fsl_debug_console.h" #include "fsl_lpi2c.h" #include "app.h" /******************************************************************************* * Definitions ******************************************************************************/ #define EXAMPLE_I2C_MASTER ((LPI2C_Type *)EXAMPLE_I2C_MASTER_BASE) #define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U #define LPI2C_BAUDRATE 100000U #define LPI2C_DATA_LENGTH 2U /******************************************************************************* * Prototypes ******************************************************************************/ /******************************************************************************* * Variables ******************************************************************************/ uint8_t g_master_txBuff[LPI2C_DATA_LENGTH]; uint8_t g_master_rxBuff[LPI2C_DATA_LENGTH]; uint16_t temp; /* 追加 */ uint16_t temperature; /* 追加 */ /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Main function */ int main(void) { lpi2c_master_config_t masterConfig; status_t reVal = kStatus_Fail; uint8_t deviceAddress = 0x00U; size_t txCount = 0x01U; BOARD_InitHardware(); /* Set up i2c master to send data to slave*/ /* First data in txBuff is data length of the transmiting data. */ g_master_txBuff[0] = LPI2C_DATA_LENGTH - 1U; for (uint32_t i = 1U; i < LPI2C_DATA_LENGTH; i++) { g_master_txBuff[i] = i - 1; } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH - 1U; i++) { if (i % 8 == 0) { } } /* * masterConfig.debugEnable = false; * masterConfig.ignoreAck = false; * masterConfig.pinConfig = kLPI2C_2PinOpenDrain; * masterConfig.baudRate_Hz = 100000U; * masterConfig.busIdleTimeout_ns = 0; * masterConfig.pinLowTimeout_ns = 0; * masterConfig.sdaGlitchFilterWidth_ns = 0; * masterConfig.sclGlitchFilterWidth_ns = 0; */ LPI2C_MasterGetDefaultConfig(&masterConfig); /* Change the default baudrate configuration */ masterConfig.baudRate_Hz = LPI2C_BAUDRATE; /* Initialize the LPI2C master peripheral */ LPI2C_MasterInit(EXAMPLE_I2C_MASTER, &masterConfig, LPI2C_MASTER_CLOCK_FREQUENCY); /* Send master start bit &Slave Address + Write Bit */ if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, g_master_txBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < WAIT_TIME; i++) { __NOP(); } if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { /* Check master tx FIFO empty or not */ LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } /* Check communicate with slave successful or not */ if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterRepeatedStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Read); if (reVal != kStatus_Success) { return -1; } reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH; i++) { if (i % 8 == 0) { } } temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; temperature = temp >> 4; PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); while (1) { } }   6.5 Change the pin settings using the PIN Configurator   We will reconnect the I3C port currently connected to the P3T1755 to the LPI2C port . This is done using the Pin Configurator tool within MCUXpresso Config Tools , rather than modifying the program code. First, we will disable the default settings of pins 33 and 34 , which are LPI2C0_SDA and LPI2C0_SCL . In the Pins tab, scroll down to display pins 33 and 34. Then, scroll to the right to display the LPI2C column. Clicking on LPI2C0_SDA and LPI2C0_SCL , respectively, displayed in the LPI2C column for pins 33 and 34 will disable pins 33 and 34 . Next, in the Pins tab, assign pin 54 to LPI2C0_SDA . Clicking the checkbox for pin 54 will display all the functions assigned to that pin. Select LPI2C0:SDA from the list. Pin 54 in the Pins tab will then turn green. Click " Done " to complete the assignment. Similarly, in the Pins tab, assign pin 55 to LPI2C0_SCL . Click the checkbox for pin 55 and select LPI2C0:SCL . Pin 55 in the Pins tab will then turn green. Click " Done " to complete the assignment. Next, we will configure the functions of pins 54 and 55. To configure the functions, use " Routing Details for… " located at the bottom. In Routing Details for…, change the Pull Select for pins 54 ( LPI2C0_SDA ) and 55 ( LPI2C0_SCL ) to Pullup , and change Pull enable to Enabled . If you set the Label to I2C_SDA and I2C_SCL , then in board/pin_mux.hIt adds a definition to it. The pin configuration is now complete. To reflect the changes made so far in the code, click the Update Code button. 6.6 Build & Debug, Test Functionality Once you've finished changing the code, build it. When you hover your cursor over "Projects," a build button will appear. Clicking it will build the project. If you see the message " build finished successfully, " then it's OK . Next to the build button, there's a debug button. Clicking this will enter debug mode. When you enter debug mode, the program stops at the breakpoint, so click the " |▶ " icon at the top of the screen. The program will then run. The temperature will be displayed on the Tera Term screen. summary This article explained the basic I²C communication method and the main functions of the LPI2C module installed in the MCX A153. It also demonstrated how to add pull-up resistors, configure pins using the Pin Configurator, and modify the LPI2C SDK sample code, using the P3T1755 temperature sensor installed in the FRDM-MCXA153 as an example. In I²C communication, it is crucial to configure the slave address, register address, and data length according to the specifications of the connected device. Please use the information in this article to apply it to communication with various I²C devices such as sensors and EEPROMs. =========================​ 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.) This article focuses on the LPI2C (Low Power Inter-Integrated Circuit) controller included in the NXP microcontroller MCX A153. After reviewing the basics of I²C, we will explain the differences between I²C and LPI2C, and then learn about the specifications and usage of the LPI2C on the MCX A153. (Reading time: 30 minutes) MCUXpresso IDE MCUXpresso SDK MCX Japanese Blog
View full article
如何为 i.MX 95 Neutron NPU 编译和运行 AI 模型(日文博客) 介绍 i.MX 95集成的 eIQ Neutron NPU 可以将 AI 模型推理处理卸载到专用加速器上。但是,并非总是可以直接运行模型;需要进行多项准备工作,包括量化、运算符兼容性以及编译器和目标运行时之间的版本兼容性。 本文概述了将使用 ONNX 或 TensorFlow 创建的模型转换为 TFLite 的完整流程,包括执行 INT8 量化、编译以适配 Neutron NPU、部署到 i.MX 95 以及使用 benchmark_model 评估性能。我们将主要介绍标准且灵活的流程 A ,同时也会介绍利用现有 ONNX 量化环境的流程 B。 *本文并未具体限制人工智能模型的使用;它只是描述了该过程中涉及的步骤。 命令示例适用于 Neutron-S。实际使用时,请务必查看目标系统上已安装的Neutron SDK 、 Yocto BSP和运行时附带的文档和发行说明。 目录 概述 主机端工具安装 转换流程(流程 A 详情) 备选流程:流程 B(ONNX 级量化) i.MX 95 目标的部署和性能评估。 (可选)位精确验证:neutron-runner 支持的算符和量化约束 故障排除/常见陷阱 综上所述   1. 概述 本文概述了在 i.MX 95 中安装的 eIQ Neutron NPU 上运行使用 ONNX 或 TensorFlow 训练的 AI 模型的转换过程。它基于安装 Neutron SDK 后 docs 文件夹中包含的官方文档:“Neutron SDK 用户指南”、“Neutron 编译器用户指南”、“TFLite 分析器/量化器用户指南”、“Neutron Runner 用户指南”、“支持的运算符 (Neutron-S / Neutron-C)”以及i.MX 机器学习用户指南 (UG10166) 。 ℹ️ 注:i.MX 95 中的 Neutron NPU 属于“Neutron-S”架构(子系统类型)。它与 i.MX RT700 等 MCU 中使用的“Neutron-C”架构在转换流程和一些工具选项方面有所不同。本文重点介绍 i.MX 95(Neutron-S)。   1.1 总流量(流量 A:推荐) Neutron SDK 提供的标准流程包括将模型转换为 TFLite 格式,在代表性数据集上对其进行分析,然后使用 INT8 对其进行量化,最后使用 neutron-compiler 将其编译为 NPU。 ℹ️首次用户补充信息 i.MX 95 的 Neutron NPU 实际上运行在为 Neutron NPU 编译的 INT8 量化 TFLite 模型上。此过程最终会将您的 ONNX/TensorFlow 模型转换为这种格式。 根据您准备的预训练模型的格式,起始步骤会有所不同。请参考以下步骤,并从适用于您的步骤开始。 INT8 量化 TFLite 模型:跳过步骤 1-3,从步骤 4 开始。 FP32 TFLite 模型:跳过步骤 1,直接从步骤 2 开始。 ONNX/TensorFlow FP32 模型:执行步骤 1 到 1。 有关每个步骤的详细信息,请参阅以下章节。 程序 工作详情 章节号 ① 将 ONNX 转换为 TFLite FP32 步骤 1:将 ONNX 模型转换为 TFLite FP32 格式。 ② 利用代表性数据集进行分析 步骤 2:FP32 模型分析 ③ 基于配置文件的 INT8 量化 步骤 3:基于配置文件信息的 INT8 量化 ④ 为 Neutron NPU 编译 步骤 4:为 Neutron NPU 编译 ⑤ 根据需要进行位精确验证 6.(可选)位精确验证:neutron-runner ⑥ 将转换后的模型部署到目标平台。 5.2 模型部署 ⑦ 推理执行和性能评估 5.3 性能评估(基准模型)   1.2 两种量化流(流 A / 流 B) Neutron SDK 用户指南定义了获取量化 TFLite 模型的两种流程。 流动 管道 量化工具 特点 流程 A(推荐) ONNX FP32 → TFLite FP32 → TFLite INT8 → 中子转换 tflite-profiler + tflite-quantizer(包含在 Neutron SDK 中) 它提供了高度的量化灵活性。特定的算子可以被排除在量化之外,从而允许映射到中子插值器,同时保持FP精度。 流程 B ONNX FP32 → ONNX INT8 → TFLite INT8 → 中子转换 onnx2quant (eIQ ONNX2TFLite) 当已有基于 ONNX 的量化流水线时,此功能非常有用。但其对运算符排除的细粒度控制有限。 💡 提示:如果您不确定,我们推荐流程 A(tflite-profiler + tflite-quantizer)。如果您希望将某些算符(例如非线性激活函数)映射到中子插值器而不对其进行量化,则流程 A 至关重要。   2. 设置主机端工具 模型转换将在开发主机(Linux/Windows PC)上进行。请从NXP eIQ软件仓库安装以下工具。 # ONNX → TFLite 转换工具 pip安装 eiq-onnx2tflite --index-url https://eiq.nxp.com/repository/# eIQ Neutron SDK(包括 tflite-profiler、tflite-quantizer、neutron-compiler、neutron-runner 等) pip安装 eiq-neutron-sdk --index-url https://eiq.nxp.com/repository/ ℹ️ 注意:开发主机(neutron-compiler)的推荐最低配置:CPU 2GHz 或更高,8 核或更高;内存 4GB 或更高。Neutron-S(例如 i.MX 95)使用约束编程求解器,因此转换时间可能需要几分钟到几十分钟不等,具体取决于模型。 ℹ️如果 pip 安装失败 如果 pip install 在您的内部代理环境中无法完成,请考虑以下选项。 使用 eIQ Toolkit 的 zip 版本— 从eIQ Toolkit 产品页面获取并解压 zip 文件后,您可以在 bin/ 下运行 Neutron 工具。zip 版本使用连字符,例如 tflite-profiler 、 tflite-quantizer 、 neutron-compiler 和 neutron-runner 。而 pip/uv 版本可能使用下划线,例如 tflite_profiler 、 tflite_quantizer 和 neutron_compiler 。但是,zip 版本不包含 onnx2tflite 和 onnx2quant ,必须使用 pip 或 uv 安装。以下命令示例使用与 zip 版本等效的表示法。 使用 uv 进行安装——根据您的环境,这可能比使用 pip install 更成功。 pip install uv uv pip install eiq-onnx2tflite \ --index-url https://eiq.nxp.com/repository/ \ --extra-index-url https://pypi.org/simple/ 如果需要代理,您可能需要配置 http_proxy / https_proxy (包括大写的环境变量)。配置方法取决于贵公司的具体环境。   2.1 Neutron SDK 版本和 Yocto BSP 兼容性 Neutron 驱动程序、固件和编译器必须与 Neutron SDK 版本一致。如果它们不兼容,运行时将输出以下警告。 Microcode version mismatch! Neutron Driver is 3.1.0-0X359f358d but model converted with 3.0.1-0Xd5d7918e. Runtime (driver, firmware) should be aligned with compiler Yocto BSP 版本与 Neutron SDK 版本之间的兼容性(摘录,基于截至 2026 年第三季度的最新 BSP): Yocto BSP 支持的发布周期 默认 Neutron SDK LF_6.12.3_1.0.0 2025年第一季度 1.2.0 LF_6.12.20_2.0.0 2025年第二季度 2.0.2 LF_6.12.34_2.1.0 2025年第三季度 2.1.3 LF_6.12.49_2.2.0 2025年第四季度 2.2.2 LF_6.18.2_1.0.0 2026年第一季度 2.2.3 LF_6.18.20_2.0.0 2026年第二季度 3.1.2 LF_6.18.37_2.1.0 2026年第三季度 3.2.1 其他 Neutron SDK 版本也可以作为“可升级版本”使用,但这种情况下,您需要将目标运行时(驱动程序/固件/委托)更新到相应的版本,并使用相同版本的 neutron-compiler 重新编译模型。详情请参阅《Neutron SDK 用户指南》中的版本兼容性表格。 3. 转换流程(流程 A 详情)   步骤 1:将 ONNX 模型转换为 TFLite FP32 格式。 如果您的模型已经是 TFLite FP32 格式,则无需执行此步骤。请使用 onnx2tflite 工具将您的 ONNX 模型转换为 TFLite 格式。 onnx2tflite -o .tflite .onnx ℹ️ 关于 SDK 版本的说明 -i (输入规范)和 -target (FP32/INT8 切换)在某些 SDK 版本中已弃用。输入 ONNX 文件使用位置参数指定,并在执行前使用 onnx2tflite --help 检查最新选项。如果您更改了输入/输出布局,还请检查您使用的 SDK 中是否存在 --keep-io-format / --no-keep-io-format 以及它们的默认值。   步骤 2:FP32 模型分析 我们使用 tflite-profiler,利用代表性的输入数据集(校准数据)测量每个张量的动态范围(最小值/最大值/直方图)。 ./tflite-profiler \ --input < my_model_fp32 > .tflite \ --dataset <输入数据目录> \ --output < my_model_fp32_profile > .csv ℹ️关于输入数据的说明 这包含一个 float32 格式的 .bin 文件,其尺寸与模型的输入尺寸相匹配。对于图像模型,您可以使用 SDK 中包含的 scripts/serialize_image.py 进行调整大小、归一化并转换为 float32 格式 .bin 。当没有代表性数据集时,可以使用 --use_random_data 进行形状验证和通信验证,但不适用于精度验证。 ./tflite-profiler \ --input < my_model_fp32 > .tflite \ --use_random_data \ --random-data-samples 10 \ --output < my_model_fp32_profile > .csv 通常认为,200 到 1000 个样本的样本量足以构建具有代表性的数据集。为了验证量化结果的准确性,建议使用一个未用于校准的独立验证数据集。   步骤 3:基于配置文件信息的 INT8 量化 我们将使用 tflite-quantizer 根据步骤 2 中生成的配置文件 (CSV) 执行 INT8 量化。 ./tflite-quantizer \ --input < my_model_fp32 > .tflite \ --profile < my_model_fp32_profile > .csv \ --output < my_model_quantized > .tflite 主要量化参数(默认值)如下: 选项 说明 默认值 --quantization-constant-type 权重量化数据类型 INT8 --quantization-constant-type-bias 具有偏差的量化数据类型(Conv2D/FC 等) INT32 --quantization-variable-type 激活的量化数据类型 INT8 --quantization-constant-granularity 权重量化粒度(PTQ/PCQ) PCQ(每通道) --quantization-constant-schema 权重量化方案 对称 --quantization-variable-schema 激活量化方案 不对称 --quantization-calibration-method 校准方法(最小值/最大值/百分位数) 最小最大值 要将特定算子排除在量化之外,请使用 --quantize-operator-types-except (例如, ADD,AVERAGE_POOL_2D )。像 LayerNorm 这样对量化敏感的复合算子也可以使用 layernorm 排除。 💡 提示:量化后,您可以使用 --run-after-quantize 选项通过虚拟输入验证操作(仅对标准 INT8 量化配置有效)。 ℹ️关于 SDK 版本的补充信息 量化选项可能因 SDK 而异。在我们的验证环境中,SDK 3.2.3 已确认可与表格中所示的选项以及 --quantization-constant-granularity PCQ 配合使用,但请务必在使用前使用目标 SDK 的 tflite-quantizer --help 进行验证。   步骤 4:为 Neutron NPU 编译 使用 neutron-compiler 为 i.MX 95 Neutron NPU 编译量化的 TFLite 模型。 ./neutron-compiler \ --input < my_model_quantized > .tflite \ --output < my_model_converted > .tflite \ --target imx95 中子编译器分以下三个阶段执行转换: 步 内容 ① 优化 将图转换为符合 Neutron 硬件约束的数学等价形式(图路径)。 ② 提取物 将 NeutronOperator 中的对应运算符按层次结构映射到 NeutronGraph 中的自定义运算符。 ③ 生成 微代码/权重/内核的分块、调度、内存分配和二进制生成。 您可以使用以下命令查看支持的目标和运算符类型列表。 neutron-compiler --show-targets neutron-compiler --show-operator-types neutron-compiler --target imx95 --show-kernel-kinds   3.1 主要编译器选项 选项 说明 --target 要转换的目标 Neutron 对象(例如 imx95)。如果省略,则默认为 mcxn94x。 --output 输出文件路径。如果省略,则会在输入文件名后附加 _compiled 。 --dump-statistics / --dump-statistics-file 将周期估算统计信息(根据 NeutronGraph)输出到控制台/文件。 --optimization-level OFast :快速启发式算法(默认)/ OOpt :使用ILP/SAT求解器求解最优解(转换时间较长) --include-operator-types / --exclude-operator-types 指定要映射到/排除在 NPU 之外的运算符类型。 --min-num-ops-per-graph 要提取为 NeutronGraph 的最小算子数量。较小的图针对 CPU 执行进行了优化。 --use-profiling / --use-profiling-tick-trace 启用实际硬件上的运行时性能分析(内核级/时钟周期级) --keep-graphs 保留中间图(这是中子运行器中进行位精确验证所必需的)。 --force-determinism 这样可以抑制求解器中的多线程争用,并获得明确的转换结果(转换时间大约增加 2-3 倍)。 ℹ️ 注意:由于 Neutron-S(i.MX 95 等)编译器使用约束编程求解器,因此对同一模型进行多次转换时,生成的微代码(尤其是 TCM 地址)可能会略有不同。这是因为多线程竞争会导致选择多个最优解之一,而所有解都是正确的。如果需要确定性,请使用 --force-determinism 。   4. 备选流程:流程 B(ONNX 级别量化) 如果您的现有流程依赖于 ONNX 级别的量化( onnx2quant ),您也可以使用以下流程。与流程 A 相比,该流程对运算符排除的细粒度控制更为有限。 程序 实施细节 使用的工具/主要交付成果 1 将 ONNX FP32 模型量化为 INT8 onnx2quant , model_int8.onnx 2 将 ONNX INT8 转换为 TFLite INT8 onnx2tflite , model_int8.tflite 3 为 Neutron NPU 编译 neutron-compiler --target imx95   # ① ONNXレベルでINT8量子化 # -cには入力テンソル名と.npyキャリブレーションデータのディレクトリを指定 onnx2quant .onnx -o .onnx -c " ; " # ② ONNX INT8 → TFLite INT8変換(QDQ形式の場合) onnx2tflite --qdq-aware-conversion -o .tflite .onnx # ③ Neutron NPU用コンパイル neutron-compiler --input .tflite --output .tflite --target imx95 ℹ️流程 B 笔记 onnx2quant 然后,需要指定 -c (校准数据规范)或 -u (随机校准数据)。对于多个输入模型,请为每个输入指定 -c 。将 ONNX 转换为 QDQ 格式时,请使用 --qdq-aware-conversion 。执行前,请使用 onnx2quant --help / onnx2tflite --help 检查所用 SDK 的选项。   5. 部署到 i.MX 95 目标平台及性能评估   5.1 Neutron 运行时配置 i.MX 95 (Neutron-S) 的 Neutron 运行时由以下三个组件构成: 组件 文件 地点 中子固件 NeutronFirmware.elf /lib/firmware/ 中子驱动器 libNeutronDriver.so /lib/ TensorFlow Neutron Delegate libneutron_delegate.so /lib/ ⚠️ 注意:更新运行时环境前务必备份现有文件。如果驱动程序、固件和编译器版本不匹配,则会显示“微代码版本不匹配”警告,并且系统可能变得不稳定。   5.2 模型部署 将转换后的 TFLite 模型( .tflite )复制到 i.MX 95 目标板(使用 scp 等)。   5.3 性能评估(基准模型) 我们将使用 NXP Yocto BSP 中包含的 TensorFlow Lite benchmark_model 应用程序,并通过 Neutron Delegate 进行性能评估。 /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph = .tflite \ --external_delegate_path = /usr/lib/libneutron_delegate.so \ --enable_op_profiling = true \ --num_threads = 5 示例输出(按节点类型汇总): Number of nodes executed: 26 ============================== Summary by node type ============================== [Node type] [count] [avg ms] [avg %] [cdf %] [mem KB] [times called] NeutronDelegate 1 2.882 87.919% 87.919% 0.000 1 Slice (ND, X8) 10 0.175 5.339% 93.258% 0.000 10 CONCATENATION 2 0.096 2.929% 96.187% 0.000 2 Unary Elementwise (NC) 2 0.078 2.379% 98.566% 0.000 2 Copy (NC, X8) 11 0.047 1.434% 100.000% 0.000 11 Timings (microseconds): count=270 first=3372 curr=3303 min=3015 max=3537 avg=3290.54 std=76 26 nodes observed 💡 提示: “NeutronDelegate”行中较高的平均百分比表示大部分计算已卸载到 NPU。其他节点(例如切片、连接等)则在 CPU 上执行。如果此比例较低,则可能是由于不支持的运算符导致性能瓶颈,因此请查看“支持的运算符”文档中每个运算符的限制。   6.(可选)位精确验证:neutron-runner neutron-runner 是一款用于验证由 neutron-compiler 转换的模型是否能产生与 Neutron Golden Kernel(参考实现)完全匹配的结果的工具。它不用于生产环境部署,但可用于在迁移过程中验证模型的正确性。 项目 中子模 原版模式 目标模型 使用中子编译器将模型转换为 --keep-graphs 标准 TFLite 型号(FP32/FP16/INT8) 目标 IMX95、IMXRT700 不适用 目的 使用黄金内核进行位精确验证 参考运行(用于比较的基准) 典型的验证工作流程: # ① 启用 --keep-graphs 进行编译 neutron-compiler --input model.tflite --output model_neutron.tflite --target imx95 --keep-graphs # ② 使用 Neutron 运行时(黄金内核)执行 neutron-runner --input model_neutron.tflite --dataset inputs/ --use-neutron-runtime = true --target imx95 # ③ 使用 Vanilla 运行时(参考)运行 neutron-runner --input model.tflite --dataset inputs/ --use-neutron-runtime = false # ④ 比较结果 diff model_neutron_results_0.bin model_results_0.bin ℹ️ 注意:Neutron Golden Kernel 不支持的操作符将自动回退到 TFLite Vanilla 实现。执行完成后,控制台将显示回退的操作符列表。 在 pip 安装环境中 neutron-runner 的执行路径 在 pip/uv 版本中,不会生成 neutron-runner Python 包装器,您可能需要直接在站点包中指定 ELF 二进制文件。 /eiq_neutron_sdk/bin/neutron-runner \ --input model_neutron.tflite \ --dataset inputs/ \ --use-neutron-runtime=true \ --target imx95 在 eIQ Toolkit 的 zip 版本中,像往常一样执行 bin/neutron-runner 。   7. 支持的算符和量化约束 中子编译器对可映射到NPU的运算符存在一些常见限制。不满足这些限制的运算符将回退到CPU执行。   7.1 通用约束(Neutron-S / Neutron-C 通用) 张量的形状必须是静态的(固定的)(批次大小 N 固定为 1;Neutron-C 部分支持可变批次)。 张量类型为 UINT8 / INT8 / INT16 / INT32 / INT64 之一。 张量布局为 NHWC(TFLite 标准)。 量化标度必须为正的 FLOAT32 值。 使用 PTQ 或 PCQ 对权重进行对称量化(偏移量 = 0)。 使用 PTQ 或 PCQ 对偏差进行对称量化,其尺度为 input_scale × weights_scale 不符合上述约束条件的图层将不会映射到 NPU。   7.2 i.MX 95 (Neutron-S) 支持的主要运算符 CONV_2D , DEPTHWISE_CONV_2D , FULLY_CONNECTED , ADD , SUB , MUL , AVERAGE_POOL_2D , MAX_POOL_2D , CONCATENATION , PAD , PADV2 , RESHAPE , RESIZE_BILINEAR , RESIZE_NEAREST_NEIGHBOR , MEAN , SUM , LOGISTIC , TANH , HARD_SWISH , PRELU , LEAKY_RELU ,RELU 系统, TRANSPOSE_CONV , UNIDIRECTIONAL_SEQUENCE_LSTM 等(有关详细约束,请参见 SupportedOperatorsS.md )。 ⚠️ 注意:支持的运算符列表会随着 Neutron Compiler 的每个版本而更新(例如,3.2.1 版本支持 Group Conv2D,3.1.1 版本添加了 CAST/SELECT/UNIDIRECTIONAL_SEQUENCE_LSTM)。请务必查看您正在使用的 SDK 版本的发行说明。   8. 故障排除/常见陷阱 症状 原因 处理 微代码版本不匹配警告 驱动程序/固件/编译器版本不匹配 所有组件均已重新转换和重新排列,以匹配相同的 Neutron SDK 版本。 NeutronDelegate 的平均百分比较低(NPU 利用率低)。 该模型包含许多不支持的操作符(例如 Resize/Reduce)。 检查支持的运算符中的约束,用替代运算符替换它们,或者在保持运算符为 FP 的同时,手动将运算符映射到插值器。 量化后准确度显著下降。 校准数据缺乏代表性,或者特定操作员对量化敏感。 增加校准样本数量(200-1000)。排除 LayerNorm 和类似值,使用 --quantize-operator-types-except 中子编译器转换速度极慢。 使用 OOpt 优化级别或大型模型 首先,使用 OFast(默认)进行检查。仅在需要最高性能时才使用 OOpt(最多使用 16 个核心,会增加转换时间)。 在中子跑者中,一些操作符会回退到原始状态。 黄金内核不支持某些运算符。 未发现问题(运行正常)。请检查备用方案列表,确保它不会影响性能。 未找到命令( command not found ) 命令名称和位置因安装方法而异。 对于 pip/uv 版本,请检查站点包中的下划线表示法和实际路径;对于 zip 版本,请检查连字符表示法和 bin/ onnx2tflite 选项错误,错误代码为 onnx2quant 随附文档与 SDK 版本之间的差异 执行前,请用 --help 检查当前选项名称。   综上所述 本文概述了在 i.MX 95 Neutron-S NPU 上运行 AI 模型的标准转换流程。对于实际应用而言,以下三点尤为重要: 请确保 Neutron SDK 和目标运行时版本匹配。驱动程序、固件、委托和编译器之间的不一致将导致 Microcode version mismatch 。 首先,使用流程 A 检查量化和算子之间的对应关系。使用代表性数据集进行性能分析,可以更轻松地调整精度和与 NPU 的映射关系。 逐个检查 benchmark_model 的结果。如果除了 NeutronDelegate 之外还有许多其他操作,则可能是由于使用了不支持的操作或数据转换导致性能瓶颈。 模型精度、NPU卸载率和推理延迟会因模型结构、量化设置、输入数据和SDK版本而异。建议先从小型模型入手,在真机上进行转换和评估,如果没有出现问题,再逐步应用到目标模型。 本文中的命令示例和相关信息可能因您使用的 Neutron SDK 版本而异。有关最新的官方规范,请参阅 SDK 随附的文档和发行说明。 ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 这是一份关于在i.MX 95的 eIQ Neutron NPU 上运行 AI 模型的实用指南。 本文档解释了将 ONNX/TensorFlow 模型转换为 TFLite、将其量化为 INT8、将其编译为 Neutron NPU、将其部署到目标以及使用 benchmark_model 评估其性能的过程。 (阅读时间:20分钟)*实际编译时间会因型号而异。 i.MX 处理器 技术聚焦 日本博客
View full article
How to compile and run AI models for the i.MX 95 Neutron NPU (Japanese blog) Introduction The eIQ Neutron NPU integrated into the i.MX 95 allows you to offload AI model inference processing to a dedicated accelerator. However, it's not always possible to run the model directly; several preparations are necessary, including quantization, operator compatibility, and version compatibility between the compiler and target runtime. This article outlines the entire process of converting a model created with ONNX or TensorFlow to TFLite, performing INT8 quantization, compiling for Neutron NPUs, deploying to i.MX 95, and evaluating performance using benchmark_model . We will primarily introduce the standard and flexible Flow A , but will also introduce Flow B , which leverages existing ONNX quantization environments. *This article does not specifically limit the use of the AI model; it simply describes the steps involved in the process. The command examples are for Neutron-S. When actually using them, be sure to check the documentation and release notes that come with your installed Neutron SDK , Yocto BSP , and runtime on your target. table of contents overview Host-side tool setup Conversion procedure (Flow A details) Alternative flow: Flow B (ONNX level quantization) Deployment and performance evaluation of the i.MX 95 target. (Optional) Bit-exact verification: neutron-runner Supported Operators and Quantization Constraints Troubleshooting / Common Pitfalls In conclusion   1. Overview This article outlines the conversion procedure for running AI models trained with ONNX or TensorFlow on the eIQ Neutron NPU installed in the i.MX 95. It is based on the official documentation included in the docs folder after installing the Neutron SDK: "Neutron SDK User Guide," "Neutron Compiler User Guide," "TFLite Profiler/Quantizer User Guide," "Neutron Runner User Guide," "Supported Operators (Neutron-S / Neutron-C)," and the i.MX Machine Learning User Guide (UG10166) . ℹ️ Note: The Neutron NPU in the i.MX 95 is classified as the "Neutron-S" architecture (subsystem type). It differs from "Neutron-C" used in MCUs such as the i.MX RT700 in terms of conversion flow and some tool options. This article focuses on the i.MX 95 (Neutron-S).   1.1 Overall Flow (Flow A: Recommended) The standard flow provided by the Neutron SDK involves converting the model to TFLite format, profiling it on a representative dataset, then quantizing it using INT8, and finally compiling it for the NPU with neutron-compiler . ℹ️Supplementary information for first-time users The i.MX 95's Neutron NPU actually runs on INT8 quantized TFLite models compiled for the Neutron NPU . This procedure will ultimately convert your ONNX/TensorFlow model to this format. The starting step will vary depending on the format of the pre-trained model you have prepared. Please use the following as a guide and start from the step that applies to you. INT8 quantized TFLite model: Skip steps 1-3 and start from step 4. FP32 TFLite model: Skip step 1 and start from step 2 onwards. ONNX/TensorFlow FP32 model: Perform steps 1 through 1. For detailed information on each step, please refer to the following chapters. procedure Work details Chapter number ① Convert from ONNX to TFLite FP32 Step 1: Convert the ONNX model to TFLite FP32 format. ② Profiling with representative datasets Step 2: Profiling the FP32 model ③ INT8 quantization based on profile Step 3: INT8 quantization based on profile information ④ Compiled for Neutron NPU Step 4: Compiling for Neutron NPU ⑤ Bit-exact verification as needed 6. (Optional) Bit-exact verification: neutron-runner ⑥ Deploy the converted model to the target. 5.2 Model Deployment ⑦ Inference execution and performance evaluation 5.3 Performance Evaluation (benchmark_model)   1.2 Two Quantization Flows (Flow A / Flow B) The Neutron SDK User Guide defines two flows for obtaining a quantized TFLite model. flow pipeline Quantization tools Features Flow A (Recommended) ONNX FP32 → TFLite FP32 → TFLite INT8 → Neutron conversion tflite-profiler + tflite-quantizer (included with Neutron SDK) It offers a high degree of quantization flexibility. Specific operators can be excluded from quantization, allowing mapping to the Neutron Interpolator while maintaining FP precision. Flow B ONNX FP32 → ONNX INT8 → TFLite INT8 → Neutron conversion onnx2quant (eIQ ONNX2TFLite) Useful when an existing ONNX-based quantization pipeline is in place. Fine-grained operator exclusion control is limited. 💡 Hint: If you're unsure, we recommend Flow A (tflite-profiler + tflite-quantizer). Flow A is essential if you want to map certain operators (such as nonlinear activation functions) to the Neutron Interpolator without quantizing them.   2. Setting up the host-side tools Model conversion will be performed on the development host (Linux/Windows PC). Install the following tools from the NXP eIQ repository. # ONNX → TFLite Conversion Tool pip install eiq-onnx2tflite --index-url https://eiq.nxp.com/repository/ # eIQ Neutron SDK (including tflite-profiler, tflite-quantizer, neutron-compiler, neutron-runner, etc.) pip install eiq-neutron-sdk --index-url https://eiq.nxp.com/repository/ ℹ️ Note: Recommended minimum configuration for development host (neutron-compiler): CPU 2GHz or higher x 8 cores or higher, RAM 4GB or higher. Neutron-S (i.MX 95, etc.) uses a constraint programming solver, so conversion time may take several minutes to several tens of minutes depending on the model. ℹ️If pip install fails If pip install fails to complete in your internal proxy environment, please consider the following options. Using the zip version of eIQ Toolkit — After obtaining and extracting the zip file from the eIQ Toolkit product page , you can run the Neutron tools under bin/ . The zip version uses hyphens, as in tflite-profiler , tflite-quantizer , neutron-compiler , and neutron-runner . On the other hand, the pip/uv version may use underscores, as in tflite_profiler , tflite_quantizer , and neutron_compiler . However, onnx2tflite and onnx2quant are not included in the zip version and must be installed using pip or uv. The following command examples use notation equivalent to the zip version. Install using uv — this may be more successful than pip install depending on your environment. pip install uv uv pip install eiq-onnx2tflite \ --index-url https://eiq.nxp.com/repository/ \ --extra-index-url https://pypi.org/simple/ If a proxy is required, you may need to configure http_proxy / https_proxy (including uppercase environment variables). The configuration method depends on your company's environment.   2.1 Neutron SDK Version and Yocto BSP Compatibility The Neutron Driver, Firmware, and Compiler must all be the same Neutron SDK version. If they are not compatible, the following warning will be output at runtime. Microcode version mismatch! Neutron Driver is 3.1.0-0X359f358d but model converted with 3.0.1-0Xd5d7918e. Runtime (driver, firmware) should be aligned with compiler Compatibility between Yocto BSP versions and Neutron SDK versions (excerpt, based on the latest BSP as of Q3 2026): Yocto BSP Support Release Period Default Neutron SDK LF_6.12.3_1.0.0 Q1/2025 1.2.0 LF_6.12.20_2.0.0 Q2/2025 2.0.2 LF_6.12.34_2.1.0 Q3/2025 2.1.3 LF_6.12.49_2.2.0 Q4/2025 2.2.2 LF_6.18.2_1.0.0 Q1/2026 2.2.3 LF_6.18.20_2.0.0 Q2/2026 3.1.2 LF_6.18.37_2.1.0 Q3/2026 3.2.1 Other Neutron SDK versions can also be used as "Upgradable," but in that case, you will need to update the target runtime (Driver/Firmware/Delegate) to the corresponding version and re-compile the model with the same version of neutron-compiler. For details, please refer to the version compatibility table in the "Neutron SDK User Guide." 3. Conversion Procedure (Flow A Details)   Step 1: Convert the ONNX model to TFLite FP32 format. If your model is already in TFLite FP32 format, this step is unnecessary. Use the onnx2tflite tool to convert your ONNX model to TFLite format. onnx2tflite -o .tflite .onnx ℹ️ Note regarding SDK version -i (Input specification) and -target (FP32/INT8 switching) are deprecated in some SDK versions. The input ONNX file is specified using positional arguments, and check the latest options with onnx2tflite --help before execution. If you change the input/output layout, also check the presence and default values of --keep-io-format / --no-keep-io-format in the SDK you are using.   Step 2: Profiling the FP32 model Using tflite-profiler, we measure the dynamic range (min/max/histogram) of each tensor using a representative input dataset (calibration data). ./tflite-profiler \ --input < my_model_fp32 > .tflite \ --dataset < input_data_dir > \ --output < my_model_fp32_profile > .csv ℹ️Notes regarding input data This contains a .bin file in float32 format that matches the input dimensions of the model. For image models, you can use scripts/serialize_image.py included with the SDK to resize, normalize, and convert to float32 .bin . --use_random_data , used when there is no representative dataset, is for shape verification and communication verification, but is not suitable for accuracy verification. ./tflite-profiler \ --input < my_model_fp32 > .tflite \ --use_random_data \ --random-data-samples 10 \ --output < my_model_fp32_profile > .csv A sample size of 200 to 1000 samples is usually considered sufficient for a representative dataset. For accuracy validation of quantization results, it is recommended to use a separate validation dataset that was not used for calibration.   Step 3: INT8 quantization based on profile information We will use tflite-quantizer to perform INT8 quantization based on the profile (CSV) generated in step 2. ./tflite-quantizer \ --input < my_model_fp32 > .tflite \ --profile < my_model_fp32_profile > .csv \ --output < my_model_quantized > .tflite The main quantization parameters (default values) are as follows: option explanation Default value --quantization-constant-type Weight quantization data type INT8 --quantization-constant-type-bias Quantized data types with bias (Conv2D/FC, etc.) INT32 --quantization-variable-type Quantized data type of activation INT8 --quantization-constant-granularity Granularity of weight quantization (PTQ/PCQ) PCQ (per channel) --quantization-constant-schema Weight quantization schema Symmetric --quantization-variable-schema Activation Quantization Schema Asymmetric --quantization-calibration-method Calibration method (MinMax/Percentile) MinMax To exclude a specific operator from quantization, use --quantize-operator-types-except (e.g., ADD,AVERAGE_POOL_2D ). Quantization-sensitive compound operators like LayerNorm can also be excluded using layernorm . 💡 Hint: After quantization, you can verify the operation with a dummy input using the --run-after-quantize option (only valid for standard INT8 quantization configurations). ℹ️Supplementary information regarding SDK versions Quantization options may vary depending on the SDK. In our verification environment, SDK 3.2.3 has been confirmed to work with the options shown in the table and --quantization-constant-granularity PCQ , but please be sure to verify with tflite-quantizer --help of your target SDK before use.   Step 4: Compiling for Neutron NPU Compile the quantized TFLite model for the i.MX 95 Neutron NPU using neutron-compiler. ./neutron-compiler \ --input < my_model_quantized > .tflite \ --output < my_model_converted > .tflite \ --target imx95 neutron-compiler performs the conversion in the following three stages: step Content ① Optimize Transform the graph into a mathematically equivalent form that conforms to Neutron hardware constraints (graph path). ② Extract Hierarchically mapping corresponding operators from NeutronOperator to custom operators in NeutronGraph. ③ Generate Tile partitioning, scheduling, memory allocation, and binary generation of microcode/weights/kernels. You can check the list of supported targets and operator types using the following command. neutron-compiler --show-targets neutron-compiler --show-operator-types neutron-compiler --target imx95 --show-kernel-kinds   3.1 Major Compiler Options option explanation --target The target Neutron object to be converted (e.g., imx95). If omitted, it defaults to mcxn94x. --output Output file path. If omitted, _compiled will be appended to the input name. --dump-statistics / --dump-statistics-file Output cycle estimation statistics (per NeutronGraph) to console/file. --optimization-level OFast : Fast heuristic (default) / OOpt : Optimal solution using ILP/SAT solver (conversion time is long) --include-operator-types / --exclude-operator-types Specify the operator types to map to/exclude from the NPU. --min-num-ops-per-graph The minimum number of operators to extract as a NeutronGraph. Smaller graphs are optimized for CPU execution. --use-profiling / --use-profiling-tick-trace Enable runtime profiling on actual hardware (kernel level/tick level) --keep-graphs Preserve the intermediate graph (necessary for bit-exact verification in neutron-runner) --force-determinism This suppresses multithreaded contention in the solver and obtains definitive conversion results (conversion time increases by approximately 2-3 times). ℹ️ Note: Because Neutron-S (i.MX 95, etc.) compilers use a constraint programming solver, the generated microcode (especially the TCM address) may differ slightly when the same model is converted multiple times. This is because one of several optimal solutions is selected due to multithreaded contention, and all are correct results. Use --force-determinism when determinism is required.   4. Alternative Flow: Flow B (ONNX Level Quantization) If your existing pipeline relies on ONNX-level quantization ( onnx2quant ), you can also use the following flow. Fine-grained operator exclusion control is more limited than in Flow A. procedure Implementation details Tools used / Main deliverables 1 Quantizing the ONNX FP32 model to INT8 onnx2quant , model_int8.onnx 2 Converting from ONNX INT8 to TFLite INT8 onnx2tflite , model_int8.tflite 3 Compiled for Neutron NPU neutron-compiler --target imx95   # ① ONNXレベルでINT8量子化 # -cには入力テンソル名と.npyキャリブレーションデータのディレクトリを指定 onnx2quant .onnx -o .onnx -c " ; " # ② ONNX INT8 → TFLite INT8変換(QDQ形式の場合) onnx2tflite --qdq-aware-conversion -o .tflite .onnx # ③ Neutron NPU用コンパイル neutron-compiler --input .tflite --output .tflite --target imx95 ℹ️Flow B Notes onnx2quant Then, either -c (calibration data specification) or -u (random calibration data) is required. For multiple input models, specify -c for each input. Use --qdq-aware-conversion when converting ONNX in QDQ format. Before execution, check the options of the SDK being used with onnx2quant --help / onnx2tflite --help .   5. Deployment to the i.MX 95 target and performance evaluation   5.1 Neutron Runtime Configuration The Neutron runtime for i.MX 95 (Neutron-S) consists of the following three components: component file Location Neutron Firmware NeutronFirmware.elf /lib/firmware/ Neutron Driver libNeutronDriver.so /lib/ TensorFlow Neutron Delegate libneutron_delegate.so /lib/ ⚠️ Note: Always back up existing files before updating the runtime. If the driver, firmware, and compiler versions do not match, a "Microcode version mismatch" warning will be displayed, and the system may become unstable.   5.2 Model Deployment Copy the converted TFLite model ( .tflite ) to the i.MX 95 target board (using scp, etc.).   5.3 Performance Evaluation (benchmark_model) We will use the TensorFlow Lite benchmark_model application included in the NXP Yocto BSP and perform performance evaluation via Neutron Delegate. /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph =< my_model_converted > .tflite \ --external_delegate_path = /usr/lib/libneutron_delegate.so \ --enable_op_profiling = true \ --num_threads = 5 Example output (summary by node type): Number of nodes executed: 26 ============================== Summary by node type ============================== [Node type] [count] [avg ms] [avg %] [cdf %] [mem KB] [times called] NeutronDelegate 1 2.882 87.919% 87.919% 0.000 1 Slice (ND, X8) 10 0.175 5.339% 93.258% 0.000 10 CONCATENATION 2 0.096 2.929% 96.187% 0.000 2 Unary Elementwise (NC) 2 0.078 2.379% 98.566% 0.000 2 Copy (NC, X8) 11 0.047 1.434% 100.000% 0.000 11 Timings (microseconds): count=270 first=3372 curr=3303 min=3015 max=3537 avg=3290.54 std=76 26 nodes observed 💡 Hint: A higher avg % in the "NeutronDelegate" row indicates that the majority of the computation is offloaded to the NPU. Other nodes (Slice, Concatenation, etc.) are executed on the CPU. If this ratio is low, unsupported operators may be causing bottlenecks, so check the constraints of each operator in the "Supported Operators" documentation.   6. (Optional) Bit-exact verification: neutron-runner neutron-runner is a tool that verifies whether a model converted by neutron-compiler produces results that perfectly match the Neutron Golden Kernel (reference implementation). It is not used for production deployment, but is useful for verifying the correctness of models during migration. item Neutron Mode Vanilla Mode Target models Model converted with --keep-graphs using neutron-compiler Standard TFLite models (FP32/FP16/INT8) Target IMX95, IMXRT700 N/A the purpose bit-exact verification using Golden Kernel Reference run (baseline for comparison) Typical validation workflow: # ① Compile with --keep-graphs enabled neutron-compiler --input model.tflite --output model_neutron.tflite --target imx95 --keep-graphs # ② Execute using the Neutron runtime (Golden Kernel) neutron-runner --input model_neutron.tflite --dataset inputs/ --use-neutron-runtime = true --target imx95 # ③ Run with Vanilla runtime (reference) neutron-runner --input model.tflite --dataset inputs/ --use-neutron-runtime = false # ④ Compare results diff model_neutron_results_0.bin model_results_0.bin ℹ️ Note: Operators not supported by the Neutron Golden Kernel will automatically fall back to the TFLite Vanilla implementation. After execution is complete, a list of the operators to which it fell back will be displayed in the console. neutron-runner execution path in a pip install environment In the pip/uv version, a Python wrapper for neutron-runner is not generated, and you may need to directly specify the ELF binary within the site package. /eiq_neutron_sdk/bin/neutron-runner \ --input model_neutron.tflite \ --dataset inputs/ \ --use-neutron-runtime=true \ --target imx95 In the zip version of eIQ Toolkit, execute bin/neutron-runner as usual.   7. Supported Operators and Quantization Constraints There are common constraints on the operators that neutron-compiler can map to the NPU. Operators that do not satisfy these constraints will fall back to CPU execution.   7.1 Common constraints (common to Neutron-S / Neutron-C) The shape of the tensor must be static (fixed) (batch size N is fixed at 1; Neutron-C partially supports variable batches). The tensor type is one of UINT8 / INT8 / INT16 / INT32 / INT64. The tensor layout is NHWC (TFLite standard). The quantization scale must be a positive FLOAT32 value. The weights are symmetrically quantized (offset = 0) using PTQ or PCQ. The bias is symmetrically quantized using PTQ or PCQ, and its scale is input_scale × weights_scale Layers that do not meet the above constraints will not be mapped to the NPU.   7.2 Main operators supported by i.MX 95 (Neutron-S) CONV_2D , DEPTHWISE_CONV_2D , FULLY_CONNECTED , ADD , SUB , MUL , AVERAGE_POOL_2D , MAX_POOL_2D , CONCATENATION , PAD , PADV2 , RESHAPE , RESIZE_BILINEAR , RESIZE_NEAREST_NEIGHBOR , MEAN , SUM , LOGISTIC , TANH , HARD_SWISH , PRELU , LEAKY_RELU , RELU systems, TRANSPOSE_CONV , UNIDIRECTIONAL_SEQUENCE_LSTM etc (see SupportedOperatorsS.md for detailed constraints). ⚠️ Note: The list of supported operators is updated with each version of the Neutron Compiler (e.g., Group Conv2D support in 3.2.1, CAST/SELECT/UNIDIRECTIONAL_SEQUENCE_LSTM added in 3.1.1). Be sure to check the release notes for the SDK version you are using.   8. Troubleshooting / Common Pitfalls Symptoms cause handle Microcode version mismatch warning Driver/Firmware/Compiler version mismatch All components are reconverted and rearranged to match the same Neutron SDK version. The average percentage of NeutronDelegate is low (low NPU utilization). The model contains many unsupported operators (such as Resize/Reduce). Check the constraints in Supported Operators, replace them with alternative operators, or manually map the operators to the Interpolator while keeping them as FP. Accuracy decreases significantly after quantization. Calibration data lacks representativeness, or specific operators are sensitive to quantization. Increase the number of calibration samples (200-1000). Exclude LayerNorm and similar values using --quantize-operator-types-except The neutron-compiler conversion is extremely slow. Use OOpt optimization level, or large model First, check with OFast (default). Use OOpt only when maximum performance is required (uses up to 16 cores, increases conversion time). In neutron-runner, some operators fall back to vanilla. There are operators that are not supported by the Golden Kernel. No issues found (expected operation). Check the fallback list to ensure it's not a performance-critical area. Command not found ( command not found ) The command name and location vary depending on the installation method. For pip/uv versions, check for underscore notation and actual paths within the site package; for zip versions, check for hyphen notation and what is under bin/ onnx2tflite Option error with onnx2quant Differences between the included documentation and the SDK version Check the current option name with --help before execution.   In conclusion This article outlined a standard conversion flow for running AI models on the i.MX 95 Neutron-S NPU. Three points are particularly important for practical use: Ensure that the Neutron SDK and the target runtime versions are matched. Inconsistencies between the Driver, Firmware, Delegate, and Compiler will result in Microcode version mismatch . First, use Flow A to check the correspondence between quantization and operators. Profiling with a representative dataset will make it easier to adjust accuracy and mapping to the NPU. Check the results of benchmark_model on an operator-by-operator basis. If there are many operations other than NeutronDelegate , unsupported operators or data conversions may be causing performance bottlenecks. Model accuracy, NPU offload rate, and inference latency vary depending on the model structure, quantization settings, input data, and SDK version. It is recommended to start with a small model, go through the conversion and evaluation on a real device, and then gradually apply it to the target model if there are no problems. The command examples and corresponding information in this article may vary depending on the version of the Neutron SDK you are using. For the latest official specifications, please refer to the documentation and release notes included with your SDK. ========================= 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 an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This is a practical guide for running AI models on the i.MX 95 's eIQ Neutron NPU. This document explains the process from converting an ONNX/TensorFlow model to TFLite, quantizing it to INT8, compiling it for Neutron NPUs, deploying it to the target, and evaluating its performance using benchmark_model. (Reading time: 20 minutes) *Actual compilation time will vary depending on the model. i.MX Processors Technology Focus Japanese Blog
View full article
i.MX 95のNeutron NPU向けにAIモデルをコンパイルして実行する方法 (日本語ブログ) はじめに i.MX 95に搭載されたeIQ Neutron NPUを活用すると、AIモデルの推論処理を専用アクセラレータへオフロードできます。一方で、モデルをそのまま実行できるとは限らず、量子化、演算子の対応状況、コンパイラとターゲット側ランタイムのバージョン整合など、いくつかの準備が必要です。 本記事では、ONNXまたはTensorFlowで作成したモデルをTFLiteへ変換し、INT8量子化、Neutron NPU向けコンパイル、i.MX 95への展開、 benchmark_model による性能評価までを一連の流れとして整理します。標準的で柔軟な Flow A を中心に紹介します。また既存のONNX量子化環境を活用できる Flow B も紹介します。 ※本記事では、AIモデルの用途は特に限定しておらず、一連の流れの手順を紹介します。 コマンド例はNeutron-S向けのものです。実際に使用する際は、インストールしたNeutron SDK、Yocto BSP、およびターゲット上のランタイムに付属するドキュメントとリリースノートを必ず確認してください。 目次 概要 ホスト側ツールのセットアップ 変換手順(Flow A 詳細) 代替フロー:Flow B(ONNXレベル量子化) i.MX 95ターゲットへの展開と性能評価 (任意)Bit-exact検証:neutron-runner 対応演算子(Supported Operators)と量子化制約 トラブルシューティング/よくある落とし穴 おわりに   1. 概要 本記事は、ONNXまたはTensorFlowで学習したAIモデルを、i.MX 95に搭載された eIQ Neutron NPU 上で実行するための変換手順をまとめたものです。Neutron SDKをインストールした後のdocsフォルダに含まれる公式ドキュメント「Neutron SDK User Guide」「Neutron Compiler User Guide」「TFLite Profiler/Quantizer User Guide」「Neutron Runner User Guide」「Supported Operators (Neutron-S / Neutron-C)」およびi.MX機械学習ユーザー・ガイド(UG10166)を基に構成しています。 ℹ️ 補足: i.MX 95 の Neutron NPU は「Neutron-S」アーキテクチャ(サブシステム型)に分類されます。i.MX RT700等のMCU向け「Neutron-C」とは変換フローや一部ツールオプションが異なります。本記事は i.MX 95(Neutron-S)を対象とします。   1.1 全体フロー(Flow A:推奨) Neutron SDKが提供する標準フローは、モデルをTFLite形式へ変換し、代表データセットでプロファイリングを行ったうえでINT8量子化し、 neutron-compiler でNPU向けにコンパイルする流れです。 ℹ️ 初めての方向けの補足 i.MX 95のNeutron NPUで実際に動作するのは、Neutron NPU向けにコンパイルされたINT8量子化済みのTFLiteモデルです。本手順では、手元のONNX/TensorFlowモデルを最終的にこの形式へ変換します。 準備した学習済みモデルの形式によって、開始するステップが異なります。以下を目安に、該当するステップから実施してください。 INT8量子化済みTFLiteモデル:ステップ1〜3を省略し、ステップ4以降から開始 FP32 TFLiteモデル:ステップ1を省略し、ステップ2以降から開始 ONNX/TensorFlowのFP32モデル:ステップ1から順に実施  各手順の詳細は以下の章をご参照ください。 手順 作業内容 章番号 ① ONNXからTFLite FP32へ変換 ステップ1:ONNXモデルをTFLite FP32形式に変換 ② 代表データセットでプロファイリング ステップ2:FP32モデルのプロファイリング ③ プロファイルに基づいてINT8量子化 ステップ3:プロファイル情報に基づくINT8量子化 ④ Neutron NPU向けにコンパイル ステップ4:Neutron NPU用コンパイル ⑤ 必要に応じてBit-exact検証 6. (任意)Bit-exact検証:neutron-runner ⑥ 変換済みモデルをターゲットへ展開 5.2 モデルの展開 ⑦ 推論実行と性能評価 5.3 性能評価(benchmark_model)   1.2 2つの量子化フロー(Flow A / Flow B) Neutron SDK User Guide では、量子化済みTFLiteモデルを得るための2つのフローが定義されています。 フロー パイプライン 量子化ツール 特徴 Flow A(推奨) ONNX FP32 → TFLite FP32 → TFLite INT8 → Neutron変換 tflite-profiler + tflite-quantizer(Neutron SDK付属) 量子化の自由度が高い。特定演算子を量子化対象から除外しFP精度のまま Neutron Interpolator にマッピング可能 Flow B ONNX FP32 → ONNX INT8 → TFLite INT8 → Neutron変換 onnx2quant(eIQ ONNX2TFLite) 既存のONNXベース量子化パイプラインがある場合に有用。細かい演算子除外制御は限定的 💡 ヒント: 判断に迷う場合は Flow A(tflite-profiler + tflite-quantizer)を推奨します。特定の演算子(非線形活性化関数など)を量子化せずNeutron Interpolatorへマッピングしたい場合は Flow A が必須です。   2. ホスト側ツールのセットアップ モデル変換は開発ホスト(Linux/Windows PC)上で実施します。NXPのeIQリポジトリから以下のツールをインストールします。 # ONNX → TFLite 変換ツール pip install eiq-onnx2tflite --index-url https://eiq.nxp.com/repository/ # eIQ Neutron SDK(tflite-profiler, tflite-quantizer, neutron-compiler, neutron-runner 等を含む) pip install eiq-neutron-sdk --index-url https://eiq.nxp.com/repository/ ℹ️ 補足: 推奨開発ホスト最小構成(neutron-compiler):CPU 2GHz以上 ×8コア以上、RAM 4GB以上。Neutron-S(i.MX 95等)はconstraint programmingソルバーを使用するため、モデルによって変換時間が数分~数十分かかることがあります。 ℹ️ pip installがうまくいかない場合 社内プロキシ環境などで pip install が完了しない場合は、次の方法を検討してください。 eIQ Toolkitのzip版を使う — eIQ Toolkit製品ページからzipを取得して展開すると、 bin/ 配下のNeutronツールを実行できます。zip版では、 tflite-profiler 、 tflite-quantizer 、 neutron-compiler 、 neutron-runner のようにハイフン表記を使用します。一方、pip/uv版では tflite_profiler 、 tflite_quantizer 、 neutron_compiler のようにアンダースコア表記になる場合があります。ただし、 onnx2tflite / onnx2quant はzip版に含まれないため、pipまたはuvでの導入が必要です。以降のコマンド例はzip版相当の表記です。 uv を使ってインストールする — 環境によっては pip install より成功しやすい場合があります。 pip install uv uv pip install eiq-onnx2tflite \ --index-url https://eiq.nxp.com/repository/ \ --extra-index-url https://pypi.org/simple/ プロキシ経由が必要な場合は、 http_proxy / https_proxy (大文字の環境変数も含む)の設定が必要になる場合があります。設定方法は社内環境に依存します。   2.1 Neutron SDK バージョンと Yocto BSP の整合性 Neutron Driver・Firmware・Compilerは必ず同一のNeutron SDKバージョンに揃える必要があります。整合していない場合、ランタイムに次の警告が出力されます。 Microcode version mismatch! Neutron Driver is 3.1.0-0X359f358d but model converted with 3.0.1-0Xd5d7918e. Runtime (driver, firmware) should be aligned with compiler Yocto BSPバージョンとNeutron SDKバージョンの対応(抜粋、2026年Q3時点の最新BSPを基準): Yocto BSP 対応リリース期 デフォルトNeutron SDK LF_6.12.3_1.0.0 Q1/2025 1.2.0 LF_6.12.20_2.0.0 Q2/2025 2.0.2 LF_6.12.34_2.1.0 Q3/2025 2.1.3 LF_6.12.49_2.2.0 Q4/2025 2.2.2 LF_6.18.2_1.0.0 Q1/2026 2.2.3 LF_6.18.20_2.0.0 Q2/2026 3.1.2 LF_6.18.37_2.1.0 Q3/2026 3.2.1 上記以外のNeutron SDKバージョンも「Upgradable」として使用可能ですが、その場合はターゲット側のランタイム(Driver / Firmware / Delegate)を該当バージョンに更新し、同じバージョンの neutron-compiler でモデルを再変換する必要があります。詳細は「Neutron SDK User Guide」のバージョン互換表を参照してください。 3. 変換手順(Flow A 詳細)   ステップ1:ONNXモデルをTFLite FP32形式に変換 モデルが既にTFLite FP32形式の場合はこのステップは不要です。onnx2tfliteツールを使用してONNXモデルをTFLite形式に変換します。 onnx2tflite -o .tflite .onnx ℹ️ SDKバージョンに関する注意 -i (入力指定)や -target (FP32/INT8の切り替え)は、SDKバージョンによっては廃止されています。入力ONNXファイルは位置引数で指定し、実行前に onnx2tflite --help で最新のオプションを確認してください。入出力レイアウトを変更する場合は、使用中のSDKで --keep-io-format / --no-keep-io-format の有無と既定値も確認します。   ステップ2:FP32モデルのプロファイリング tflite-profilerを使用し、代表的な入力データセット(キャリブレーションデータ)を用いて各テンソルの動的範囲(min/max/ヒストグラム)を計測します。 ./tflite-profiler \ --input <my_model_fp32>.tflite \ --dataset <input_data_dir> \ --output <my_model_fp32_profile>.csv ℹ️ 入力データに関する注意 には、モデルの入力次元に一致するfloat32形式の .bin ファイルを格納します。画像モデルでは、SDKに付属する scripts/serialize_image.py を使って、リサイズ・正規化・float32の .bin 化を行えます。代表データセットがない場合の --use_random_data は、形状確認や疎通確認向けで、精度検証には適しません。 ./tflite-profiler \ --input <my_model_fp32>.tflite \ --use_random_data \ --random-data-samples 10 \ --output <my_model_fp32_profile>.csv 代表データセットのサンプル数は、通常200〜1000サンプルで十分とされています。量子化結果の精度検証には、キャリブレーションに使用していない別の検証用データセットを使用することが推奨されます。   ステップ3:プロファイル情報に基づくINT8量子化 tflite-quantizerを使用して、ステップ2で生成したプロファイル(CSV)に基づきINT8量子化を行います。 ./tflite-quantizer \ --input <my_model_fp32>.tflite \ --profile <my_model_fp32_profile>.csv \ --output <my_model_quantized>.tflite 主な量子化パラメータ(デフォルト値)は以下の通りです。 オプション 説明 デフォルト値 --quantization-constant-type 重みの量子化データ型 INT8 --quantization-constant-type-bias バイアス(Conv2D/FC等)の量子化データ型 INT32 --quantization-variable-type 活性化(アクティベーション)の量子化データ型 INT8 --quantization-constant-granularity 重み量子化の粒度(PTQ/PCQ) PCQ(チャネル単位) --quantization-constant-schema 重みの量子化スキーマ Symmetric --quantization-variable-schema 活性化の量子化スキーマ Asymmetric --quantization-calibration-method キャリブレーション方式(MinMax/Percentile) MinMax 特定の演算子を量子化対象から除外したい場合は --quantize-operator-types-except (例: ADD,AVERAGE_POOL_2D )を使用します。LayerNormのような量子化に敏感な複合演算子も layernorm 指定で除外可能です。 💡 ヒント: 量子化後は --run-after-quantize オプションでダミー入力による動作確認が可能です(標準的なINT8量子化構成の場合のみ有効)。 ℹ️ SDKバージョンに関する補足 量子化オプションはSDKによって異なる場合があります。検証環境のSDK 3.2.3では、表に示したオプションと --quantization-constant-granularity PCQ の実行を確認していますが、使用前に必ず対象SDKの tflite-quantizer --help で確認してください。   ステップ4:Neutron NPU用コンパイル 量子化済みTFLiteモデルをneutron-compilerでi.MX 95のNeutron NPU向けにコンパイルします。 ./neutron-compiler \ --input <my_model_quantized>.tflite \ --output <my_model_converted>.tflite \ --target imx95 neutron-compilerは以下の3段階で変換を行います。 段階 内容 ① Optimize(最適化) グラフをNeutronハードウェア制約に適合するよう数学的に等価な形へ変換(グラフパス) ② Extract(抽出) 対応演算子を NeutronOperator → NeutronGraph のカスタム演算子へ階層的にマッピング ③ Generate(生成) タイル分割、スケジューリング、メモリ割り付け、マイクロコード/重み/カーネルのバイナリ生成 対応ターゲット一覧やオペレータタイプ一覧は以下のコマンドで確認できます。 neutron-compiler --show-targets neutron-compiler --show-operator-types neutron-compiler --target imx95 --show-kernel-kinds   3.1 主要なコンパイラオプション オプション 説明 --target 変換先のNeutronターゲット(例:imx95)。省略時は mcxn94x --output 出力ファイルパス。省略時は入力名に _compiled を付加 --dump-statistics / --dump-statistics-file サイクル推定統計(NeutronGraphごと)をコンソール/ファイルへ出力 --optimization-level OFast :高速ヒューリスティック(デフォルト) / OOpt :ILP/SATソルバーで最適解(変換時間は長い) --include-operator-types / --exclude-operator-types NPUへマッピングする/除外する演算子タイプを指定 --min-num-ops-per-graph NeutronGraphとして抽出する最小演算子数。小さいグラフはCPU実行の方が有利な場合に調整 --use-profiling / --use-profiling-tick-trace 実機でのランタイムプロファイリングを有効化(カーネル単位/ティック単位) --keep-graphs 中間グラフを保持(neutron-runnerでのbit-exact検証に必要) --force-determinism ソルバーのマルチスレッド競合を抑制し決定的な変換結果を得る(変換時間は約2〜3倍に増加) ℹ️ 補足: Neutron-S(i.MX 95等)のコンパイラは制約プログラミングソルバーを使用するため、同一モデルを複数回変換すると生成されるマイクロコード(特にTCMアドレス)がわずかに異なることがあります。これはマルチスレッドの競合による複数の最適解の一つが選ばれるためで、いずれも正しい結果です。決定性が必要な場合は --force-determinism を使用します。   4. 代替フロー:Flow B(ONNXレベル量子化) 既存のパイプラインがONNXレベルの量子化( onnx2quant )に依存している場合は、次のフローも利用できます。細かな演算子除外制御はFlow Aより限定的です。 手順 実施内容 使用ツール/主な成果物 1 ONNX FP32モデルをINT8量子化 onnx2quant 、 model_int8.onnx 2 ONNX INT8からTFLite INT8へ変換 onnx2tflite 、 model_int8.tflite 3 Neutron NPU向けにコンパイル neutron-compiler --target imx95   # ① ONNXレベルでINT8量子化 # -cには入力テンソル名と.npyキャリブレーションデータのディレクトリを指定 onnx2quant .onnx -o .onnx -c " ; " # ② ONNX INT8 → TFLite INT8変換(QDQ形式の場合) onnx2tflite --qdq-aware-conversion -o .tflite .onnx # ③ Neutron NPU用コンパイル neutron-compiler --input .tflite --output .tflite --target imx95 ℹ️ Flow Bの注意 onnx2quant では、 -c (キャリブレーションデータ指定)または -u (ランダムキャリブレーションデータ)のいずれかが必要です。複数入力モデルでは入力ごとに -c を指定します。QDQ形式のONNXを変換する場合は --qdq-aware-conversion を使用します。実行前に onnx2quant --help / onnx2tflite --help で使用中SDKのオプションを確認してください。   5. i.MX 95ターゲットへの展開と性能評価   5.1 Neutronランタイムの構成 i.MX 95(Neutron-S)のNeutronランタイムは以下3つのコンポーネントで構成されます。 コンポーネント ファイル 配置先 Neutron Firmware NeutronFirmware.elf /lib/firmware/ Neutron Driver libNeutronDriver.so /lib/ TensorFlow Neutron Delegate libneutron_delegate.so /lib/ ⚠️ 注意: ランタイム更新前に既存ファイルを必ずバックアップしてください。Driver・Firmware・Compilerのバージョンが一致していないと「Microcode version mismatch」警告が出力され、動作が不安定になる可能性があります。   5.2 モデルの展開 変換済みTFLiteモデル( .tflite )をi.MX 95ターゲットボードへコピーします(scp等)。   5.3 性能評価(benchmark_model) NXP Yocto BSPに含まれるTensorFlow Liteの benchmark_model アプリケーションを使用し、Neutron Delegate経由で性能評価を行います。 /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=<my_model_converted>.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so \ --enable_op_profiling=true \ --num_threads=5 出力例(ノードタイプ別サマリー): Number of nodes executed: 26 ============================== Summary by node type ============================== [Node type] [count] [avg ms] [avg %] [cdf %] [mem KB] [times called] NeutronDelegate 1 2.882 87.919% 87.919% 0.000 1 Slice (ND, X8) 10 0.175 5.339% 93.258% 0.000 10 CONCATENATION 2 0.096 2.929% 96.187% 0.000 2 Unary Elementwise (NC) 2 0.078 2.379% 98.566% 0.000 2 Copy (NC, X8) 11 0.047 1.434% 100.000% 0.000 11 Timings (microseconds): count=270 first=3372 curr=3303 min=3015 max=3537 avg=3290.54 std=76 26 nodes observed 💡 ヒント: 「NeutronDelegate」行の avg % が高いほど、計算の大部分がNPUへオフロードされていることを示します。それ以外のノード(Slice, Concatenation等)はCPU実行です。この比率が低い場合、未対応演算子がボトルネックになっている可能性があるため、「Supported Operators」資料で各演算子の制約を確認してください。   6. (任意)Bit-exact検証:neutron-runner neutron-runnerは、neutron-compilerで変換したモデルがNeutron Golden Kernel(参照実装)と完全に一致した結果を出すかを検証するツールです。本番デプロイには使用しませんが、モデル移行時の正しさの検証に有用です。 項目 Neutron Mode Vanilla Mode 対象モデル neutron-compilerで --keep-graphs 付きで変換したモデル 標準TFLiteモデル(FP32/FP16/INT8) 対応ターゲット imx95, imxrt700 N/A 目的 Golden Kernelによるbit-exact検証 リファレンス実行(比較用ベースライン) 典型的な検証ワークフロー: # ① --keep-graphs付きでコンパイル neutron-compiler --input model.tflite --output model_neutron.tflite --target imx95 --keep-graphs # ② Neutronランタイム(Golden Kernel)で実行 neutron-runner --input model_neutron.tflite --dataset inputs/ --use-neutron-runtime=true --target imx95 # ③ Vanillaランタイム(リファレンス)で実行 neutron-runner --input model.tflite --dataset inputs/ --use-neutron-runtime=false # ④ 結果比較 diff model_neutron_results_0.bin model_results_0.bin ℹ️ 補足: Neutron Golden Kernelが未対応の演算子は自動的にTFLite Vanilla実装にフォールバックします。実行完了後、フォールバックした演算子一覧がコンソールに表示されます。 pip install環境でのneutron-runner実行パス pip/uv版では、 neutron-runner 用のPythonラッパーが生成されず、サイトパッケージ内のELFバイナリを直接指定する場合があります。 /eiq_neutron_sdk/bin/neutron-runner \ --input model_neutron.tflite \ --dataset inputs/ \ --use-neutron-runtime=true \ --target imx95 eIQ Toolkitのzip版では、通常どおり bin/neutron-runner を実行します。   7. 対応演算子(Supported Operators)と量子化制約 neutron-compilerがNPUへマッピング可能な演算子には共通の制約があります。制約を満たさない演算子はCPU実行にフォールバックします。   7.1 共通制約(Neutron-S / Neutron-C 共通) テンソルの形状は静的(固定)でなければならない(バッチサイズNは1固定:Neutron-Cは可変バッチも一部対応) テンソル型は UINT8 / INT8 / INT16 / INT32 / INT64 のいずれか テンソルレイアウトは NHWC(TFLite標準) 量子化スケールは正のFLOAT32値であること 重み(Weights)はPTQまたはPCQで対称量子化(オフセット=0)されていること バイアス(Bias)はPTQまたはPCQで対称量子化され、スケールは input_scale × weights_scale であること 上記制約を満たさない層はNPUへマッピングされません。   7.2 i.MX 95(Neutron-S)で対応する主な演算子 CONV_2D , DEPTHWISE_CONV_2D , FULLY_CONNECTED , ADD , SUB , MUL , AVERAGE_POOL_2D , MAX_POOL_2D , CONCATENATION , PAD , PADV2 , RESHAPE , RESIZE_BILINEAR , RESIZE_NEAREST_NEIGHBOR , MEAN , SUM , LOGISTIC , TANH , HARD_SWISH , PRELU , LEAKY_RELU , RELU系, TRANSPOSE_CONV , UNIDIRECTIONAL_SEQUENCE_LSTM 等(詳細な制約は SupportedOperatorsS.md を参照)。 ⚠️ 注意: 対応演算子リストは Neutron Compiler のバージョンごとに更新されます(例:3.2.1でGroup Conv2D対応、3.1.1でCAST/SELECT/UNIDIRECTIONAL_SEQUENCE_LSTM追加)。使用するSDKバージョンのリリースノートを必ず確認してください。   8. トラブルシューティング/よくある落とし穴 症状 原因 対処 Microcode version mismatch 警告 Driver/Firmware/Compilerのバージョン不一致 全コンポーネントを同一Neutron SDKバージョンに揃えて再変換・再配置 NeutronDelegateのavg%が低い(NPU活用率が低い) モデル内に未対応演算子(Resize/Reduce等)が多く含まれる Supported Operatorsで制約を確認し、代替演算子へ置換、または演算子を手動でFPのままInterpolatorへマッピング 量子化後に精度が大きく低下 キャリブレーションデータが代表性不足、または特定演算子が量子化に敏感 キャリブレーションサンプル数を増やす(200〜1000)。LayerNorm等は --quantize-operator-types-except で除外 neutron-compilerの変換が極端に遅い OOpt最適化レベル使用、または大規模モデル まずOFast(デフォルト)で確認。OOptは最大性能が必要な場合のみ使用(最大16コア使用、変換時間増大) neutron-runnerで一部演算子がVanillaにフォールバック Golden Kernel未対応演算子が存在 問題なし(想定動作)。フォールバック一覧を確認し、性能クリティカルな箇所でないか確認 コマンドが見つからない( command not found ) インストール方法によってコマンド名・配置場所が異なる pip/uv版はアンダースコア表記やサイトパッケージ内の実体パスを確認し、zip版はハイフン表記と bin/ 配下を確認する onnx2tflite / onnx2quant でオプションエラー 付属ドキュメントとSDKバージョンの相違 実行前に --help で現在のオプション名を確認する   おわりに 本記事では、i.MX 95のNeutron-S NPUでAIモデルを実行するための標準的な変換フローを紹介しました。実運用で特に重要なポイントは、次の3点です。 Neutron SDKとターゲット側ランタイムのバージョンを揃えること。 Driver、Firmware、Delegate、Compilerの不整合は、 Microcode version mismatch の原因になります。 まずはFlow Aで量子化と演算子の対応状況を確認すること。 代表データセットを使ったプロファイリングにより、精度とNPUへのマッピングを調整しやすくなります。 benchmark_model の結果を演算子単位で確認すること。 NeutronDelegate 以外の処理が多い場合は、未対応演算子やデータ変換が性能上のボトルネックになっている可能性があります。 モデルの精度、NPUへのオフロード率、推論レイテンシーは、モデル構造、量子化設定、入力データ、SDKバージョンによって変わります。まずは小さなモデルで変換から実機評価までを通し、問題がなければ対象モデルへ段階的に適用する進め方がおすすめです。 本記事のコマンド例および対応情報は、使用するNeutron SDKのバージョンによって変わる場合があります。最新の正式仕様は、利用中のSDKに付属するドキュメントとリリースノートを参照してください。 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) i.MX 95のeIQ Neutron NPUでAIモデルを実行するための実践ガイドです。 ONNX/TensorFlowモデルのTFLite変換、INT8量子化、Neutron NPU向けコンパイル、ターゲットへの展開、benchmark_modelによる性能評価までの流れを解説します。 (読了:20分) ※実際に作業する場合は、モデルによってコンパイル時間が変わります。 i.MX Processors Technology Focus 日本語ブログ
View full article
[MCX A153] LPI2C入門ガイド (日本語ブログ) はじめに 本記事はマイコン初心者を対象に、NXPマイコン MCX A153の周辺機能と使い方を解説し、NXPが提供するSDKサンプルプログラムを実際に変更しながら、基本的な考え方と実装方法を学びます。 目次   1. アプリケーション上のよくある使い方の例(I²C編) 1.1 主な用途 1.2 使用例 2. I²Cの基礎 2.1 そもそもI²Cとは 2.2 マイコンのI²Cモジュール 3. MCX A153 I²Cモジュール(LPI2C)の主な機能とブロック図 3.1 概要 3.2 ブロック図 3.3 機能 4. 使用機材と開発ツール 4.1 評価ボード(FRDM-MCXA153) 4.2 開発ツール(MCUXpresso for VS CodeとIDE) 5. プログラミング 5.1 ベースとなるサンプルコードの内容を確認する 5.2 ピン設定 5.3 プログラムコードの変更点 6. 実習 6.1 実習内容 6.2 実習手順 6.3 評価ボードにプルアップ抵抗を付ける 6.4 変更点のコーディング 6.5 PIN configuratorを使ってピン設定を変更 6.6 ビルド&デバッグ、動作確認   1. アプリケーション上のよくある使い方の例(I²C編)   この章のポイント:I²Cがどのような場面で使われるかを確認します。   1.1 主な用途 I²Cは、デバイス内のレジスタアドレスを指定してデータを読み書きする通信方式です。信号線が少ないため、1枚の基板上で複数のICを制御する用途に向いています。一方、配線容量やノイズの影響を受けやすいため、一般には短距離の通信に使います。 温度・加速度・磁気センサーなどの各種センサー接続 デジタルポテンショメータ IOエキスパンダ EEPROM RTC 表示用デバイス(LCD、LEDなど)の入出力拡張 マイコン間通信(FRDM-MCXA153評価ボードのサンプルプログラムにあります) 1.2 使用例 実際の使用例は、パソコンのマザーボード、組み込みシステム、携帯電話などです。   2. I²Cの基礎   この章のポイント:SDA、SCL、アドレス、ACK/NACK、プルアップ抵抗というI²Cの基本用語を整理します。   2.1 そもそもI²Cとは I²Cは、Philips Semiconductors社(現在のNXP Semiconductors社)が開発したシリアルバス通信規格です。現在では、基板上のセンサーや周辺ICを接続する代表的な方式として広く使われています。 I²Cは、クロックに同期してデータを送る同期式シリアル通信です。データ線をSDA、クロック線をSCLと呼び、SDAをSCLのタイミングに合わせて通信します。 各スレーブは固有のアドレスを持ち、マスターはそのアドレスを指定して通信します。通信開始時にアドレスを送ると、対象のスレーブがACK(アクノリッジ)を返します。受信できない場合はACKを返さず、これをNACK(ナック)と呼びます。 スタートコンディション、アドレス、R/Wビット、ACK/NACK、ストップコンディションというプロトコルで通信します。 アドレスには7ビットモードと10ビットモードがあります。 I²Cはオープンドレイン方式です。プルアップ抵抗によってSDAとSCLを通常Highに保ち、各デバイスが必要なタイミングでLowに引き下げます。そのため、通信ラインにはプルアップ抵抗が必要です。 マスターには通常マイコンを使います。通信完了を知る方法には、スレーブからの割り込みを使う方法と、マスターが完了フラグを繰り返し確認するポーリング方式があります。割り込みを使う時には、各スレーブに割り込み出力、マスターに割り込み入力を設けなければなりません。割り込みを使う場合の方が、レスポンスが速いですが、ハードウェアが重くなります。 I²Cについて、より詳しく知りたい方は以下の記事をご参考ください。 I²Cバスの概要 (日本語ブログ) 今回は、評価ボードの配線条件に合わせてポーリング方式を使います。 代表的な転送速度は、標準モードが100kbps、ファストモードが400kbpsです。MCX A153はファストモードプラスにも対応し、最大1Mbpsで通信できます。 マスターからスレーブにデータを送信する場合の手順は次のようになります。 マスターが通信を開始 マスターがスレーブアドレスを指定 マスターからスレーブにデータを送信 マスターが通信を終了 逆に、マスターがスレーブからデータを受信する場合の手順は次のようになります。 マスターが通信を開始 マスターがスレーブアドレスを指定 マスターがスレーブからデータを受信する マスターが通信を終了   2.2 マイコンのI²Cモジュール 下図に一般的なマイコンに搭載されているI²Cモジュールのブロック図を示します。 構成ブロックはそんなに多くありません。送信バッファのCommand/TX FIFO、受信バッファのRXFIFO、設定用レジスタと、通信を制御する制御回路が主なブロックです。さらに、最近では、ほとんどのマイコンでノイズフィルタが内蔵されています。 3. MCX A153 I²Cモジュール(LPI2C)の主な機能とブロック図   この章のポイント:一般的なI²Cと、MCX A153のLPI2Cモジュールの違いを確認します。   3.1 概要 ここまで、一般的なI²Cの基礎知識を説明しましたが、この章では、MCX A153のI²CモジュールLPI2Cについて説明します。LPI2Cは前述した基本的なI²Cよりはるかに高機能です。LPI2Cは、マスター(コントローラ)およびスレーブ(ターゲット)としてI²Cバスへの効率的なインターフェースをサポートします。 以下に、主な特長を挙げます。 標準、高速、高速+、HSモード(ターゲットのみ)、超高速の各動作モードのロジックをサポート。 FIFOへのアクセスをDMAオフロードすることで、CPUオーバーヘッドを最小限に抑える。 LPI2Cは、システム管理バス(SMBus)仕様バージョン3にも準拠。 ※注1 MCX A153のリファレンスマニュアルの中では、「マスターとコントローラ」、「スレーブとターゲット」という言葉が混在して使われています。現在では「コントローラ」「ターゲット」が推奨されていますが、今回は、マスターとスレーブで統一します。 3.2 ブロック図 MCX A153のLPI2Cモジュールは、上半分がマスター、下半分がスレーブになっています。SDAとSCLもマスター用とスレーブ用に分かれており、スレーブ用には添え字にSが付いているので、SDASとSCLSになります。また、外部端子HREQや内部信号Triggerで通信をスタートすることができます。 3.3 機能 LPI2Cの機能は以下の通りです。 標準、高速、高速+、超高速モード マルチコントローラ(同期およびアービトレーションを含む) クロックストレッチング アービトレーション(システムに複数のコントローラが存在する場合) 7ビットアドレッシング、10ビットアドレッシング ソフトウェアリセット、スタートバイト、デバイスID(ソフトウェアサポートも必要) コマンドおよび送信FIFO(4ワード、8ビット送信データ+3ビットコマンド) 受信FIFO(4ワード、8ビット受信データ) I²Cバス転送の開始時間を制御するためのホスト要求入力 受信データマッチングによる、データ一致時および不要なデータ拒否時の割り込み生成 繰り返し開始条件、停止条件、アービトレーションの喪失、予期しないNACK、およびコマンドワードエラー時のフラグとオプションの割り込み信号 設定可能なバスアイドルタイムアウトおよびピンスタックロータイムアウト 独立したI²Cターゲットレジスタ 7ビットまたは10ビットのアドレス指定 割り込みまたはDMA要求をサポートする送/受信データレジスタ ACKまたはNACKをソフトウェアで制御可能 送信FIFOアンダーランおよび受信FIFOオーバーランエラーを回避するためのクロックストレッチング設定可能 パケット終了時のフラグおよびオプションの割り込み、ストップコンディション、またはビットエラー検出 4. 使用機材と開発ツール   4.1 評価ボード(FRDM-MCXA153) 今回の実習に使用する機材は、Windows PCとMCX A153用の評価キットFRDM-MCXA153(FRDM-MCXA153 Development Board using MCUXpresso | NXP Semiconductors )です。 USB Type-CケーブルはFRDM-MCXA153に同梱されています。FRDM-MCXA153の基板情報や回路については、Webの「デザイン・ファイル」をクリックすると入手できます。(アカウント登録が必要) FRDM-MCXA153には温度センサーP3T1755が搭載されています。初期状態ではP3T1755がI3C0に接続されているため、今回はピン設定を変更してLPI2Cに接続し、LPI2Cで温度を読み出します。 P3T1755からLPI2Cへの割り込みラインは配線されていないため、LPI2Cはポーリング方式のマスターとして使います。また、MCX A153とP3T1755の信号線にはプルアップ抵抗がないため、外付け抵抗を追加します。 4.2 開発ツール(MCUXpresso for VS CodeとIDE) 本記事では、MCUXpresso for VS CodeまたはMCUXpresso IDEを使って、SDKサンプルを編集・実行します。開発ツールは、プロジェクトの作成、コード編集、設定、実行を行うための環境です。ツールのインストール方法や初期設定は、本記事では扱いません。使用する環境に合わせて、NXPの公式ガイドを参照してください。 5. プログラミング   この章のポイント:まずサンプルコードの動きを理解し、その後にP3T1755用へ変更します。   5.1 ベースとなるサンプルコードの内容を確認する I²Cのサンプルプログラムとしていくつかのプログラムが準備されています。 今回は、ポーリングを使ったマスターの「lpi2c_edma_b2b_polling_master」のサンプルプログラムを使います。このサンプルプログラムを変更して、FRDM-MCXA153に搭載されている温度センサーのP3T1755からI²Cを使って温度データを読み取るプログラムを作ります。 デフォルトだと、P3T1755にはI3CモジュールI3C0がつながっていますが、プログラムを変更することでLPI2Cにつなぎ変えて、LPI2Cを使ってP3T1755の温度を読み出すプログラムを作ります。 FRDM-MCXA153では、P3T1755からLPI2Cに割り込みラインは配線されていないため、LPI2Cはポーリングのマスターで使わなければなりません。また、MCX A153とP3T1755をつなぐ配線にはプルアップ抵抗が付いていないため、プルアップ抵抗を追加します。 このサンプルでは、一方のボードに lpi2cインスタンスをマスターとして、もう一方のボードに lpi2cインスタンスをスレーブとして実装します。マスターはスレーブにデータを送信し、スレーブからデータを受信します。このサンプルでは、スレーブから受信したデータが正しいかどうかを確認します。 通信手順の概略は、次のようになります。 マスターから通信開始の合図(スタートコンディション)を送信 マスターからスレーブアドレスを送信 スレーブからマスターに通信可能の合図(アクノリッジ)を返す データの通信を行う (送信データに応じて繰り返す) マスターから通信終了の合図(ストップコンディション)を出す さらに細かく分けると、スレーブに情報を書き込むWrite制御と、スレーブから情報を読み出すRead制御の2つに分けられます。最初にWrite制御を行い、次にRead制御を行い、温度データを読み出します。 ポーリングを使ったマスター側の制御としては、これが基本手順です。スレーブがマイコンのI²Cモジュールだろうが、温度センサーなどのセンサーICだろうが、同じです。 [Write制御] Write制御の手順は、次のようになります。使用する関数と説明を記載します。 ①Start コンディション + スレーブアドレス + ライトビット を送信: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 この関数は新しいマスターモード転送を開始する。 ②ターゲットデバイスのレジスタアドレスとデータを送信: LPI2C_MasterSend:I²Cバスにデータを送信。 この関数はバッファのデータを送信するまで待機する。 ③Stop コンディションを送信: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 この関数はストップ信号が送信されるまで待機し、トランザクション が終了するまで待機する。 [Read制御] Read制御の手順は、次のようになります。ここでも使用する関数と説明を記載します。 ①Startコンディション + スレーブアドレス + ライトビットを送信: LPI2C_MasterStart:スタート信号とスレーブアドレスを送信。 この関数は新しいマスターモード転送を開始する。 ②ターゲットデバイスのレジスタアドレスを送信: LPI2C_MasterRepeatedStart:LPI2C_MasterStart を再度実行する。 この関数では通常、レジスタアドレスを送る ③Startコンディション + スレーブアドレス + リードビットを送信: LPI2C_MasterReceive:I²Cバスからデータを受信。 この関数はバッファのデータを転送するまで待機する。 ④ターゲットデバイスのデータを受信: LPI2C_MasterSend:I²Cバスにデータを送信。 この関数はバッファのデータを送信するまで待機する。 ⑤Stop コンディションを送信: LPI2C_MasterStop:I²Cバスにストップ信号を送信。 この関数はストップ信号が送信されるまで待機し、トランザクションが終了するまで待機する。 サンプルプログラム「lpi2c_edma_b2b_polling_master」のフローチャートを、最後の章の補足説明に載せておきました。参考にしてください。 また、使用されている関数の説明は MCX A153 API Reference にありますが、今回使用する関数の説明を最後の章の補足説明に抜き出しました。こちらも参考にしてください。 5.2 ピン設定 P3T1755は、デフォルトだとI3CモジュールのI3C0がつながっていますので、これをLPI2Cにつなぎ変える必要があります。ピン接続の変さらにはConfig Tools というツールの中の、Pin Configuratorという便利な機能を使います。Pin Configuratorを使うと、GUIでピン割り当てを変更できて、さらに自動でC言語コードまで作ってくれます。具体的な操作は実習の章で詳しく説明します。 5.3 プログラムコードの変更点 通信の基本的な流れはサンプルと同じですが、P3T1755に合わせて、スレーブアドレス、レジスタアドレス、データ長を変更します。さらに、受信した16ビット値を温度へ変換します。 まず、スレーブアドレスをP3T1755の0x48Uに変更します サンプルプログラムでは扱うデータが33バイトですが、P3T1755の場合は16ビットの温度データですので、データ長を16ビットに変更します P3T1755から読み出す温度データ16ビットを入れる定数を定義します。ここではtemperatureとします レジスタアドレスは、deviceAddressで定義されていて、0x01Uですが、P3T1755の場合は0x00Uです 転送するデータの数をtxCountで定義していて、サンプルプログラムでは0xFFUですが、P3T1755から読み出す温度データは2バイト(16ビット)なので、0x01Uに減らします サンプルプログラムでは、マスターが送信したデータと同じデータがスレーブから返ってきて、送受信データの比較を行っていますが、ここの処理は不要です その代わりにP3T1755から受信したデータを温度データとしてまとめる処理が必要です。P3T1755から受信するデータは2バイト(16ビット)です。受信バッファはg_master_rxBuff[1]とg_master_rxBuff[0]で定義しており、各々1バイトが入りますので、 g_master_rxBuff[0]を上位バイト、g_master_rxBuff[1]を下位バイトとして 16 ビットに結合します。結合結果をtempに入れます 結合した温度データの1ビットが0.0625℃に相当しますので、0.0625倍すると温度が得られます。幸いにも0.0625倍は、浮動小数点演算など使わずに、右に4ビットシフトすると簡単に計算できます。計算結果はtemperatureに入れます 最後にtemperatureをprintfで表示します     6. 実習   この章では、ツールのインストールや画面操作の詳細ではなく、必要なハードウェア準備と、P3T1755用にコードを変更するポイントに集中します。   6.1 実習内容 FRDM-MCXA153に搭載されたP3T1755温度センサーを、LPI2Cで読み出します。P3T1755は初期状態ではI3C0に接続されているため、LPI2Cへ接続するピン設定が必要です。また、I²C信号線にはプルアップ抵抗を追加します。 ソフトウェアでは、LPI2CのSDKサンプルをベースに、P3T1755のスレーブアドレス、レジスタアドレス、データ長、温度データの計算処理を変更します。 6.2 実習手順(概要) 評価ボードのSDA・SCLに4.7kΩのプルアップ抵抗を接続します。 MCUXpresso環境でLPI2Cのサンプルプロジェクトを準備します。具体的なインストール・インポート手順は省略します。 ピン設定を、P3T1755が接続されているLPI2C用のピンへ変更します。 次の6.7節に示すコード変更を行います。 プログラムを実行し、温度値が出力されることを確認します。   6.3 評価ボードにプルアップ抵抗を付ける P3T1755のI²CラインにはJunction PA(J20、J21)が設けられています。J20とJ21に4.7kΩの抵抗を付け、SDAとSCLをプルアップ接続してください。 重要! 内蔵プルアップだけでは、ボードによって通信が安定しない場合があります。確実に通信するため、外付けのプルアップ抵抗を使用してください。 6.4 変更点のコーディング プログラミングの章で説明した内容を、実際の.cファイルにコーディングします。 「5.3 プログラムコードの変更点」で説明した変更内容を、コードに反映していきます。 (1)スレーブアドレスをP3T1755の0x48Uに変更する。 [変更前]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x7EU [変更後]#define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U (2)データ長を16ビットに変更する。 [変更前]#define LPI2C_DATA_LENGTH 33U [変更後]#define LPI2C_DATA_LENGTH 2U (3)P3T1755から読み出す温度データ16ビットを入れる定数temperatureを定義する。 [追加]uint16_t temperature; (4)レジスタアドレスdeviceAddressを0x00Uに変更する。 [変更前]uint8_t deviceAddress = 0x01U; [変更後]uint8_t deviceAddress = 0x00U; (5)転送データ数txCountを0x01Uに変更する。 [変更前]size_t txCount = 0xFFU; [変更後]size_t txCount = 0x01U; (6)受信データの数の調整 [変更前]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH - 1); [変更後]reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); (7)送信データと受信データの比較部分を削除。 [削除] /* Transfer completed. Check the data.*/以下のコード (8)P3T1755から受信したデータを温度データとしてまとめる。g_master_rxBuff[0]を上位バイト、g_master_rxBuff[1]を下位バイトとして 16 ビットに結合し、結合結果をtempに入れる。 [追加] temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; (9)tempを右に4ビットシフトしてtemperatureに入れる。 [追加]temperature = temp >> 4; (10)temperatureをprintfで表示します。 [追加] PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); (11)最後には、無限ループを入れておきます。 [追加]while (1) {} ここまでの変更を反映した全コードを、参考として以下に示します。   [全コード] /* * Copyright 2017 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ /* Standard C Included Files */ #include #include #include "board.h" #include "fsl_debug_console.h" #include "fsl_lpi2c.h" #include "app.h" /******************************************************************************* * Definitions ******************************************************************************/ #define EXAMPLE_I2C_MASTER ((LPI2C_Type *)EXAMPLE_I2C_MASTER_BASE) #define LPI2C_MASTER_SLAVE_ADDR_7BIT 0x48U #define LPI2C_BAUDRATE 100000U #define LPI2C_DATA_LENGTH 2U /******************************************************************************* * Prototypes ******************************************************************************/ /******************************************************************************* * Variables ******************************************************************************/ uint8_t g_master_txBuff[LPI2C_DATA_LENGTH]; uint8_t g_master_rxBuff[LPI2C_DATA_LENGTH]; uint16_t temp; /* 追加 */ uint16_t temperature; /* 追加 */ /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Main function */ int main(void) { lpi2c_master_config_t masterConfig; status_t reVal = kStatus_Fail; uint8_t deviceAddress = 0x00U; size_t txCount = 0x01U; BOARD_InitHardware(); /* Set up i2c master to send data to slave*/ /* First data in txBuff is data length of the transmiting data. */ g_master_txBuff[0] = LPI2C_DATA_LENGTH - 1U; for (uint32_t i = 1U; i < LPI2C_DATA_LENGTH; i++) { g_master_txBuff[i] = i - 1; } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH - 1U; i++) { if (i % 8 == 0) { } } /* * masterConfig.debugEnable = false; * masterConfig.ignoreAck = false; * masterConfig.pinConfig = kLPI2C_2PinOpenDrain; * masterConfig.baudRate_Hz = 100000U; * masterConfig.busIdleTimeout_ns = 0; * masterConfig.pinLowTimeout_ns = 0; * masterConfig.sdaGlitchFilterWidth_ns = 0; * masterConfig.sclGlitchFilterWidth_ns = 0; */ LPI2C_MasterGetDefaultConfig(&masterConfig); /* Change the default baudrate configuration */ masterConfig.baudRate_Hz = LPI2C_BAUDRATE; /* Initialize the LPI2C master peripheral */ LPI2C_MasterInit(EXAMPLE_I2C_MASTER, &masterConfig, LPI2C_MASTER_CLOCK_FREQUENCY); /* Send master start bit &Slave Address + Write Bit */ if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, g_master_txBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < WAIT_TIME; i++) { __NOP(); } if (kStatus_Success == LPI2C_MasterStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Write)) { /* Check master tx FIFO empty or not */ LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); while (txCount) { LPI2C_MasterGetFifoCounts(EXAMPLE_I2C_MASTER, NULL, &txCount); } /* Check communicate with slave successful or not */ if (LPI2C_MasterGetStatusFlags(EXAMPLE_I2C_MASTER) & kLPI2C_MasterNackDetectFlag) { return kStatus_LPI2C_Nak; } reVal = LPI2C_MasterSend(EXAMPLE_I2C_MASTER, &deviceAddress, 1); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterRepeatedStart(EXAMPLE_I2C_MASTER, LPI2C_MASTER_SLAVE_ADDR_7BIT, kLPI2C_Read); if (reVal != kStatus_Success) { return -1; } reVal = LPI2C_MasterReceive(EXAMPLE_I2C_MASTER, g_master_rxBuff, LPI2C_DATA_LENGTH); if (reVal != kStatus_Success) { if (reVal == kStatus_LPI2C_Nak) { LPI2C_MasterStop(EXAMPLE_I2C_MASTER); } return -1; } reVal = LPI2C_MasterStop(EXAMPLE_I2C_MASTER); if (reVal != kStatus_Success) { return -1; } } for (uint32_t i = 0U; i < LPI2C_DATA_LENGTH; i++) { if (i % 8 == 0) { } } temp = (((uint16_t) g_master_rxBuff[0] << 8U) | (uint16_t) g_master_rxBuff[1]) >> 4U; temperature = temp >> 4; PRINTF("Temperature=%d", temperature); PRINTF("Celsius"); while (1) { } }   6.5 PIN Configuratorを使ってピン設定を変更   P3T1755につながっているI3CをLPI2Cにつなぎ変えます。これは、プログラムコードを変更するのではなく、MCUXpresso Config Toolsの中のPin Configuratorというツールを使って行います。 まず、デフォルトで33ピンと34ピンがLPI2C0_SDAとLPI2C0_SCLに設定されているのを無効化します。Pinsタグで、下にスクロールして33ピンと34ピンを表示します。そして、右にスクロールしてLPI2C列を表示します。33ピンと34ピンのLPI2C列に表示されているLPI2C0_SDAとLPI2C0_SCLを、それぞれクリックすると、33ピンと34ピンが無効化されます。 次に、Pinsタグで、54ピンをLPI2C0_SDAに割り当てます。54ピンのチェックボックスをクリックすると、ピンに割り当てられている全機能が表示されます。その中からLPI2C0:SDAを選択します。すると、Pinsタグの54ピンが緑色に変わります。「Done」をクリックして割り当て完了です。 同じように、Pinsタグで、 55ピンをLPI2C0_SCLに割り当てます。55ピンのチェックボックスをクリックして、LPI2C0:SCLを選択します。すると、Pinsタグの55ピンが緑色に変わります。「Done」をクリックして割り当て完了です。 次に、54ピンと55ピンの機能設定を行います。機能設定には、下段にある「Routing Details for …」を使います。 Routing Details for …で、54ピン(LPI2C0_SDA)と55ピン( LPI2C0_SCL )のPull SelectをPullupに、Pull enableをEnabledに変更します。LabelをI2C_SDA とI2C_SCLにしておくと、board/pin_mux.h に定義を追加してくれます。 ピン設定は、これで完了です。 今までの変更内容をコードに反映させるには、Update Codeボタンをクリックします。 6.6 ビルド&デバッグ、動作確認 コードの変更が終わったら、ビルドします。 Projectsにカーソルを持っていくと、ビルドボタンが現れます。クリックするとビルドされます。 「build finished successfully.」のメッセージが出ればOKです。 ビルドボタンの隣に、デバッグボタンがあります。これをクリックすると、デバッグモードに入ります。 デバッグモードに入ると、プログラムはブレイクポイントで止まっているので、画面上部のアイコン内の「|▶」をクリックします。するとプログラムが走ります。 Tera Termの画面に、温度が表示されます。 まとめ 本記事では、I²Cの基本的な通信方式と、MCX A153に搭載されているLPI2Cモジュールの主な機能について説明しました。また、FRDM-MCXA153に搭載されたP3T1755温度センサーを例に、プルアップ抵抗の追加、Pin Configuratorによるピン設定、LPI2CのSDKサンプルコードの変更方法を確認しました。I²C通信では、スレーブアドレスやレジスタアドレス、データ長を接続するデバイスの仕様に合わせて設定することが重要です。本記事の内容を参考に、センサーやEEPROMなど、さまざまなI²Cデバイスとの通信に応用してください。 =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。)​ 本記事は、NXPマイコンMCX A153に搭載されているLPI2C(Low Power Inter-Integrated Circuit)コントローラを題材にします。I²Cの基本を確認した後、I²CとLPI2Cの違いについて説明し、MCX A153のLPI2Cの仕様・使い方を学びます。 (読了時間: 30分) MCUXpresso IDE MCUXpresso SDK MCX 日本語ブログ
View full article
RW61xシリーズトレーニング RW61xは 、MCUとWi-Fi ® 6 +Bluetooth ® Low Energy(LE) 5.4/802.15.4無線を内蔵した高度に統合された低電力3無線ワイヤレスMCUで、接続されたスマートホームデバイス、企業および産業オートメーション 、スマートアクセサリー、スマートエネルギーなど、幅広いアプリケーション向けに設計されています 。 RW612 MCUサブシステムには、Trustzone-M ™ を備えた260MHz Arm ® Cortex-M33 ® コア、1.2MBのオンチップSRAM、およびオフチップのXIPフラッシュに安全にアクセスするためのオンザフライ復号化エンジンを備えた高帯域幅Quad SPIインターフェイスが含まれています。 RW612には、フル機能の1x1デュアルバンド(2.4GHz/5GHz)、20メガヘルツのWi-Fi 6(802.11ax)が搭載されています前世代のWi-Fi標準よりも高いスループット、より良いネットワーク効率、より低い遅延、そしてより広い範囲をもたらすサブシステム。Bluetooth LEラジオは、2Mbit/sの高速データレート、長距離、拡張広告をサポートしています。内蔵の802.15.4無線は、最新のスレッド・メッシュ・ネットワーク・プロトコルをサポートできます。さらに、RW612はMatter over Wi-FiまたはMatter over Threadをサポートし、エコシステムや製品全体で共通の相互運用可能なアプリケーションレイヤーを提供します。 ハンズオントレーニング RW61xとFRDM-RW612の紹介 RW61xファミリー、モジュール製品、FRDM-RW612評価ボードの簡単な紹介 FRDM-RW612すぐに使えるエクスペリエンスWi-Fi CLI(コマンドラインインターフェイス)デモでは、FRDM RW612ボードのWi-Fi機能を調べるためのさまざまなコマンドを含むメニューをユーザーに提供します。ボードに初めて電源を入れると、緑色のRGB LEDが点滅して、 デモがボードにロードされたことを示します。 FRDM-RW612はじめに。VS Code の Wi-Fi CLI このラボでは、Visual Studio Code を使用して FRD-RW612 ボードの使用を開始する方法を順を追って説明します FRDM-RW612 ZEPHYR上のBLEセンサーこのデモは、ボードに統合されたi2c温度センサーからの温度を示しています。このデモは、Zephyr RTOS に基づいています。情報は、UART端末またはIoT Toolboxアプリで監視できます。 FRDM-RW612 低コストLCDを使用したキッチンタイマー このラボでは、 LCD-PAR-S035ディスプレイを使用してキッチンタイマーのグラフィカルアプリケーションを変更する方法を示します 日付とボタンの色を変更する。タイマーはシリアル端末でも表示できます。 コミュニティ・サポート このトレーニングやRW61xシリーズに関するご質問は、ワイヤレスMCUコミュニティにご意見をお寄せください ここは FRDM-RW612 FRDMトレーニング ハンズオン・トレーニング MCU ワイヤレス
View full article
RW61x系列培训 RW61x是一款高度集成、低功耗三频无线 MCU ,集成 MCU 和 Wi-Fi ®  6 + 蓝牙 ®  低能耗 (LE) 5.4 / 802.15.4 无线电专为广泛的应用而设计,包括连接的智能家居设备、企业和工业自动化、智能配件和智能能源。 RW612 MCU 子系统包括 260 MHz Arm ®  Cortex ® -M33 内核带有 Trustzone ™ -M、1.2 MB 片上 SRAM 和高带宽四路 SPI 接口,并带有即时解密引擎,可安全访问片外 XIP 闪存。 RW612 包括功能齐全的 1x1 双频(2.4 GHz/5 GHz)20 MHz Wi-Fi 6(802.11ax)与上一代 Wi-Fi 标准相比,子系统带来了更高的吞吐量、更好的网络效率、更低的延迟和更大的范围。蓝牙 LE 无线电支持 2 Mbit/s 高速数据速率、长距离和扩展广告。片上 802.15.4 无线电可以支持最新的 Thread 网状网络协议。此外,RW612 可以支持 Matter over Wi-Fi 或 Matter over Thread,从而提供跨生态系统和产品的通用、可互操作的应用层。 实践培训 RW61x 和 FRDM-RW612 简介RW61x 系列、模块产品和 FRDM-RW612 评估板的快速介绍 FRDM-RW612 开箱即用体验Wi-Fi CLI(命令行界面)演示为用户提供了包含不同命令的菜单,以探索 FRDM RW612 板的 Wi-Fi 功能。首次打开电路板时,绿色 RGB LED 应闪烁,表示演示已加载到 董事会。 FRDM-RW612 入门指南。VS Code 上的 Wi-Fi CLI本实验将逐步指导您如何使用 Visual Studio Code 开始使用 FRD-RW612 开发板 通过 Zephyr 的 FRDM-RW612 BLE 传感器此演示展示了来自集成在电路板上的 i2c 温度传感器的温度。该演示基于 Zephyr RTOS。可以在 UART 终端或 IoT Toolbox 应用程序中监控该信息。 FRDM-RW612 厨房定时器采用低成本 LCD该实验室展示如何使用LCD-PAR-S035 显示器修改厨房定时器图形应用程序,更改日期和按钮颜色。还可以在串行终端上查看计时器。 技术论坛支持 如果您对本次培训或 RW61x 系列有任何疑问,请在我们的无线 MCU 社区中留下您的评论! 这里 FRDM-RW612 FRDM 培训 动手实践培训 MCU 无线连接
View full article
RW61x Series Training   The RW61x is a highly integrated, low-power tri-radio wireless MCU with an integrated MCU and Wi-Fi ®  6 + Bluetooth ®  Low Energy (LE) 5.4 / 802.15.4 radios designed for a broad array of applications, including connected smart home devices, enterprise and industrial automation, smart accessories and smart energy. The RW612 MCU subsystem includes a 260 MHz Arm ®  Cortex ® -M33 core with Trustzone ™ -M, 1.2 MB on-chip SRAM and a high-bandwidth Quad SPI interface with an on-the-fly decryption engine for securely accessing off-chip XIP flash. The RW612 includes a full-featured 1x1 dual-band (2.4 GHz/5 GHz) 20 MHz Wi-Fi 6 (802.11ax) subsystem bringing higher throughput, better network efficiency, lower latency and improved range over previous generation Wi-Fi standards. The Bluetooth LE radio supports 2 Mbit/s high-speed data rate, long range and extended advertising. The on-chip 802.15.4 radio can support the latest Thread mesh networking protocol. In addition, the RW612 can support Matter over Wi-Fi or Matter over Thread offering a common, interoperable application layer across ecosystems and products. Hands-On Trainings Introduction to RW61x and FRDM-RW612 Quick introduction to RW61x family, module offering and FRDM-RW612 evaluation board FRDM-RW612 Out of the Box Experience Wi-Fi CLI (Command Line Interface) demo provides the user with a menu with different commands to explore the Wi-Fi capabilities of the FRDM RW612 board. When the board is powered on for the first time, the green RGB LED should be blinking indicating that the demo is loaded into the board. FRDM-RW612 Getting Started. Wi-Fi CLI on VS Code This lab guides you step by step on how to get started with FRD-RW612 board using Visual Studio Code  FRDM-RW612 BLE Sensors over Zephyr This demo shows the temperature from the i2c temperature sensor integrated in the board. This demo is based on Zephyr RTOS. The information can be monitored in the UART terminal or in the IoT Toolbox app. FRDM-RW612 Kitchen Timer using Low-cost LCD This lab shows how to modify a Kitchen Timer graphical application using LCD-PAR-S035 display Changing the date and button colors. The timer can also be viewed on a serial terminal.   Community Support If you have questions regarding this training or RW61x series, please leave your comments in our Wireless MCU Community! here  FRDM-RW612 FRDM-Training Hands-On Training MCU Wireless
View full article
RW610 / RW612 Knowledge Hub The RW61x series is a highly integrated, low-power tri-radio wireless MCU with an integrated MCU and Wi-Fi® 6 + Bluetooth® Low Energy (LE) 5.4 / 802.15.4 radios designed for a broad array of applications, including connected smart home devices, enterprise and industrial automation, smart accessories and smart energy. The RW61x series MCU subsystem includes a 260 MHz Arm® Cortex®-M33 core with Trustzone™-M, 1.2 MB on-chip SRAM and a high-bandwidth Quad SPI interface with an on-the-fly decryption engine for securely accessing off-chip XIP flash. The RW61x series includes a full-featured 1x1 dual-band (2.4 GHz/5 GHz) 20 MHz Wi-Fi 6 (802.11ax) subsystem bringing higher throughput, better network efficiency, lower latency and improved range over previous generation Wi-Fi standards. The Bluetooth LE radio supports 2 Mbit/s high-speed data rate, long range and extended advertising.  The on-chip 802.15.4 radio can support the latest Thread mesh networking protocol. In addition, the RW612 can support Matter over Wi-Fi or Matter over Thread offering a common, interoperable application layer across ecosystems and products. NXP RW61x Block DiagramNXP RW61x Block Diagram Documents RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61x User Manual: UM11865: RW61x User Manual RW61x Register Manual: RM00278: RX16x Registers   Certifications FRDM-RW612 Radio Equipment Directive Declaration of Conformity  User Guide Getting Started with FRDM-RW612 Quick Start Guide - FRDM-RW612 UG10185: RW612 Matter-Zigbee Bridge User Guide UG10178: Matter Demo Using NXP Chip Tool App for FRDM-RW612 and FRDM-MCXW71  UG10612: NXP Wi-Fi and Bluetooth Feature Debug for FRDM-RW612 UG10182: NXP 802.15.4 Demo Applications for FRDM-RW612 UG10160: Getting Started with Wireless on FRDM-RW612 Board Running RTOS  UG10171: NXP Wi-Fi and Bluetooth Demo Applications for FRDM-RW61X     RW61x Modules Azurewave: RW612 - AW-CU570 is a highly integrated, low-power tri-radio Wireless RW612 MCU with an integrated MCU and Wi-Fi 6 + Bluetooth Low Energy (LE) 5.2 / 802.15.4 radios designed for a broad array of applications. RW610 - AW-CU598 is a highly integrated, low-power tri-radio Wireless RW610 MCU with an integrated MCU and Wi-Fi 6 + Bluetooth Low Energy (LE) 5.3 radios designed for a broad array of applications U-blox: RW612 - IRIS-W10 Series are small, stand-alone, dual-band Wi-Fi and Bluetooth Low Energy wireless microcontroller unit (MCU) modules. The modules are ideal for users looking to add advanced wireless connectivity to their end products. RW610 - IRIS-W16 Series are small, stand-alone, dual-band Wi-Fi and Bluetooth Low Energy wireless modules, with everything needed for integration into end-products. The modules are ideal for users looking to add advanced wireless connectivity to their end products.  Murata: RW612 - LBES0ZZ2FR-580 Murata’s Type 2FR is a small and very high-performance module based on NXP RW612 combo chipset, supporting IEEE 802.11a/b/g/n/ac/ax + Bluetooth LE 5.4 / IEEE 802.15.4. RW610 - LBES0ZZ2FP-580 Type 2FR/2FP is a family of small and highly integrated multi-radio modules with built-in high-performance MCU with advanced security features for connected smart devices in smart homes, enterprise and industrial automation, smart accessories, and smart energy. It supports the latest Matter smart home connectivity protocol. California Eastern Laboratories (CEL): RW612 - CMP4612 is a fully integrated Dual-Band, Tri-mode (Wi-Fi 6, BT5.4, 802.15.4) radio, that includes a host MCU, Flash, RAM, peripherals, and numerous interfaces (SDIO, UART, USB, Ethernet. SPI, I2C) to support both HOSTLESS (RTOS) and HOSTED (NCP mode) architectures. CEL's solution includes either an on-board antenna or connector.   Evaluation boards  FRDM-RW612 FRDM-RW612 is a compact and scalable development board for rapid prototyping of the RW61x series of Wi-Fi 6 + Bluetooth Low Energy + 802.15.4 tri-radio wireless MCUs. It offers easy access to the MCU’s I/O's and peripherals, integrated open-standard serial interfaces, external flash memory and on-board MCU-Link debugger. FRDM-RW612 Getting Started Getting Started with FRDM-RW612 FRDM-RW612 User Manual: UM12160: FRDM-RW612 Board User Manual Current Measurement configuration: Remove the 0-ohms resistor R103 Solder a couple of pins in JP5. When trying to measure the RW61x current consumption, connect your current meter using the pins in JP5. When using the FRDM board in normal operation, connect a jumper to the pins in JP5.   u-blox   USB-IRIS-W1 The USB-IRIS-W1 development platform is built on the dual-band Wi-Fi 6 and Bluetooth LE module IRIS-W1, based on the NXP RW610/612 chip. The board is designed with a USB interface to simplify evaluation and prototyping directly from a PC. In addition to the IRIS-W1 module with integrated antenna, it also integrates four buttons, an RGB LED, and a USB/UART converter, to further support an easy evaluation. u-blox   EVK-IRIS-W1 The EVK-IRIS-W1 evaluation kit provides stand-alone use of the IRIS-W1 module series featuring the NXP RW610/612 chipset. Azurewave    AW-CU570-EVB Evaluation board for AW-CU570 module includes wireless MCU with Integrated Tri-radio Wi-Fi 6 + Bluetooth Low Energy 5.3 /802.15.4. Murata   2FR EVK Evaluation kit for Murata Type 2FR module (Murata part number LBES0ZZ2FR) includes 3 radios: Wi-Fi, BLE and 802.15.4. It is based on NXP’s RW612 chip. California Eastern Laboratories (CEL) CMP4612-2-EVB The CMP4612 Evaluation Board (CMP4612-2-EVB), based on the NXP RW612 chipset, features dual-band Wi-Fi 6, BLE 5.4 and 802.15.4 radios. The CMP4612 Evaluation Board includes an onboard Ethernet port and PHY hardware as well as an Arduino header, MCULink SWD, and USB ports. This board is designed to facilitate a seamless and efficient evaluation process for customers wanting a certified module for their end product.   Application Notes RM00287: Wi-Fi Driver API for SDK 2.16.100     The radio driver source code provides APIs to send and receive packets over the radio interfaces by communicating with the firmware images. This manual provides the reference documentation for the Wi-Fi driver and Wi-Fi Connection Manager.  UM12133: NXP NCP Application Guide for RW612 with MCU Host - User manual     This user manual describes: • The NXP NCP application for RW612 with MCU host platform i.MX RT1060 as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX RT1060) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT)    UM12095:  NXP NCP Application Guide for RW612 with MPU Host - User manual      This user manual describes: • The NXP NCP application for RW612 with MPU host platform i.MX 8M Mini as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX 8M Mini) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT).  AN14439: Migration Guide from FRDM-RW612 Board to Third-Party Module board This Application note provides an overview of what it means to migrate the application to a different board with different flash and pSRAM AN14111: Target Wake Time (TWT) on RW16x This application note describes the target wake time feature and provides examples for RW61X AN13006: Compliance and Certification Considerations This application note provides guidance and tips on how to test products on NXP Wi-Fi devices for regulatory compliance. AN13049: Wi-Fi/Bluetooth/802.15.4 M.2 Key E Pinout Definition This Application note defines M.2 usage for both NXP Wi-Fi/Bluetooth and Tri-Radio M.2 module design AN14489 – Wi-Fi Firmware Automatic Recovery on RW61x Describes Wi-Fi automatic recovery feature as well as how to enable and verify it on RW61x SDK. AN14464 - Low Power Checklist RW61x Family This document provides an overview on how to use the low power consumption features of the RW61x. AN13869 - RW61x Flashloader for Custom Flash Devices: This document provides guidance to program the application image and boot up RW61X from a third party FlexSPI NOR flash device.   AN14125 - Manufacturing Software Development Kit API Specification: This document explains the Labtool Software Development Kit (SDK) used to automate manufacturing test programs.   AN14002 - RW61x Design Guide: Provides design guidelines for RW61x RF: AN14476 - NXP Dual PAN Feature and Performance ResultsThis document provides a comprehensive exploration of the Dual Personal Area Network (Dual-PAN) feature on NXP Wireless Connectivity products implementing IEEE 802.15.4 low-rate wireless protocol area network standard. AN13639 - Calibration Structure for RW61X: This document describes the RF calibration parameters and data structure used to store calibration/configuration data for RW61x. The document explains how to adjust the RF calibration parameters to attain tighter tolerances. AN14282 - RF Test Mode on FreeRTOS:  This document provides an overview of how to enable and use the Radio Frequency (RF) test mode on a Real-time Operating System (RTOS)-based host. Using the RF test mode feature, users can easily set RF parameters, such as the operating channel, TX power, and channel bandwidth for regulatory compliance testing. AN14001 - RW61x TCP Throughput Optimization: This document explains how to optimize TCP throughput for RW61X with MCUXpresso SDK and analyze the test results after tuning with different parameter combinations. AN14463 - Antenna Diversity: This application note describes the antenna diversity feature capabilities of NXP wireless SoCs. Implementation of antenna diversity requires appropriate external hardware (Single Dipole Pole Throw (SPDT) or Double Dipole Pole Throw (DPDT) switches) in the customer design.  AN14714 - Wi-Fi Firmware Download Modes for FreeRTOS:  This document introduces the firmware download process and configuration for these two modes. AN14281 - Channel State Information (CSI) on FreeRTOS: This document explains how to get the CSI records from the Wi-Fi packets in STA mode AN13681 - Wi-Fi Alliance Derivative Certification Process for RW61x: The document presents the Wi-Fi Alliance derivative certification process. AN14466 - Antenna Auto Detection: Describes the antenna auto detection feature AN14121 - Coexistence Overview for RW61X:  Provides an overview of coexistence between Wi-Fi and Bluetooth LE or 802.15.4 radios. Security: AN14544 – EdgeLock 2GO Services for MPU and MCU This application note introduces various methods that the EdgeLock 2GO service can be used with MCU and MPU devices and the features available for each method. AN13813 – Secure Boot on RW61x Describes how to generate and run the secure boot (signed image) on RW61x. AN13814 – Debug Authentication on RW61x Describes the steps for debug authentication using the secure provisioning SDK tool. AN14705  - Using EdgeLock 2GO for Matter Provisioning on RW612 Devices: This document explains how to use the NXP EdgeLock 2GO service to provision an RW612 device for Matter. AN15038 - EdgeLock 2Go Provisioning MCUs via Product Type using Secure Provisioning (SEC) Tool: This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via product type" flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server. AN14670 - EdgeLock 2GO Provisioning via SPSDK for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the “Device provisioning via proxy” flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server.  AN14624 EdgeLock 2GO Provisioning via Secure Provisioning Tool (SEC) for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via proxy" flow. Import Wrapped Blob using ELS Cryptolib - Uses ELS Cryptolib to import a blob from OTP that was wrapped using HSM_STORE_KEY trust provisioning command.  Import Wrapped Blob using PSA APIs - Uses PSA API to import a blob from OTP that was wrapped using HSM_STORE_KEY trust provisioning command. Training RW61x Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the wireless equipment to help you accelerate your project development Development Tools  SDK builder The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. NXP MCUXpresso MCUXpresso IDE offers advanced editing, compiling and debugging features with the addition of MCU-Specific debugging and supports connections with all general-purpose Arm Cortex-M.  VSCode MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. Zephyr RTOS  The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications. NXP Application Code Hub Application Code Hub (ACH) repository enables engineers to easily find microcontroller software examples, code snippets, application software packs and demos developed by our in-house experts. This space provides a quick, easy and consistent way to find microcontroller applications. NXP SPSDK Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool Is an application that helps the user to perform an over the air firmware update of an NXP development board. SDK Examples for Wireless MCUs The wireless examples feature many common connectivity configurations.   Useful Links Connecting LCD_PAR_S035 to the U-blox IRIS-W1-EVK: This article describes how to connect the LCD_PAR_S035 display to the U-blox IRIS-W1 EVK using the 8080 8-bit parallel interface, including the required GPIO mapping and hardware modifications. It also explains the display configuration and software setup needed to run LVGL-based graphical applications on the platform Bluetooth Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   FRDM-RW612
View full article
RW610 / RW612 ナレッジハブ RW61xシリーズは、MCUとWi-Fi ® 6 + Bluetooth ® Low Energy (LE) 5.4 / 802.15.4無線を内蔵した高集積、低消費電力のトライラジオ・ワイヤレスMCUで、コネクテッド・スマートホーム・デバイス、エンタープライズおよび産業オートメーション、スマート・アクセサリ、スマート・エネルギーなどの幅広いアプリケーションに対応しています。 RW61xシリーズMCUサブシステムには、260MHz Arm ®  Cortex ® -M33コア(TrustZone ™ -M搭載)、1.2MBのオンチップSRAM、およびオフチップXIPフラッシュへの安全なアクセスを可能にするオンザフライ復号化エンジンを搭載した高帯域幅クアッドSPIインターフェースを備えています。 RW61xシリーズには、フル機能の1x1デュアルバンド(2.4GHz/5GHz)20MHz Wi-Fi 6(802.11ax)サブシステムを搭載しており、前世代のWi-Fi標準を上回る高スループット、優れたネットワーク効率、低レイテンシ、広い通信範囲を実現します。Bluetooth LE無線機能によって、2Mbit/sの高速データ・レート、長距離通信、拡張アドバタイズをサポートします。オンチップの802.15.4無線は、最新のThreadメッシュ・ネットワーキング・プロトコルをサポートできます。さらに、RW612はMatter over Wi-FiまたはMatter over Threadをサポートでき、エコシステムや製品の違いを超えた共通の相互運用可能なアプリケーション・レイヤを提供します。 NXP RW61x Block DiagramNXP RW61xブロック図 書類 RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61xユーザーマニュアル:UM11865:RW61xユーザーマニュアル RW61xレジスタマニュアル:RM00278:RX16xレジスタ   RW61xモジュール AzureWave: RW612 - AW-CU570は、高集積、低消費電力のトライラジオ・ワイヤレスRW612 MCUで、MCUとWi-Fi 6 + Bluetooth Low Energy (LE) 5.2 / 802.15.4無線を内蔵し、幅広いアプリケーションに対応するように設計されています。 RW610 - AW-CU598 は、MCUとWi-Fi 6 + Bluetooth Low Energy (LE) 5.3無線を統合した高集積、低消費電力のトリプル無線RW610 MCUで、多様なアプリケーション向けに設計されています。 U-blox: RW612 - IRIS-W10シリーズは、小型でスタンドアロンのデュアルバンドWi-FiおよびBluetooth Low Energyワイヤレス・マイクロコントローラ・ユニット(MCU)モジュールです。これらのモジュールは、最終製品に高度なワイヤレス接続機能を追加したいユーザーに最適です。 RW610 - IRIS-W16シリーズは、小型で独立したデュアルバンドWi-FiおよびBluetooth Low Energy無線モジュールで、最終製品への組み込みに必要なすべてを備えています。これらのモジュールは、最終製品に高度な無線接続を追加したいユーザーに最適です。 Murata: RW612 - LBES0ZZ2FR-580 村田製作所のType 2FRは、NXP RW612コンボ・チップセットを基にした小型で非常に高性能なモジュールです。IEEE 802.11a/b/g/n/ac/ax + Bluetooth LE 5.4 / IEEE 802.15.4をサポートしています。 RW610 - LBES0ZZ2FP-580 Type 2FR/2FPは、スマートホーム、エンタープライズおよび産業オートメーション、スマート・アクセサリー、スマート・エネルギー向けの接続型スマート・デバイス向けに設計された、小型で高度に統合されたマルチ無線モジュール・ファミリーです。高性能MCUを内蔵し、高度なセキュリティ機能を備えています。最新のMatterスマートホーム接続プロトコルに対応しています。 California Eastern Laboratories (CEL): RW612 - CMP4612は、デュアルバンド、トライモード(Wi-Fi 6、BT5.4、802.15.4)に対応した完全統合型無線モジュールで、ホストMCU、フラッシュ、RAM、周辺機器、および多数のインターフェース(SDIO、UART、USB、Ethernet、SPI、I2C)を備えています。ホストレス(RTOS)とホスト(NCPモード)の両方のアーキテクチャをサポートします。CELのソリューションには、オンボードのアンテナまたはコネクタが含まれています。 評価ボード  FRDM-RW612 FRDM-RW612は、Wi-Fi 6 + Bluetooth Low Energy + 802.15.4に対応するトライラジオ・ワイヤレスMCUであるRW61xシリーズのラピッド・プロトタイピングを目的とした、小型で拡張性に優れた開発ボードです。 このMCUのI/Oおよびペリフェラルに容易にアクセスできるほか、オープン・スタンダードの統合シリアル・インターフェース、外部フラッシュ・メモリ、オンボードMCU-Linkデバッガを備えています。 FRDM-RW612入門:FRDM-RW612入門ガイド FRDM-RW612ユーザー・マニュアル:UM12160: FRDM-RW612ボード・ユーザー・マニュアル FRDM-RW612クイック・スタート・ガイド:FRDM-RW612クイック・スタート・ガイド 電流測定構成: 0オームの抵抗器R103を取り外します。 JP5に2本のピンをはんだ付けします。 RW61xの消費電流を測定する場合は、JP5のピンを使用して電流メーターを接続します。FRDMボードを通常の操作で使用する場合は、ジャンパーをJP5のピンに接続します。 u-blox   USB-IRIS-W1 USB-IRIS-W1 開発プラットフォームは、NXP RW610/612 チップを基にしたデュアルバンド Wi-Fi 6 および Bluetooth LE モジュール IRIS-W1 上に構築されています。 このボードはUSBインターフェースを備えており、PCから直接評価やプロトタイピングを簡単に行うことができます。アンテナを内蔵したIRIS-W1モジュールに加え、4つのボタン、RGB LED、USB/UARTコンバータも統合されており、評価がさらに容易になります。 u-blox   EVK-IRIS-W1 EVK-IRIS-W1評価キットは、NXP RW610/612チップセットを搭載したIRIS-W1モジュール・シリーズを単独で使用することを可能にします。 Azurewave AW-CU570-EVB AW-CU570モジュールの評価ボードには、統合型トライラジオWi-Fi 6 + Bluetooth Low Energy 5.3 / 802.15.4を搭載したワイヤレスMCUが含まれています。 Murata   2FR EVK Murata Type 2FRモジュール(Murata部品番号:LBES0ZZ2FR)の評価キットには、Wi-Fi、BLE、および802.15.4の3つの無線が含まれています。NXPのRW612チップをベースにしています。 カリフォルニア・イースタン・ラボラトリーズ(CEL)CMP4612-2-EVB NXP RW612 チップセットを基にした CMP4612 評価ボード(CMP4612-2-EVB)は、デュアルバンド Wi-Fi 6、BLE 5.4、および 802.15.4 ラジオを備えています。CMP4612 評価ボードには、オンボードのイーサネットポートとPHYハードウェア、Arduinoヘッダー、MCULink SWD、USBポートが含まれています。このボードは、最終製品の認定モジュールを希望するお客様に対して、シームレスで効率的な評価プロセスを提供するために設計されています。 アプリケーション・ノート RM00287:SDK 2.16.100用Wi-FiドライバーAPI   この無線ドライバのソースコードは、ファームウェアイメージと通信することにより、無線インターフェイスを介してパケットを送受信するためのAPIを提供します。このマニュアルには、Wi-FiドライバーとWi-Fi接続マネージャーのリファレンス・ドキュメントが記載されています。 UM12133:NXP NCPアプリケーション・ガイド for RW612 with MCUホスト - ユーザー・マニュアル       このユーザーマニュアルでは、以下の内容について説明しています。 • NXP NCPアプリケーション for RW612 with MCUホスト・プラットフォーム i.MX RT1060を例として説明しています。 • NXP RW612 BGA V4ボードでNCPモードを有効にするための、サポートされている4つのインターフェース(UART、USB、SDIO、またはSPI)のうち1つのハードウェア接続。 • NCPホスト(i.MX RT1060)およびNCPデバイス(RW612)の両方でNCPアプリケーションをビルドして実行する方法。 アプリケーションは、Wi-Fi、Bluetooth Low Energy、OpenThread(OT)に適用されます。 UM12095:NXP NCPアプリケーション・ガイド(RW612用MPUホスト) - ユーザー・マニュアル このユーザーマニュアルでは次のことを説明しています。 • MPUホスト・プラットフォームi.MX 8M Miniを例にしたRW612用NXP NCPアプリケーション。 • NXP RW612 BGA V4ボードでNCPモードを有効にするための、サポートされている4つのインターフェース(UART、USB、SDIO、またはSPI)のうち1つのハードウェア接続。 • NCPホスト(i.MX 8M Mini)とNCPデバイス(RW612)の両方でNCPアプリケーションをビルドして実行する方法。アプリケーションはWi-Fi、Bluetooth Low Energy、OpenThread(OT)に適用されます。 AN14439:FRDM-RW612ボードからサードパーティ製モジュール・ボードへの移行ガイド このアプリケーション/ノートは、異なるフラッシュとpSRAMを持つ別のボードへのアプリケーション移行の概要を提供します。 AN14111:RW16xのターゲットウェイクタイム(TWT) このアプリケーション・ノートでは、ターゲット・ウェイク・タイム機能について説明し、RW61Xの例を示します。 AN13006:準拠および認証に関する考慮事項 このアプリケーション・ノートでは、NXPのWi-Fiデバイスで製品の規制準拠をテストする方法に関するガイダンスとヒントを提供します。 AN13049:Wi-Fi/Bluetooth/802.15.4 M.2キー Eピン配置定義 このアプリケーション・ノートは、NXPのWi-Fi/BluetoothおよびTri-Radio M.2モジュール設計におけるM.2の使用法を定義しています。 AN14489:RW61xにおけるWi-Fiファームウェアの自動回復 Wi-Fiの自動回復機能およびRW61x SDKでの有効化と確認方法について説明します。 セキュリティ: AN14544:MPUおよびMCU向けEdgeLock 2GOサービス このアプリケーション・ノートでは、MCUおよびMPUデバイスでEdgeLock 2GOサービスを使用するためのさまざまな方法と、各方法で利用可能な機能を紹介します。 AN13813:RW61xにおけるセキュアなブート RW61xにおけるセキュアなブート(署名済みイメージ)を生成して実行する方法について説明します。 AN13814:RW61xでのデバッグ認証 セキュア・プロビジョニングSDKツールを使用してデバッグ認証を行う手順について説明します。 コミュニティ・サポート RW61xシリーズに関するご質問は、こちらからワイヤレスMCUコミュニティにご意見をお寄せください。   トレーニング FRDM-RW612 セキュアな i.MX RT MCU での Wi-Fi 6 トライラジオのトレーニング RW61xシリーズトレーニング - NXPコミュニティ 機器 無線機器: 本記事では、プロジェクト開発を加速するために役立つ無線機器へのリンクを提供します。 開発ツール SDKビルダー MCUXpresso SDKは、オープンソースのドライバ、ミドルウェア、リファレンス例のアプリケーションを提供し、ソフトウェア開発を加速します。 NXP MCUXpresso MCUXpresso IDEは、高度な編集、コンパイル、デバッグ機能を提供し、MCU固有のデバッグを追加し、すべての汎用Arm Cortex-Mとの接続をサポートします。 VSCode MCUXpresso for Visual Studio Code(VS Code)は、コードの編集と開発向けに最適化された組込み開発者エクスペリエンスを提供します。 Zephyr RTOS  Zephyr OSは、リソース制約のある組み込みシステム向けに設計された小型カーネルを基盤としています。シンプルな組み込み環境センサーやLEDウェアラブルから、高度な組み込みコントローラー、スマートウォッチ、IoTワイヤレス・アプリケーションまで、幅広い用途に対応しています。 NXPアプリケーション・コード・ハブ アプリケーション・コード・ハブ(ACH)リポジトリにより、エンジニアは社内の専門家によって開発されたマイクロコントローラ・ソフトウェアの例、コード・スニペット、アプリケーション・ソフトウェア・パック、デモを簡単に見つけることができます。このスペースは、マイクロコントローラ・アプリケーションを迅速かつ簡単、そして一貫して見つけるための方法を提供します。 NXP SPSDKは、NXP MCUポートフォリオ全体で動作する信頼性が高くて使いやすいPython SDK統合ライブラリです。お客様の迅速なプロトタイピングから生産の展開までをサポートする強力な基盤を提供します。 NXP SECツール MCUXpressoセキュア・プロビジョニング・ツールは、NCP MCUデバイスでブート可能な実行ファイルを簡単に生成およびプロビジョニングできる、GUIベースのアプリケーションです。 NXP OTAP Toolは、ユーザーがNXP開発ボードの無線ファームウェア・アップデートを実行するのに役立つアプリケーションです。 ワイヤレスMCUのSDK例 ワイヤレスの例には、多くの一般的な接続構成が含まれています。 便利なリンク Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   FRDMトレーニング ハンズオン・トレーニング 製品: WiFi RW6XX プロトコル:802.15.4 プロトコル:BLE→コネクティビティ プロトコル:Bluetooth プロトコル:Matter プロトコル:Thread プロトコル:Wi-Fi プロトコル:Zigbee
View full article
RW610 / RW612 知识中心 RW61x 系列是一款高度集成的低功耗三射频无线 MCU,集成了 MCU 以及 Wi-Fi ® 6 + Bluetooth ® 低功耗 (LE) 5.4 / 802.15.4 射频,适用于广泛的应用场景,包括联网智能家居设备、企业和工业自动化、智能配件以及智能能源领域。 RW61x 系列 MCU 子系统包含一个 260 MHz 的 Arm ® Cortex ® -M33 内核(带 Trustzone ™ -M)、1.2 MB 片上 SRAM,以及一个高带宽 Quad SPI 接口(配备实时解密引擎,用于安全访问片外 XIP 闪存)。 RW61x 系列配备全功能的 1x1 双频段(2.4 GHz/5 GHz)20 MHz Wi-Fi 6(802.11ax)子系统,与前一代 Wi-Fi 标准相比,能提供更高的吞吐量、更好的网络效率、更低的延迟和更远的覆盖范围。蓝牙 LE 射频支持 2 Mbit/s 高速数据传输率、远距离传输和扩展广播功能。片上 802.15.4 射频可支持最新的 Thread mesh 网络协议。此外,RW612 还支持 Wi-Fi 上的 Matter 协议或 Thread 上的 Matter 协议,能在不同生态系统和产品间提供通用、可互操作的应用层。 NXP RW61x Block DiagramNXP RW61x 框图 文件 RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61x 用户手册:UM11865:RW61x 用户手册 RW61x 寄存器手册:RM00278:RX16x 寄存器   RW61x 模块 Azurewave: RW612 - AW-CU570:一款高度集成的低功耗三射频无线 RW612 MCU,集成了 MCU 以及 Wi-Fi 6 + 蓝牙低功耗 (LE) 5.2 / 802.15.4 射频,适用于广泛的应用场景。 RW610 - AW-CU598:一款高度集成的低功耗三射频无线 RW610 MCU,集成了 MCU 以及 Wi-Fi 6 + 蓝牙低功耗 (LE) 5.3 射频,适用于广泛的应用场景。 U-blox: RW612 - IRIS-W10 系列:小型独立式双频段 Wi-Fi 和蓝牙低功耗无线微控制器单元 (MCU) 模块。这些模块非常适合希望在其终端产品中添加高级无线连接功能的用户。 RW610 - IRIS-W16 系列:小型独立式双频段 Wi-Fi 和蓝牙低功耗无线模块,包含集成到终端产品所需的所有组件。这些模块非常适合希望在其终端产品中添加高级无线连接功能的用户。 Murata: RW612 - LBES0ZZ2FR-580:Murata 的 Type 2FR 是基于 NXP RW612 组合芯片组的小型且高性能模块,支持 IEEE 802.11a/b/g/n/ac/ax + 蓝牙 LE 5.4 / IEEE 802.15.4。 RW610 - LBES0ZZ2FP-580:Type 2FR/2FP 是一系列小型且高度集成的多射频模块,内置高性能 MCU(带高级安全功能),适用于智能家居、企业和工业自动化、智能配件及智能能源领域的联网智能设备。它支持最新的 Matter 智能家居连接协议。 California Eastern Laboratories (CEL): RW612 - CMP4612:一款全集成双频段、三模式(Wi-Fi 6、BT5.4、802.15.4)射频,包含主机 MCU、闪存、RAM、外设和众多接口(SDIO、UART、USB、以太网、SPI、I2C),支持无主机(RTOS)和有主机(NCP 模式)架构。CEL 的解决方案包含板载天线或连接器。 评估板  FRDM-RW612 FRDM-RW612 是一款紧凑且可扩展的开发板,用于 RW61x 系列 Wi-Fi 6 + 蓝牙低功耗 + 802.15.4 三射频无线 MCU 的快速原型开发。 它提供了便捷的 MCU I/O 和外设访问方式、集成的开放标准串行接口、外部闪存和板载 MCU-Link 调试器。 RDM-RW612 入门指南:FRDM-RW612 入门 FRDM-RW612 用户手册:UM12160:FRDM-RW612 板用户手册 FRDM-RW612 快速入门指南:FRDM-RW612 快速入门指南 电流测量配置: 移除0欧姆电阻R103 在JP5上焊接几个引脚。 若要测量 RW61x 的电流消耗,使用 JP5 上的引脚连接电流计。正常操作 FRDM 板时,用跳线连接 JP5 上的引脚。 u-blox   USB-IRIS-W1 USB-IRIS-W1 开发平台基于双频段 Wi-Fi 6 和蓝牙 LE 模块 IRIS-W1(基于 NXP RW610/612 芯片)构建。 开发板设计有 USB 接口,方便直接通过 PC 进行评估和原型开发。除了带集成天线的 IRIS-W1 模块外,它还集成了四个按钮、一个 RGB LED 和一个 USB/UART 转换器,进一步为便捷评估提供支持。 u-blox   EVK-IRIS-W1 EVK-IRIS-W1 评估套件提供 IRIS-W1 模块系列的独立使用,采用 NXP RW610/612 芯片组。 Azurewave    AW-CU570-EVB AW-CU570 模块的评估板包含集成三射频(Wi-Fi 6 + 蓝牙低功耗 5.3 / 802.15.4)的无线 MCU。 Murata   2FR EVK Murata Type 2FR 模块(Murata 部件号 LBES0ZZ2FR)的评估套件包含三种射频:Wi-Fi、BLE 和 802.15.4。它基于 NXP 的 RW612 芯片。 California Eastern Laboratories (CEL) CMP4612-2-EVB CMP4612 评估板 (CMP4612-2-EVB) 基于NXP RW612 芯片组,具有双频段 Wi-Fi 6、BLE 5.4 和 802.15.4 射频。该评估板包含板载以太网端口和 PHY 硬件,以及 Arduino 接口、MCULink SWD 和 USB 端口。对于希望为其终端产品使用经过认证的模块的客户,该开发板能促进无缝高效的评估过程。 应用笔记 RM00287:SDK 2.16.100 的 Wi-Fi 驱动 API:射频驱动源代码提供了通过与固件镜像通信在射频接口上发送和接收数据包的 API。本手册提供了 Wi-Fi 驱动和 Wi-Fi 连接管理器的参考文档。 UM12133:带 MCU 主机的 RW612 的 NXP NCP 应用指南 - 用户手册:本用户手册介绍: • 以 i.MX RT1060 为 MCU 主机平台的 RW612 的 NXP NCP 应用。 • 在 NXP RW612 BGA V4 板上启用 NCP 模式的四种支持 接口(UART、USB、SDIO 或 SPI)之一的硬件连接。 • 在 NCP 主机 (i.MX RT1060) 和 NCP 设备 (RW612) 上构建和运行 NCP 应用的方法。 这些应用适用于 Wi-Fi、蓝牙低功耗和 OpenThread (OT)。 UM12095:带 MPU 主机的 RW612 的 NXP NCP 应用指南 - 用户手册:本用户手册介绍: • 以 i.MX 8M Mini 为 MPU 主机平台的 RW612 的 NXP NCP 应用。 • 在 NXP RW612 BGA V4 板上启用 NCP 模式的四种支持 接口(UART、USB、SDIO 或 SPI)之一的硬件连接。 • 在 NCP 主机 (i.MX 8M Mini) 和 NCP 设备 (RW612) 上构建和运行 NCP 应用的方法。 这些应用适用于 Wi-Fi、蓝牙低功耗和 OpenThread (OT)。 AN14439:从 FRDM-RW612 板迁移到第三方模块板的指南:本应用笔记概述了将应用迁移到具有不同闪存和 pSRAM 的不同板子的相关内容。 AN14111:RW16x 上的目标唤醒时间 (TWT):本应用笔记介绍了目标唤醒时间功能,并提供了 RW61X 的相关示例。 AN13006:合规性和认证注意事项:本应用笔记提供了关于如何在 NXP Wi-Fi 设备上测试产品以确保符合法规的指导和提示。 AN13049:Wi-Fi / 蓝牙 / 802.15.4 M.2 Key E 引脚定义:本应用笔记定义了 M.2 在 NXP Wi-Fi / 蓝牙和三射频 M.2 模块设计中的使用方式。 AN14489 – RW61x 上的 Wi-Fi 固件自动恢复:介绍了 Wi-Fi 自动恢复功能,以及如何在 RW61x SDK 中启用和验证该功能。 安全性: AN14544 – 用于 MPU 和 MCU 的 EdgeLock 2GO 服务:本应用笔记介绍了 EdgeLock 2GO 服务可用于 MCU 和 MPU 设备的各种方法,以及每种方法可用的功能。 AN13813 – RW61x 上的安全启动:介绍了如何在 RW61x 上生成和运行安全启动(签名镜像)。 AN13814 – RW61x 上的调试认证:介绍了使用安全配置 SDK 工具进行调试认证的步骤。 技术论坛支持 如果你对 RW61x 系列有任何疑问,请在我们的无线 MCU 社区中留下你的评论!此处   培训 FRDM-RW612 培训:安全 i.MX RT MCU 中的 Wi-Fi 6 三射频 RW61x 系列培训 - NXP 社区 设备 无线设备:本文提供了无线设备的链接,以帮助你加快项目开发。 开发工具 SDK 构建器:MCUXpresso SDK 提供开源驱动程序、中间件和参考示例应用,以加快你的软件开发。 NXP MCUXpresso:MCUXpresso IDE 提供高级编辑、编译和调试功能,外加 MCU 特定调试功能,并支持与所有通用 Arm Cortex-M 的连接。 VSCode MCUXpresso:适用于 Visual Studio Code (VS Code) 的 MCUXpresso 为代码编辑和开发提供优化的嵌入式开发体验。 Zephyr RTOS:Zephyr 操作系统基于小尺寸内核设计,适用于资源受限的嵌入式系统:从简单的嵌入式环境传感器和 LED 可穿戴设备,到复杂的嵌入式控制器、智能手表和物联网无线应用。 NXP Application Code Hub:应用代码中心 (ACH) 存储库使工程师能够轻松找到由我们内部专家开发的微控制器软件示例、代码片段、应用软件包和演示。该平台提供了一种快速、简便且一致的方式来查找微控制器应用。 NXP SPSDK:一个统一、可靠且易于使用的 Python SDK 库,适用于整个 NXP MCU 产品组合,为从快速客户原型设计到生产部署提供坚实基础。 NXP SEC Tool:MCUXpresso 安全配置工具是一个基于 GUI 的应用程序,旨在简化 NCP MCU 设备上可引导可执行文件的生成和配置。 NXP OTAP Tool:一款帮助用户对 NXP 开发板执行空中固件更新的应用程序。 用于无线 MCU 的 SDK 示例:无线示例包含许多常见的连接配置。 有用链接 蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   FRDM 培训 动手实践培训 产品:WiFi RW6XX 协议:802.15.4 协议:BLE -> 连接性 协议:蓝牙 协议:Matter 协议:Thread 协议:Wi-Fi 协议:Zigbee
View full article
Getting Started: MCP Server for Documentation Disclaimer: This product is currently offered as a preview and is available only to selected customers. Introduction Large language models are great at explaining concepts, but they do not always know the exact register offset, the latest bit-field definition or a device-specific detail from an NXP reference manual. When the answer has to be correct, the model should not be guessing.   MCP Server for Documentation solves this by bringing NXP product documentation directly into your agentic development workflow. Instead of relying only on what the model already knows – or asking you to search through hundreds of pages of a hardware manual yourself – your AI agent can discover the right product, search the documentation and read the underlying source content, all without leaving your development environment.   This article explains what MCP Server for Documentation is, what you can use it for, which documentation it covers, and how to get started in a few simple steps. What is MCP Server for Documentation?   MCP Server for Documentation is a remote MCP (Model Context Protocol) service that gives an MCP-compatible AI client access to structured NXP product documentation.   With MCP Server for Documentation, your agent can:   Discover the products and documents that are available to you Search the documentation for the hardware information it needs Retrieve the underlying source content before it produces an answer   The key idea is simple: instead of searching blindly through PDFs, the agent navigates a structured knowledge graph – chapters, sections, registers and fields – and retrieves exactly the context that is relevant to your question.   The flow of MCP Server for DocumentationThe flow of MCP Server for Documentation Why use MCP Server for Documentation? Ground your AI Give your agent relevant NXP product information instead of relying only on what the model already knows. This reduces guessing and helps avoid hallucinated register values or configuration steps.   Find details faster Ask about registers, bit fields, peripherals, configuration sequences and other hardware topics, and let the agent locate the answer for you.   Improve code generation Retrieve product-specific documentation context before asking the agent to explain hardware behaviour or generate an implementation.   Reduce manual searching Let the agent search and retrieve the relevant information while you stay inside your development environment. What can I use it for?   MCP Server for Documentation already supports a range of everyday hardware development workflows.   Find precise hardware information Ask about a known register, field, peripheral, acronym or hardware concept. Example: "Using ChipDocs MCP, find the S32K3xx eDMA TCD NBYTES register and explain the SMLOE and DMLOE fields."   Ask how-to questions Use MCP Server for Documentation when the answer requires multiple sections or a sequence of configuration steps. Example: "Using ChipDocs MCP, explain how to configure FlexCAN0 on MCX N947 for CAN FD with bit rate switching, and which CTRL1 fields set the nominal bit timing."   Generate documentation-grounded code Give your agent relevant product context before asking it to generate an implementation. Example: "Using ChipDocs MCP, generate a simple initialization function called LPI2C_init that configures LPI2C1 as a controller at 400 kHz on i.MX RT1180."   Work with document attachments Where available, MCP Server for Documentation can expose supporting PDFs, spreadsheets and other document assets. Example: "Using ChipDocs MCP, retrieve the S32N55 DMA channel mapping spreadsheet and list the request sources for eDMA channels 0 through 7."   Example of a grounded answer in an AI clientExample of a grounded answer in an AI client Documentation coverage   MCP Server for Documentation provides access to reference manuals and data sheets for recent NXP MCU and MPU products, with additional documentation being added through regular releases.   Publicly available product families currently include:   S32 Automotive – S32E2, S32G2, S32G3, S32K3, S32N5, S32Z2 MCX family – MCXA, MCXC, MCXE, MCXN, MCXW i.MX family – i.MX 91, i.MX 93, i.MX 95 i.MX RT family – i.MX RT700, i.MX RT1180 KW family – KW45, KW47   Additional products and documentation may be available based on the user's access permissions. Document visibility varies by product and user authorization, and the available documentation is continuously expanded   Getting started   MCP Server for Documentation is a remote MCP service. There is no local MCP server or SDK to install – you simply connect your AI client to the service. Prerequisites   An MCP-compatible AI client that supports the current MCP protocol and OAuth authentication Connectivity to the MCP Server for Documentation service An NXP account with access to the documentation you want to use   MCP Server for Documentation has been tested with GitHub Copilot, Claude Code and Kiro. Other clients that implement the current MCP protocol and OAuth authentication are expected to be compatible.   Step 1 – Add MCP Server for Documentation to your AI client MCP Server for Documentation is reachable at a single HTTP endpoint: MCP endpoint https://mcp.gw.ext.nxp.com/mcp   Add the server through your client's interface, or directly in your MCP configuration file. For GitHub Copilot in VS Code, open the Command Palette, choose "MCP: Add Server...", select HTTP, and paste the endpoint above. Give the server a name (for example, chipdocs) and choose whether it should apply to all projects or only the current one.   If you prefer to edit the configuration file yourself, the entry looks like this: .vscode/mcp.json { "servers": { "chipdocs": { "url": "https://mcp.gw.ext.nxp.com/mcp", "type": "http" } } }   Adding the MCP Server for Documentation in VS CodeAdding the MCP Server for Documentation in VS Code Step 2 – Authenticate MCP Server for Documentation uses OAuth authentication. Start or activate the MCP Server for Documentation in your client and complete the sign-in flow with your NXP account when authorization is requested.   Step 3 – Verify your connection Confirm that the MCP Server for Documentation tools are available and that the server responds. Try: "Using the ChipDocs MCP, show me which chips are currently available to me."   Step 4 – Check what documentation you have access to Try: "Using the ChipDocs MCP, what manuals are available for the chip I am working with?" If your agent has no project open to infer the device from, name it in the prompt instead – for example, "… what manuals are available for S32K3?" The reply lists the document types and versions your account can read for that product. That single answer confirms all three things at once: the server responds, your sign-in was accepted, and your account is authorized for the documentation.   Step 5 – Run your first grounded hardware query Now ask something a model cannot answer reliably from memory. Try: "Using the ChipDocs MCP, find the LPSPI version ID register on S32K3 and give me the exact offset and bit fields." The answer should use retrieved NXP documentation and provide the requested hardware details instead of guessing device-specific values.     Result of the first grounded hardware queryResult of the first grounded hardware query Watch: Get started with MCP Server for Documentation   The short video below walks through the whole flow – from adding the server and authenticating, to verifying the connection and running your first grounded query.   (function() { var wrapper = document.getElementById('lia-vid-6405633198112w960h540r370'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) Tips for better results   For the best results, include three things in your prompt whenever possible:   Product – the NXP device you are working with (for example, s32k3xx) Topic – the register, peripheral or concept you are asking about Desired result – what you want back (an explanation, an offset, a code snippet)   Example: "Using ChipDocs MCP, for S32K3 find the LPSPI version ID register and give me the exact offset and bit fields."   Explicitly mentioning "Using ChipDocs MCP" makes it clear that the agent should retrieve information from MCP Server for Documentation instead of answering only from existing model knowledge. Known issues   GitHub Copilot in VS Code may not enable the server automatically – after setup, GitHub Copilot can send requests before authentication completes, so the server may not turn on by itself. When this happens, enable (start) the server manually. This is a VS Code behaviour and has no further effect once the server is enabled.   Support   Your feedback helps shape MCP Server for Documentation. Whether you run into a problem, notice a documentation error, have an idea for how the service could work better, or want a product or document added, we want to hear from you – just let us know which product and document type you need.   Share feedback, report issues, and request additional documentation on the Agentic AI Development feedback page.   What's next for MCP Server for Documentation?   MCP Server for Documentation is actively evolving. Additional NXP product documentation is being added through regular releases, increasing the range of hardware information available to agentic workflows. Capabilities will continue to improve based on developer workflows, product needs and user feedback. Conclusion   MCP Server for Documentation gives your AI agent direct, grounded access to NXP hardware documentation. Instead of guessing device-specific details, your agent can discover the right product, search the documentation and retrieve the real source content – helping you get accurate answers and better code without manually browsing large reference manuals.   Connect MCP Server for Documentation to your AI development environment and give your agent the NXP product context it needs. MCP Server for Documentation is a remote MCP service that connects your AI agent directly to structured NXP hardware documentation, so it can search reference manuals, look up registers and bit fields, and retrieve the real source content before it answers a question or generates code. Getting Started
View full article
需要NXP IMX 1050evkb的帮助 我学过C语言编程。现在,我正在尝试学习嵌入式开发的基础知识。我刚买了一套NXP 1050评估套件。但这与 NXP 入门指南中提到的基本步骤并不一致。- 它没有内置加速度计项目。我尝试安装驱动程序,但链接指向构建 SDK 的页面。指南上说要安装SDK,但我找不到任何可安装的文件。里面的视频都太老了。 有人能帮忙吗? Re: Need help with NXP IMX 1050evkb 嗨@achino , 非常感谢您对我们产品的关注以及对我们社区的使用。 SDK 以 ZIP 包的形式下载;没有单独的 SDK 安装程序需要运行。请检查您的板是 MIMXRT1050-EVK 还是 MIMXRT1050-EVKB,并在下载 SDK 时选择匹配的板。 https://mcuxpresso.nxp.com/ 将 SDK ZIP 导入 MCUXpresso IDE 后,使用导入 SDK 示例。对于 MIMXRT1050-EVKB,选择“evkbimxrt1050_flexio_i2c_read_accel_value_transfer”。本示例通过板的虚拟串口将三轴加速度计读数打印到 PC 串口终端。 请检查您的 MCUXpresso IDE 版本、SDK 版本和评估板是否兼容。 希望对你有帮助 顺祝商祺! 刘梅
View full article
如何在 CodeWarrior 10.6 中使用 CodeWarrior 2.1 生成的 hex 文件对 MPC5607B 进行编程 您好,我遇到一个问题。在CodeWarrior 2.1中编译MPC5607B生成的hex文件可以在CodeWarrior 2.1中正常烧录,但无法在CodeWarrior 10.6中编程。 CodeWarrior 10.6 中的编程配置选择和错误信息如下: 回复: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 我的项目比较老旧,而且包含库,所以只能用 2.1 版本编译,不能用 10.6 版本编译。然后我把它连接到 10.6 系统上,我想直接用 10.6 系统对用 2.1 系统编译的文件进行编程。附件是我的 elf 文件和 hex 文件。 Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 你好, 感谢您提供如此详细的信息。 根据日志,闪存擦除操作已成功完成,这表明所选的闪存配置和擦除程序运行正常。 故障发生在编程阶段。具体来说,在地址 0x00000000 处编程成功,但在尝试对地址 0x00007FCC 处的数据进行编程时失败: 由于设备已成功擦除,因此该问题似乎与擦除算法本身无关。相反,它更有可能与故障地址处正在编程的内容有关,或者与 CodeWarrior 10.6 如何处理生成的映像有关。 请提供链接器映射文件,并指出地址 0x00007FCC 附近的段是什么?将生成的 HEX/S19 文件与 CodeWarrior 10.6 中编程的 ELF 图像进行比较也很有用。 顺祝商祺! Peter Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 我的项目比较老旧,而且包含库,所以只能用 2.1 版本编译,不能用 10.6 版本编译。然后我把它连接到 10.6 系统上,我想直接用 10.6 系统对用 2.1 系统编译的文件进行编程。附件是我的 elf 文件和 hex 文件。
View full article
How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 Hi,I encountered a problem,The hex file generated by compiling MPC5607B in CodeWarrior 2.1 can be normally burned in CodeWarrior 2.1, but it cannot be programmed in CodeWarrior 10.6 The programming configuration selection and error messages in CodeWarrior 10.6 are as follows: Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6    My project is quite old and contains libraries, so it can only be compiled with 2.1 and cannot be compiled with 10.6. Then I attach it on 10.6, and I want to directly program the files compiled with 2.1 using 10.6. The attachments are my elf and hex files. Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 Hello, Thank you for the detailed information. Based on the log, the flash erase operation completes successfully, which indicates that the selected flash configuration and erase procedure are working correctly. The failure occurs during the programming phase. Specifically, programming succeeds at address 0x00000000 but fails when attempting to program data at address 0x00007FCC: Since the device was erased successfully, the issue does not appear to be related to the erase algorithm itself. Instead, it is more likely associated with the contents being programmed at the failing address or with how CodeWarrior 10.6 handles the generated image. Could you please provide the linker map file and identify which section is located around address 0x00007FCC? It would also be useful to compare the generated HEX/S19 file and the ELF image being programmed in CodeWarrior 10.6. Best regards, Peter 回复: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6    My project is quite old and contains libraries, so it can only be compiled with 2.1 and cannot be compiled with 10.6. Then I attach it on 10.6, and I want to directly program the files compiled with 2.1 using 10.6. The attachments are my elf and hex files.
View full article
CodeWarrior 2.1で生成されたhexファイルを使用して、CodeWarrior 10.6でMPC5607Bをプログラムする方法 こんにちは、問題が発生しました。CodeWarrior 2.1でMPC5607Bをコンパイルして生成された16進形ファイルは通常CodeWarrior 2.1では焼くことができますが、CodeWarrior 10.6ではプログラムできません CodeWarrior 10.6におけるプログラミング構成の選択とエラーメッセージは以下のとおりです。 回复: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 私のプロジェクトはかなり古く、ライブラリが含まれているため、2.1でしかコンパイルできず、10.6ではコンパイルできません。次にそれを10.6に接続し、2.1でコンパイルされたファイルを10.6を使用して直接プログラムしたいと考えています。添付ファイルは私のelfファイルとhexファイルです。 Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 こんにちは、 詳細な情報を提供していただきありがとうございます。 ログに基づくと、フラッシュ消去操作は正常に完了しており、選択されたフラッシュ構成と消去手順が正しく機能していることがわかります。 不具合はプログラミング段階で発生します。具体的には、アドレス0x00000000ではプログラミングは成功するが、アドレス0x00007FCCにデータをプログラムしようとすると失敗する。 デバイスのデータ消去は正常に完了したため、問題は消去アルゴリズム自体とは関係がないようです。むしろ、それは障害が発生したアドレスにプログラムされている内容、あるいはCodeWarrior 10.6が生成されたイメージをどのように処理するかに関連している可能性が高い。 リンカーマップファイルを教えていただけますか?住所0x00007FCC周辺のどのセクションかを教えていただけますか?生成されたHEX/S19ファイルと、CodeWarrior 10.6でプログラムされているELFイメージを比較することも有用でしょう。 よろしくお願いいたします。 ピーター Re: How to program MPC5607B with hex files generated from CodeWarrior 2.1 in CodeWarrior 10.6 私のプロジェクトはかなり古く、ライブラリが含まれているため、2.1でしかコンパイルできず、10.6ではコンパイルできません。次にそれを10.6に接続し、2.1でコンパイルされたファイルを10.6を使用して直接プログラムしたいと考えています。添付ファイルは私のelfファイルとhexファイルです。
View full article
Need help with NXP IMX 1050evkb I’ve done C Programming. Now, I’m trying to learn basics of embedded development. I just bought an NXP 1050 evaluation kit. But it does not align with the basic steps mentioned on the NXP Getting Started guide. - It doesn’t have an accelerometer project in built. I tried installing the driver but the Link takes me to build an SDK. And the guide says to install the SDK but I can’t find any installable files there. All the videos in there are too old. Can somebody help? Re: Need help with NXP IMX 1050evkb Hi @achino , Thank you so much for your interest in our products and for using our community. The SDK is downloaded as a ZIP package; there is no separate SDK installer to run. Please check whether your board is the MIMXRT1050-EVK or MIMXRT1050-EVKB , and select the matching board when downloading the SDK. https://mcuxpresso.nxp.com/ After importing the SDK ZIP into MCUXpresso IDE, use Import SDK example(s) . For the MIMXRT1050-EVKB , select "evkbimxrt1050_flexio_i2c_read_accel_value_transfer ". This example prints the three-axis accelerometer readings to a PC serial terminal through the board’s virtual serial port. Please check that your MCUXpresso IDE version, SDK version, and evaluation board are compatible. Wish it helps you Best Regards, May Liu
View full article
S32K396 eTPU:TCR1 无法通过 STAC 总线共享(TCR2 可以)——请确认此限制 产品/环境 设备:S32K396(S32K39/37/36 系列),eTPU 单实例,双引擎 参考资料:S32K39、S32K37 和 S32K36 参考手册,修订版。4、11/2024、第 67 章(eTPU) SDK:S32 设计工作室 3.6.10RTD 6.0.0,ETpu_Ip /Etpu_Pwmm_Ip 驱动程序 板:S32K396BMS-EVB,176 LQFP 通过在运行时直接写入 eTPU 时基寄存器来重现此现象(寄存器)。 仅包含地址和值,不涉及应用程序代码)。 手册上是怎么说的 RM 67.3.8.3 “STAC接口”:“发动机和控制器之间可以共享两个时基TCR1和TCR2。” 与同一MCU中的其他模块……TCR1:可以导出到总线或从总线导入。 RM 67.3.8.1.5:“STAC 总线服务器模式 - TCR1 总线可以作为服务器导出到总线。” RM 表 378(芯片特定):引擎 1 TCR1 = 服务器 ID 0,引擎 2 TCR1 = 服务器 ID 1。 因此,TCR1 服务器/客户端操作预计可以在该设备上正常工作。 有效方法(基线,20 MHz 共享时基) 引擎 1 导出 TCR2(服务器 ID 2),引擎 2 将其导入为 TCR1: STAC_ENG1 (0x4068002C) = 0x8002C200 (REN2=1, RSC2=1 服务器; REN1=1, RSC1=0 ID 为 2 的客户端) STAC_ENG2 (0x4068004C) = 0x81020300 (REN1=1, RSC1=0client, SRV1=2) TB1R_ENG1 和 TB1R_ENG2 相互跟踪;此配置可正确运行 9 相 PWM。 失败的原因(TCR1 作为共享资源)——双向尝试均失败 根据 STAC_ENGn 中的注释,使用的序列是:“当 REN1 位钳位时,RSC1 不得更改”, 首先清除 REN1,然后写入 RSC1/SRV1,然后再次设置 REN1。 客户端引擎也使用 TBCR[TCR1CTL]=11(“TCR1 冻结,但作为 STAC 客户端除外”)进行了测试。 (a)引擎 1 服务器,引擎 2 客户端 TBCR_ENG1 (0x40680020) = 0x8000A000 (TCR2CTL=100DIV8; TCR1CTL=10, TCR1CS=1 = eTPU 时钟) TBCR_ENG2 (0x40680040) = 0x8000C000 (客户端,TCR1CTL=11 已冻结) STAC_ENG1 = 0xC002C200 (REN1=1, RSC1=1 服务器,SERVER_ID1 读取 0) STAC_ENG2 = 0x81000300 (REN1=1, RSC1=0 客户端, SRV1=0) 结果:TB1R_ENG1 持续计数,TB1R_ENG2 冻结在其当前值 (1989303) 且不再计数 在 400 毫秒的观察时间内发生了变化。 (b)引擎 2 服务器,引擎 1 客户端 STAC_ENG2 = 0xC1020300 (REN1=1, RSC1=1 服务器,SERVER_ID1 读取 1) STAC_ENG1 = 0x8001C200 (REN1=1, RSC1=0 客户端, SRV1=1) 结果:TB1R_ENG1 冻结在 1769497,TB1R_ENG2 继续计数。 STAC_ENGn 的回读确认每一位都已生效(REN/RSC/SRV/SERVER_ID 按写入),MCR[GTBE] 钳位,两台发动机均未处于角度模式(AM=0),且没有发动机配置为客户端。 本身。 问题 1.S32K396 系统集成 STAC 控制器是否为 eTPU TCR1 分配时隙 资源(服务器 ID 0 和 1)?RM 67.3.8.3 指出 eTPU 没有控制器模块,并且它是 “在系统集成中实例化一次”,但 S32K396 RM 没有记录该控制器。 2. 如果此设备支持 TCR1 导出,那么缺少哪一步配置?是否存在其他配置步骤? 系统集成寄存器、PCMC/时钟控制设置或外设工具选项必须 是否允许在RedLine赛道上驾驶TCR1时段的赛车? 3. 如果 S32K396 不支持 TCR1 导出,请记录此限制(RM 勘误表或注释)。 eTPU 章节),因为目前的措辞暗示它有效。 为什么这很重要 目前唯一能够保证两个 eTPU 引擎都能计数的方法就是采用 20 MHz STAC 时基。 相同的时基。它提供 50 ns 的 PWM 分辨率,这对于电流环路占空比控制来说是不够的。 (12 位,20 kHz 采样率需要 >= 8192 个计数)。在 80 或 160 MHz 频率下共享 TCR1 可以直接解决这个问题。 作为备选方案,我们正在评估 160 MHz 下的原生 TCR1(TCR1CTL=10,TCR1CS=1),并以 MCR[GTBE] 开始; RM 67.3.8.4 规定,当 TCR1CS=1 时,两台发动机的 TCR1 同时启动,这也是可以接受的。 如果得到确认。 相关公开信息 NXP社区,“STAC接口”(MPC5xxx,2016),NXP技术支持解答: https://community.nxp.com/t5/MPC5xxx/STAC-Interface/mp/532642 它指出,STAC总线允许一个eTPU将其时基(TCR1/TCR2)导出到另一个eTPU以及…… 对于诸如 eMIOS 之类的外围设备,只需要对 REDCR(eTPU_TBR_STAC_ENGx) 进行编程即可。 两台发动机有“4 个固定时间段”。在S32K396上,这四个插槽恰好就是服务器ID。 根据表 378(引擎 1 为 0/2,引擎 2 为 1/3),预计 TCR1 的插槽 0 和 1 将启用。 因此,我们想知道 S32K396 集成是否实现了所有四个插槽。 可应要求提供附件:重现冻结问题的注册表转储序列(gdbscript);无客户 涉及到应用程序代码。 Re: S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restricti STAC 接口,也称为红线,存在于 S32K396 上。两个 eTPU 引擎之间成功共享 TCR2,证实了接口本身是可操作的。 根据当前的参考手册描述和表 378,通过服务器 ID 0 和 1 导出 TCR1 似乎是受支持的。我不知道启用这些 STAC 资源还需要进行任何额外的 PCMC、时钟控制、系统集成或外围设备工具配置。所描述的编程顺序似乎也遵循在更改 RSC1 和 SRV1 之前清除 REN1 的要求。 由于 TCR2 共享在两个方向上都有效,而 TCR1 共享在两个方向上都无效,尽管 STAC 寄存器值按预期读取,但我目前无法确定明显的配置错误。这需要 eTPU 应用团队进行澄清,以确定是否存在其他未记录的要求、S32K396 集成中的限制,或者可能存在文档或实施问题。可以使用提供的 GDB 寄存器转储脚本来查看和重现确切的配置序列。 关于备用方案,MCR[GTBE] 提供了用于同时启动引擎时基的已记录机制。但是,当每个引擎使用自己的原生 TCR1 时钟时,计数器在初始启动后保持独立。因此,在将此方法用于最终的电流环 PWM 实现之前,应确认由此产生的同步精度和任何可能的长期偏移。 Re: S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restricti 请您向eTPU申请团队澄清一个问题: S32K396 是否实际实现了通过 STAC(红线)总线进行 TCR1 导出/导入? 我们观察到的现象,可以通过在运行时仅写入 eTPU 时基寄存器来重现。 (仅寄存器值,无应用程序代码,已验证回读,客户端 TCR1CTL = 10 和 11 都尝试过, (双向): - TCR2(服务器 ID 2 / 3)在两个引擎之间共享:有效,客户端计数器跟踪服务器。 - TCR1(服务器 ID 0 / 1)由两个引擎共享:客户端 TB1R 冻结且不再跟随, 双向的。 RM 67.3.8.3 和表 378 规定,TCR1 可以导出到/从总线导入,并且根据 您的回复是,无需额外的PCMC、时钟控制或工具设置即可启用这些资源。 因此,这种行为无法用我们的配置来解释。 那么问题就很简单:S32K396 中是否实现了 TCR1 时隙(服务器 ID 0 和 1) 系统集成方面有什么问题吗? 如果答案是肯定的,那么我们还缺少什么? - 如果没有,请记录该限制(RM 注释或勘误表),因为目前的措辞暗示了这一点 该设备支持 TCR1 导出/导入功能。 可应要求提供重现冻结的 gdb 脚本(仅限寄存器写入和读取)。
View full article
S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restriction Product / environment Device: S32K396 (S32K39/37/36 family), eTPU singleinstance, dual engine Reference: S32K39, S32K37 and S32K36 Reference Manual,Rev. 4, 11/2024, chapter 67 (eTPU) SDK: S32 Design Studio 3.6.10, RTD 6.0.0, ETpu_Ip /Etpu_Pwmm_Ip drivers Board: S32K396BMS-EVB, 176 LQFP Phenomenon reproduced by writing the eTPU time-baseregisters directly at run time (register addresses and values only, no application code involved). What the manual says RM 67.3.8.3 "STAC interface": "Both time bases TCR1 andTCR2 can be shared between the Engines and with other blocks in the same MCU... TCR1: Can be exportedto or imported from the bus." RM 67.3.8.1.5: "STAC Bus Server mode - TCR1 bus can beexported to the bus as a server." RM Table 378 (chip-specific): engine 1 TCR1 = server ID 0,engine 2 TCR1 = server ID 1. So TCR1 server/client operation is expected to work on thisdevice. What works (baseline, 20 MHz shared time base) Engine 1 exports TCR2 (server ID 2), engine 2 imports it as itsTCR1: STAC_ENG1 (0x4068002C) = 0x8002C200 (REN2=1, RSC2=1server; REN1=1, RSC1=0 client of ID 2) STAC_ENG2 (0x4068004C) = 0x81020300 (REN1=1, RSC1=0client, SRV1=2) TB1R_ENG1 and TB1R_ENG2 track each other; thisconfiguration runs a 9-phase PWM correctly. What fails (TCR1 as the shared resource) - tried in bothdirections Sequence used, per the NOTE in STAC_ENGn: "RSC1 mustnot be changed when the REN1 bit is asserted", so REN1 was cleared first, then RSC1/SRV1 written, thenREN1 set again. The client engine was also tested with TBCR[TCR1CTL]=11("TCR1 frozen, except as a STAC client"). (a) Engine 1 server, engine 2 client TBCR_ENG1 (0x40680020) = 0x8000A000 (TCR2CTL=100DIV8; TCR1CTL=10, TCR1CS=1 = eTPU clock) TBCR_ENG2 (0x40680040) = 0x8000C000 (client,TCR1CTL=11 frozen) STAC_ENG1 = 0xC002C200 (REN1=1, RSC1=1 server,SERVER_ID1 reads 0) STAC_ENG2 = 0x81000300 (REN1=1, RSC1=0 client,SRV1=0) Result: TB1R_ENG1 keeps counting, TB1R_ENG2 freezes at itscurrent value (1989303) and does not change over 400 ms of observation. (b) Engine 2 server, engine 1 client STAC_ENG2 = 0xC1020300 (REN1=1, RSC1=1 server,SERVER_ID1 reads 1) STAC_ENG1 = 0x8001C200 (REN1=1, RSC1=0 client,SRV1=1) Result: TB1R_ENG1 freezes at 1769497, TB1R_ENG2 keepscounting. Readback of STAC_ENGn confirmed every bit took effect(REN/RSC/SRV/SERVER_ID as written), MCR[GTBE] was asserted, both engines were out of Angle Mode (AM=0)and no engine was configured as a client of itself. Questions 1. Does the S32K396 system-integration STAC controllerallocate time slots for the eTPU TCR1 resources (server IDs 0 and 1)? RM 67.3.8.3 states the eTPUhas no Controller module and that it is "instantiated once in the system integration", but theS32K396 RM does not document that controller. 2. If TCR1 export is supported on this device, what is themissing configuration step - is there a system-integration register, a PCMC/clock-control setting,or a Peripherals-tool option that has to be enabled for the TCR1 time slot to be driven on the RedLine? 3. If TCR1 export is NOT supported on S32K396, pleasedocument the restriction (RM errata or a note in the eTPU chapter), because the current wording implies itworks. Why it matters The 20 MHz STAC time base is the only way currentlyavailable to guarantee that both eTPU engines count the same time base. It gives 50 ns PWM resolution, which isnot enough for current-loop duty control (12 bit at 20 kHz needs >= 8192 counts). Sharing TCR1 at 80or 160 MHz would solve that directly. As a fallback we are evaluating native TCR1 at 160 MHz(TCR1CTL=10, TCR1CS=1) with MCR[GTBE] start; RM 67.3.8.4 states that with TCR1CS=1 both engines' TCR1start together, which would also be acceptable if confirmed. Related public information NXP Community, "STAC Interface" (MPC5xxx, 2016), NXPTechSupport answer: https://community.nxp.com/t5/MPC5xxx/STAC-Interface/m-p/532642 It states that the STAC bus lets an eTPU export its timebase(TCR1/TCR2) to another eTPU as well as to peripherals such as eMIOS, that REDCR(eTPU_TBR_STAC_ENGx) is all that has to be programmed,and that with two engines there are "4 fixed time slots". On S32K396those four slots are exactly the server IDs of Table 378 (0/2 for engine 1, 1/3 for engine 2), so slots 0and 1 for TCR1 are expected to be live. This is why we would like to know whether the S32K396integration implements all four slots. Attachments on request: register dump sequence (gdbscript) that reproduces the freeze; no customer application code is involved. Re: S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restricti The STAC interface, also referred to as the Red Line, is present on S32K396. The successful sharing of TCR2 between the two eTPU engines confirms that the interface itself is operational. Based on the current Reference Manual description and Table 378, TCR1 export through server IDs 0 and 1 appears to be supported. I am not aware of any additional PCMC, clock-control, system-integration, or Peripherals-tool configuration required to enable these STAC resources. The described programming sequence also appears to follow the requirement to clear REN1 before changing RSC1 and SRV1. Since TCR2 sharing works while TCR1 sharing does not work in either direction, although the STAC register values read back as expected, I cannot currently identify an obvious configuration error. This requires clarification from the eTPU application team to determine whether there is an additional undocumented requirement, a restriction in the S32K396 integration, or a possible documentation or implementation issue. The provided GDB register-dump script can be used to review and reproduce the exact configuration sequence. Regarding the fallback solution, MCR[GTBE] provides the documented mechanism for starting the engine time bases together. However, when each engine uses its own native TCR1 clock, the counters remain independent after the initial start. Therefore, the resulting synchronization accuracy and any possible long-term offset should be confirmed before this approach is used for the final current-loop PWM implementation. Re: S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restricti Could you please clarify one point with the eTPU application team: Is TCR1 export/import over the STAC (Red Line) bus actually implemented on S32K396? What we observe, reproduced by writing only the eTPU time-base registers at run time (register values only, no application code, readbacks verified, client TCR1CTL = 10 and 11 both tried, both directions): - TCR2 (server IDs 2 / 3) shared between the two engines: works, the client counter tracks the server. - TCR1 (server IDs 0 / 1) shared between the two engines: the client TB1R freezes and never follows, in both directions. RM 67.3.8.3 and Table 378 state that TCR1 can be exported to / imported from the bus, and according to your reply there is no additional PCMC, clock-control or tool setting needed to enable these resources, so the behaviour cannot be explained by our configuration. The question is then simply: are the TCR1 time slots (server IDs 0 and 1) implemented in the S32K396 system integration at all? - If yes, what are we missing? - If no, please document the restriction (RM note or errata), because the current wording implies that TCR1 export/import works on this device. The gdb script that reproduces the freeze is available on request (register writes and readbacks only).
View full article