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 哈利

MC9S12ZVM128 SRAM 双位 ECC 处理 我们正在使用 MC9S12ZVM128，想知道如何处理 SRAM 中的双位 ECC 错误。具体来说，系统是否可以通过使用以下方法执行软件重启来恢复正常运行 CPMUCOP = 0x01; CPMUARMCOP = 0x00；? Re: MC9S12ZVM128 SRAM double bit ECC handling 你好，喇嘛 感谢您的答复。这个问题我们现在已经很清楚了，我相信我们可以结束这个话题。 BR, Mark Re: MC9S12ZVM128 SRAM double bit ECC handling 您好， 让我来概括一下。 在 POR 期间，SRAM 将被初始化。如果检测到双位 ECC 错误： 内存访问受阻。 已通知启动器模块。 7.3.4内存初始化 ... 为避免出现虚假的 ECC 错误报告，允许在首次写入前进行读取的内存操作（如非对齐访问的读取-修改-写入操作）要求在执行首次读取-修改-写入访问之前，内存必须包含有效的 ECC 值。ECC 模块提供在开机阶段将整个内存内容初始化为零的逻辑。在初始化过程中，SRAM 的访问被禁用，RDY 状态位被清零。如果初始化过程完成，则可以访问 SRAM，并设置 RDY 状态位。 POR（上电复位） 它的作用：POR 是通过重新启动电源或由专用 POR 信号触发的全面硬件 RESET。 对 ECC 错误的影响 -SRAM 已清除：所有易失性存储器都丢失，包括损坏的数据。 -ECC 逻辑已 RESET：所有 ECC 错误标志或状态位都被清除。 -寄存器RESET为默认值：所有配置寄存器返回其默认状态。 - 影响：除非从闪存或外部资源重新加载相同的损坏数据，否则系统将重新启动，双位 ECC 错误将不会继续存在。 ________________________________________ COP（计算机正常运行）RESET 它的作用：当软件无法及时维修时，看门狗定时器会触发 COP RESET。 对 ECC 错误的影响 - SRAM 未清除 - ECC 错误持续存在：如果损坏的数据仍在 SRAM 中，ECC 逻辑可能会在重启后再次检测到相同的双位错误。 -寄存器可能保留值：某些寄存器可能会保留其值，具体取决于RESET配置。 ________________________________________ 建议 如果您想保证消除 ECC 错误状态，请使用 POR RESET。如果您正在调试软件故障或从软件故障中恢复，并希望保留内存以供分析，则 RESET COP 可能更合适。 因此，最好确保在 POR 之后检查并处理 RDY，而不使用 RAM。 如果 COP 重新启动了系统，则尝试写入该字，并检查 ECC 错误是否确定。 此致 拉吉斯拉夫

LS1043 GPIO support in Linux SDK This document introduces how to configure RCW to support GPIO on LS1043 platform, how to configure Linux Kernel to load Linux GPIO driver to access GPIO from SYSFS and using loopback method to do verification on the target board. RCW configuration to support GPIO Configure GPIO driver in Linux Kernel Verify GPIO on the target board QorIQ LS1 Devices Re: LS1043 GPIO support in Linux SDK For all those who - like me - were searching for a list to map the individual pins to the GPIO number.. This is the answer I got from NXP Technical Support (thank you, Fedor!): modified table (refer to the QorIQ LS1043A Reference Manual, Table 2-3. CCSR Block Base Address Map): GPIOs 384-415, /soc/gpio@2330000: GPIO4[0-31] GPIOs 416-447, /soc/gpio@2320000: GPIO3[0-31] GPIOs 448-479, /soc/gpio@2310000: GPIO2[0-31] GPIOs 480-511, /soc/gpio@2300000: GPIO1[0-31] even if not all 32 signals are implemented for each GPIOn set, the math is identical - i.e., for GPIO4_03 it is: 384+3=387

S32K Sound Mixer Hi all, Recently, we completed S32K Sound Mixer reference code and demo, and glad to share this demo at here. Some key feature of this demo:  - Demo HW based on S32K344/S32K148 + audio codec SGTL5000 + QSPI flash MX25L6433.  - Demo SW based on S32K3 RTD RTM 2.0.0 and S32K1 RTD RTM 1.0.0.  - Demo provided 2 kinds of sound mixing algorithm realization code, and corresponding audio materials and codec SGTL5000 driver.  - Demo showed how to programming QSPI flash and its AHB accessing via audio storage and playing process.  - Demo used mono audio as source for processing, and output stereo audio (I2S format) via SAI HW FIFO combine (Line_Mux) function with nearly no extra cost. HMI/Cluster apps need multiple audio sources (usually warning sounds) be played simultaneously, which brings sound mixing ability requirement. However, S32K1/3 lack of this HW/SW feature support. With the demand from local key customer, and considering potential customer requirements, we planned to enable a SW sound mixer with scheduled peripherals, to enhance the S32K family audio mixing ability. It shall be easy of using/porting on S32K1/3, and use QSPI flash (AHB mode read) to store the music. Attachment the Sound Mixer package includes 2 sound mixing examples based on S32K344 EVB and S32K148 T-Box RDB, and some slides to introduce this implementation and quick start guide.  Thanks and welcome any comment from you. Best Regards, Shuailin Li Re: S32K Sound Mixer Hi @zyc0211 , Please sign-in your NXP website account, and see below place: FYI. If you still can not obtain the RTD 2.0.0 driver, please contact corresponding NXP FAE/DFAE to get the resources. Regards, Shuailin 回复： S32K Sound Mixer Hello, where is the download connection for S32K3 RTD RTM2.0? The S32K3 RTD 4.4 I installed cannot open the project

Video: Install S32R45 Development Package (view in My Videos)

1.1 S32V overview The S32V234 is our 2nd generation vision processor family designed to support computation intensive applications for image processing and offers an ISP, powerful 3D GPU, dual APEX-2 vision accelerators, security and supports SafeAssure™. S32V234 is suited for ADAS, NCAP front camera, object detection and recognition, surround view, machine learning and sensor fusion applications. S32V234 is engineered for automotive-grade reliability, functional safety and security measures to support vehicle and industrial automation. S32V234 has a complete enablement platform supported by S32 Design Studio IDE for Vision which includes a compiler, debugger, Vision SDK, Linux BSP and graph tools. Video Link : 8296 The target applications for S32V234 are: Automotive Sensor Fusion Systems Automotive Vision Systems Front View Camera Intelligent Roadside Unit Smart  Rear-View Camera Surround View & Sense Park Assist System Surround View Park Assist System NEXT TOPIC

LAT-DES-T2443 - i.MX アプリケーション プロセッサ製品ファミリのアップデート: i.MX 6UltraLite、i.MX 6ULL、i.MX 6QuadPlus、i.MX 7、i.MX 8 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、利用可能なすべての最新の i.MX プロセッサを取り上げ、まもなく発売されるプロセッサについて説明します。i.MX 6、i.MX 7、i.MX 8 アプリケーションプロセッサの製品。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、利用可能なすべての最新の i.MX プロセッサを取り上げ、まもなく発売されるプロセッサについて説明します。i.MX 6、i.MX 7、i.MX 8 アプリケーションプロセッサの製品。

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の課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 スマートネットワーク

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 系列的更多细节，重点关注安全性、处理能力和低功耗技术。

ESC技术报告.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队

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" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。

AMF-ACC-T1645 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在仍然执行微控制器应用程序的同时，在闪存中编写第二个应用程序代码映像，然后切换到新的代码映像的需求正在增加。提供了飞思卡尔微控制器架构的示例实现，以演示如何通过应用程序执行进行并发编程并随后重新映射到新的应用程序代码映像。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在仍然执行微控制器应用程序的同时，在闪存中编写第二个应用程序代码映像，然后切换到新的代码映像的需求正在增加。提供了飞思卡尔微控制器架构的示例实现，以演示如何通过应用程序执行进行并发编程并随后重新映射到新的应用程序代码映像。

一种检测不精确硬故障源的方法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本文档与Dragos Musoiu合作创建 尝试调试基于 ARM Cortex M4 的微控制器 MKW24D512 上的硬故障，我们没有找到太多关于处理不精确硬故障的文档。我们从 Erich Styger 的帖子“调试 ARM Cortex-M 上的硬故障”开始调查。基于此，我们使用Erich的代码来查找硬故障源，但无法找到导致硬故障的指令，因为围绕保存的PC执行的指令看起来是正确的。 之后，我们检查了硬故障状态寄存器，从 ARM Cortex M4 处理器的系统控制块中，我们发现 FORCED 位被设置了。ARM Cortex M4 文档提到，该位表示强制硬故障，由可配置优先级的故障升级产生，由于优先级或被禁用而无法处理。当该位设置为 1 时，HardFault 处理程序必须读取其他故障状态寄存器来查找故障原因。我们检查了其他故障寄存器，发现 ARM Cortex M4 处理器的系统控制块中的可配置故障状态寄存器（总线故障状态寄存器）中的 IMPRECISERR 位被设置。根据 ARM Cortex M4 文档，如果设置了此位，则发生数据总线错误，但堆栈帧中的返回地址与导致错误的指令无关。当处理器将此位设置为 1 时，它不会将故障地址写入 BFAR。所以这就解释了为什么我们没有按照 Erich 的指示找到导致硬故障的指令。此外，这是一个异步错误。因此，如果检测到当前进程的优先级高于 BusFault 优先级，则 BusFault 变为待处理状态，并且只有当处理器从所有更高优先级的进程返回时才会变为活动状态。 Cortex M4 处理器具有写入缓冲区功能，当对可缓冲内存区域进行写入时，处理器可以在传输完成之前继续执行下一条指令。这对于性能来说非常好，但可能会导致调试不精确的总线故障时出现一些复杂性。 通过更好地研究文档，我们发现 ARM Cortex M4 辅助控制寄存器中的 DISDEFWBUF 位在设置为 1 时会禁用默认内存映射访问期间的写入缓冲区使用。这会导致所有 BusFault 都成为精确的 BusFault，但会降低性能，因为任何存储到内存的操作都必须在处理器执行下一条指令之前完成。这样，处理器将不会继续执行下一条指令，直到写入操作完成，因此启用该位并使用 Erich 的代码，保存的 PC 指向导致硬故障的指令。 在其他情况下，如果总线故障是由中断处理程序中执行的指令触发的，且其优先级高于总线故障处理程序，则设置 DISDEFWBUF 在调试过程中很有用，因为即使出现精确错误，BFAR 寄存器值仍然有效。

DwF MCUおよびオートモーティブソリューション - Tianan - 2015-03-19 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 自動車およびコネクテッドカー 車載用マイクロコントローラの概要 : KinetisおよびS12 MagniVミックスド・シグナル・マイクロコントローラを含む BCCおよび高圧センサを搭載した車載用アナログおよびセンサの概要 インサイトとイノベーション Kinetisマイクロコントローラの概要 - Kinetisの性能上の利点とアプリケーション 設計、ソフトウェア、サービス フリースケールMQX™ RTOSの概要 ARM®プロセッサ キネティスCortex®-Mマイクロコントローラー センサ ソフトウェアとツール

汽车模拟和传感器概述，包括 BCC 和高压传感器 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日，天安 MCU 和汽车解决方案大会 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日，天安 MCU 和汽车解决方案大会 传感器

LS1043ARDB - How to update DPAA1 FMan microcode (ucode) image on SD card Follow these steps to update the DPAA1 FMan ucode image on the SD card.  Obtaining DPAA1 FMan ucode image Clone the qoriq-fm-ucode repository. $ git clone https://github.com/NXP/qoriq-fm-ucode.git $ cd qoriq-fm-ucode $ git checkout LSDK- . For example, $ git checkout LSDK-19.06 The prebuilt FMan ucode images, fsl_fman_ucode_ls1043_r1.1_ .bin , are at qoriq-fm-ucode/. In the binary file, ls1043_r1.1 refers to the LS1043A silicon revision 1.1. See qoriq-fm-ucode/readme for a description of the ucode version numbers. SD card start block number for DPAA1 FMan ucode image Image  SD card start block number DPAA1 FMan ucode image 0x04800 = 18432 Refer Flash layout for new boot flow with TF-A for complete listing of the SD card start block numbers for all LSDK firmware images. Programming DPAA1 FMan ucode image to SD card Option 1: Load image on SD card plugged into Linux host via dd command Plug the SD card into the Linux host. Run the following command on the Linux host: $ sudo dd if=fsl_fman_ucode_ls1043_r1.1_ .bin  of=/dev/sdX bs=512 seek=18432 conv=fsync Use the command cat /proc/partitions to see a list of devices and their sizes to make sure that the correct device names have been chosen. The SDHC storage drive in the Linux PC is detected as /dev/sdX, where X is a letter such as a, b, c. Make sure to choose the correct device name, because data on this device will be replaced. If your Linux host machine supports read/write SDHC card directly without an extra SDHC card reader device, the device name of SDHC card is typically mmcblk0.                                                   Remove the SD card from the Linux host machine. Plug the SD card into LS1043ARDB and boot the board to Ubuntu using the SD card. You can boot the board using the SD card either by: setting the switches: SW3[1:8] = 10110011, SW4 [1:8] =00100000 , SW5 [1:8] = 00100010, or boot switching to SD card => cpld reset sd In boot log, you’ll see: Board: LS1043ARDB, boot from SD You can check the following code line in the boot log to confirm that the DPAA1 FMan ucode image on the SD card is updated. Fman1: Uploading microcode version 106.4.18 If U-Boot does not find LSDK on the SD card, it will boot TinyDistro from lsdk_linux_arm64_tiny.itb stored on the SD card. Option 2: Load image on SD card plugged into board from the TFTP server Boot LS1043ARDB from NOR flash. Ensure that the switches are set to boot the board from NOR bank 0. For booting from NOR bank 0, switch settings are as follows: SW3[1:8] = 10110011 SW4[1:8] = 00010010 SW5[1:8] = 10100010 Boot from NOR bank 0: => cpld reset For LS1043ARDB, in boot log, you'll see: Board: LS1043ARDB, boot from vBank 0 Set up Ethernet connection When board boots up, U-Boot prints a list of enabled Ethernet interfaces. FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3 [PRIME], FM1@DTSEC4, FM1@DTSEC5 Set server IP address to the IP address of the host machine on which you have configured the TFTP server.  => setenv serverip Set ethact and ethprime as the Ethernet interface connected to the TFTP server. See LS1043ARDB Ethernet and FMC port mapping for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux.                        => setenv ethprime For example: => setenv ethprime FM1@DTSEC4 => setenv ethact For example: => setenv ethact FM1@DTSEC4 Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr => setenv netmask Dynamic IP address assignment: => dhcp Save the settings. => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using FM1@DTSEC4 device host 192.168.1.1 is alive Load FMan ucode image from the TFTP server Flash the FMan ucode image: => tftp 0xa0000000 fsl_fman_ucode_ls1043_r1.1_ .bin Program the FMan ucode image to SD card: => mmc write 0xa0000000 0x04800  Address  0x04800 is the SD card block number for the FMan ucode image.  ReferFlash layout for new boot flow with TF-A for the complete flash memory layout. Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load FMan ucode from the TFTP server, if the bytes transferred is 37560 (92b8 hex), then blk_cnt is calculated as "37560/512 = 73 (49 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 5 (5 hex) sectors, for this example, mmc write command will be: => mmc write 0xa0000000 0x04800 4E You can boot the board using the SD card either by: setting the switches: SW3[1:8] = 10110011, SW4 [1:8] =00100000 , SW5 [1:8] = 00100010, or boot switching to SD card => cpld reset sd In boot log, you’ll see: Board: LS1043ARDB, boot from SD You can check the following code line in the boot log to confirm that the DPAA1 FMan ucode image on the SD card is updated. Fman1: Uploading microcode version 106.4.18 If U-Boot does not find LSDK on the SD card, it will boot TinyDistro from lsdk_linux_arm64_tiny.itb stored on the SD card. QorIQ LS1 Devices Re: LS1043ARDB - How to update DPAA1 FMan microcode (ucode) image on SD card I think it will be good to have also a section where you show how we write the sd card from u-boot in case we do not have a card reader on the host

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

How to do NAN test on 2 IW612 modules with I.MX93-EVK What is NAN? Neighbor Awareness Networking (NAN), also known as Wi-Fi Aware, is a mechanism defined by the Wi-Fi Alliance. NAN is an additional Wi-Fi interface to micro-AP (uAP), Station (STA), and Wi-Fi direct (wfd) that allows for quick discovery without the connection-association flow. The interface named: nan0.In this demo test, NAN is used to Wi-Fi locate and/or range. NXP Wi-Fi Products Supports NAN: Currently we have our IW612, IW611,AW611 and AW693 support NAN feature on Linux OS, and the remote devices should also be Linux OS or Android OS. Currently we do not support for remote device which running iOS. Below is the Release Notes showing which product in our NXP supports NAN feature. https://github.com/nxp-imx/mwifiex/blob/doc_WCT_release/doc/Release_Notes/Linux_RN/topics/wi_fi_radio.md Caution: There is typo in above release note. Actually IW610 doesn't support NAN feature. Demo setup: In this doc, the test is based on 2 IW612 module: Murata 2EL M.2 module on I.MX93-EVK which is running Linux OS, the Linux kernel is L6.12.49. IW612's driver and FW version is: SDIW612---18.99.8.p3--MM6X18542.p8-(FP92), and the nanapp in this release could not outout wls message, official working nanapp will be in next release, available in the end of March/2026. wifi_mod_para.conf SDIW612 = { cfg80211_wext=0xf max_vir_bss=1 cal_data_cfg=none ps_mode=2 auto_ds=2 host_mlme=1 drv_mode=0x17 fw_name=nxp/sduart_nw61x_v1.bin.se } Copy correct version's nanapp and mlanutl and mlanwls to 2 boards, and add execute permission. root@imx93evk:~# chmod +x nanapp root@imx93evk:~# chmod +x mlanutl root@imx93evk:~# chmod +x mlanwls Copy correct FWand driver: mlan.ko + moal.ko(Cross compiled with L6.12.49 linux kernel BSP, not included in this doc). After the I.MX93-EVK board boot up, need to unload the default L6.12.49's Wi-Fi driver, then load the newer L6.18.2 Wi-Fi driver and FW. The whole process is shown as follow: The generated wls_leader.log and wls_follower.log files contain location information. The Wireshark sniffer contains NAN-related packets. Please see attached .pdf file for more detailed steps and logs outputs. How to configure to use Wireshark capture Sniffer logs On Ubuntu PC 24.04.2 LTS? Below is the commands for your reference. sudo iw dev //Check your Wi-Fi card name. Here is:wlp111s0 for me. sudo ifconfig wlp111s0 down sudo systemctl stop NetworkManager sudo killall wpa_supplicant //Here need to stop NetworkManager and wpa_supplicant, otherwise, after we configure wlp111s0 into monitor mode, these 2 service will automatically change it to managed mode. sudo iwconfig wlp111s0 mode monitor //set wlp111s0 into monitor mode sudo iwconfig //check whether set into monitor mode successfully. Here should show Mode:monitor sudo wireshark //Need to use sudo permission to run Wireshark, otherwise, could not use Wireshark to capture sniffer. Then choose wlp111s0 to capture sniffer. Reference link: Neighbor Awareness Networking (NAN) -Application note (confidential) https://github.com/nxp-imx/mwifiex/blob/doc_WCT_release/doc/Release_Notes/Linux_RN/topics/wi_fi_radio.md Best regards, Christine.

起動中にUSBデバイスが認識されない 私はIMX8M Plusプロセッサーを使っています。ファームウェアをUSBからダウンロードするために、ブート構成を0001に設定しました。 これは今回初めて電源を入れるカスタムボードです。 これはuuuツールのログです。 PS C:\NXP\UUU> .\uuu.exe -lsusb NXP IMXチップ用uuu（Universal Update Utility）-- libuuu_1.5.243-0-g230f1b1 コネクテッド既知のUSBデバイス Path Chip Pro vid pid bcdバージョンSerial_no ==================================================================== また、JTAGを接続することもできません。 TDOピンは常時ハイレベルです。 IMX8MPLUS @support @ritesh Re: Not Getting USB Device during Boot 問題は解決しました。 VDD_PLL_ANA_1V8ネットに電源が供給されていないことがわかりました。 @Zhiming_Liuさん、ご回答ありがとうございます。 Re: Not Getting USB Device during Boot こんにちは、 uuu -lsusb に「既知の USB デバイス」が表示されない場合、i.MX8M Plus が ROM シリアルダウンローダーまたは USB SDP モードに正常に移行していないか、USB OTG デバイスが PC によって正しく列挙されていないことを示しています。 JTAG経由での接続ができない、TDO信号がハイのままになっているといった状況から、これは初期段階のボードレベルの起動問題であると考えられます。SoCがリセットを正しく解除していない、重要な電源やクロックに異常がある、ブートモードストラップが正しくサンプリングされていない、あるいはJTAG/USB関連のピンへの接続や電源供給に問題があるなどが考えられます。 よろしくお願いします、 志明

SPI Underrun Hello: I am using the SPI of S32K312 as a slave to communicate with external devices, in the actual test I found that it works fine when the SPI bus is 5MHZ, but because of the demand I need the SPI to communicate at 10MHZ rate, the test found that the trigger event of SPI is LPSPI_IP_EVENT_FAULT and the SPI is configured for DMA, I have set the DMA in the void Lpspi_Ip_IrqTxDmaHandler(uint8 Instance). void Lpspi_Ip_IrqRxDmaHandler(uint8 Instance);Interrupt point observation to SR register for observation. Found out that triggering RX first at this point SR = 6914, after that it will return to the callback function I registered, then triggering TX at this point SR = 3; By checking the datasheet I found out that an SPI underflow and FIFO overflow problem occurs when triggering the RX. I have run the slave's asynchronous transceiver program Lpspi_Ip_AsyncTransmit before the host initiates the communication, I would like to know why and how this problem occurs, and how I can optimize it hope to get some suggestions. Attached is my SPI configuration. Re: SPI Underrun Hello @siyuanzhengwei, What do you mean by this statement: "Without monitoring the slave device's SPI interrupt trigger events, the master device can receive the correct data sent by the slave device." TX underrun (SR[TEF]) is set only when the master starts the transfer while the slave TX FIFO does not contain valid data, i.e. the driver or DMA did not write the next data word in time. There is no other condition under which this flag is set. Therefore, this error cannot be explained by SPI signal quality; it indicates that the slave transmit path was not serviced early enough before or during the transfer. BR, Daniel Re: SPI Underrun Hello: I roughly say the workflow, MCU slave will start the first reception after power on, the external master device sends about 15ms to initiate a communication, after that the slave will be based on the information received to parse and send the corresponding data, in the not pay attention to the slave SPI interrupt triggering event, the host is able to receive the correct data sent by the slave. There is about 10ms from the first time the slave calls Lpspi_Ip_AsyncTransmit to the time the host initiates the communication, and the SPI error occurs not after a period of time, but the first time the communication is faulty. I call the slave's Lpspi_Ip_AsyncTransmit every 2ms through a timer, 10ms should be enough time to prepare the data, but every SPI trigger event is FAULT, I have used a logic analyzer to check the waveform of the data, and I can observe the correct send/receive data, but through the oscilloscope to observe the quality of the signal is not good and not a smooth square wave. The signal quality is not very good and not a smooth square wave, is it possible that this is also related to the signal quality? Re: SPI Underrun Hi @siyuanzhengwei, The return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS because this is an asynchronous transfer (it only indicates that the transfer was started, not completed). The key issue is the TX underrun (SR[TEF]). This means the slave did not have data available in the TX FIFO when the master started clocking. In SPI slave mode, the TX FIFO must be populated before the master asserts CS and starts the transfer.  The RTD drivers introduce some overhead, and starting the transfer on the slave side takes time. As a result, Lpspi_Ip_AsyncTransmit is called too late and the first data words are not ready in time. Do you monitor the TX line with an oscilloscope? What do you measure there? Regards, Daniel Re: SPI Underrun One more piece of information to add; although the SPI trigger event is LPSPI_IP_EVENT_FAULT, the return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS, the LpspiHwStatus is LPSPI_IP_BUSY, and the received data again is correct.