i.MX6SLL 寄存器编程辅助工具 重要提示：如果您有任何疑问或想要报告有关 DDR 工具或支持文档的任何问题，请在i.MX 社区中创建支持工单。请注意，任何私人消息或直接邮件不会被监控，也不会收到回复。 这是针对与 MMDC 初始化相关寄存器的详细编程辅助资料。最后一张表格格式化寄存器设置以便与 ARM RealView ICE 一起使用。它还可以与 DDR 压力测试的 Windows 可执行文件一起使用。此编程辅助工具用于内部 NXP 验证板。 i.MX6 全部 i.MX6SL

FIR滤波器套件 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本内容最初由 Steve Sabram 贡献给 lpcware.com 该示例项目使用 LPC4350 演示板和 ARM CMSIS DSP 库实现了声学范围、有限无限响应 (FIR) 滤波器。科幻“电击枪”的声音资源从演示板的耳机插孔中播放出来。该声音样本非常适合演示，因为它在声学带中具有许多低频、中频和高频成分。您可以通过触摸演示板上的电容式触摸按钮来播放声音资源，如演示板 LCD 上显示的菜单所示。最好使用耳机或耳塞聆听声音。四个按钮分别播放相同的声音资源 不同之处： 1) Raw – 未处理的声音按照其格式播放（采样率为 44.1 kHz、16 位样本和单声道）。 2) 低通——通过低通巴特沃斯滤波器滤波，截止频率为 5 kHz，类似于普通模拟电话的带宽。播放时，请注意高音部分被移除，类似 通过电话听到的声音。 3) 高通——通过高通巴特沃斯滤波器滤波，低频截止频率为 8 kHz。请注意，由于仅播放高音谐波成分，因此音量较低。 4) 后向掩码——声音资源样本以相反的顺序播放。“Zap！”现在变成了“Zoup！”数字滤波器是使用广受欢迎的公共领域工具 WinFilter ( http://www.winfilter.20m.com/ ) 设计的。 伴随这个例子。随着 NXP 推出这款免费 DSP 设计工具，我希望它的作者能够扩展其功能。 用户内容

无线充电让您摆脱电线的束缚！ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。

フリースケール・カップ・ワールドワイド・ファイナル2015トレーニング・ハイライトをご覧ください <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> トレーニング・セッションについては、フリースケール・カップ・ワールドワイド・ファイナル2015のハイライト・ビデオをご覧ください。クレジット:Fraunhofer IIS (マイビデオで視聴) フリースケール・カップの内容

在 MIFARE DESFire E 上使用本地 ISO 封装命令将默认 PICC 主密钥从 DES 更改为 AES 你好，恩智浦社区、 我正在使用出厂状态下的 MIFARE DESFire EV3 卡，并试图使用 ISO7816 APDU 包装的本地命令（不使用 TapLinx）将默认 PICC 主密钥从出厂时的 DES 密钥迁移到 AES-128 密钥。 我目前的设置 卡：MIFARE DESFire EV3 选定的应用程序：皮卡（AID 000000） 当前 PICC 主密钥：出厂默认 DES 密钥 (00 00 00 00 00 00 00 00 00 00) 验证方法：验证 ISO 通信：以 ISO7816 APDU 包装的本地命令 ISO 身份验证成功完成： 第一次响应返回 91 AF 第二次响应返回 91 00 会话密钥正确生成，身份验证成功 验证后，我尝试使用 ChangeKey (0xC4) 将 PICC 主密钥从 DES 更改为 AES-128，但卡返回： 91 7E 我想确认以下操作的正确步骤和有效载荷格式： 将 PICC 主密钥从 DES 迁移到 AES-128。 更改密钥类型（DES → AES）时的正确 KeyNo 值。 在发送 ChangeKey 之前必须加密的确切明文结构。 在这种情况下需要 CRC16 还是 CRC32。 预期有效负载长度和 APDU 结构。 将 PICC 主密钥从 DES 转换为 AES 时的任何 EV3 特定要求。 身份验证日志示例： A UTH_START-> 93 95 31 16 1C 30 76 A6 91 AF 解密的 rndB-> 5E B7 C8 89 89 71 49 ED CF rnda-> 61 84 03 0 A 61 7C 07 1E SessionKey-> 61 84 03 0A 5E B7 C8 89 身份验证结果-> 91 00 示例 ChangeKey 命令： 90 C4 00 00 18 6D FF 22 1D A7 A9 DD A6 12 8E EF 2E CA 14 A 3 78 FA 73 FA 73 FA D8 51 42 3B 16 00 回复： 91 7E 有人 能提供参考示例或解释 DesFire E V3 上正确的 DES 到 AES PICC 主 密钥迁移程序吗？ 谢谢。 Re: Change default PICC Master Key from DES to AES using native ISO-wrapped commands on MIFARE DESFi 您好，先生， 遗憾的是，这不是讨论 MIFARE DESFire 功能和使用的安全渠道。 我们确实有一份安全文档，名为：应用笔记 — AN12757 MIFARE DesFire EV3 功能和提示 本文档在 MIFARE DESFire EV3 快速入门指南第 3 节。 如需了解更多信息，请在我们的门户网站上创建Ticket。

i.MX95/i.MX952 - LPDDR5/LPDDR4X 内存兼容性指南 本文档的目的是为选择 i.MX 95 和 i.MX 952 处理器支持的兼容 LPDDR5 和 LPDDR4X 内存设备提供扩展指导。在所有情况下，强烈建议遵循恩智浦硬件开发者指南中针对特定 SoC 概述的动态随机存取存储器(DRAM)布局指南。 请注意，某些LPDDR4x设备可能不支持低速运行，此外，DQ ODT可能未处于活动状态，这可能会影响这些速度下的信号完整性。如果用例中计划低速运行，请向内存供应商咨询内存设备的配置方面和可能的自定义，以确保功能正确。 LPDDR5 - 最大支持密度 SoC 最大数据总线宽度 最大密度 假定内存组织 说明 i.MX 95 32 位 128GB/16GB 双列双通道设备，具有 17 行地址和 x8（字节模式）组织 1, 3, 7 i.MX 952 32 位 128GB/16GB 双列双通道设备，具有 17 行地址和 x8（字节模式）组织 1, 3, 7, 9   LPDDR5 - 有效存储器列表 注意：内存供应商通常在其高级产品信息中将其设备列为 LPDDR5x，而实际上，它们在大多数情况下都与 LPDDR5 模式向后兼容。这可能会给人一种错误的印象，即市场上没有那么多 LPDDR5 设备。在这种情况下，强烈建议查看完整的数据表，以确认该设备实际上是仅限LPDDR5/LPDDR5x还是LPDDR5x。SoC 不能用于仅支持 LPDDR5X 模式的设备。 验证过程是一项持续性工作--预计将定期更新表格。 SoC 密度 内存供应商 经过验证的内存部件编号 说明 i.MX 95 128GB/16GB 美光 MT62F4G32D8DV-023 FAAT:C - 64GB/8GB 三星 K3KL9L90QM-MHCT - 32GB/4GB 三星 K3KL8L80QM-MHCT 2 32GB/4GB 三星 K3KL8L80EM-MUCV 2 64GB/8GB SK HYNIX H58G66DK9VX067N 2 64GB/8GB 美光 MT62F2G32D4DS-023 FAAT:C 2, 6 32GB/4GB 美光 MT62F1G32D2DS-020 WT:D 2 16GB/2GB 美光 MT62F1G16D1DS-023 IT:B 2 64GB / 8GB 雷森 RS2G32LO5D24DB-31BT 2 64GB / 8GB CXMT CXDB6CCBM-MA-A 2 i.MX 952 128GB/16GB 美光 MT62F4G32D8DV-023 FAAT:C 9 32GB/4GB 美光 MT62F1G32D2DS-020 WT:D 2   LPDDR5-不兼容设备列表 SoC 不能与仅支持 LPDDR5x 模式的存储设备一起使用。 LPDDR4x - 最大支持密度 SoC 最大数据总线宽度 最大密度 假定内存组织 说明 i.MX 95 32 位 128GB/16GB 具有 17 行地址的双列双通道设备 1 i.MX 952 32 位 128GB/16GB 具有 17 行地址的双列双通道设备 1, 9   LPDDR4x - 经过验证的存储器列表 验证过程是一项持续性工作--预计将定期更新表格。 SoC 密度 内存供应商 经过验证的内存部件编号 说明 i.MX 95 64GB/8GB 美光   MT53E2G32D4DE-046 AUT:C 5 8Gb/1GB 美光 MT53E256M32D1KS-046 IT:L 2 128GB/16GB 美光 MT53E4G32D8GS-046 2 64GB/8GB SK 海力士 H54G66BYVPX104 2 32GB/4GB 智能存储器 imbg32l4kbb_v10 2 48GB/6GB 美光 MT53E1536M32D4DT-046 WT:A 3, 8 24GB/3GB 美光 MT53E768M32D4DT-053 AIT:E 3, 8 8Gb/1GB 三星 K4U8E3S4ADGHCL 2 32GB/4GB 智能存储器 IMBG32LK4BBG-046I 2 32GB/4GB 联盟记忆 AS4C1G32MD4V-046BIN 2 64GB/8GB 雷森 Atl4x8g32m2d-46it 2 64GB/8GB 雷森 Atl4x8g32m2d-46ait 2 64GB/8GB DW DWCTB36HLC0 2 8Gb/1GB 联盟记忆 AS4C256M32MD4V-062BAN 2 i.MX 952 64GB/8GB 美光   MT53E2G32D4DE-046 AUT:C 9   LPDDR4/4X-不兼容设备列表 Note: This SoC supports LPDDR4x memory devices. This SoC is not compatible with memories that only support LPDDR4. Combo Devices that support both LPDDR4x and LPDDR4 are compatible with the SoC. 注 1： 这些数字完全基于DDR控制器和DDR PHY的IP文档、为将其集成到SoC而选择的实现参数设置、SoC参考手册以及JEDEC标准 JESD209-5（LPDDR5）和JESD209-4C/JESD209-4-1（LPDDR4/4X）。因此，除非另有说明，否则它们没有经过验证，也不能保证存储器供应商提供的 SoC 具有特定的密度和/或所需的内部结构。如果客户选择使用最大密度，并将其用于预期用途，则风险自负。 注 2： 该内存部件号没有经过 JEDEC 的全面验证，但通过了所有功能测试项目。 注 3： 二进制密度（例如 1 GB、2 GB、4 GB）的内存设备是首选，因为它们通过与系统寻址方案保持一致并降低软件复杂性来简化内存管理。 注 4： 除非另有说明，否则所有内存部件均可从供应商处获得。已检查 2026 年第二季度 注 5： 存储设备支持 LPDDR4x 和 LPDDR4，但只能在 LPDDR4x 模式下使用 注 6： 未经恩智浦验证，但已确认在非恩智浦板上工作 注 7： 将来，当 动态随机存取存储器(DRAM) 供应商提供更高密度的选项时，支持的最大密度可能会发生变化 注 8： 不建议将此 动态随机存取存储器(DRAM) 部件号用于新设计 注 9： 该 SoC 处于试生产阶段 IMX95EVK

在 Zephyr 中启用 ROM 引导加载程序支持%28Non%E2%80%91BL2%29 for TF%E2%80%91M 导言 Zephyr 中的标准可信固件-M (TF-M) 目标（包括基于 RW61x 的平台）假定存在BL2（MCUboot）作为第二阶段引导加载程序。BL2 负责镜像验证、升级处理和闪存布局执行。 但是，许多恩智浦设备提供基于ROM的安全启动/双重启动机制，能够对固件进行身份验证并将控制权直接转移到安全映像。在这种情况下，BL2 是冗余的，可以禁用以减少启动时间和闪存使用量。 本文介绍如何在 TF‑M 中禁用 BL2，并配置 Zephyr 直接从 ROM 启动到 TF‑M Secure 镜像，然后启动非安全应用程序。 典型的 TF‑M 启动流程（使用 BL2） Zephyr TF‑M 的默认启动链是： BootROM → BL2 (MCUboot) → TF‑M Secure → Non‑Secure application BL2： 拥有闪存布局（主/辅插槽） 执行图像验证 管理固件升级 使用 samples/tfm_integration/config_build 的示例 目标启动流程（ROM 启动，不是 BL2） 使用 ROM 引导加载程序时： BootROM → TF‑M Secure → Non‑Secure application 在这种情况下 ROM 执行身份验证和版本检查 TF-M Secure 成为第一个可执行阶段 无需固件交换或辅助插槽 使用 samples/tfm_integration/config_build 的示例 禁用 TF-M 中的 BL2 Kconfig 更改 在项目配置中明确禁用 BL2，并更新基地址： CONFIG_TFM_BL2=n CONFIG_FLASH_BASE_ADDRESS=0x80A0000   这会将 McuBoot 从编译版本中移除，并防止生成 BL2 工件。 安全图像输入要求 删除 BL2 时，ROM 必须直接跳转到 TF-M 安全向量表。 确保： 安全映像链接到 ROM 的预期地址 安全矢量表有效 安全重置处理程序初始化： VTOR_S SAU / MPU Secure Partition Manager (SPM) 无需 BL2 移交逻辑。 非安全图像注意事项 TF-M 安全图像将在初始化后传输控制权。 作为直接启动的 Zephyr 应用程序构建 无 MCUboot 头 在分区布局中定义的非安全偏移处链接 支持双启动（由 ROM 管理的 A/B 映像） 在 RW61x 级设备上，ROM 期望安全映像在可启动插槽内的偏移量 0x1000 处开始，非安全映像位于偏移量 0xA0000 处。因此，每个启动插槽都包含一对固定偏移量的完整安全 + 非安全对。 ROM 验证插槽，跳转到安全偏移，然后 TF-M 将控制权转移到非安全映像。 BootROM ├─ Authenticate Slot A → Secure@+0x1000 → Non‑Secure@+0xA0000 └─ Authenticate Slot B → Secure@+0x1000 → Non‑Secure@+0xA0000 不涉及 BL2 或运行时图像交换。 Flash 布局示例（已更正） 插槽 A A 插槽基数： 0x08000000 Secure Image (A) : 0x08001000  Non‑Secure Image A : 0x080A0000    插槽 B Slot B Base : 0x08200000 Secure Image (B) : 0x08201000  Non‑Secure Image B : 0x082A0000   每个插槽都可独立启动，不包含与其他插槽共享的状态。 ROM 启动期望 对于每个插槽，ROM 都希望 插槽身份验证数据（签名/清单） 在 slot_base + 0x1000 有效的安全重置处理程序 ROM不会直接跳转到非安全模式。 使用 高效密码学标准(SEC) 工具启用双启动 首先，我们将创建两个图像，一个用于插槽 0，一个用于插槽 1。非安全图像的文本中会注明差异。 1。构建 Zephyr 镜像（插槽 A 和 Slot‑B） 对于每个插槽，构建： TF-M 安全图像（链接至 +0x1000 ) Zephyr 非安全图像（链接至 +0xA0000 ) 插槽 0，我修改了非安全图像，以打印一条快速信息，标明编程的插槽。 插槽 1，我修改了非安全图像，以打印一条快速信息，标明编程的插槽。 使用 高效密码学标准(SEC) 工具，我们将使用 " 合并工具 " 以适当的偏移量合并安全和非安全的二进制文件。 2.合并安全和非安全图像 ROM 要求每个插槽有一个连续的映像，而不是两个独立的二进制文件。 在 高效密码学标准(SEC) 工具中： 打开合并工具 选择： 安全二进制（不带启动头）→ 偏移量 0x1000 非安全二进制 → 偏移量 0xA0000 输出单一合并图像 * 如果您使用上述的 kconfig 选项，FCB 将附加到安全二进制文件中，因此请确保您的安全二进制文件偏移量考虑偏移量的 FCB 位置 0x400 对两个插槽图像都这样做。在本例中，我创建了 merged_imaged_slot_0 和 merged_image_slot_1。 3.分配版本元数据 双启动选择完全由 ROM 元数据驱动。 对于每个合并后的图像： 设置图像版本 例如 插槽 A 版本： 1 插槽 B 版本： 2 ROM 规则通常是 启动最高有效版本 验证失败时使用后备插槽 先为要编程的插槽选择合并图像。选择该插槽将使用的版本。 接下来，打开 " Dual Image 启动 " 对于插槽 0，选择"Image 0" ，然后选择插槽划分所需的偏移量。对于插槽 1，选择"Image 1" 。 4。程序插槽 0（初始启动） 仅程序槽 0 RESET 设备 预期行为： ROM 验证插槽 A ROM 跳转到 slotA + 0x1000 TF-M Secure 初始化 运行非安全应用程序 ✅ 确认您的安全链 → 非安全链可在没有 BL2 的情况下工作 5.程序插槽 1（升级测试） 程序插槽 1 更新插槽元数据（版本> Slot 0） RESET 设备 预期行为： ROM 选择插槽 1 插槽 1 安全执行 出现插槽 1 非安全信息 应避免的常见错误 在错误的偏移位置合并图像 ( 0x0 而不是 0x1000 ) 忘记升级插槽 B 的版本了 启用 MCUboot 头 假设 TF-M 控制时隙选择 结论 当设备 ROM 已经提供安全启动和双重启动服务时，在 TF‑M 中禁用 BL2 并直接从 ROM 启动是一种有效、高效且可用于生产的配置。在这种架构中，ROM 是验证、版本选择和回滚的权威，而 TF-M Secure 则成为可执行固件的第一阶段。 当与 ROM 管理的 A/B 双启动结合使用时，这种方法可提供： 独立、完全自足的插槽 A 和插槽 B 图像 基于 ROM 策略（版本或备用）的确定性启动行为 安全回滚，无需运行时图像交换 不依赖 MCUboot 或 BL2 基础设施 成功的关键要求是 在 TF-M 中明确禁用 BL2 在 ROM 要求的偏移量处链接安全映像 ( +0x1000 ) 在固定的非安全偏移量上链接非安全应用程序 ( +0xA0000 ) 将安全二进制文件和非安全二进制文件合并为单个插槽映像 使用 SEC 工具可以： 指定图像版本 启用双启动策略 验证并签署每个插槽图像 在这种模式下，TF-M 和 Zephyr 与插槽无关：它们不管理升级、插槽选择或回滚。所有启动决定都是由 ROM 根据美国证券交易委员会提供的元数据在开始执行之前做出的。 这种设计缩短了启动时间，简化了闪存布局，消除了固件交换的复杂性，并且与高可靠性生产系统非常吻合，在这些系统中，固件更新是带外执行的，由 ROM 级别的安全性强制执行。

HSE_b: Not allowed to import RSA key to RAM I'm trying to understand how to use the key import service by importing a single 1024-bit RSA public key into the RAM catalog, but the server responds HSE_SRV_RSP_NOT_ALLOWED. My test application formats the RAM key catalog as follows: { { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_RSA_PUB, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY1024_BITS, }, { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_ECC_PUB_EXT, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY256_BITS, }, { muMask = 0, groupOwner = 0, keyType = 0, numOfKeySlots = 0, maxKeyBitLen = 0 }, } and I get server reply HSE_SRV_RSP_OK. I then try to import an RSA key with the following key info: { keyFlags = HSE_KF_USAGE_VERIFY, keyBitLen = HSE_KEY1024_BITS, keyCounter = 0x0, smrFlags = 0x0, keyType = HSE_KEY_TYPE_RSA_PUB, specific = { pubExponentSize = 4, } } and my request is as follows: { targetKeyHandle = 0x20000, pKeyInfo = 0x20401f74, pKey = { 0x210034b4, 0x21003534, 0x0}, keyLen = { 0x80, 0x4, 0x0}, } . I have set HSE_RAM_PUB_KEY_IMPORT_POLICY_ATTR_ID to HSE_KM_POLICY_ALLOW_RAM_PUB_KEY_IMPORT, and read it back as the same. LC attribute is 0x04, HSE error flags are 0x0000, HSE status flags are 0x0B60. Firmware version reads as 0x0F SoC ID 0x0000 FW type 0x02 major 0x32 minor 0x00 patch. Re: HSE_b: Not allowed to import RSA key to RAM Hi @Emma_G-gbg  Your parameters are correct, I can see nothing wrong there. If you have super user rights, it’s not even necessary to set that attribute. I was testing something very similar yesterday, so I just slightly updated my code to import 1024bit RSA public key with 4-bytes public exponent. It looks like this: Notice that it’s not necessary to set pubExponentSize when importing RSA public key. HSE ignores this parameter. It uses keyLen[1] instead. Parameter pubExponentSize is used when reading the keyInfo by service HSE_SRV_ID_GET_KEY_INFO. This is what I got when I read the keyInfo of that key: Isn’t that just data cache issue? Could you try to disable data cache to see if it makes a difference? Regards, Lukas Re: HSE_b: Not allowed to import RSA key to RAM Thank you, I had missed filling in cipher and auth key handle information, I hadn't checked so I thought HSE_INVALID_KEY_HANDLE would be zero. It's currently working with at least some of the values in cached memories, with cache maintenance operations before and after service calls. Since we are adding HSE services to an existing project we are precluded from changing the cache structure, but so far everything has worked as long as we make sure it's actually written to the shared memory, although I did also try disabling the cache for the relevant memories, which made no difference.

s32k344 罐 你好，我正在使用 s32k344 电机驱动器代码，并有几个原型。我发现其中一台 CAN 机器在运行一段时间后会脱机，发送和接收都会出现异常。我打开了离线回复，发现信息会丢失 200 毫秒的帧。我更换了 CAN 收发器，但同样的现象依然存在。我已经阅读了勘误手册，是否是芯片本身存在这个错误？ Re: s32k344 can Hi@qicbeng 示例代码"MCSPTE1AK344_PMSM_FOC_2Sh_ll" 不提供 FLEXCAN 功能；您必须自行添加 CAN 相关功能。 请提供您的 CAN 测试项目，以便我检查您的配置是否正确。

iMX8MP MIPI DSI 至 HDMI 转换器（LT9611UXD）调出 您好， 我们设计了一款基于 imx8MP 的主板，用于使用 LT9611UXD 将 MIPI DSI 转换为 HDMI，但该芯片不断报告错误，例如 MIPI DSI 时钟不稳定和无法同步。 我们试图用 LT9611UXC 替换同一块主板上的 LT9611UXD，HDMI 有输出，但是换回来后 LT9611UXD 仍然无法工作。 能否请您指点一二？ 1。恩智浦是否有 LT9611UXD 的解决方案或演示板？ 2.恩智浦是否遇到过 MIPI DSI 时钟不稳定的问题？是如何解决的？    Re: iMX8MP MIPI DSI to HDMI Convertor(LT9611UXD) Bring Up 你好@杨志荣 希望你一切都好。 实际上，我们在 i.MX95 15mm x 15mm EVK DTSO 中使用了 LT9611UXC。 请看一看： https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx95-15x15-evk-lt9611uxc.dtso 对于 i.MX8MP，我们没有任何示例。 此外，您还可以使用 i.MX8MP 的原生 HDMI 来代替 LT9611UXD。 顺祝商祺！ 萨拉斯

MCUXPRESSOでc11を選択しても機能しません。 MCUXPRESSO c11にチェックを入れても、FRDM MCXA156ではstatic_assertが動作しません。プロジェクト全体は添付ファイルにあります。       MCXA Re: MCUXPRESSO钩选c11不起作用 プロジェクトはこちらです Re: MCUXPRESSO钩选c11不起作用 こんにちは、 @bigz static_assert を変更してみてください。 _Static_assert。     BR アリス Re: MCUXPRESSO钩选c11不起作用 Keilプラットフォームに移行しました。

T2080ブートフラッシュ設定に関するお問い合わせ 親愛なる友人たち、 私はT2080 + VxWorksブートローダー + NORブートフラッシュ（tACC=120ns、tOE=35ns）を使用しています。 電源を入れると、断続的にブートローダーまでしか起動せず（vxworksカーネルをロードできない）、起動が停止します。 T2080 CPUのIFC_FTIM1には、97nsのTRAD_NORを使用しています。これはNORフラッシュのtOE（35ns）を完全に満たしていると思います。 1. tACC(120ns)を満たすためにTRAD_NORを変更する必要がありますか？ 2. T2080(ifc_clk=11.5ns)からNORブート(tACC=120ns、tOE=35ns)にアクセスする場合、よく設定されるIFC_FTIM0~3の値と、既知の注意事項を教えていただけますか？ ご回答ありがとうございます。 QorIQ T2デバイス Re: Inquiry regarding T2080 Boot Flash settings tOEおよびtACCのNORフラッシュのタイミングシーケンス図、または対応するNORデータシートをご提供いただけますでしょうか。 可能であれば、これらのパラメータが指定されているページ番号も併せてご提示ください。 よろしくお願いします。 Re: Inquiry regarding T2080 Boot Flash settings ご返信よろしくお願いします。 私はCypress社のS29GL01GTを使用しています。 tACC=120ns（最大）、tOE=35ns（最大）、tCE=120ns（最大）。 Re: Inquiry regarding T2080 Boot Flash settings ジューン・ルーさん、ありがとう。 TACOは11サイクルを使用しており、CSの前のアドレスが安定していることを確認しました。 データシートに記載されている要件は満たしているように見えるが、断続的な起動エラーが依然として発生している。 ChatGPTのようなAOツールに問い合わせると、TRADはtACC+遅延（温度などの影響を受ける）を満たす必要があると示唆されます。これについてどう思いますか？ それと、u-bootなど、T2080で一般的に使用されているブートローダーの設定を教えていただけますか？ （IFC_FTIM0/1の設定とブートフラッシュモデル） よろしくお願いします。 Re: Inquiry regarding T2080 Boot Flash settings IFCモジュールの入力クロックをご確認いただけますでしょうか？ T2080リファレンスマニュアル（図4-3）によると、それはip_clkであり、プラットフォームクロックの1/2です。 プラットフォームクロックの有効範囲はデータシート（表121）に記載されており、構成によって異なります。 IFC_CLKとip_clkが同じかどうか確認していただけますか？ S29GL01GSを使用してT1023RDBプラットフォームを確認しました（ただし、これはNO-ADMです）。S29GL01GTと非常によく似ており、そのタイミング構成を初期参照として使用できます。 このプラットフォームでは、プラットフォームクロックは400MHzに設定されています。 https://github.com/nxp-qoriq/u-boot/blob/LSDK-1703/include/configs/T102xRDB.h#L328 追加の遅延（例えば、温度の影響を受ける遅延）については、QorIQ T2080のデータシートの図20および図21を参照してください。これらの図には、最大出力遅延が2.5 ns、最小出力ホールド時間が-2 nsであることが示されています。 tACOとtRAdが設定されている場合、実際のCE_BとOE_Bのタイミングは、プログラムされた値よりも少なくとも0.5ナノ秒長くなります。温度やレイアウトによる変動を考慮しても、3 × 11.5 ns = 34.5 ns は、要求される 23 ns と比較しても十分な余裕がある。 T2080リファレンスマニュアルのセクション13.4.2も参照してください。（フラッシュインターフェースタイミングのプログラミングモデル）は、IFCモジュールの入力クロックサイクルを1つ追加することで、マージンをさらに拡大することを可能にします。 いずれにしても、タイミングが要件を満たしていることを確認するために、オシロスコープを使用して波形を検証することをお勧めします。 波形とIFCレジスタの設定をさらに詳しく確認することもできます。 Re: Inquiry regarding T2080 Boot Flash settings ジューン・ルーさん、ありがとう。 私は以下のように時計を使用しています。 プラットフォームクロック：533.33MHz - ip_clk : 266.66MHz (IFCモジュール入力クロック) - IFC_CLK：88.88MHz（IFC外部クロック） ご提供いただいた参照データ（T102xRDB.h）を見ると、TRADは0x1Aに設定されています。プラットフォームクロックは400MHz、ip_clkは200MHzなので、TRAD = 5ns * 26(0x1A) = 130nsと推定されます。 つまり、TRADはFlashのtOE(35ns)ではなくtACC(120ns)を満たすように設計されているようだ。 Re: Inquiry regarding T2080 Boot Flash settings 親愛なるジュン・ルー様、 データシートを再度確認しましたが、同じ内容でした。 Re: Inquiry regarding T2080 Boot Flash settings TACCとTOEの定義を確認してください。 手持ちのS29GL01GTのデータシートを確認しました。それによると、TACCはアドレスから出力までの遅延、tCEはチップイネーブルから出力までの遅延、tOEは出力イネーブルから出力までの遅延である。これらの定義は、データシートに記載されているものと同じですか？ 図17は、下に示した図と同じものですか？ Re: Inquiry regarding T2080 Boot Flash settings T2080 RM 式 TRAD_NORは、TOEmaxに2×ボード遅延とセットアップ時間を加えた値を明示的に使用します。これはtOEに関連しています。tACC/tCEは、 TRAD_NOR単独ではなく、 tACO + tRADという複合パスと比較してチェックする必要があります。 T102xRDB.hのパラメータは、ボードにアクセスするための十分な余裕を残しています。すべての設定を試して問題が解決するかどうかを確認し、解決できた場合は、リファレンスマニュアルとデータシートに従ってパラメータを調整してください。 さらにご質問がある場合は、波形とすべてのIFCレジスタ設定を共有してください。 Re: Inquiry regarding T2080 Boot Flash settings 親愛なるジュン・ルー様、 u-bootコードでTRADを130ns（tACCより大きい値）に設定する理由がまだ気になっていますが、あなたの回答はとても参考になりました。 ご協力ありがとうございます。 Re: Inquiry regarding T2080 Boot Flash settings 十分なマージンを確保するため、TRADを130 nsに設定することをお勧めします。ただし、97ナノ秒などのより小さな値を試してみることもできます。この値でも問題なく動作するはずです。 結果が出ましたら、随時お知らせください。 ありがとうございます。

S32DS Warnings from Clock IP with S32K5xx RTD 0.8.0 When using S32K5xx RTD 0.8.0 I receive a number of warnings from the Clock IP module when compiling.  Is there a way to correct them?  Are these warnings safe to ignore?  Is there a plan to get them fixed? Re: S32DS Warnings from Clock IP with S32K5xx RTD 0.8.0 Hello @DirkEtzler , Thank you for your question. As mentioned previously, the S32K5 family is currently an NPI (New Product Introduction) device. For this reason, all support requests must be handled directly through your assigned NXP FAE. Alternatively, please create a support ticket at: https://support.nxp.com/s/?language=en_US The system will automatically route your request to the appropriate FAE team for further assistance. Thank you for your understanding. Best regards, Pavel

i.MX 93 データシートに FlexSPI クロックモード 0x2 の最大周波数情報が記載されていない こんにちは、 i.MX 93 用の FlexSPI FPGA インターフェイス アプリケーションを計画しており、可能なスループットを検討しています。QSPI 用の SD3 と eMMC 用の SD1 を提供するモジュールを使用しています。DQS ラインはすでに eMMC インターフェースで使用されているため、正しく理解していれば、クロック モード FlexSPIn_MCR0[RXCLKSRC] = 0x0 および 0x2 に制限されます。リファレンスマニュアルではモード 0x1 と同様の「中」速度が提案されていますが、データシートにはモード 0x2 の最大周波数仕様が記載されていません。 データシートでモード 0x2 が省略されている理由は何ですか?モード 0x1 と同様の速度が期待できますか?DQS ピンが他の用途に多重化されている場合、モード 0x1 は使用できないと思いますか? よろしくお願いします フランク Re: i.MX 93 No max frequency info for FlexSPI clocking mode 0x2 in datasheet こんにちは@FvM お元気でお過ごしのことと思います。 FlexSPI インターフェースに関する詳細情報については、リファレンス・マニュアルの表 195 を参照してください。 よろしくお願いいたします。 サラス。 Re: i.MX 93 No max frequency info for FlexSPI clocking mode 0x2 in datasheet こんにちは@FvM 心の中で尋ねました。 残念ながら、デバイスの特性評価によりループバック信号に信号整合性の問題があり、動作を保証できないことが判明したため、RXCLKsrc=2 オプションはデータシートから削除されました。 RM 内のオプションに関する記述は削除されます。 よろしくお願いいたします。 サラス。 Re: i.MX 93 No max frequency info for FlexSPI clocking mode 0x2 in datasheet こんにちは@Manuel_Salas 、 回答ありがとうございます。 FlexSPI リファレンス マニュアルのセクションを認識しています。問題は、データシートのパラグラフ4.12.9 FlexSPI タイミング パラメータでモード 0、1、3 のみが指定されており、モード 2 については何も言及されていないことです。具体的には、公称モードでのモード 2 (SCK 出力および SCK パッドからのループバック) DDR タイミング パラメータを求めています。これらはモード 1 と等しいと想定してよいですか? 私のアプリケーションでは SD1_STROBE ピンが eMMC インターフェイスによって占有されているため、モード 1 または 3 を使用できません。それでも、私は QSPI FPGA インターフェースで最大のスループットを達成しようとしています。 よろしく フランク Re: i.MX 93 No max frequency info for FlexSPI clocking mode 0x2 in datasheet こんにちは@Manuel_Salas 、 RXCLKsrc=2 の問題についてオープンにご報告いただき、誠にありがとうございます。DQSピンが使用できないため、弊社のアプリケーションは66MHz SDR/33MHz DDRクロック速度に制限されていると承知しております。 よろしくお願いします フランク

CLRC663 と CLRC663 plus AUX1 および AUX2 ピン構成の違い。 CLRC663およびCLRC663plusのAUX1およびAUX2のデフォルト状態に関する質問 アプリケーション ノートでは、AUX1 ピンと AUX2 ピンのデフォルトの予想される状態は次のように記載されています。 CLRC663 のGND 。 CLRC663plus 用にオープン。 具体的な質問: CLRC663 では AUX1 と AUX2 のデフォルト状態が GNDなのに、CLRC663plus ではオープンになっているのはなぜですか? CLRC663+ で AUX1 と AUX2 をオープンのままにせずにGNDに接続すると、何が起こるでしょうか、またはどのような影響があるでしょうか? CLRC663plus でこれらのピンを接地すると、LPCD の誤起動の原因になったり、デバイスの動作に他の影響が生じたりしますか? Re: CLRC663 and CLRC663 plus AUX1 and AUX2 pin configuration difference. こんにちは@rahultt999 あなたの調子が良いといいのですが。 CLRC663 の非プラス バージョンは新しいデザインには推奨されないことにご注意ください。 これらのテスト信号は通常の動作モードでは使用できません。これらのピンをデバッグ目的で設定する場合は、必ずCLRC663 アンテナデザインのセクション 4.4.2 の指示に従ってください。そうしないと、デバイスが損傷する可能性があります。NFC アンテナ設計トレーニング シリーズ、講義 4 (約 24 分 30 秒) もご覧ください。 これらのピンを使用していない場合は、AUX1 ピンと AUX2 ピンの対応するアプリケーション ノートの推奨接続に従ってください。 - AN11145はCLRC663にGNDを推奨しています - AN11783はCLRC663プラスでオープンにしておくことを推奨しています よろしくお願いいたします エドゥアルド。 Re: CLRC663 and CLRC663 plus AUX1 and AUX2 pin configuration difference. こんにちは、 必要に応じて、これらのピンを (適切な構成後に) アナログ デバッグに使用できるように、テスト ポイントに接続することをお勧めします。AN11145 および AN11783 の推奨事項は、低電力デザインを目的としています。 よろしくお願いいたします エドゥアルド。 Re: CLRC663 and CLRC663 plus AUX1 and AUX2 pin configuration difference. こんにちは、エドゥアルドさん。 早速のご返信ありがとうございます。 現在の製品設計では、 CLRC663 plusチップを使用しており、これらの特定のピンは現在接地されています。ただし、「プラス」バージョンのアプリケーション ノートでは、これらのピンをオープンのままにしておくことを推奨していることに気付きました。 これらのピンをオープンのままにせずにグランドに接続したままにしておくと、製品のパフォーマンスに既知の影響やリスクはありますか? Re: CLRC663 and CLRC663 plus AUX1 and AUX2 pin configuration difference. ありがとう、エドゥアルド。これらのピンをオープンにしない場合、消費電力に具体的な影響があるかどうかご存知ですか?これらのピンの内部回路の詳細がなければ、決定的な結論を導き出すことができないため、質問しています。

MMA8451 传感器数据长期错误 - 芯片损坏？ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大家好 我们公司的 MMA8451 型号出现了一个非常奇怪的问题。我们发现，随着时间的推移，加速度计的数据可能会突然出错。 我们有大约 250 台设备在现场运行，大约有 10 台设备遇到了这个问题。传感器数据会发生什么变化？ - 突然出现了一个完全错误的偏移量（超出了 MMA 应有的最小/最大值）。 - 或者它的 Z 轴是锁定在"固定的" 值上，还是在波动。 我们看到，PCB/传感器的机械碰撞会使其突然恢复工作。这让我们认为，MMA 芯片已损坏。 如果我们把一个全新的 MMA 焊接到早先出现问题的印刷电路板上，就不会出现问题。因此，它是随着时间的推移而发生的。一旦发生了这种情况，它就能恢复或再次恢复正常。 当然，我们也有很多软件来检查 I2C 等所有通信是否正常。我们与 STM32 微控制器连接。当问题发生时，所有关机、RESET芯片等都不会受到错误数据的影响。 我在这里提供了一些可视化数据。首先是正常功能的 MMA 测量：（X 轴 = 红色，Y 轴 = 绿色，Z 轴 = 蓝色）。所有测量均在设备沿 z 方向水平固定，然后绕 z 轴旋转的情况下完成。 该图的 x 轴为采样率（100 赫兹采样率）。Y 轴为传感器原始值。 下面的图片显示了故障的 MMA 测量： 还有一个 如你所见，随着x和y轴的变化，传感器在某种意义上起作用。但有一个不切实际的偏移量。如果我们机械地击中设备，之后轴线恰好是正常的。 z 轴可以像这样起作用，只是波动，也可以将其锁定在 8192（最大值）或 -8191（最小值）。 我们进行了各种 ESD 测试来推翻这一假设。但我们非常困惑。 我们希望恩智浦或其他人，对这个问题有所了解，或者以前听说过这个问题？ 先谢谢大家了。 加速度传感器 电池传感器 传感平台 Re: MMA8451 wrong sensor data over time - damaged chip? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，米克尔、 请详细说明 MMA8451Q 在您的应用中是如何使用的？ 在我看来，这部分是一个质量问题，被称为 Z 轴粘滞故障。出现此故障的设备通常具有正 (0x7FFC) 或负 (0x8000) 的轨道输出。 实际上，在制造或使用设备时可能会出现粘连。正如您在PCN14989和PCN15484 中看到的那样，为了消除这一故障，我们在设计/测试方面做了一些改进。在高加速度事件导致其活动元件接触到固定表面后，可能会发生使用中的粘连。再次机械冲击通常会使它们恢复正常工作。 遇到类似问题的客户可以联系我们的质量团队和客户服务团队。恩智浦质量团队将把信息输入恩智浦 CQC 系统，以便转给正确的质量团队和业务线联系人以获得支持。 至于 X 轴（红色）和 Y 轴（绿色）上的偏移，我至今还没有听说或看到过类似的问题。我建议将受影响的部件寄回去进行质量分析。 我们的标准程序是通过采购方提交不合格部件的 CQI 申请。 顺祝商祺！ 托马斯  

Issue with LPUART1 BREAK Detection on RT1170 Dear NXP Support Team, I am currently developing on the RT1170 using SDK with LPUART1 for UART communication. I am encountering an issue with Send BREAK detection and would like your guidance. Description of the issue: When I enable LIN Break Detection (LBKDE) and LBKDIE: The Send BREAK signal from the PC is successfully detected on the MCU (LBKDIF flag is set). However, normal UART data communication not working. RX and TX are working correctly in normal UART mode. Scope measurements show that the PC’s TX line stays low during the Send BREAK for the expected duration (~2100 ms). Question: Is this behavior expected on RT1170 LPUART? Is there a recommended way to detect a PC Send BREAK while still allowing normal UART communcation? I would appreciate your guidance on how to reliably detect a Send BREAK from a PC while maintaining normal UART data reception on RT1170. Thank you for your assistance. Best regards, Re: Issue with LPUART1 BREAK Detection on RT1170 Dear NXP Support Team, Thank you for your previous explanation and the reference to the RT1170 Reference Manual. Based on the RM description, we understand that when LBKDE = 1, the LIN break detection circuit is enabled and received data is not written to the RX FIFO, so normal UART reception is intentionally disabled. We acknowledge that this behavior is expected. However, we would like to ask a follow-up question regarding possible alternatives or recommended solutions. Our requirement Detect a Send BREAK condition from a PC (via USB-UART). At the same time, continue normal UART data transmission and reception. LIN protocol stack is not required; this is general UART communication with a BREAK used as a synchronization or control signal. What we have observed With LBKDE = 1 LIN BREAK is detected correctly (LBKDIF is set). Normal UART RX data is blocked, as described in the RM. With LBKDE = 0 Normal UART RX works correctly. Our questions Is there any supported or recommended method on RT1170 to detect a Send BREAK while keeping normal UART RX active, without enabling LBKDE? Is using Framing Error (FE) + RX FIFO flush considered the intended workaround for non-LIN UART BREAK detection? Are there any errata, undocumented settings, or hardware limitations related to using LBKDE with general UART communication? If this use case is not supported, could you please confirm that RT1170 LPUART does not support simultaneous LIN BREAK detection and normal UART reception by design? We would appreciate your confirmation or any recommended best practices for this scenario. Thank you very much for your continued support. Best regards, Re: Issue with LPUART1 BREAK Detection on RT1170 Hi @dskim2 , Thanks for your interest in NXP MIMXRT series! The phenomenon you described is expected. Please refer to the following explanation from RM: Additionally, one of our colleagues has implemented a similar feature that may be helpful to you: 1. https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/RT1170-LIN-driver-development-and-stack-porting/ta-p/1356144 2. https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Use-RT1060-STAT-LBKDE-to-detect-Lin-quot-break-quot-but-cannot/m-p/1458242 Best regards, Gavin

eIQ Neutron NPU 实验室指南 这些实验室指南提供了详细的分步说明，介绍了如何制作量化的 TensorFlow Lite 模型，以及如何使用eIQ 工具包中的中子转换工具，将模型转换为可在 MCX N 设备上的 eIQ 中子核处理器上运行的格式。《eIQ Neutron NPU for MCUs 实验室指南——第 1 部分——Mobilenet》文档重点介绍了如何使用 eIQ Toolkit GUI 方法转换模型，随后将转换后的模型导入 eIQ MCUXpresso SDK 示例中。建议您首先完成这个实验。根据 MCUXpresso SDK 的下载方式，存在两个版本：一个版本可从MCUXpresso SDK Builder 网站下载为 zip 文件，另一个版本可从NXP GitHub 仓库下载。 《eIQ Neutron NPU for MCUs 实验室指南 - 第 2 部分 - 人脸检测.pdf》文档重点介绍了如何使用 eIQ 工具包的命令行工具将模型转换为 eIQ Neutron NPU 格式，并将转换后的模型集成到 Face Detect demo 中，该演示可在 Application Code Hub 中找到。这两个实验室均设计为在 FRDM-MCXN947 上运行，但相同的概念也适用于其他 MCX N 系列开发板，以及搭载 eIQ Neutron 神经处理单元的其他设备，如 i.MX RT700。另外，请务必查看入门社区帖子，以获取有关 eIQ Neutron 神经处理单元的更多详细信息。 ---更新于 2025 年 4 月，适用于 eIQ Toolkit 1.15 MCXN NPU|ML

S32K310 CAN Interrupt Receive S32K310のCANドライバモジュールをCANとCANIFを使って設定しました。CAN_Write()関数を呼び出してメッセージを送信できることは分かっていますが、以下の点について疑問があります。 1. メッセージを受信するにはどうすればよいですか？CanIf_RxIndication()関数を使ってメッセージを受信できるという記事をいくつか見ました。しかし、この関数のロジックは静的コード内で自動的に呼び出されるべきであり、外部メインプログラムで自分で記述するべきではありません。あるいは、この関数は割り込み発生後にデータを保存するので、どのようにデータを読み出せばいいのでしょうか？自分で作成したコールバック関数に置き換えることは可能でしょうか？（MCALルーチンの中に割り込みを使用するCANルーチンは見つかりませんでした。POLLINGモードのルーチンしかないようです。） 2. CANの受信はCANIFを経由する必要があるのに、送信はCANドライバーから直接送信できるのはなぜですか？何か仕様上の制限があるのでしょうか？ 助けてくれてありがとう!! Re:S32K310 CAN割り込み受信 こんにちは@Embedded_novice、 1.FlexCANがドライバーとどのように連携するかについては、次のトレーニングをご覧ください:RTDおよび低レベルドライバーを使用したFLEXCAN。 割り込みモードでメッセージを受信するには、割り込みドライバー(IntCtrl)を設定し、FlexCANデータ情報構造体内でpolling = FALSEを選択し、「FlexCAN_Ip_Receive」を使用する必要があります。 この例は、コミュニティの投稿からガイダンスとして使用できます: TX/RX/EnhanceRXFIFO DMAテストの例S32K344 FlexCAN_Ip S32DS3.5 RTD400 - NXPコミュニティ。 2. CanIf_RxIndication APIのことを言っているのですね。前の回答で述べたように、代わりにFlexCAN_Ip_Receiveを使用できます。 Best regards, Julián

FreeMASTER を S32K3、Simulink MBDT、Segger JLink で使用すると問題が発生する こんにちは、 当社では、S32K311 を使用する独自設計のハードウェアを保有しています。 Segger JLink (Ver 7.98d) を使用して、Simulink 自体からターゲットをビルドしてフラッシュすることができました。 データ ストア メモリ変数を監視/変更するための FreeMASTER プロジェクトを作成しました。Segger JLink との通信ウィザードを設定し、接続が成功することを確認しました。 FreeMASTER で「GO」ボタンを押すと、ターゲットがフリーズ状態になるように見えます。たとえば、このモデルでは、Alive LED が点滅していますが、「GO」ボタンを押すと停止します。後で「STOP」を押しても何も変わりません。 電源をリセットすると、プログラムはデフォルトに戻り、変更した変数値も取得されませんでした。 FreeMASTER Config ブロックを使用する必要がありますか (接続タイプは Serial/CAN と記載されていますが)?モデル内で FreeMASTER Config ブロックを使用せずに変数を監視/変更することは可能ですか? 何が足りないのか教えてください。 Re: Running into issues using FreeMASTER with S32K3, Simulink MBDT, Segger JLink こんにちは、 @beginner100さん FreeMASTERプロジェクトで変数を監視するには、 FreeMASTER Configブロックが必須です。現在の進捗状況についてお知らせいただけますか？また、可能であれば、FreeMASTERの設定に関する追加情報もご提供いただけますでしょうか？ 最新の S32K3 Toolbox バージョン1.8.0 (NXP Model-Based Design Toolbox for S32K3 バージョン 1.8.0 - 製品リリース発表) をインストールすることもお勧めします。 よろしくお願いいたします。 ドラゴス