S32K344 CAN 接收 参考 "Can_Example_S32K344 "示例项目。 CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_WRITE "变为 "STD_ON"，"Can_43_FLEXCAN_MainFunction_Read" "被禁用，因此无法接收 CAN 信号。 Can_43_FLEXCAN_MainFunction_Read_CanMainFunctionRWPeriods_0" 未启用。 我已经安装了 3 个频道，“FLEXCAN_0”、“FLEXCAN_2” 和 “FLEXCAN_5”。         附带的是 "FLEXCAN_0 "的 "Can_43_FLEXCAN "设置屏幕。 Re: S32K344 CAN receive 你好，@toru88、 应该没有问题。传输时，请确认波特率和采样点是否设置正确。您使用的是两块板还是 CAN 分析仪工具？ 社区中有一些 CAN 示例，请参考： [RTD600 MCAL & IP] S32K3X4EVB-T172 FlexCAN 示例中断/轮询-恩智浦社区 示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO DMA 测试 S32DS3.5RTD400 - NXP 社区 示例 S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500 - NXP Community 致以最诚挚的问候， Julián Re: S32K344 CAN receive 你好，胡利安 由于无法更改到版本 6.0，我能够通过执行以下定义进行构建。 这个答复有问题吗？ #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_0 CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_0 #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_1CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_1 #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_2 CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_2 #defineCAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_3 CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_3 #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_4CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_4 #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_5 CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_5 我正在尝试让它工作，但无法发送/接收 CAN。 我参考 “Can_Example_S32K344” 进行设置。 我认为如果取消选中 "Can Loop Back Mode（可回环模式）"，就可以从外部发送/接收 CAN 数据。 CAN 数据接收到 MCU 的终端。 是否有任何在 CAN 总线上发送和接收帧的示例代码？ 致以最诚挚的问候， toru88 Re: S32K344 CAN receive 你好，@toru88、 你说得对。我测试了您的项目，没有生成主函数 RW 周期的正确定义。但是，这个问题似乎已在6.0.0版本中修复（我目前正在使用RTD代码包）。您能将 RTD 更新到新版本吗？ 如果没有，只需编辑Can_43_FLEXCAN_Cfg.h即可。文件，如下所示。 从这里： /** * @brief Period for cyclic call of Main Function Read/Write */ #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_0 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_1 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_2 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_3 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_4 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_5 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_WRITE (STD_ON) #define CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_READ (STD_ON) 对此 /** * @brief Period for cyclic call of Main Function Read/Write */ #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_0 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_1 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_2 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_3 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_4 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_WRITE_PERIOD_CanMainFunctionRWPeriods_5 (0.001F) #define CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_WRITE (STD_ON) #define CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_READ (STD_ON) Re: S32K344 CAN receive 你好，胡利安 我有同样的设置，但结果不同。 无法生成 RWPeriods_0/1/2。 附上设置屏幕截图。 我还附上了正在开发的 S32K 项目。 请检查 "AGV_CTRL.mex"。 用户程序已删除。 S32K Design Studio for S32 Platform 的版本为 "Verison 3.5"。 致以最诚挚的问候， toru88 Re: S32K344 CAN receive 你好，@toru88、 当仅定义了 1 个 RW 周期时，使用单个函数进行轮询： void Can_43_FLEXCAN_MainFunction_Read(void); 另一方面，当定义多个周期时，会针对不同的时间要求定义多个轮询函数： void Can_43_FLEXCAN_MainFunction_Read_CanMainFunctionRWPeriods_0(void); void Can_43_FLEXCAN_MainFunction_Read_CanMainFunctionRWPeriods_1(void); // etc. 但是，您还需要在 CanHardwareObject 容器中正确配置 CAN 实例各自的 RWperiod，否则，在生成代码时，将不会生成 RWPeriods_0/1/2/3： 致以最诚挚的问候， Julián Re: S32K344 CAN receive 你好 Julián_AragónM 感谢您的答复。 感谢您的回复。 CAN_43_FLEXCAN_MAINFUNCTION_MULTIPLE_WRITE "变为 "STD_ON"，"Can_43_FLEXCAN_MainFunction_Read "从编译目标中删除。 以下定义尚未完成。 - CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_0 - CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_1 - CAN_43_FLEXCAN_MAINFUNCTION_READ_PERIOD_CanMainFunctionRWPeriods_2 由于未设置该定义，因此无法启用以下功能。 因此，在 Main 中调用的代码中会出现编译错误。 -can_43_flexcan_mainfunction_read_canMainFunctionrwperiods_0-can_43_flexcan_mainfunction_read_canMainfunctionrwperiods_1-can_43_flexcan_mainfunctionrwperiods_read_c anMainfunctionrwp 该代码尚未运行，无法版本。 顺祝商祺！ toru88 Re: S32K344 CAN receive 你好，@toru88、 您能提供更多信息吗？您是否在 FlexCAN 接收方面遇到问题？您提到""Can_43_FLEXCAN_MainFunction_Read" 已禁用，因此无法接收 CAN。"，您的主代码中是否无法读取帧？ 如果可能，请分享您的项目（或 main.c文件），这样我就能了解你的日常工作是什么了。 此外，您还可以参考 RTD 中的示例。它们与本培训演示中显示的相同：S32K3xx 通信模块：带有 rtd 和低级驱动程序的 flexcan。 这些项目配置为环回，因此需要启用正常/用户模式并初始化收发器输出引脚（CAN_H& CAN_L）。 还有一些社区帖子提供了一些实例： 示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO DMA 测试 S32DS3.5RTD400 - NXP 社区 已解决：S32K344 EVB 与 MCAL FLEXCAN TJA1153 - NXP Community 致以最诚挚的问候， Julián

S32G3-Linux 上 A53 Core 的 FlexCan 示例版本 您好， 当我版本 FlexCan 示例项目时，我想获得一个 .elf可执行文件，可在Linux 下的 A53 内核上运行。 不过，该示例似乎是为M7 内核设计的。 有没有办法版本或调整 FlexCan 示例，使其生成可执行文件 .elf是否适合 A53 内核？ 我还尝试从头开始创建一个针对A53的新应用程序项目，但我不确定如何重复使用或转移所有FlexCan配置（外围设备、驱动程序、初始化代码等）到这个新项目中。 请指导我如何实现这一目标？ Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 我更新了主题，说我用 Goldvip 的图片解决了问题。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 感谢您分享您正在使用的板。 对于 Goldbox3，你需要在设备树中启用 can0 和 can1 节点。在这些节点中，您可以配置 CAN 输出使用哪些引脚。必须确保所选引脚在其 SSS 中支持 can0 或 can1 输出。 你可以查看哪些引脚可以在主板原理图和参考手册中附带的 S32G3_IOMUX.xlsx 文件中使用（你需要用 acrobat 阅读器打开 RM 才能看到附带的文件） Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好，我正在使用这个https://www.nxp.com/design/design-center/development-boards-and-designs/GOLDBOX-3 (S32G3 ) Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好@MrAlexIV 你能分享一下你在用哪个板吗？我分享的图片中提到的连接器适用于扩展名为 S32GRV-PLATEVB 的 S32G-VNP-EVB3。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 另外，按照手册（我在 S32G3 中关注过）它会提到 J166、J169... 但是在我的板上那些 Jumpers 不可用。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 谢谢你，卡洛斯。 好吧，我明白你的意思了。我按照您的指示进行了操作，但这样我只能在 can0 和 can1 之间收发信息。我想要的是通过 CAN 总线接收或发送到其他设备（我有一个 CAN 总线，用于连接所有设备）。以 FlexCan 为例，我可以从其他设备接收，但是如果我只有低压差线性稳压器(LDO) candump can0，我就无法从其他设备接收 CAN 消息。 接口未处于环回状态。 这就是我想得到 .elf 的原因。因为我已经测试过 M7 的 FlexCan 示例，它可以正常工作。 我可以将简单的 candump can0 与你建议的 system () 一起使用，但看来我没有收到来自其他设备的 CAN 消息。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好@MrAlexIV 感谢您的提问 在运行 linux 的 A53 内核中，对 gpios、can 等模块的使用有些不同，而不是像裸机或 RTD（如 M7 内核）那样直接通过寄存器传递值。对于Linux的实现，需要一个驱动程序来在操作系统和硬件之间传递这些值，其中一些驱动程序已经在恩智浦提供的电路板支持包发行版中实现了。 要在 Linux 中使用 CAN，您可以查看电路板支持包用户手册中给出的示例 [适用于 S32G2 平台的 Linux 电路板支持包 44.0 用户手册] 这个例子是在 linux 控制台中编写这些命令，你可以编写一个 C 程序，使用system() 函数发送命令，然后只执行你的 C 代码。

LPC55S36 I3C 主站在读取长度超过从站数据大小时挂起 我连接了两块用于 I3C 通信的 LPC5536-EVK 板，其中一块配置为 I3C 主板，另一块配置为 I3C 从机。如果主站指定的读取长度超过从站提供的数据量，主站就会卡在读取函数I3C_MasterTransferBlocking 中。根据波形，信号似乎是正确的，因此我认为问题出在主控端。 在我提供的示例中，从属服务器的数据是 [0x01，0x02]，长度仅为 2 字节。但是，主服务器将读取长度指定为 3。因此，在第 2 字节的末尾，Slave 将 T-Bit 作为 0 返回，以表示消息结束。 测试步骤： (1) RESET 从属板 (2) RESET 主板 有关 T 位的定义，请参阅《MIPI I3C 基本规范》v1.1.1。 第 5.1.2.3.4 节、SDR 目标返回（读取）数据的第九位为数据结束位 在 I2C 中，"从目标读取 "有一个问题，即只有控制器才能结束读取，因此目标无法控制其返回的数据量。相比之下，在 I3C SDR 中，目标可控制其返回的数据字数；但它也允许 I3C 控制器在必要时提前终止读取。 ... Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 尽管用户无法确定i3c_masterTransferNonBlocking实际传输了多少字节，但对于我的应用程序来说，这似乎已经足够了。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 我尝试改用I3C_MasterTransferNonBlocking。尽管它不会挂起，但用户无法知道Slave实际提供了多少字节。在我分享的示例中，它需要返回传输计数 = 2 这样的信息。 在你使用 lpcxpresso55s36_i3c_interrupt_b2b_transfer_master 示例进行测试时，尽管你将 dataSize 更改为 50，但之后代码仍会打印固定的32字节，这恰好与从属提供的传输数量相匹配。 在实际应用中，例如我在另一篇关于IBI 与待读通知的文章中提到的情况，在发生 IBI 并执行私人读取后，从属设备的传输计数是不可预测的，可能会发生变化。当主站使用大缓冲区调用读取传输函数时，传输函数需要返回实际传输的计数。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 你好@黄铃铃 我已经测试过了。 您是对的。 我检查了 I3C_MasterReceive 函数。 /* Check RX data */ if ((0UL != rxSize) && (0UL != (base->MDATACTRL & I3C_MDATACTRL_RXCOUNT_MASK))) { *buf++ = (uint8_t)(base->MRDATAB & I3C_MRDATAB_VALUE_MASK); rxSize--; if ((flags & (uint32_t)kI3C_TransferDisableRxTermFlag) == 0UL) { if ((!isRxAutoTerm) && (rxSize == 1U)) { base->MCTRL |= I3C_MCTRL_RDTERM(1U); } } } 它读取数据的大小取决于数据的大小。 我测试了 i3c 中断演示，它支持这一功能。 我将dataSize设置为 50。 它从来没有挂过。 您可以试试看。 BR 哈利

恩智浦 OTA 示例中的不可缓存区域 亲爱的各位， 我试图使用这里给出的 OTA 机制示例： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/tree/release/25.09.00-pvw1/_boards/evkbmimxrt1170/ota_examples/mcuboot_opensource 链接器脚本中有一节： /* Specify the memory areas */ MEMORY { m_flash_config (RX) : ORIGIN = 0x30000400, LENGTH = 0x00000C00 m_ivt (RX) : ORIGIN = 0x30001000, LENGTH = 0x00001000 m_interrupts (RX) : ORIGIN = 0x30002000, LENGTH = 0x00000400 m_text (RX) : ORIGIN = 0x30002400, LENGTH = TEXT_SIZE m_qacode (RX) : ORIGIN = 0x00000000, LENGTH = 0x00040000 m_data (RW) : ORIGIN = 0x20240000, LENGTH = 0x00040000 m_data2 (RW) : ORIGIN = 0x202C0000 + RPMSG_SHMEM_SIZE, LENGTH = 0x00080000 - RPMSG_SHMEM_SIZE rpmsg_sh_mem (RW) : ORIGIN = 0x202C0000, LENGTH = RPMSG_SHMEM_SIZE m_core1_image (RX) : ORIGIN = CORE1IMAGE_START, LENGTH = 0x00040000 } Then later there is: __NDATA_ROM = __ram_function_flash_start + (__ram_function_end__ - __ram_function_start__); .ncache.init : AT(__NDATA_ROM) { __noncachedata_start__ = .; /* create a global symbol at ncache data start */ *(NonCacheable.init) . = ALIGN(4); __noncachedata_init_end__ = .; /* create a global symbol at initialized ncache data end */ } > m_data2 . = __noncachedata_init_end__; .ncache : { *(NonCacheable) . = ALIGN(4); __noncachedata_end__ = .; /* define a global symbol at ncache data end */ } > m_data2 这将额外的不可缓存部分定义为 OCRAM2 的剩余部分（从 202C_0000 到 2033_FFFF - 512KB）。 不过，Board_ConfigMPU 确实： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/release/25.09.00-pvw1/_boards/evkbmimxrt1170/board.c #if defined(CACHE_MODE_WRITE_THROUGH) && CACHE_MODE_WRITE_THROUGH /* Region 6 setting: Memory with Normal type, not shareable, write through */ MPU->RBAR = ARM_MPU_RBAR(6, 0x20200000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 0, 0, ARM_MPU_REGION_SIZE_1MB); /* Region 7 setting: Memory with Normal type, not shareable, write trough */ MPU->RBAR = ARM_MPU_RBAR(7, 0x20300000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 0, 0, ARM_MPU_REGION_SIZE_512KB); #else /* Region 6 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(6, 0x20200000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_1MB); /* Region 7 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(7, 0x20300000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_512KB); #endif 将此内存扇区标记为可缓存。 有谁能告诉我，示例代码是否真的将 m_data2 的提醒标记为不可缓存？ 或者换句话说--谁能告诉我如何实现这一目标--在我们的应用程序中，我们希望将这一 ram 部分的剩余部分用作非高速缓存。 感谢您的支持 Re: Non-Cachable region in NXP OTA example 你好@jslota13245、 感谢您对 NXP MIMXRT 系列的关注！ OCRAM 是一个可缓存区域。针对您的应用场景，请参考本指南： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Using-NonCached-Memory-on-i-MXRT/ta-p/1183369 致以最诚挚的问候， Gavin

i.MX 8M Quad/Mini/Nano/Plus - LPDDR4, DDR4 & DDR3L memory compatibility guide The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2 LPDDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad  24Gb/3GB    Micron MT53B768M32D4NQ-062 WT:B  15 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D  14 4Gb/512MB ISSI IS43LQ16256B-062BLI  5, 14 8Gb/1GB ISSI IS43LQ32256B-062BLI  5, 14 i.MX 8M Mini 16Gb/2GB Micron MT53D512M32D2DS-053 WT:D  15 16Gb/2GB    ESMT M56Z16G32512A-SMBIG 5, 14 32Gb/4GB Micron MT53E1G32D2FW-046 WT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DT-046 AIT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DE-046 AUT:C 5, 14 32Gb/4GB Intelligent Memory IMBG32L4KBB 5,14 32Gb/4GB Kingston B3221PM3BDGUI -U 5 16Gb/2GB Kingston D1621PM4CDGVIW-U 5 i.MX 8M Nano  16Gb / 2GB  Kingston C1612PC2WDGTKR-U  15 16Gb / 2GB  Kingston  D1611PM3BDGUI-U 5,14 32Gb / 4GB Micron MT53E2G32D4DT-046 AIT:A  5, 13, 15 16Gb / 2GB Intelligent Memory  IMAG16L4KBB 5,14 4Gb / 512MB Nanya NT6AN256M16AV-J2 5,14 4Gb / 512MB  Winbond W66CP6RBQAHJ 5,14 8Gb / 1GB ISSI IS43LQ16512A-053BLI 5,14 8Gb / 1GB  Micron MT53D512M32D2DS-053 WT:D 13, 15 i.MX 8M Plus 48Gb/6GB  Micron MT53E1536M32D4DT-046 WT:A  15 64Gb/8GB  Micron MT53E2G32D4DE-046 AUT:C  5, 14 32Gb/4GB Samsung K4FBE3D4HB-KHCL  5, 14 32Gb/4GB Kingston B3221PM3BDGVIW-U 5, 14 64Gb/8GB Kingston Q6422PM3BDGVK-U  5, 14 8Gb/1GB Winbond W66DP2RQQAHJ  5, 14 32Gb/4GB ISSI IS46LQ32K01S2A-046BLA2 5, 14 16Gb/2GB ISSI IS46LQ32512A-046BLA3 5 32Gb/4GB ISSI IS43LQ32K01S2A-046BLI 5, 14 32Gb/4GB IM IMBG32LK4BBG-046I 5, 14 32Gb/4GB Nanya NT6AN1024F32AV-J2 5, 14 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory Vendor Memory Part# Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL K4UJE3D4AA-KU(H/F)CL 24Gb/3Gb 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.  DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 DDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad 32Gb/4GB Micron 4x MT40A512M16JY-083EAAT  15 i.MX 8M Mini  16Gb/2GB Micron 2x MT40A512M16LY-075:E  15 i.MX 8M Nano 16Gb/2GB Micron 1x MT40A1G16RC-062E:B  15 8Gb/1GB Rayson 1x RS512M16Z2DD-62DT 14 8Gb/1GB UniIC SCB12Q8G160BF-06SI 14 i.MX 8M Plus 64Gb/8GB Micron 4x MT40A1G16RC-062E:B  15 16Gb/2GB Nanya NT5AD512M16C4-JRI  14 DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus does not support DDR3L DDR3L - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Vendor Validated Memory Part#  Notes i.MX 8M Quad  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14 i.MX 8M Mini  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14              i.MX 8M Nano 8Gb/1GB Micron MT41K512M16VRN-107  15 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed Jan 2026 Note 15: Part will either EoL or is not recommended for new designs by the respective vendor. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715            IMX8MPLUSEVK

使用 i.MX28 添加对新型 NAND 的支持——NAND 分析 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本页介绍如何确定 NAND 驱动程序中使用的 NAND 时序参数。这与可能使用的任何操作系统无关。 分析NAND数据表 我们使用电子表格来捕获和分析 NAND 特性。该电子表格[附加到此 wiki 页面|使用 i.MX28 添加对新 NAND 的支持 - Nand 分析^nand_analysis_template.xls]。 我们分析一个 NAND，如下所述。 我们必须有 NAND 数据表才能进行分析。 将*分析电子表格*复制到一个新文件名，其中包含正在分析的 NAND 的确切零件编号。 填写分析电子表格的第 1 页（“封面”）。 接下来处理第 3 张表： 基本特征。 其他表。 如果 NAND 是数据表中列出的某个系列之一，则使用一个电子表格来分析整个系列。您可以使用“类似”行来查找家庭的其他成员。如果需要，添加更多行。 大多数 NAND 都有异步接口，因此不涉及简单的时钟频率。相反，存在各种设置时间、保持时间和输出延迟，这意味着 NAND 的 I/O 速率受到限制。电子表格比较了 NAND 的时序规格，以查看设置、保持和输出时间的总和是否短于最小读取周期或写入周期时间。该电子表格专门用于 STMP378x/i.MX233/i.mx28 中的 Nand 控制器芯片，因此电子表格执行时序计算，目的是得出这些 CPU 的时序参数 *TSU*、*TDS* 和 *TDH*。如果在计算完所有时间之后，TDS 和/或 TDH 量 {color:#ff0000} 变为红色{color}，则计算出的 TDS 和/或 TDH 对于 NAND 的指定周期时间来说太短。在这种情况下： 您必须在软件中增加其中一个或两个。 在分析电子表格中的某处写下您选择的值的注释，但不要弄乱自动计算。 记录闪存如何表示工厂标记的坏块。（有些使用块的第一页，有些使用最后一页，等等）将其与此[当前坏块标记方法超集[ http://wiki.freescale.net/display/PSGSW/Storage+Media%2C+Flash+Bad+Block+Marks ]进行比较用于检测任何闪存工厂坏块。 实例分析 NAND 数据表和分析的示例可以在 [Hynix NAND 页面 | http://wiki.freescale.net/display/PSGSW/Hynix+NAND+Flash+Documents ] 上找到。 i.MX2x 回复：使用 i.MX28 添加对新 NAND 的支持–NAND 分析 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，谢谢你的信息。由于某些原因，链接不起作用。您能否提供分析电子表格的新链接？谢谢，马克

实践研讨会：利用恩智浦最新多媒体应用处理器 i.MX 8M Mini 快速推进您的产品开发 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 从 i.MX 8M Mini EVK 开始实践，我们将介绍开箱即用的支持，包括软件、工具、硬件设计指南和演示软件。参加者在完成本课程后应该能够自信地使用 i.MX 8M Mini 开始自己的设计。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 从 i.MX 8M Mini EVK 开始实践，我们将介绍开箱即用的支持，包括软件、工具、硬件设计指南和演示软件。参加者在完成本课程后应该能够自信地使用 i.MX 8M Mini 开始自己的设计。 i.MX 应用处理器

ADAS: NXP Secure V2X Solution As the US Government prepares to mandate Car-to-Car communication in the US, the car industry is gearing up to provide cars which support this Dedicated Short Range Communications technology. We look at what benefits this will bring to road users, how the ITS-G5 standard is being deployed around the globe, and the challenges faced by the car industry in bringing this to market, and NXP’s leadership role in this deployment. As the US Government prepares to mandate Car-to-Car communication in the US, the car industry is gearing up to provide cars which support this Dedicated Short Range Communications technology. We look at what benefits this will bring to road users, how the ITS-G5 standard is being deployed around the globe, and the challenges faced by the car industry in bringing this to market, and NXP’s leadership role in this deployment.

基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该视频显示： - 采用 S32K144 rev2.0 的电机控制典型设置评估板； - 用于 BLDC 电机控制的 Simulink 模型； - 如何设置 Simulink 为 S32K144 rev2.0 生成 ANSI C 代码单片机； - 快速浏览基于模型的设计工具箱； - 快速浏览 FreeMASTER 数据可视化工具； - 使用 DevKit S32K144EVB 和 MotorGD 屏蔽运行的电机控制示例； （在 “我的视频” 中查看） 视频库 回复：基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 非常感谢！ 回复：基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢分享，但是 C 代码在哪里？

スマートホーム、ビル、照明向けのNXPコネクティビティソリューションと、コンシューマ、医療、インダストリアルIoT、オートモーティブ市場向けのBLE低電力ソリューション <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、まず、NXPのワイヤレス・コネクティビティ・マイコン・ポートフォリオがIoT市場に対応するために含まれる製品、ソフトウェア、およびイネーブルメントの概要を説明します。次に、Thread™ネットワーキングテクノロジーと、NXPのThread StackおよびZigBee® Dotdotアプリケーションレイヤーを使用してアプリケーションを開発する方法について、より深く掘り下げてデモします。このセッションでは、最新のQN9080/83超低電力BLE WMCUおよびKW35/36車載および産業用BLE WMCUを含むNXP BLE製品ファミリも紹介し、対象とするユースケース、デバイスの機能、BLEとスタックのハイライト、およびイネーブルメントのサポートについて詳しく説明します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、まず、NXPのワイヤレス・コネクティビティ・マイコン・ポートフォリオがIoT市場に対応するために含まれる製品、ソフトウェア、およびイネーブルメントの概要を説明します。次に、Thread™ネットワーキングテクノロジーと、NXPのThread StackおよびZigBee® Dotdotアプリケーションレイヤーを使用してアプリケーションを開発する方法について、より深く掘り下げてデモします。このセッションでは、最新のQN9080/83超低電力BLE WMCUおよびKW35/36車載および産業用BLE WMCUを含むNXP BLE製品ファミリも紹介し、対象とするユースケース、デバイスの機能、BLEとスタックのハイライト、およびイネーブルメントのサポートについて詳しく説明します。

NET-N1879 5Gの推進:次世代のアクセス技術 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 スマートネットワーク

HMB-N1937 推出基于 Android 的互联设备 Brillio 操作系统 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Brillo 是基于Android的轻量级操作系统， 适用于小型联网设备，开放、可扩展且安全。 Brillo将Android平台扩展至您所有的联网设备， 使这些设备可以轻松安装并与其他设备和您的智能手机无缝协作。 它与谷歌'Weave'通信API配套提供，可以在Brillo设备之间轻松实现通信和交换，并在云中存储数据。 在本次课程中，我们将向您介绍Brillo以及恩智浦如何与谷歌合作，将Brillo扩展至i.MX 6UltraLite处理器和其他平台。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Brillo 是基于Android的轻量级操作系统， 适用于小型联网设备，开放、可扩展且安全。 Brillo将Android平台扩展至您所有的联网设备， 使这些设备可以轻松安装并与其他设备和您的智能手机无缝协作。 它与谷歌'Weave'通信API配套提供，可以在Brillo设备之间轻松实现通信和交换，并在云中存储数据。 在本次课程中，我们将向您介绍Brillo以及恩智浦如何与谷歌合作，将Brillo扩展至i.MX 6UltraLite处理器和其他平台。 观看视频演示 智能家居和智能建筑

DES-N1846 - 关于 DDR4 你需要知道的一切 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解 DDR4 的基础知识以及如何在 QorIQ 设备上配置 DDR4 控制器。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解 DDR4 的基础知识以及如何在 QorIQ 设备上配置 DDR4 控制器。 观看视频演示 设计 | 软件与服务

FTF-INS-F1134 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 备受期待的 i.MX 7 系列专为物联网应用、销售点产品和许多其他成本敏感的嵌入式应用而设计。本课程将揭示下一代 i.MX 系列的更多细节，重点关注安全性、处理能力和低功耗技术。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 备受期待的 i.MX 7 系列专为物联网应用、销售点产品和许多其他成本敏感的嵌入式应用而设计。本课程将揭示下一代 i.MX 系列的更多细节，重点关注安全性、处理能力和低功耗技术。

AMF-ACC-T1647 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。

示例 S32K146-Set_whole_FlexRAM-as_RAM v0_0 S32DS.ARM.2.2 ******************************************************************************** * 文件：main.c * 所有者：David Tosenovjan * 版本：0.0 * 日期：2021年3月12日 * 分类：一般商业信息 ******************************************************************************** * 详细说明： * 示例代码将整个 4kB FlexRAM 区域配置为 SRAM 使用。 *默认情况下或批量擦除后，S32K1设备只有地址范围 * 0x1400_0000-0x1400_0DFF (3.5kB) 可供 SRAM 使用。 * 要启用剩余的 0.5kB，需要执行程序分区命令 *（使用示例中所示的设置），但只能使用空白的新 * 设备（或之前已批量擦除）。设置地址范围 * 0x1400_0000-0x1400_0FFF 用于 SRAM。 * ---------------------------------------------------------------------------------------------- *测试硬件：S32K146EVB-Q144 * 微控制器：PS32K146UAVLQ 0N73V QAC1735D * Fsys: 默认 * 调试器：Lauterbach Trace32、OpenSDA * 目标：Debug_RAM * 终端：无 * EVB连接：默认 ********************************************************************************

RT1064 I2C 通信异常，频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常，但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看，这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS：将该设备的 I2C 驱动程序移植到另一台 1064 设备上，测试模块 A，在 400k 功耗下未发现问题。 原因可能是什么？ 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2：模块 A 在 100kHz 下的逻辑分析仪波形 图3：模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察，该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足，而不是模块 A 本身的异常。 即使上升时间在规格范围内，在 RT1064 上，我们仍然建议检查 LPI2C 主侧 400 kHz 配置，特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1，因为 RT1064 上的主同步延迟不仅受上升时间的影响，还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置，并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符： I2C模块时钟源 目标波特率：400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息：昨天在定位方面取得了一些进展： 我们的硬件扩容计划如下： 主板：RT1064--- ADUM1251 3.3V 至 5 V 子板：ADUM1251-模块A 5V转3.3V 经验证，在硬件链路的两层中添加 ADUM1251 后，模块 A 的通信出现异常。但移除 ADUM1251 后，通信在 400k 处恢复正常。造成这种情况的原因可能是什么？ PS：我们的硬件工程师认为 ADUM1251 只会增加通信延迟，不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好，@mayliu1 我们的产品即将发布，我们已经调查这个问题好几天了。如果您能尽快回复，我们将不胜感激！ Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形，上升时间符合要求，在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备，并测试了模块 A，没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑： 1.如果时钟在拉伸后恢复异常，还有哪些其他原因可能导致这种情况？ 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置？我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求，我们是否就不需要考虑这些寄存器设置了？ Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题，而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上，LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出，上升时间越大，同步延迟就越高。（参见第 47.3.1.4 章）时序参数） 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置，使其延迟保持在最小 SCL 低/高周期以下，RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此，如果模块 A 使总线边沿稍微变慢或改变有效负载，则总线可能在 400 kHz 时发生故障，但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率，但应根据 I2C 规范仔细验证自动生成的定时参数，特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险，建议使用经过验证的时钟源，例如 48 MHz，如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数？ PS：显然是由于自动接口分配造成的 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 您可以尝试直接设置寄存器。 例如，当使用 60 MHz I2C 时钟时，可以采用以下配置。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率？（时钟树似乎看不见） Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz，但仍然无效。下图中的红色方框显示的是修改后打印的值，这些值与手册中的值不同。 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz，因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版： "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一：将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 方法二：将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源，并将分频器设置为 3，这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示，我尝试修改寄存器设置以匹配参数，但在 60MHz 下性能没有提升；即使是性能良好的模块在 8MHz 下也无法正常工作。 Re: RT1064 I2C communication abnormality at 400kHz 原因已查明，出现问题的模块将在 400k 时出现时钟拉伸现象。 但是我们使用的隔离器芯片不支持 SCL 双向。更换隔离芯片后， 测试结果正常；此订单可以结案。

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.

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ナノ秒などのより小さな値を試してみることもできます。この値でも問題なく動作するはずです。 結果が出ましたら、随時お知らせください。 ありがとうございます。

[不正行為] 投稿者: @RishavKaaraTech / 掲示板: TapLinx-SDK / 報告者: bedhcyqo bedhcyqo は、 @RishavKaaraTech が投稿した 「RFIDDiscover ツールを入手したが、その使い方はわからない」という 投稿を以下の理由で報告しました。 理由：嫌がらせ 詳細： 購入アンビエン 代金引換 購入非ジェネリックのアンビエンをオンラインで購入 アンビエンシドニーでは処方箋なしで ジェネリックアンビエン格安 アンビエン処方箋不要のオンライン薬局 購入プロアンビエン どこで次のアンビエンを購入する 今はダメ アンビエン セイウチ バルプロ酸アンビエンの相互作用ジェネリック アンビエンブルガリアでは処方箋なしで http://sp-journal.ru/article/19339 "> 一般的なアンビエン対アンビエン アンビエンの購入方法 アンビエンリトアニアでは処方箋なしで https://www.rapidservice.com.ec/es/content/ambien-cheap-non-prescription "> ジェネリックアンビエン 安い アンビエンを購入したい 購入モントリオールのアンビエン 購入モントリオールのアンビエン アンビエンネブラスカ州では処方箋なしで入手可能 アンビエンジェネリック写真 オーストラリアでアンビエンを安く購入 安いアンビエン アメリカ 安いオーストラリアでのアンビエン アンビエンを次に注文する場所 アンビエンの購入価格 アンビエンをオンラインで購入する 割引アンビエン cr 購入アンビエンCRオンライン アンビエン処方箋なしでオンラインで購入 購入無料の翌日配送薬局アンビエン valiumアンビエンの相互作用ジェネリック ジェネリックアンビエン 安い 処方箋なしでアンビエンを購入する 次にアンビエンを購入する場所 アンビエンの注文方法 アンビエンのジェネリック %E2%オーストラリアで安いアンビエン どこで次のアンビエンを購入する 割引アンビエン cr プロアンビエンを購入する 購入バイアグラ インド ジェネリック アンビエン 投稿リンク： https://community.nxp.com/t5/TapLinx-SDK-TagWriter-and/RFIDDiscover-tool-acquired-but-how-to-use-it/mp/2164324#M205 投稿者: @RishavKaaraTech |作成者に電子メールを送信する 報告者： bedhcyqo |メールによる報告 報告された投稿には3件の返信があります。