NXP基于模型的S32M2xx设计工具箱——版本1.0.0 产品发布公告 汽车处理 恩智浦基于模型的设计工具箱 适用于 S32M2xx – 版本 1.0.0树脂经延展 恩智浦半导体汽车处理基于模型的设计工具团队很高兴地宣布发布适用于 S32M2xx 版本 1.0.0 的基于模型的设计工具箱。此版本支持从 MATLAB/Simulink 为 NXP S32M2xx 汽车微处理器自动生成 S32M2xx 外设的代码和应用程序原型。该新产品基于 RTD MCAL 组件（ADC、AE、DIO、CAN、DPGA、GDU、GPT、MCL、PWM、MCU、PORT、QDEC、UART）增加了对 S32M41、S32M242、S32M43、S32M244、S32M274、S32M276 MCU 及其部分外设的支持。在此版本中，我们还添加了对 FreeMASTER、AMMCLib 和 MATLAB 最新版本的支持。该产品附带 60 多个示例，涵盖所有支持的外设，以及 Simulink 仿真模式软件在环、处理器在环和外部模式。 目标受众： 该产品是汽车软件 - S32M2 标准软件包的一部分。 FlexNet 位置： https://nxp.flexnetoperations.com/control/frse/download?element=3785898 技术支持： 针对 S32M2xx 问题的 NXP 基于模型的设计工具箱将通过 NXP 基于模型的设计工具社区空间进行跟踪。 https://community.nxp.com/community/mbdt     版本内容 针对 NXP S32M2xx 衍生产品，从 MATLAB ®自动生成 C 代码： S32M241 S32M242 S32M243 S32M244 S32M274 S32M276 支持以下外设（MCAL 组件）： ADC AE DIO CAN DPGA GDU GPT MCL PWM MCU PORT QDEC UART 提供两种操作模式： 基础模式——使用外设的预配置配置；适用于快速硬件评估和测试 高级——使用 S32 配置工具或 EB Tresos 配置外设/引脚/时钟 集成汽车数学和电机控制库版本 1.1.34： 汽车数学和电机控制函数库v1.1.34 中的所有函数作为模拟和嵌入式目标代码生成的块来支持。 与 FreeMASTER 集成 我们提供了多个 Simulink 示例模型和相关的 FreeMASTER 项目，以演示我们的工具箱如何与实时数据可视化工具交互，以及如何用于调整嵌入式软件应用。 支持 MATLAB ®版本 R2021a R2021b R2022a R2022b R2023a R2023b 支持自定义板初始化 Toolbox 按照 Board Initialization 窗口中的配置生成组件的外围设备初始化函数调用，这些函数调用可以根据每个 Simulink 模型进行定制。此功能允许用户为组件初始化、自定义代码序列的插入设置自定义顺序，或通过导出和导入功能与多个 Simulink 模型共享自定义初始化。     支持自定义默认项目配置 该工具箱为用户创建自定义默认项目配置提供支持。这在定制电路板设计时非常有用——只需要创建一次硬件配置。将其保存为自定义默认项目后，它可以用于正在开发的每个模型。 与S32配置工具版本v1.7集成：     与 S32 Design Studio 集成 该工具箱会自动在 Simulink 模型位置旁边生成 _Config 文件夹，让用户可以轻松地将 Simulink 生成的代码导入 S32 Design Studio。每次生成代码时， _Config 文件夹都会根据新的更改进行更新。该工具箱还提供了一种启动 S32 Design Studio 实例的机制，并在 S32DS 的 Project Explorer 选项卡中导入生成的代码项目。 仿真模式： 我们支持以下仿真模式（每种模式均有助于验证和确认）： 软件在环 (SIL) 处理器在环 (PIL) 外部模式 支持 PIL 模式下的分析： 每个受支持的外设/功能的示例： 我们添加了60 多个示例，包括： CDD 块（Ae、Dpga、Gdu、Mcl、Qdec） 通信（CAN、UART） AMMCLib IO Blocks (Adc, Dio, Pwm) ISR 块（硬件中断处理程序） MCAL 块（Gpt） 实用程序块（FreeMASTER） 软件在环/处理器在环/外部模式 有关更多详细信息、功能以及如何使用新功能，请参阅随附的《版本说明》文档。   MATLAB® 集成 NXP 基于模型的设计工具箱扩展了 MATLAB ®和 Simulink ®体验，允许客户评估和使用 NXP 的 S32M2xx MCU 和开箱即用的评估板解决方案： 基于模型的设计工具箱 S32M2xx 版本 1.0.0在安装方面与 MATLAB ®环境完全集成：   目标受众 此版本（1.0.0）旨在用于技术演示、评估目的以及 S32M2xx MCU 和评估板的原型设计。   有用的资源 示例、培训和支持： https://community.nxp.com/community/mbdt 回复：基于 NXP 模型的 S32M2xx 设计工具箱 - 版本 1.0.0 当我点击以下“转到 NXP 下载站点”按钮时： 它将我重定向到以下页面： 您能提供我可以下载 S32M2xx 基于模型的设计工具箱的位置吗？ 回复：基于 NXP 模型的 S32M2xx 设计工具箱 - 版本 1.0.0 S32M2，不带外部升压电源吗？ 回复： NXP 基于模型的设计工具箱（适用于 S32M2xx）– 版本 1.0.0 当我点击这个 Matlab 脚本上的链接时，我仍然找不到正确的 URL。 回复： NXP 基于模型的设计工具箱（适用于 S32M2xx）– 版本 1.0.0 你好，我也遇到了同样的问题。点击这个链接https://nxp.flexnetoperations.com/control/frse/download?element=3785898还是会跳转到账户信息界面，我找不到正确的网址。而且，在此之前我已经登录过我自己的账户。 首先，我点击这个链接： 然后， 结果是无法重定向正确的 URL。 回复：基于 NXP 模型的 S32M2xx 设计工具箱 - 版本 1.0.0 你好@SmallWhite ， 发布后我们需要花一点时间来更新 NXP.com 网站上的所有文档。FlexNET 位置网址上提供了适用于 S32M2xx 的 MBDT 的发行说明以及快速入门指南：此处： https://nxp.flexnetoperations.com/control/frse/download ?element=3785898 请在访问此链接之前登录 NXP.COM。 回复： NXP 基于模型的设计工具箱（适用于 S32M2xx）– 版本 1.0.0 当我点击这段文字中的网址时，我总是会重定向到我的个人页面，而无法转到真正的网址。 我想知道是否有类似的 s32m244 快速参考指南？

罐头连接 Hi , 我有一块 IMX6 ULL evk 板。我的理解是它具有 CAN 功能。 有人可以告诉我将 DB-9 连接器连接到电路板的连接器吗？另外，如果盒子附带的基本图像启用了 CAN，如果没有，如何启用它。 提前致谢， 阿苏尔 i.MX6UL 回复：CAN 连接 Hello,  如果您要查找确切的零件编号，则是 WF1250801200，但它似乎已不再生产。 您可以参考此链接查看9 针 D 型连接器的引脚排列。 顺祝商祺！ Salas. 回复：CAN 连接 Hi @Manuel_Salas , 如果您不能给我提供连接器。您能告诉我8针端口中每个针脚的用途吗？例如 CAN0_H 代表哪个引脚、CAN0_L 代表哪个引脚等等。 谢谢！ 阿苏尔 回复：CAN 连接 Hi @Manuel_Salas , 谢谢您的回复。我希望使用连接器将 imx6ull 板端口连接到 DB-9 连接器，因为电路板的包装中没有附带连接器。 提前感谢！ 阿苏尔 回复：CAN 连接 你好@athul_am 所有 i.MX 6 均支持一个 CAN，并在 i.MX 6SABRE-AI 上使用默认设备树。支持使用 FlexCAN 设备树的两种 CAN，但与 FEC 存在引脚冲突。支持 i.MX 6SoloX-SD、7Dual SABRE-SD、6Ultre Lite EVK 和 6ULL EVK 上的默认设备树。通过支持FlexCAN模块的平台，FlexCAN支持CANFD模式。 您还可以查看表格 42。IMX 参考手册上的 FlexCAN 驱动程序文件。 此外，i.MX6ULL 通过 J1201 端口提供 CAN 访问。 顺祝商祺！ Salas.

bossac_windows.zip <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 适用于 UDOO 的 Arduino IDE 补丁 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 适用于 UDOO 的 Arduino IDE 补丁 研讨会文件

Freescale's commonly used offline programming tools <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1. CycloneMAX, Support Kinetis, ColdFire V2/V3/V4, Power MPC5xx/8xx, Qorivva MPC5xxx, DSC, MAC7xxx PE Micro, http://www.pemicro.com/ 2. Flasher ARM Supports the full range of ARM cores, including the traditional ARM7, ARM9 and ARM11, as well as the new Cortex-A, Cortex-M and Cortex-R series, and can power the target board.    Segger, SEGGER - The Embedded Experts - Flasher ARM 3. Flasher Portable Supports the full range of ARM cores, including the traditional ARM7, ARM9 and ARM11, as well as the new Cortex-A, Cortex-M and Cortex-R series, battery-powered, portable programmer.    Segger, SEGGER - The Embedded Experts-Flaser Portable 4. SmartPRO Supports Kinetis, S12, S12X, ColdFireV2. Zhou Ligong, http://www.zlgmcu.com/ 5. MCP-104    支持飞思卡尔ARM based Microcontroller Kinetis.    祥佑科技(Micetek), http://www.micetek.com 6.Xeltek programmer, http://www.xeltek.com 7. Hilo programmer, http://www.hilosystems.com.tw Kinetis Hardware Support

LS1043ARDB - 如何在 SD 卡上部署 TF-A 二进制文件 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Cortex-A 可信固件 (TF-A) 是 EL3 安全固件的一个实现。TF-A 在安全固件中取代了 PPA 的角色。 请注意，本主题中列出的步骤只能使用LSDK 18.12 及更新版本执行。                                                      要从之前的启动流程（带PPA）迁移到TF-A启动流程，您需要编译TF-A二进制文件，bl2_ . pbl和fip.bin，并将这些二进制文件刷写到主板上的特定启动介质上。 对于 SD 启动，您需要编译以下 TF-A 二进制文件。 TF-A 二进制名称 组件 bl2_sd.pbl BL2 二进制：平台初始化二进制 用于 SD 启动的 RCW 二进制文件 fip.bin BL31：安全运行时固件 BL32：可信操作系统，例如OPTEE（可选） BL33：U-Boot/UEFI 镜像 按照以下步骤编译和部署 TF-A 二进制文件( bl2_sd.pbl 和 SD 卡上有 一个名为 fip.bin 的文件 。 从 RCW 源文件编译 PBL 二进制文件 编译 U-Boot 二进制文件 [可选] 编译 OPTEE 二进制文件 编译 TF- A 二进制文件( bl2_sd.pbl 和 fip.bin） 用于 SD 启动 将 TF-A 二进制文件烧录到 SD 卡 第 1 步：从 RCW 源文件编译 PBL 二进制文件 您需要编译rcw_1600_sdboot.bin二进制文件来构建bl2_sd.pbl二进制文件。 克隆rcw仓库并编译 PBL 二进制文件。 $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/rcw $ cd rcw $ git checkout -b   . 例如，$ git checkout -b LSDK-19.03 LSDK-19.03  $ cd ls1043ardb 如果需要，请对 rcw 文件进行更改。 $ make 适用于LS1043ARDB 上的 SD 启动的已编译 PBL 二进制文件rcw_1600_sdboot.bin可在rcw/ls1043ardb/RR_FQPP_1455/中找到。  请参阅 rcw/ls1043ardb/README 文件，了解包含 RCW 源代码和二进制文件的目录命名规范。 步骤 2：编译 U-Boot 二进制文件 您需要编译u-boot.bin二进制文件以构建 fip.bin二进制文件。 克隆 u-boot 仓库，并为 TF-A 编译 U-Boot 二进制文件。 $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git $ cd u-boot $ git checkout -b LSDK- . 例如， $ git checkout -b LSDK-19.03 LSDK-19.03 $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ make distclean $ make ls1043ardb_tfa_defconfig $ make 如果make命令显示错误 “*** 您的 GCC 版本早于 6.0 且不受支持” ，请确保您使用 Ubuntu 18.04 64 位版本来构建 LSDK 18.12 U-Boot 二进制文件。                                                      编译后的 U-Boot 二进制文件u-boot.bin，可在 u-boot/目录中找到。 第三步：[可选]编译OPTEE二进制文件 要使用OPTEE生成FIP.bin， 您需要编译tee.bin二进制文档。不过，OPTEE是可选的， 如果您想在不使用OPTEE的情况下编译FIP二进制文档， 可以跳过编译OPTEE的步骤。 克隆optee_os存储库并构建OPTEE二进制文件。 $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/optee_os $ cd optee_os $ git checkout -b LSDK-. . 例如， $ git checkout -b LSDK-19.03 LSDK-19.03 $ export ARCH=arm $ export CROSS_COMPILE=aarch64-linux-gnu- $ make CFG_ARM64_core=y PLATFORM=ls-ls1043ardb $ aarch64-linux-gnu-objcopy -v -O binary out/arm-plat-ls/core/tee.elf out/arm-plat-ls/core/tee.bin 编译后的OPTEE镜像tee.bin可在 optee_os/out/arm-plat-ls/core/处获取。 步骤 4：编译 TF-A 二进制文件以进行 SD 启动 克隆 atf 存储库并编译 TF-A 二进制 文件 bl2_sd.pbl 和 fip.bin 。 $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/atf $ cd atf $ git checkout -b LSDK-. 例如， $ git checkout -b LSDK-19.03 LSDK-19.03 $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- Build BL2 binary with OPTEE. $ make PLAT=ls1043ardb bl2 SPD=opteed BOOT_MODE=sd BL32= / tee.bin pbl RCW= /rcw_1600_sdboot.bin 编译后的 BL2 映像bl2.bin和bl2_sd.pbl可在atf/build/ls1043ardb/release/处找到。 对于 BL2 源代码或 RCW 二进制文件的任何更新，都需要重新编译bl2_sd.pbl二进制文件。 在没有OPTEE的情况下编译BL2二进制文件： $ make PLAT=ls1043ardb bl2 BOOT_MODE=sd pbl RCW= / rcw_1600_sdboot.bin                  使用OPTEE构建FIP二进制文件 ，无需可信板启动。 $ make PLAT=ls1043ardb fip BL33= /u-boot.bin SPD=opteed BL32= /tee.bin 编译后的 BL31 和 FIP 二进制文件，bl31.bin，fip.bin，可在 atf/build/ls1043ardb/release/ 获取。 对于 BL31、BL32 或 BL33 二进制文件的任何更新，需要重新编译 fip.bin二进制文件。 要编译不包含OPTEE且不依赖可信板启动的FIP 二进制文件： $ make PLAT=ls1043ardb fip BOOT_MODE=sd BL33= / u-boot.bin 要编译带有可信板启动的 FIP 二进制文件，请参阅 /plat/nxp/README.TRUSTED_BOOT 中的说明                               步骤 5：将 TF-A 二进制文件烧录到 SD 卡 引导 LS1043ARDB从 NOR 闪存启动。确保开关设置为从 NOR 组 0 启动。从 NOR bank 0 ，开关设置如下： SW3[1:8] = 10110011 SW4[1:8] = 00010010 SW5[1:8] = 10100010 从 NOR bank 0 启动：=> cpld reset 对于 LS1043ARDB，在启动日志中，您会看到： 板：LS1043ARDB，从vBank 0启动   设置以太网连接 主板启动后，U-Boot 会打印出已启用的以太网接口列表。 FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3 [PRIME], FM1@DTSEC4, FM1@DTSEC5 将服务器 IP 地址设置为您已配置 TFTP 服务器的主机的 IP 地址。 => setenv serverip 将ethact和ethprime设置为连接到 TFTP 服务器的以太网接口。 请参阅 LS1043ARDB Ethernet 和 FMC 端口映射 ，以了解机箱前面板上显示的以太网端口名称与 U-Boot 和 Linux 中端口名称的映射。                                                   => setenv ethprime 例如： => setenv ethprime FM1@DTSEC4 => setenv ethact 例如： => setenv ethact FM1@DTSEC4 设置电路板的IP地址。您可以设置静态IP地址，或者如果主板可以连接到DHCP服务器，您可以使用 dhcp 命令。 静态 IP 地址分配： => setenv ipaddr => setenv netmask 动态 IP 地址分配： => dhcp 保存设置。 =>  saveenv 检查电路板与 TFTP 服务器之间的连接。 => ping $serverip 使用 FM1@DTSEC4 设备 主机 192.168.1.1 是活跃的。   从TFTP服务器加载TF-A二进制文件 有关 TF-A 二进制文件的闪存映像布局的详细信息，请参阅LSDK 启动流程的内存布局。                               Flash bl2_sd.pbl: => tftp 82000000 bl2_sd.pbl => mmc 写入 82000000 8 此处，blk_cnt指的是根据文件大小需要在SD卡上写入的块数量。 例如，当您从 TFTP 服务器加载bl2_sd.pbl时，如果传输的字节数为82809（十六进制 14379） ，则blk_cnt 的计算方式为“ 82809/512 = 161（十六进制 A1）”+“用于向上舍入的几个扇区，以免遗漏最后一个块” 。因此，如果您按 10（A 十六进制）扇区向上舍入，则对于此示例，mmc 写入命令将为： => mmc write 82000000 8 AB Flash fip.bin: => tftp 82000000 fip.bin => mmc 写入 82000000 800 此处，blk_cnt 指的是根据文件大小需要在 SD 卡上写入的块数量。 例如，当您从 TFTP 服务器加载fip.bin时，如果传输的字节数为1077157（十六进制 106fa5） ，则blk_cnt 计算公式为“ 1077157 / 512 = 2103（837 十六进制）” + “用于向上舍入的几个扇区，以免遗漏最后一个块” 。因此，如果您按 10（A 十六进制）扇区向上舍入，则在此示例中，mmc write 命令将为：=> mmc write 82000000 800 841 从 SD 卡 启动 ： => cpld reset sd LS1043ARDB 将使用 TF-A 启动。在启动日志中，您将看到： 注意：已修复主板上的 DDR 注意：2 GB DDR4，32 位，CL=11，ECC 关闭 注意：BL2：v1.5（发布）：LSDK-19.03 通知：BL2：建造时间：2019年5月28日 14:59:48 注意：BL31：v1.5（发布）：LSDK-19.03 通知：BL31：建造时间：2019年5月28日 15:07:21 通知：欢迎来到 LS1043 BL31 阶段 U-Boot 2018.09（2019 年 5 月 23 日 - 14:35:16 +0530） SoC：LS1043AE Rev1.1（0x87920011） 时钟配置： CPU0(A53):1600 MHz CPU1(A53):1600 MHz CPU2(A53):1600 MHz CPU3(A53)：1600 MHz 总线：400 MHz DDR：1600 MT/s FMAN：500 MHz 复位配置字（RCW）： 00000000: 08100010 0a000000 00000000 00000000 00000010: 14550002 80004012 60040000 c1002000 00000020: 00000000 00000000 00000000 00038800 00000030: 00000000 00001100 00000096 00000001 型号：LS1043A RDB板 主板：LS1043ARDB，从 SD 启动 QorIQ LS1设备

NXP 电池管理系统基于模型的设计工具箱 - 版本 1.0.0EAR 产品发布公告 汽车处理 恩智浦基于模型的设计工具箱 适用于 BMS - 版本 1.0.0 EAREAR NXP 半导体汽车处理器与基于模型的设计工具团队欣然发布 BMS 基于模型的设计工具箱 1.0.0 EAR 版本。此版本是 NXP S32K3xx 1.4.0 基于模型设计工具箱的附加组件，支持从 MATLAB/Simulink 自动生成电池单元控制器和应用程序原型。该新产品基于 BMS SDK 组件（Bcc_772c、Bcc_772c_SL、Bcc_775a、Bms_TPL3_SL_E2E、Bms_common、Phy_665a），新增对 MC33775A、MC33772C、MC33665A 电池控制器及其部分外设的支持。在此版本中，我们已添加了与 S32K3xx 基于模型的设计工具箱 1.4.0 的集成,新增对 BMS SDK 1.0.1 的支持，并提供对 MATLAB 最新版本的兼容支持。产品内置针对 NXP 高压 BMS 参考设计板的电池控制器应用示例。 目标受众： 该产品是汽车 SW（基于模型的设计工具箱）的一部分。 FlexNet 位置： https://nxp.flexnetoperations.com/control/frse/download?element=3720278 技术支持： 恩智浦电池管理系统（BMS）基于模型的设计工具箱相关问题将通过恩智浦基于模型设计工具社区空间进行跟踪。 https://community.nxp.com/community/mbdt 发布内容： 从MATLAB®自动生成C代码用于NXP电芯控制器衍生产品： MC33775A MC33772C MC33665A 支持以下外围设备（BMS SDK组件）： Bcc_775a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E 支持MC33775A和MC33772C电池单元控制器及MC33665PHY 该工具箱支持 MC33775A、MC33772C 和 MC33665。MC33775A 和 MC33772C 是专为汽车应用设计的锂离子电池单元控制器 IC，能够对电池单元的差分电压和电池温度进行 ADC 转换，而 MC33665 是一款收发器物理层变压器驱动器，设计用于通过高速隔离通信网络将微控制器与电池单元控制器连接。MBDT for S32K3 提供的现成示例展示了如何通过 MC33665 收发器在 S32K344、MC33775A 和 MC33772C 之间进行通信。对于MC33775A，示例展示了如何配置电池单元控制器以执行主链和次链转换，并从MC33775A读取电池单元电压转换结果。而对于MC33772C，示例展示了如何配置电池单元控制器以读取电流。所有转换后的值均通过FreeMASTER应用程序显示给用户。 支持的BMS SDK版本（1.0.1） 支持 MATLAB 版本 我们增加了对以下 MATLAB 版本的支持： R2021a R2021b R2022a R2022b R2023a 支持的功能示例： MC33775A 配置和数据采集示例 MC33772C 配置和数据采集示例 RD-HVBMSCTBUN 配置和数据采集示例 有关更多详细信息、功能以及如何使用新功能，请参阅随附的《版本说明》文档。 MATLAB ®积分： NXP基于模型设计工具箱扩展了MATLAB®和Simulink®的使用体验，使客户能够评估和使用NXP的电池单元控制器与S32K3xx微控制器及评估板解决方案，实现开箱即用： NXP Model-Based Design Toolbox for BMS 1.0.0 版在安装方面与 MATLAB® 环境完全集成：     目标受众： 此版本（1.0.0 EAR）旨在用于技术演示、评估目的，以及使用NXP电池单元控制器和S32K3xx微控制器及评估板进行电池管理系统的原型设计。 有用的资源： 示例、培训和支持： https://community.nxp.com/community/mbdt  

[802.11] Wi-Fi接続/切断プロセス 802.11 標準では、接続手順には、デバイスを Wi-Fi ネットワークの一部にし、ネットワーク内で通信するために実行する必要がある 3 つの主要な手順が含まれています。その3つのステップは、デバイスの検出(スキャン)、デバイス認証(接続前に互換性機能などを確認する)、そして最後に接続を確立する(関連付け)です。今後、この投稿では各ステップの詳細を提供します。接続手順でのメッセージのやり取りを以下に示します。   図 1.オープンシステムでの接続プロセス   図 2.接続プロセスでのメッセージ交換 図2は、接続時のクライアントとAPデバイス間のメッセージ交換手順のWi-Fiスニファログを示しています(ここでは、クライアントデバイスはXiaomi、APはMarvellデバイスです。 接続設定プロセス 1. スキャン ネットワークに参加するには、まずクライアントまたはステーションがネットワークを見つける必要があります。有線ネットワークでは、ケーブルまたはジャックを差し込むだけでネットワークが見つかります。ワイヤレスの世界では、参加プロセスを開始する前に、互換性のあるネットワークを特定する必要があります。このネットワークの識別プロセスは、 スキャンと呼ばれます。 スキャンプロセスにはいくつかのパラメータが必要です。これらのパラメータは、BSSType、BSSID、チャンネルリスト、スキャンタイプ、MinChannelTime、MaxChannelTimeです。パラメータは、メーカーのWi-Fiドライバに応じてデフォルトとして設定されますが、ユーザーが変更することができます、つまり、要件が非表示のネットワークの場合、アクティブスキャンは非表示のネットワーク(SSIDをブロードキャストしないネットワーク)には役立たないため、scantypeパラメータをパッシブスキャンとして設定できます。 スキャン方法には、パッシブスキャンとアクティブスキャンの2つがあります。 デフォルトでは、無線は、運用国で許可されているすべてのチャネルで両方のタイプのスキャンを実行します。デフォルトではどちらのタイプのスキャンも使用できますが、アクティブスキャンは、地域の政府の規制で送信が許可されているチャネルによってのみ実行されます。ライセンスなしの使用が許可されていないチャンネルは、アクティブスキャンから除外されます。 パッシブスキャン: パッシブスキャンでは、WLANステーションはチャネルリストに従って各チャネルに移動し、ビーコンフレームを待ちます。ビーコンフレームは、アクセスポイント(およびIBSSのステーション)が通信または自身をアナウンスするために使用されます。 アクセス ポイントは、Target Beacon Transmission Time(TBTT)と呼ばれる定義された間隔でビーコンの送信を試みます それにもかかわらず、アクセスポイントはセル内の他のワイヤレスデバイスと同じです。ネットワークがビジー状態の場合、送信できません。APがビーコンを送信する時間になり、ネットワークがビジー状態になると、APはメディアにアクセスできるようになるまでビーコンの送信を遅らせます。 802.11では、ネットワークがビジーかどうかはCSMA/CAプロトコルを使用して確認できます。CSMA/CA では、フレームの準備ができると、送信デバイスはチャネルがアイドル状態かビジー状態かを確認し、衝突を回避します。チャネルがビジー状態の場合、送信デバイスはランダムな時間待機し、チャネルがアイドル状態であるかどうかを再度確認します。チャネルがアイドル状態の場合は、フレームを送信します。ビーコンのフレーム構造は、以下の通りです。 図 3.ビーコンフレーム   ビーコンフレームの必須フィールドの説明。 タイムスタンプ:ビーコンフレームを受信した後、すべてのステーションはこのタイムスタンプでローカルクロックを更新します。これは同期に役立ちます。 ビーコン間隔: ターゲット ビーコン送信時間 (TBTT) 間の時間単位 (TU) の数を表します。デフォルト値は 100TU (102.4 ミリ秒) です。 機能情報:デバイス/ネットワークの機能に関する情報が含まれています SSID:ネットワークのサービスセットIDが含まれています。 サポートされているレート: このフィールドには、アクセスポイントでサポートされているデータレートの情報が含まれています。 この情報は、パッシブ スキャン中に潜在的なクライアントだけでなく、BSS に既に関連付けられているクライアントによっても使用されることに注意してください。 パッシブスキャンは、クライアントがビーコンをリッスンして待つ必要があるのに対し、APを見つけるためにアクティブにプローブするよりも、通常、より時間がかかります。パッシブ スキャンの別の制限は、クライアントがチャネルで十分な時間待機しない場合、クライアントが AP ビーコンを見逃す可能性があることです。 アクティブスキャン: 可能なすべてのチャネルをスキャンし、ビーコンをリッスンしてネットワークを検出することは、あまり効率的ではないと考えられています。この検出プロセスを強化するために、ステーションはアクティブスキャンと呼ばれるものを使用することがよくあります。 アクティブスキャンモードでは、ステーションは引き続き各チャネルを順番に通過しますが、APからの信号を受動的に聞く代わりに、ステーションはこのチャネルで利用可能なネットワークを尋ねることを目的としたプローブリクエスト管理フレームを送信します。IBSS 内の AP またはアクティブ ステーションがその周波数を示している場合は、プローブ応答フレームで応答する必要があります。   図 4. スキャン方法   プローブ要求が発信ステーションによって送信されると、プローブタイマーのカウントダウンが開始され、応答を待ちます。このプローブタイマーの値は、通常、ビーコン間隔よりもはるかに短くなります。一般的な値は 10 ミリ秒の範囲です。タイマーの終了時に、ステーションは受信した回答を処理します。応答が受信されなかった場合、ステーションは次のチャネル(異なる周波数)に移動し、同じ検出プロセスを繰り返します。 プローブ要求の目的は、通常、AP とそれがサポートするネットワーク (SSID や BSSID) を検出することです。 図 5. プローブ要求/応答フレーム このフレームには、主に SSID と移動局がサポートするレートの 2 つのフィールドが含まれています。プローブ要求を受信したステーションは、この情報を使用して、要求元のステーションがネットワークに参加できるかどうかを判断します。 プローブ応答フレームフィールドは、モバイルステーションがパラメータを一致させてネットワークに参加できるようにするビーコンフレームフィールドと非常によく似ています。   2. 認証 プローブ要求/プローブ応答交換、またはビーコンのリッスンによってネットワーク検出を実行した後、ネットワークに参加したいステーションは、アクセスポイントと認証フレームを交換する認証プロセスを通過します。認証フレームを受信すると、APは確認応答を送信し、次に認証応答を送信します。 「認証」フレームの最初の目的は、デバイス タイプを検証すること、つまり、要求元のステーションがネットワークに参加するための適切な 802.11 機能を持っていることを確認することです。 オープンシステム認証:機能に関連する情報は、認証リクエストを使用してステーションとAP間で交換されます。要求が受け入れられると、APは認証応答で「成功」を送信します。 共有キー認証:IEEE 802.11-1997標準には、「共有キー」と呼ばれるWEP共有キー交換認証メカニズムが含まれていました。この共有キー交換により、デフォルトのオープンシステム認証にさらに 2 つのフレームが追加され、4 フレームの交換が行われます。この後者の方法は共有キー認証と呼ばれ、WEP 暗号化の使用が必要であり、現在では広く使用されていません (また、推奨されません)。 認証の第 1 フェーズは上記で説明されていますが、WPA または WPA2 が使用されている場合は、認証の第 2 フェーズ (つまり、4-way handshakeing process) は、デバイスが関連付けられた後に行われます。 オープンシステム認証と共有鍵認証の詳細については、802.11 セキュリティの投稿 を参照してください。 図 6.認証フレーム 上記のように、認証フレームは次のフィールドで構成されています。 認証アルゴリズム番号: オープン システムの場合は 0、共有キーの場合は 1。 認証トランザクション シーケンス番号: 進行状況の現在の状態を示します。 ステータスコード: 成功の場合は 0、未指定の失敗の場合は 1。 Challenge Text: Shared Key Authentication frameで使用されます。 3. 協会 802.11 認証フェーズが成功の結果で完了すると、ステーションはアソシエーション フェーズに移行します。この交換の目的は、ステーションがネットワークに参加し、アソシエーションID[AID]を取得することです。 関連付けリクエスト: アソシエーション フェーズで送信される最初のフレームは、要求側ステーションから AP(または IBSS 内のステーション)に送信されます。このフレームはアソシエーション要求フレームであり、このフレームの応答はアソシエーション応答フレームです。 アソシエーション要求はユニキャスト管理フレームであり、常に確認応答されます。 図 7.関連付けリクエスト 関連付けの応答: アソシエーション要求が確認されると、AP は要求の各フィールドを調べ、それらがすべて自身の 802.11 パラメータと一致することを確認します(図 6 を参照)。パラメータが一致しない場合、APはその違いがブロッキングであるかどうかを確認し、それに基づいてAPが認証応答を送信します。 - パラメータの差がブロックされている場合は、ステータスコード 1 のレスポンスが送信されます (関連付けを拒否するため)。 - ノンブロッキング差分/パラメータに差分がない場合、ステータスコード0(成功)とAP独自のパラメータの応答がリクエストステーションに送信されます。ステーションは AP の機能と互換性がある必要があり、互換性がないと、関連付けプロセスが終了し、別の AP の検索が開始されます。 図 8.アソシエーションレスポンス 接続のティアダウン アソシエーション解除:ステーションがAPに関連付けられると、どちらの側もアソシエーション解除フレームを送信することで、いつでもアソシエーションを終了できます。 ステーションは、現在のネットワークを離れて別のAPをローミング/参加する前に、Disassociation frameを送信できます。 APは、ステーションが無効なパラメータを使用しようとした場合、AP自体が設定変更中、ハッカーの攻撃など、さまざまな場合にこのフレームを送信できます。 アソシエーション解除フレーム(DA)は、アソシエーションを解除するステーションのユニキャストMACアドレス、またはAPがネットワーク内のすべてのステーションのアソシエーションを解除する必要がある場合のブロードキャストアドレスです。ユニキャストフレームの場合、フレームは受信局によって確認され、ブロードキャストフレームは確認されません。 図 9.アソシエーション解除フレーム Disassociation フレームは非常に小さいです。これには、「理由コード」というフィールドが 1 つだけ含まれています。 関連付けが解除されたステーションは、引き続き認証されます。新しい Association リクエスト フレームを送信して、認証済みステータスを保持したまま、再関連付けを試みることができます。別のセルにローミングするステーションは、認証されたステータスを保持し、認証タイムアウトが期限切れになる前に同じセルに戻るときにプロセスを加速できるように、関連付け解除フレームを使用することも選択できます。   図 10.アソシエーション解除フレーム交換   このフレームは、パラメータが変更され、ステーションまたは AP が通信パラメータを再ネゴシエートする必要がある場合にも使用されます。   認証解除:ステーションまたは AP は、認証解除フレームを送信することもできます。このフレームは、AP の再起動が必要な場合や、ステーションが Wi-Fi 通信を停止した場合など、すべての通信が終了した場合に使用されます。 また、認証が完了する前にフレームを受信した場合にも使用されます。たとえば、認証シーケンスを実行する前にアソシエーション要求またはデータ フレームを送信しようとするステーションは、AP から認証解除フレームを受信し、認証を最初に実行する必要があることを示します。フレーム形式は、関連付け解除フレームと同じです。 図 11.認証解除フレーム交換   ローミング ローミングとは、802.11 ワイヤレス ネットワークのコンテキストでは、クライアントが確立された Wi-Fi ネットワークの関連付けを、接続を失うことなく、同じ拡張サービス セット (ESS) 内の 1 つのアクセス ポイントから別のアクセス ポイントに移動するプロセスです (例:定義された時間間隔内、通常は数秒の範囲)。パフォーマンスを向上させるには、ローミング時間を短くする必要があります。 ローミング プロセスでは、モバイル デバイスは関連付け解除フレームを以前に関連付けられたアクセス ポイント(AP)に送信し、デバイスが接続する別のアクセス ポイントと 802.11 フレームを交換することで再関連付けプロセスを開始します。クライアントデバイスは別のAPをスキャンし、認証フレームを交換した後、再アソシエーション要求を送信しますが、ここではアソシエーションの代わりに再アソシエーション要求が使用され、接続プロセスの最初の2つのステップは同じままです。 図 12.ローミング プロセスでのメッセージ交換     図 13.ローミング表現   接続と切断のプロセスで使用されるWi-Fi API 次の表は、NXP i.MX RT SDKで接続および切断プロセスに使用できるAPIの一部を示しています。   テーブル 1.SDK で使用できる API API 形容 から呼び出すことができます wifi_send_scan_cmd 使用可能なネットワークをスキャンするために使用されます。単一のSSIDベースのスキャンのみをサポートします。これを複数のSSIDのリストに拡張できます。 ステーションとAP wlan_add_network 既知のネットワークのリストに特定のネットワークプロファイルを追加します。 ステーションとAP wlan_remove_network 既知のネットワークのリストから特定のネットワークプロファイルを削除します。 ステーションとAP wlan_connect 特定のネットワーク(AP)に接続します。 駅 wlan_disconnect ステーションをネットワーク(AP)から切断します。 駅 wlan_start_network 特定のネットワークを開始します。 AP wlan_stop_network 特定のネットワークを停止します。 AP このようなAPIの詳細については、ドキュメント「MCUXpresso_SDK_WLAN_Driver_Reference_Manual.pdf」を参照してください。場所 /docs/wifi から入手できます。

spi nor デモ imx8qxpc0 mek 内のすべて (ブートローダー、デバイスツリー、Linux カーネル、rootfs) SPI内のすべて（ブートローダー、デバイスツリー、Linuxカーネル、rootfs）のデモです。これを実現するために、生の読み取り（sf read）/生の書き込み（uuuスクリプト内のsf write）を使用します。 sf probe 0; sf read ${fdt_addr} 0x500000 0x100000; sf read ${loadaddr} 0x600000 0x1E00000; sf read ${initrd_addr} 0x2400000 0x600000; setenv bootargs console=${console},${baudrate} earlycon=${earlycon},${baudrate} rdinit=/linuxrc; booti ${loadaddr} ${initrd_addr} ${fdt_addr} |-- 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch --- このデモ用のパッチ |-- demo_binary | |-- flash.b0.bin --- b0 ブートローダー | |-- flash.bin --- c0 ブートローダー | |-- Image-imx8qxpc0mek.bin --- Linux カーネル | |-- imx8qxp-mek.dtb --- デバイスツリー | |-- uramdisk_boot.rootfs.aarch64.img --- RAMディスク | |-- uuu.qspi.all.b0.uuu --- b0用 uuu スクリプト | `-- uuu.qspi.all.uuu --- c0用 uuu スクリプト `-- readme.txt --- このファイル # 使用される SPI レイアウトは次のとおりです: # - --------- -------------------------------------------- # | | flash.bin | env | dtb | Image | rootfs | # - --------------- -------------------------------------- # ^ ^ ^ ^ ^ ^ ^ # | | | | | | | # 0 4kiB 4MiB 5MiB 6MiB 36MiB 42MiB 0x1000 0x400000 0x500000 0x600000 0x2400000 テスト: HW: i.MX8QXP MEK SW: lf-5.10.72-2.2.0 + 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch テストログ： SF: mt35xu512aba をページサイズ 256 バイト、消去サイズ 128 KiB、合計 64 MiB で検出 デバイス 0 オフセット 0x500000、サイズ 0x100000 SF: 1048576 バイト @ 0x500000 読み取り: OK デバイス 0 オフセット 0x600000、サイズ 0x1e00000 SF: 31457280 バイト @ 0x600000 読み取り: OK デバイス 0 オフセット 0x2400000、サイズ 0x600000 SF: 6291456 バイト @ 0x2400000 読み取り: OK [ 4.787552] imx6q-pcie 5f010000.pcie：PCIeポートを追加できません。 [ 4.797467] 未使用のカーネルメモリを解放中：2944K [ 4.807379] initプロセスとして /linuxrc を実行 syslogdの起動：OK klogdの起動：OK sysctlの実行：OK ネットワークの開始：OK /bin/sh：ttyにアクセスできません。ジョブ制御がオフになっています / # i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX6 全て Linux

IMX8 SAI TDM16 の問題 IMX8Nano カーネル 5.15 カスタム ボードを使用していますが、SAI5 の TDM16 に問題があります 問題は、TDM 16 ストリームの場合、チャンネルがランダムに 8 チャンネルずつ切り替わることです。カーネルトレースを追加し、fsl_saiドライバーから次のデバッグを確認します if (フラグ & FSL_SAI_CSR_FEF) { dev_dbg(dev, "isr: 送信アンダーランを検出しました\n"); ドライバーはこの状態で FIFO リセットを実行する必要がありますが、これは発生しないか、効果がありません。 次にアンダーランが発生したときに、16 チャンネル構成で常に 8 チャンネルアウトのステップインとして、チャンネルは再調整されます。 SAI はスレーブ モードであり、送信回線のみがアクティブになっています。 &sai5 { #sound-dai-cells = <0>; pinctrl-names = "デフォルト"; ピンctrl-0 = <&pinctrl_sai5>; fsl,dataline = <0 0x00 0xff>; DMas = <&sdma2 8 24 0>, <&sdma2 9 24 0>; fsl,txmasterflag = <1>; status = "大丈夫"; };   simpl-audio-card f の使用   出力1 {   compatible = "シンプルオーディオカード"; simple-audio-card,name = "SAI51"; シンプルオーディオカード、ステータス="大丈夫"; シンプルオーディオカード、ビットクロックマスター= <&spdif_codec1>; シンプルオーディオカード、フレームマスター= <&spdif_codec1>; シンプルオーディオカード、フォーマット= "left_j";                 CPU1:シンプルオーディオカード、CPU {                 sound-dai = <&sai5>;                 dai-tdm-slot-num = <16>; dai-tdm-slot-width = <32>;         };           spdif_codec1:  simple-audio-card,codec { サウンドダイ= <&codec_out1>;         };                };          codec_out1: 1output_txcodec { #sound-dai-cells = <0>; #address セル= <0>; #size セル= <0>;         compatible = "linux,spdif-dit"; サウンド名プレフィックス= "spdif_codec1"; status = "大丈夫";     };   私たちは、オンライン上のさまざまな投稿からこれに対するいくつかの修正を試しましたが、成功しませんでした。   他の誰かがそのような問題を見ましたか?このアンダーランは、インターアップが早期に発生したため、すべてのチャネルのDMAに十分なデータがないと想定しています。 また、再生ログにエラーはなく、TDM8モードにもエラーはありません。   どんな助けでも大歓迎です。 日時:IMX8 SAI TDM16の問題 私たちは問題を脇に押しやった。しかし、dtsの観点から他の人と共有するために、ここで学んだいくつかの重要な教訓があります。 fsl,dataline = <0 0x00 0xff>; ピン マッピングで複数のデータ行を指定した場合は、この設定に注意してください。この構成を次のものと組み合わせます。 CPU1:シンプルオーディオカード、CPU {                 sound-dai = <&sai5>;                 dai-tdm-slot-num = <16>; dai-tdm-slot-width = <32>;         };   これにより、スロット番号は SAI インターフェイスのチャネルの総数ではなく、データ ラインごとに必要なチャネル数を参照する必要があるため、32 チャネル インターフェイスが作成されます。   したがって、これは基本的に32チャネル操作であり、16しか必要としなかったため、64ビットのDMAが表示されていました。   次のように 4 X TDM4 構成に切り替えました。 4データライン pinctrl_sai5: sai5grp { FSL、ピン = < MX8MN_IOMUXC_SAI2_MCLK_SAI5_MCLK 0xd6 MX8MN_IOMUXC_SAI2_RXC_SAI5_TX_BCLK 0xd6 MX8MN_IOMUXC_SAI2_RXFS_SAI5_TX_SYNC 0xd6 MX8MN_IOMUXC_SAI2_RXD0_SAI5_TX_DATA0 0xd6 MX8MN_IOMUXC_SAI2_TXFS_SAI5_TX_DATA1 0xd6 MX8MN_IOMUXC_SAI2_TXC_SAI5_TX_DATA2 0xd6 MX8MN_IOMUXC_SAI2_TXD0_SAI5_TX_DATA3 0xd6 >; }; サイ5 &sai5 { #sound-dai-cells = <0>; pinctrl-names = "デフォルト"; ピンctrl-0 = <&pinctrl_sai5>; fsl,dataline = <0 0x00 0xff>; DMas = <&sdma2 8 24 0>, <&sdma2 9 24 0>; fsl,txmasterflag = <1>; /delete-property/ fsl,shared-interrupt; status = "大丈夫"; };   カードとコーデック   出力1 {   compatible = "シンプルオーディオカード"; simple-audio-card,name = "SAI51"; シンプルオーディオカード、ステータス="大丈夫"; シンプルオーディオカード、ビットクロックマスター= <&spdif_codec1>; シンプルオーディオカード、フレームマスター= <&spdif_codec1>; シンプルオーディオカード、フォーマット= "left_j";                 CPU1:シンプルオーディオカード、CPU {                 sound-dai = <&sai5>;                 dai-tdm-slot-num = <4>; dai-tdm-slot-width = <32>;         };           spdif_codec1:  simple-audio-card,codec { サウンドダイ= <&codec_out1>;         };              };          codec_out1: 1output_txcodec { #sound-dai-cells = <0>; #address セル= <0>; #size セル= <0>;         compatible = "linux,spdif-dit"; サウンド名プレフィックス= "spdif_codec1"; status = "大丈夫";     }; スロー番号が 4 であることに注意してください。各データラインには、現在4つのデータチャネルがあります。ALSA を使用して、これらをマッピングする必要があります。dmixを使用して8つのステレオを作成しますが、マッピングは次のとおりです。 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 0    4   8    12  1     5    9    13   2   6    10    14   3     7     11     15 チャネル数は、fls、マルチレーン、および共有割り込みを無効にしなかったため、このようなものです これが他の誰かを助けることを願っています。 日時:IMX8 SAI TDM16の問題 Hello, 更新していただきありがとうございます。 確認のため、SAI Transmit Configuration 3 Register (TCR3) の送信チャネル イネーブル ビットがデザインでイネーブルになっていることを確認してください。 よろしくお願いいたします。 日時:IMX8 SAI TDM16の問題 そのため、16ビットオーディオでテストしましたが、これまでのところエラーはありません。まだ数時間しか経っていないため、テストはソークで実行し続けます。これを本番環境で使用することはできませんが、興味深いテストです。 DMAコントローラーは32ビットなので、16chの32ビットオーディオデータの場合、サンプルあたり64ビットのオーディオについて話しており、2つのDMAスロットを使用し、アンダーランの場合、FIFOは1で同期しなくなり、データの半分を表すため、8チャンネルスイッチになります。 ここで、アンダーランが発生したときの32ビットモードでのfifoリセットについて理解する必要がありますが、これは32ビットのデータのみをクリアし、フルサンプルに関連する64ビットはクリアしないため、これが影響しない理由だと思います。また、これらのアンダーランが発生する理由と、DMA割り込みがシステムに追いつかない理由についても説明します。 日時:IMX8 SAI TDM16の問題 DMIXのような他のAlsaプラグインでも発生するため、DMIX自体を除外しました 日時:IMX8 SAI TDM16の問題 この現在のテスト環境では、alsa 経由でパイプされるオーディオが固定されており、受信側コーデック (clck src) も固定されているため、ビット レートを下げることはできません。別の方法で試してみます。 アップデートとして、マスター モードでクロックを設定しましたが、スレーブ モードではクロックの安定性に関連している可能性があると考えていましたが、これは影響しませんでした。 私たちはalsaで16chと8 X 2chを混在させるdmixプラグインを実行しており、現在調査中です。 日時:IMX8 SAI TDM16の問題 Hello, ビットレートを下げた場合、エラーは発生しますか? よろしくお願いいたします。 日時:IMX8 SAI TDM16の問題 alsa再生ログにエラーはなく、TDM8モードにもエラーはありません。

MX6 Dual Lite SABRE AI CPU 卡 PMIC 选择用于定制设计 Hello, 根据 i.MX6 Dual Lite Sabre AI 原理图 (sch-27767_a_x3.pdf)，PMIC 部分与原理图中标记的电压水平存在冲突。原理图建议使用MMPF0100F0ZES PMIC 部件。 PMIC 数据表（修订版）9.0，12/2015）建议如果使用MCIMX6DLAICPU1参考设计，则使用该部件的“NP”版本。 应该使用哪个编程版本？ “ F0”版本适合这种设计吗？ i.MX6 Dual Lite 处理器的上电顺序应该如何？ 提前致谢。 回复：MX6 Dual Lite SABRE AI CPU 卡 PMIC 选择，用于定制设计 Hello, 我们建议使用MMPF0100F0AEP来设计 MX6DL 此致

S12X PLL(フィルタ)カリキュレータ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以下は、次の計算に使用できる 2 つのユーティリティです。   - HCS12 デバイスの PLL フィルター コンポーネント値 (例: MC9S12DP256   - S12XE、S12XF、S12XS、S12P、S12HYなどのS12(X)デバイスのPLLレジスタ値   どちらのユーティリティにも、PDF形式の適切なユーザーマニュアルが付属しています。 全般

操作指南：使用 S32 调试探头对 S32G2xx 进行命令行 GDB 调试 S32 Design Studio for S32 Platform IDE 内置的 S32 调试器支持通过 GDB 命令行访问 S32 调试探针的闪存编程和调试功能。本文档仅提供针对 NXP 设备启动调试会话的必要命令，不涉及常规 GDB 命令行操作（这些操作可在 GNU 社区及其他非 NXP 关联的公开网站查阅详细说明）。 准备工作 设置软件工具 安装 S32 Design Studio for S32 Platform 安装用于调试设备的开发包。在本案例中，需安装 S32G2xx 开发包。此软件包非常重要，因为 S32 调试器支持元器件包含初始化内核所需的设备特定的 Python 脚本。 设置硬件 确认 S32G274A 评估板的设置。 配置 JTAG。S32G274A 评估板支持 10 针和 20 针 JTAG 连接。默认的板载配置为 20 针，若使用 10 针 JTAG 接口，请将跳线 J59 的位置从 2-3（默认）改为 1-2。S32 调试器和 S32 调试探针均支持这两种接口。 连接电源线 设置 S32 调试探针 通过 JTAG 电缆将 S32 调试探针连接到评估板。有关安装说明，请参考《S32 调试探针用户手册》。使用上一步中已确认的 JTAG 连接。 通过 USB 或以太网（通过局域网或直接连接，并配置为静态 IP 地址）将 S32 调试探针连接到主机 PC，同时通过 USB 端口连接电源。 启动 S32 Design Studio for S32 Platform 创建新项目或打开现有项目，并确认其能成功构建。如果创建新项目，请确保在 “新建项目向导” 中选择了 S32 调试器。 流程 由于需要为每个要调试的核心启动单独的调试线程，并且启动调试线程的方法取决于它是主核心还是辅助核心以及是否会加载可执行映像，或者可执行文件是否已在运行并且只需附加调试器。以下 3 个部分将介绍这些场景： 主核心加载映像并运行：应用程序映像将由调试器直接加载到内存中，然后初始化并启动。主核心将启动应用程序使用的任何辅助核心。 辅助核心：主核心已启动辅助核心，它现在正在运行，调试器将通过连接方法进行连接。 主核心映像已在内存中并正在运行：主核心已通过其他方式初始化并启动，例如通过目标上的 Linux 操作系统，因此调试器将通过附加方法进行连接，而无需初始化或将映像加载到内存中。 请继续执行适用于您要启动调试线程的核心的部分。 主核心加载图像并运行 准备要调试的核心的初始化脚本。 打开内核初始化 Python 脚本： {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_generic_bareboard_all_cores.py 取消注释以下行： #_JTAG_SPEED = 16000 #_PROBE_IP = "10.112.101.91" #_GDB_SERVER_PORT = 45000 #_CORE_NAME = 'M7_0'#_RESET_TYPE = “默认” #_RESET_DELAY = 1 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True 此文件由 S32 Design Studio IDE 中的 S32 调试器使用，其中的设置从 GUI 提供，因此这些行被注释掉，以便允许 GUI 设置进行控制。提供注释行是为了使脚本可以更轻松地通过命令行方法运行。 更新 IP 地址行 (_PROBE_IP) 以匹配已连接到您的电脑的 S32 调试探针的 IP 地址。请参阅 S32 调试探针的用户指南，以获取有关如何获取 IP 地址的详细信息。  如有必要，更新核心名称 (_CORE_NAME)。有关受受支持内核的完整列表，请参阅 s32g2xx_context.py。 使用新名称保存文件以保留原始文件。例如，s32g2xx_gen_bb_all_c_my_probe.py。这确保了 S32 调试器仍然能够正常运行。 启动 GTA 服务器。在命令提示符或 Windows 文件资源管理器中运行命令： {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe  应出现如下窗口：   确保 Python 的环境变量已设置。在命令提示符中，运行以下命令： 设置 PYTHONPATH={S32DS 安装路径}\S32DS\build_tools\msys32\mingw32\lib\python2.7；{S32DS 安装路径}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages 启动 GDB。在命令窗口中，运行以下命令： Windows 操作系统： {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（适用于 arm32） 或者 {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（适用于 arm64） Linux 操作系统： arm-none-eabi-gdb-py 现在命令窗口中应该会显示 (gdb) 提示符： 在（gdb）提示符下，输入以下命令（按此顺序）： source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_gen_bb_all_c_my_probe.py这将指定用于初始化的脚本。 py board_init() 这将初始化电路板。它仅应针对初始核心进行调用。在多核调试工作流程中，针对其他核心的调试器启动将省略此步骤。 py core_init() 这将初始化步骤 1 中初始化脚本中指定的内核。 现在可以使用标准 GDB 命令。例如，您可能希望加载一个 ELF 文件： 文件 {S32DS Workspace Path}\\New_S32G_Project\\New_S32G_Project_M7_0\\Debug_RAM\\New_S32G_Project_M7_0.elf 加载 次级核心 完成主核调试启动后，可以通过在辅助核上启动 GDB 调试来执行多核调试。 需要在主内核 GDB 会话中执行一些额外的步骤，输入以下命令： 设置 *0x34100000 = 0x34200000  设置 *0x34100004 = 0x34100025 设置 *0x34100024 = 0xFFFEF7FF 设置 *0x34200000 = 0x34300000 设置 *0x34200004 = 0x34200025 设置 *0x34200024 = 0xFFFEF7FF b main c 这些行准备在次级内核上启动调试的环境。这将允许在每个内核有独立的 ELF 文件的情况下进行多内核调试。这些内容可以在 S32 Design Studio IDE 中主内核的调试配置的启动选项卡的运行命令字段中找到，适用于从新应用程序项目向导创建的任何多内核项目。注意：如果所有内核只有一个 ELF 文件，则应跳过这些“set *0x... = 0x...”命令。 一般来说，将断点设置在主程序处是正确的，如图所示，但这可能需要根据项目内次级内核的启动时间进行更改。 准备要调试的辅助核心的初始化脚本。 打开内核初始化 Python 脚本： {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py 此脚本与用于主内核的脚本不同。它旨在在已经初始化并运行的内核上启动调试会话。 编辑要调试的辅助核心的脚本。由于此脚本是为主核心设置的，因此需要对辅助核心的设置进行一些调整 取消注释以下几行： #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" 对以下行进行更改： _JTAG_SPEED = 14000 -> None _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> None _CORE_NAME = 'M7' -> 'M7_1'（此处应设置为与要调试的核心名称匹配，详见s32g2xx_context.py文件中的完整列表） _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" 使用新名称保存文件以保留原始文件。例如，s32g2xx_attach_my_probe_core1.py。这样可以确保 S32 调试器仍能正常工作。 现有的 GTA 服务器已在使用，因此请勿启动新的服务器。 打开一个新的命令窗口并按照与主核心类似的步骤进行操作。 如果尚未全局设置，请设置 Python 环境变量set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages 启动 GDB Windows 操作系统： {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（适用于 arm32） 或 {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（适用于 arm64） Linux 操作系统： arm-none-eabi-gdb-py 现在，命令窗口中应显示 (gdb) 提示符： 在（gdb）提示符下，输入以下命令（按此顺序）： 源 {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core1.py 这将指定用于初始化的脚本。 我们不会执行py board_init() ，因为这已经为主核心完成。 py core_init() 这将初始化在步骤 2 中指定的初始化脚本中的内核。 现在可以使用标准 GDB 命令。例如，您可能希望加载一个 ELF 文件： 文件 {S32DS Workspace Path}\\S32G_MultiCore\\S32G_MultiCore_M7_1\\Debug_RAM\\S32G_MultiCore_M7_1.elf 加载 对其他核重复步骤 3-6 主核心映像已在内存中并正在运行 核心正在运行，不需要初始化。 准备要调试的核心的初始化脚本。 打开内核初始化 Python 脚本： {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py 此脚本与用于主内核的脚本不同。它旨在在已经初始化并运行的内核上启动调试会话。 编辑要调试的辅助核心的脚本。由于此脚本是为主核心设置的，因此需要对辅助核心的设置进行一些调整 取消注释以下行： #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" 对行进行以下更改： _JTAG_SPEED = 14000 _GDB_SERVER_PORT = "127.0.0.1:45000"-> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64"->（输入探针的 IP 地址） _CORE_NAME = 'M7'-> 'M7_0'（应将其设置为与要调试的内核的名称相匹配，完整列表请参见 s32g2xx_context.py） _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" 使用新名称保存文件以保留原始文件。例如，s32g2xx_attach_my_probe_core0.py。这确保了 S32 调试器仍然能够正常运行。 启动 GTA 服务器。在命令提示符或 Windows 文件资源管理器中运行命令： {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe 应当看到一个窗口，如下所示： 确保已设置 Python 环境变量在命令提示符下运行命令：set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages 启动 GDB在命令窗口中运行命令：Windows 操作系统：{S32DS 安装路径}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（适用于 arm32）或{S32DS 安装路径}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（适用于 arm64）Linux 操作系统：arm-none-eabi-gdb-py现在命令窗口中应显示 (gdb) 提示符： 在（gdb）提示符下，输入以下命令（按此顺序）： 源 {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core0.py 这指定了用于调试器初始化的脚本。 不要执行py board_init() ，因为这将初始化电路板，并重置当前正在执行的应用程序，而这对于本例来说是不希望的。 py core_init()此命令将调试器连接初始化至步骤 1 初始化脚本中指定的内核。 现在可以使用标准 GDB 命令。例如，您可能希望加载一个 ELF 文件： 文件 {S32DS Workspace Path}\\S32G_Multicore\\S32G_Multicore_M7_0\ \Debug_RAM\\S32G_Multicore_M7_0.elf 加载 完成主核调试启动后，可以通过在辅助核上启动 GDB 调试来执行多核调试。有关每个需要调试的附加核心，请参阅“辅助核心”部分。 回复：如何使用 S32 调试探针对 S32G2xx 进行命令行 GDB 调试 大家好，团队， 我正在尝试为 S32G2 启用命令行半主机功能（使用 S32 调试探针），按照上述 主核加载镜像并运行 流程操作时， 执行 py board_init() 可正常输出，但 py core_init() 失败且导致 GTA 服务器崩溃。 请查收附件中的图片，这些图片是在执行 py board_init() 时生成的。 由于执行 core_init() 后 GTA 服务器窗口也会崩溃，无法调试或定位失败原因。请协助排查此问题。 命令行工具 gdb s32 debugger S32G274A

MT25Qフラッシュのi.MX8DXL FlexSPI構成パラメータ i.MX8DXL DDR3L EVKボード、NOR型フラッシュで使用するのはMT25QU512ABB8ESF-0SITです。 このドキュメントでは、MT25Qフラッシュから起動するためのFlexSPI設定パラメータの基準を、QUADパッドとDDRモードとで示します。 HW: i.MX8DXL DDR3L EVKボード SW：Linux 5.4.70 BSP RM 5.9.3.2以降、FlexSPIシリアルのフラッシュブート操作、FlexSPIブートフローは次のようになります。 FlexSPI設定パラメータは、2つのグループに分類できます。FlexSPI コントローラに関するパラメータと、NOR型フラッシュの操作関連パラメータです。 パラメータテーブルの完全チェックについては、i.MX8DXL RM「表5-20.FlexSPI設定ブロック」を参照してください。 MT25Qのデータシートを確認の上で、その機能を見てみましょう。ターゲットはDDRモード（80MHz）とQUADパッドであることに注意してください。   次に、FlexSPI設定パラメータを変更しましょう。 1>readSampleClkSrc を 2 に設定します。これは SCK パッドからループバックします。このフィールドはデフォルトで 0 に設定されており、この設定で起動するとこのユースケースではエラーが発生するため、2 に変更します。 2>deviceModeCfgEnableを1に設定し、deviceModeSeq.seqNumを1に設定し、deviceModeSeq.seqIdを4に設定し、deviceModeArgを0x5f に設定します。 i.MX8DXLからは、MT25QがDDRモードとQUADモードに入るよう、いくつかのコマンドをフラッシュに送信します。そのため、deviceModeCfgEnable = 1です。 seqNum=1、seqId=4の場合、LUTテーブルのインデックス4にこのシーケンスが格納され、LUTエントリが1つ必要であるということです。LUTエントリを変更する方法については後述します。 deviceModeArg=0x5fの場合は、MT25Qデータシートを確認します。その拡張揮発性レジスタを書き込むことで、フラッシュの動作モードを設定できます。 3>controllerMiscOptionを0x40にすると、このパラメータはFlexSPI コントローラ自体にのみ適用され、「外部デバイスはDDRコマンドを使用して動作する」という意味になります。 4>deviceType=1（シリアルNOR）、sflashPadType=4（QUADパッド）、serialClkFreq=4（80MHZ CLK）、これらのパラメータもFlexSPIコントローラ専用です。 5>sflashA1Sizeに実際のサイズをバイト単位で設定します。 6>LUTエントリの変更では、次に示す8DXL RM表5-21を確認します。 つまり、LUTエントリ0は読み取りコマンドのシーケンス、エントリ1は読み取りステータスシーケンス、エントリ3は書き込み有効シーケンス、エントリ15はダミーコマンドシーケンスです。 他のインデックスLUTエントリ（2、4、6、7、8、10、12、13、14など）も、フラッシュデバイスに必要なコマンドのシーケンスを格納するのに使用できます。当社ではMT25Q拡張揮発性レジスタへの書き込みシーケンスをLUTエントリに格納します。 8DXL RM「図15-6.LUTとシーケンスの構造」を確認します。 各LUTエントリ（シーケンス）では16バイトを使用し、1つのシーケンスは最大8つの命令で構成され、各命令では16ビットを使用します。 各命令は、オペコード—num_pads—オペランドの形式で表されます。 サポート対象の命令については、RM 15.2.4.8「プログラマブル・シーケンス・エンジン」を参照してください。 Mt25Q揮発性レジスタを書き込むので、実際にはまず書き込み有効シーケンスが他のシーケンスよりも前に実行されます。その前に、書き込み有効シーケンスが発行される必要があります。 MT25Qデータ・シートで次のことを確認します。 このシーケンスで必要なのは1つの命令、0x0406のみです。現時点ではまだSDRと1パッドモード、つまりオペコード（CMD_SDR）、1パッド（0）、オペランド（6）を使用しています。 LUTエントリ1、読み取りシーケンス、MT25QのREAD STATUS REGISTER（05h）です。データ・シートで次のことを確認します。 次の2つの命令を使用します。 0x0405：オペコード（CMD_SDR）、パッド（1パッド）、オペランド（0x5、READ STATUS REGISTER） 0x2404：オペコード（READ_SDR）、パッド（1パッド）、オペランド（0x4、バイト番号） LUTエントリ4は、MT25QをDDRモードにし、クワッドパッドにするためのものです。 MT25Qデータ・シートより： 次の2つの命令を使用します。 0x0461：オペコード（CMD_SDR）、1パッド（0）、オペランド（0x61 WRITE ENHANCED VOLATILE CONFIGURATION REGISTER） 0x2001：オペコード（WRITE_SDR 08）、1パッド（0）、オペランド（1バイトデータサイズ） 0x5fはデータとして送信されます。 次に、LUTエントリの読み取りを確認します。この時点で、MT25QはQUADパッドとDDRモードに入っています。 LUTエントリ0、読み取りシーケンス、MT25Qからの高速読み取りデータです。データシートより： 次の4つの命令を使用します。 86ED、オペコード（CMD_DDR）、パッド（4パッド）、オペランド（0xEDh、高速読み取り） 8a18、オペコード（RADDR_DDR）、パッド（4パッド）、オペランド（0x18、3バイトアドレス） B210、オペコード（DUMMY_ADDR）、パッド（4パッド）、オペランド（0x10、ダミーサイクル） A604、オペコード（READ_DDR）、パッド（4パッド）、オペランド（0x4、データバイト） 参考情報： 1.i.MX8DXL リファレンス・マニュアル 2. MT25Qデータ・シート   i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MT25Qフラッシュのi.MX8DXL FlexSPI設定パラメータ @fushi_peng様、FLEXSPI LUTエントリの構築に関して、このような説明を探し求めておりました。非常に役立つブログ、どうもありがとうございました。

恩智浦 PMIC 解决方案适用于多厂商处理器 这是恩智浦为非恩智浦处理器提供的 PMIC 解决方案。 链接：https://www.nxp.com/products/power-management/pmics-and-sbcs/pmics-and-sbcs-for-multi-vendor-processors:PMICS-SBCS-MULTI-VENDOR-PROCESSORS No AN 主题 PMIC 处理器 应用 链接 1 AN12883 多路低压PMIC系统 低压 PMIC NA NA https://www.nxp.com/webapp/Download?colCode=AN12883&appType=moderatedWithoutFAE 2 AN12807 采用FS84/FS85和PF502x系列的完整系统电源解决方案 FS85,PF502x NA NA https://www.nxp.com/webapp/Download?colCode=AN12807&appType=moderatedWithoutFAE 3 AN4991 使用 Freescale PMIC 对 Xilinx AP SoC 进行电源管理 PF0100 Xilinx Zynq-7000  工业、消费电子 https://www.nxp.com/docs/en/application-note/AN4991.pdf 4 AN13002 NXP 面向 Mobileye EyeQ4 中端处理器的 PMIC 解决方案 PF5024+PF5020 Mobileye EyeQ4 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13002.pdf 5 AN13020 恩智浦 PMIC 解决方案，适用于 RH850 系列 MCU FS65,FS23,FS26,FS85 Renesas RH850 电气化、集群、车身、 通用型 https://www.nxp.com.cn/docs/en/application-note/AN13020.pdf 6 AN13018 恩智浦面向 R-Car M3 处理器的 PMIC 解决方案 PF81*2 Renesas RcarM3 IVI https://www.nxp.com.cn/docs/en/application-note/AN13018.pdf 7 AN13019 适用于瑞萨 R-Car E3 处理器的 NXP PMIC 解决方案 PF71 Renesas RcarE3 仪表板 https://www.nxp.com.cn/docs/en/application-note/AN13019.pdf 8 AN13003 恩智浦适用于 Renesas R-Car H3 处理器的 PMIC 解决方案 PF82+PF5020+PF5024+PF52 Renesas RcarH3 IVI,ADAS https://www.nxp.com.cn/docs/en/application-note/AN13003.pdf 9 AN13058 恩智浦适用于 Renesas R-Car V3M 处理器的 PMIC 解决方案 PF5024+PF5020 Renesas RcarV3M ADAS https://www.nxp.com.cn/docs/en/application-note/AN13058.pdf 10 AN13197 恩智浦适用于 Toshiba TMPV7608 处理器的 PMIC 解决方案 PF71 Toshiba TMPV7608 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13197.pdf 11 AN13239 适用于 ESPRESSIF ESP32 的 NXP PMIC 解决方案 PF1550 ESPRESSIF ESP32 NON-AUTO https://www.nxp.com.cn/docs/en/application-note/AN13239.pdf 12 AN13245 恩智浦 PMIC 解决方案适用于 TI C2000 FS45,FS85 TI C2000 电气化 https://www.nxp.com.cn/docs/en/application-note/AN13245.pdf 13 AN13246 恩智浦 PMIC 解决方案 ST-Chorus ST58 FS65,FS85 ST Chorus ST58 电气化 https://www.nxp.com.cn/docs/en/application-note/AN13246.pdf 14 AN13247 适用于 MTK 处理器 2712 的 NXP PMIC 解决方案 FS56+PF81+PF5024 MTK 2712 IVI https://www.nxp.com/docs/en/application-note/AN13247.pdf 15 AN13272 恩智浦适用于 Ambarella CV22/CV25 SoC 的 PMIC 解决方案 FS56+PF81 FS85+PF82 Ambaralla CV22/CV25  ADAS https://www.nxp.com.cn/docs/en/application-note/AN13272.pdf  16 AN13320 恩智浦适用于 XILINX UltraScale+ MPSoC ZU2/ZU3 处理器的 PMIC 解决方案 FS56+PF81 FS85+PF71+PF5020+PF5024 Xilinx Zynq UltraScale+ MPSoC ZU2/ZU3 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13320.pdf 17 AN13318 恩智浦适用于 Ambarella Horizon J2 的 PMIC 解决方案 FS56+PF81 FS85+PF82 Horizon J2 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13318.pdf 18 AN13222 NXP SBC 解决方案，适用于英飞凌 AURIX TC2xx/TC3xx 系列 MCU FS26 FS45/FS65 FS85 Infineon AURIX TC2xx/TC3xx 电气化、ADAS https://www.nxp.com.cn/docs/en/application-note/AN13322.pdf 19 AN13431 恩智浦适用于 TI TMS570 MCU 的 PMIC 解决方案 FS26,FS45,FS65,FS85 TI TMS570 MCU 电气化、动力系统 https://www.nxp.com.cn/docs/en/application-note/AN13431.pdf 20 AN13432 恩智浦适用于 XILINX UltraScale+ MPSoC ZU4\ZU5\ZU6\ZU7\ZU9 处理器的 PMIC 解决方案 FS56,FS86,PF81,PF71,PF5020,PF52 XILINX UltraScale+ MPSoC ZU4\ZU5\ZU6\ZU7\ZU9  ADAS https://www.nxp.com.cn/docs/en/application-note/AN13432.pdf 21 AN13433 恩智浦适用于 XILINX UltraScale+ MPSoC ZU11_ZU15 处理器的 PMIC 解决方案 PF7100,PF5023,PF5200,FS86 XILINX UltraScale+ MPSoC ZU11_ZU15 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13433.pdf 22 AN13554 恩智浦适用于 SAMA5Dx 系列处理器的 PMIC 解决方案 PF1550,PF1510 Microchip SAMA5DX NON-AUTO https://www.nxp.com.cn/docs/en/application-note/AN13554.pdf 23 AN13615 适用于AG55xQ系列模块的NXP PMIC解决方案 FS56 AG55xQ V2X https://www.nxp.com.cn/docs/en/application-note/AN13615.pdf 24 AN13638 适用于 TI TDA2x_TDA2Ex 处理器的 NXP PMIC 解决方案 FS56+PF81 TI TDA2 ADAS https://www.nxp.com/docs/en/application-note/AN13638.pdf 25 AN13651 TI AWR2243 雷达收发器的 PMIC 解决方案 FS56+PF71/PF5020 TI AWR2243 雷达 https://www.nxp.com.cn/docs/en/application-note/AN13651.pdf 26 AN13318 Horizon Journey 3 的电源管理解决方案 FS56/FS85 + PF81 + PF5024/PF52 Horizon Journey 2 ADAS https://www.nxp.com.cn/docs/en/application-note/AN13318.pdf 27 AN13863 恩智浦适用于 Black Sesame A1000L/A1000 处理器的 PMIC 解决方案 FS86 / FS56 + PF81 Black Sesame A1000 ADAS https://www.nxp.com/docs/en/application-note/AN13863.pdf 28 AN13748 恩智浦电源解决方案适用于 Cypress Traveo II 系列 MCU 的应用说明 FS23,FS26 Cypress Traveo™ II 车身 https://www.nxp.com/webapp/Download?colCode=AN13748&appType=moderatedWithoutFAE 电源解决方案

看门狗定时器使用 imx6ull Hello, 我们计划在现有系统中使用看门狗定时器来应对任何类型的操作系统故障或硬件故障， 我们正在使用IMX6ULL板，那么您能否建议我们使用哪种看门狗来获得最佳输出和可行性？ i.MX6UL 回复：看门狗定时器使用imx6ull Hello @amiraj_patel  我希望你一切都好。 您可以参考imx6ul设备树，唯一使用的wdog是wdog1，您可以使用wdog2和wdog3，只是必须在设备树上声明它。 我希望这对你有帮助。 顺祝商祺！ Salas.

HOWTO: S32G2xx用S32デバッグプローブを使用したコマンドラインGDBデバッグ S32 Design Studio for S32 Platform IDEに含まれるS32デバッガにより、GDBコマンドラインを通じてS32デバッグプローブのフラッシュプログラミング機能およびデバッグ機能にアクセスできます。このドキュメントは、NXPデバイスでデバッグセッションを開始するために必要なコマンドのみを提供します。ここでは一般的なGDBコマンドライン操作については取り上げません。これらについては、NXPとは関連のないGNUコミュニティやその他の公開Webサイトで詳しく説明されています。 準備 ソフトウェア ツールをセットアップする S32プラットフォーム用 S32 Design Studioをインストールする デバッグするデバイスで使用できる開発パッケージをインストールします。この場合は、S32G2xx Development Packageです。S32デバッガのサポートには、コアの初期化に必要なデバイス固有のPythonスクリプトが含まれているため、このパッケージは重要です。 ハードウェアをセットアップします。 S32G274A評価ボードのセットアップを確認してください。 JTAGを設定します。S32G274A評価ボードは、10ピンおよび20ピンの両方のJTAG接続をサポートします。デフォルトのボード構成は20ピンに設定されています。10ピンJTAGインターフェースを使用している場合は、ジャンパJ59の位置を2-3（デフォルト）から1-2に変更してください。どちらもS32デバッガとS32デバッグ・プローブによりサポートされています。 電源ケーブルを接続してください S32デバッグ・プローブをセットアップします。 S32デバッグ・プローブをJTAGケーブル経由で評価ボードに接続します。インストール手順については、S32デバッグ・プローブのユーザ・ガイドを参照してください。前の手順で確認したJTAG接続を使用します。 S32デバッグ・プローブをUSBまたはイーサネット（LAN経由または直接接続、固定IPアドレス構成）でホストPCに接続し、電源をUSBポートに接続します。 S32 Design Studio for S32 Platform を起動する 新しいプロジェクトを作成するか、既存のプロジェクトを開いて、正常にビルドされることを確認します。新しいプロジェクトを作成する場合は、新しいプロジェクトのウィザードでS32デバッガが選択されていることを確認してください。 手順 デバッグするコアごとに個別のデバッグ スレッドを開始する必要があるため、デバッグ スレッドの起動方法は、プライマリ コアかセカンダリ コアか、実行可能イメージが読み込まれるか、実行可能ファイルがすでに実行されており、デバッガーをアタッチするだけでよいかによって異なります。これらのシナリオについては、次の 3 つのセクションで説明します。 プライマリコアのロードイメージと実行：アプリケーションイメージは、デバッガーによってメモリに直接ロードされ、初期化されて起動されます。プライマリコアは、アプリケーションで使用されるすべてのセカンダリコアを起動します。 セカンダリ コア: プライマリ コアがセカンダリ コアを起動し、現在実行されており、デバッガーはアタッチ メソッドを介して接続します。 プライマリ コア イメージが既にメモリ内にあり、実行中: プライマリ コアは既に初期化され、ターゲット上の Linux OS などの他の手段で起動されているため、デバッガーはイメージを初期化したりメモリに読み込んだりせずにアタッチ方法を使用して接続します。 デバッグスレッドを開始するコアに該当するセクションに進んでください。 プライマリコア、イメージをロードして実行 デバッグするコアの初期化スクリプトを準備します。 コア初期化Pythonスクリプト {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_generic_bareboard_all_cores.pyを開きます。 以下の行のコメントを解除します。 #_JTAG_SPEED = 16000 #_PROBE_IP = "10.112.101.91" #_GDB_SERVER_PORT = 45000 #_CORE_NAME = 'M7_0' #_RESET_TYPE = "default" #_RESET_DELAY = 1 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True このファイルは、S32 Design Studio IDE内のS32 デバッガで使用されます。設定はGUIから提供されるため、GUI設定が制御できるように、これらの行はコメントアウトされています。スクリプトをコマンド・ライン・メソッドでより簡単に実行できるよう、コメント行が提供されています。 PCに接続されているS32 Debug ProbeのIP アドレスと一致するように、IPアドレス行 （_PROBE_IP）を更新します。IPアドレスを取得する方法の詳細については、S32 Debug Probeのユーザーガイドをご覧ください。 必要に応じて、コア名 (_CORE_NAME) を更新してください。サポートされているコアの完全なリストについては、s32g2xx_context.pyをご覧ください。 元のファイルを保持するために、新しい名前でファイルを保存します。たとえば、s32g2xx_gen_bb_all_c_my_probe.pyなどです。これにより、S32デバッガが引き続き正常に機能します。 GTAサーバを起動し、コマンド・プロンプトまたはWindowsファイルエクスプローラーで {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe コマンドを実行します。 このようなウィンドウが表示されます。   Python の環境変数が設定されていることを確認してください。 コマンドプロンプトから、次のコマンドを実行してください。 set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages GDBを開始し、コマンド・ウィンドウで次のコマンドを実行します。 Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（arm32の場合） または {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（arm64の場合） Linux OS: arm-none-eabi-gdb-py gdbプロンプトが次のようにコマンド・ウィンドウに表示されます。 (gdb) プロンプトから、次のコマンドを (この順序で) 入力します。 source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_gen_bb_all_c_my_probe.py これは初期化のスクリプトを指定します。 py board_init () これはボードを初期化します。最初のコアに対してのみ呼び出すべきです。マルチコアのデバッグワークフローでは、追加のコアのデバッガーを起動してもこのステップは省略されます。 py core_init()このコマンドは、手順1の初期化スクリプトで指定されたコアを初期化します。 これで、標準のGDBコマンドを使用できます。たとえば、ELFファイルをロードしたい場合があります。 file {S32DS Workspace Path}\\New_S32G_Project\\New_S32G_Project_M7_0\\Debug_RAM\\New_S32G_Project_M7_0.elf load セカンダリコア プライマリ コアのデバッグの起動が完了したら、セカンダリ コアで GDB デバッグを起動してマルチコア デバッグを実行できます。 プライマリコアGDBセッション内からいくつかの追加手順を実行する必要があるため、以下のコマンドを入力します。 set *0x34100000 = 0x34200000  set *0x34100004 = 0x34100025 set *0x34100024 = 0xFFFEF7FF set *0x34200000 = 0x34300000 set *0x34200004 = 0x34200025 set *0x34200024 = 0xFFFEF7FF b main c これらの行は、セカンダリコアでデバッグを開始するための環境を準備します。これにより、コアごとに個別のELFファイルがある場合でも、マルチコア・デバッグが可能になります。これらは、S32 Design Studio IDEの新規アプリケーションプロジェクトウィザードから作成されたマルチコアプロジェクトのプライマリコアのデバッグ構成の「スタートアップ」タブにある「実行コマンド」フィールドにあります。注意：すべてのコアにELFファイルが1つしかない場合、これらの「set *0x... = 0x...」コマンドはスキップする必要があります。 一般的には、示されているように、mainにブレークポイントを設定するのが正しいですが、プロジェクト内でセカンダリコアがいつ起動されるかに応じて変更する必要があるかもしれません。 デバッグするセカンダリーコアの初期化スクリプトを準備してください。 コア初期化のPythonスクリプトを開きます。 {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py これは、プライマリコアに使用されるスクリプトとは異なるスクリプトであり、すでに初期化されて実行中のコア上でデバッグセッションを開始するように設計されています。 デバッグするセカンダリ コアのスクリプトを編集します。このスクリプトはプライマリ コア用に設定されているため、セカンダリ コアのセットアップにはいくつかの調整が必要です 以下の行のコメントを解除します。 #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" 以下の行を変更してください： _JTAG_SPEED = 14000 -> None _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> None _CORE_NAME = 'M7' -> 'M7_1'（デバッグ対象のコアの名前と一致するように設定する必要があります。詳細なリストは s32g2xx_context.py を参照してください） _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" ファイルを新しい名前で保存して、元のファイルを保持します。たとえば、s32g2xx_attach_my_probe_core1.pyなどです。これにより、S32デバッガは引き続き正常に動作します。 既存のGTAサーバーを使用しますので、新しいサーバーを起動しないでください。 新しいコマンドウィンドウを開いて、プライマリコアと同じ手順に従ってください。 グローバルに設定されていない場合は、Python環境変数を設定します。set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages GDBを起動する Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（arm32の場合） または {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（arm64の場合） Linux OS: arm-none-eabi-gdb-py gdbプロンプトがコマンド・ウィンドウに表示されます。 (gdb) プロンプトから、次のコマンドを (この順序で) 入力します。 source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core1.py これは初期化のスクリプトを指定します。 py board_init () はプライマリコアですでに実行されているので、実行しません。 py core_init()これにより、ステップ2の初期化スクリプトで指定されたコアが初期化されます。 これで、標準のGDBコマンドを使用できます。たとえば、ELFファイルをロードしたい場合があります。 file {S32DS Workspace Path}\\S32G_MultiCore\\S32G_MultiCore_M7_1\\Debug_RAM\\S32G_MultiCore_M7_1.elf load コアを追加するごとに3～6を繰り返します。 プライマリコアイメージはすでにメモリにあり、実行中です コアは動作しているので、初期化する必要はありません。 デバッグするコアの初期化スクリプトを準備してください。 コア初期化のPythonスクリプトを開きます。 {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py これは、プライマリコアに使用されるスクリプトとは異なるスクリプトであり、すでに初期化されて実行中のコア上でデバッグセッションを開始するように設計されています。 デバッグするセカンダリ コアのスクリプトを編集します。このスクリプトはプライマリ コア用に設定されているため、セカンダリ コアのセットアップにはいくつかの調整が必要です 以下の行のコメントを解除します： #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" 以下の行を変更してください： _JTAG_SPEED = 14000 _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> (プローブの IP アドレスを入力してください) _CORE_NAME = 'M7' -> 'M7_0'（デバッグ対象のコアの名前と一致するように設定してください。詳細なリストは s32g2xx_context.py を参照してください） _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" 元のファイルを保持するために、新しい名前でファイルを保存します。たとえば、s32g2xx_attach_my_probe_core0.pyなどです。これにより、S32デバッガが引き続き正常に機能します。 GTAサーバを起動し、コマンドプロンプトまたはWindowsファイルエクスプローラーから {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe コマンドを実行します。 次のようなウィンドウが表示されます。 Pythonの環境変数が設定されていることを確認してください。コマンドプロンプトから次のコマンドを実行します。 set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages GDBを起動します。コマンドウインドウで、以下のコマンドを実行します。 Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe（arm32の場合） または {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe（arm64の場合） Linux OS: arm-none-eabi-gdb-py gdbプロンプトがコマンド・ウィンドウに表示されます。 (gdb) プロンプトから、次のコマンドを (この順序で) 入力します。 source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core0.py これはデバッガ初期化用のスクリプトを指定します。 py board_init () を実行しないでください。ボードが初期化され、現在実行中のアプリケーションがリセットされます。この場合は望ましくありません。 py core_init()これにより、ステップ1の初期化スクリプトで指定されたコアへのデバッガ接続が初期化されます。 これで、標準のGDBコマンドを使用できます。たとえば、ELFファイルをロードしたい場合があります。 file {S32DS Workspace Path}\\S32G_Multicore\\S32G_Multicore_M7_0\ \Debug_RAM\\S32G_Multicore_M7_0.elf load プライマリコアのデバッグの起動が完了したら、セカンダリオコアでGDBデバッグを起動することでマルチコアデバッグを実行できます。デバッグする追加の各コアについては、「セカンダリコア」のセクションを参照してください。 Re: HOWTO: S32G2xx 用 S32 デバッグプローブを使用したコマンドライン GDB デバッグ チームの皆様、 S32デバッグプローブを使用してS32g2のコマンドラインセミホスティングを有効にしようとしています。上記のプライマリコアロードイメージと実行の手順に従って、 py board_init() は以下の出力を表示しますが、py core_init() は失敗し、gtaサーバーがクラッシュします。 py board_init() が実行された際の出力は、添付の画像をご確認ください。 gtaサーバーウィンドウもcore_init()実行後にクラッシュするため、デバッグや失敗の理由を把握できません。この問題を特定するためのサポートが欲しいです。  コマンドラインツール gdb s32 debugger s32g274a

ウォッチドッグタイマの使い方 imx6ull Hello, 既存のシステムにウォッチドッグタイマーをあらゆるタイプのOS障害またはハードウェア障害に使用することを計画しています。 また、 IMX6ULL ボードを使用していますので、最適な出力と実現可能性の観点からどのウォッチドッグを使用できるかを提案していただけますか? i.MX6UL Re:ウォッチドッグタイマの使用imx6ull Hello @amiraj_patel  お元気にお過ごしでしょうか。 imx6ul デバイスツリーを参照すると、wdog は wdog1 のみを使用し、wdog2 と wdog3 はデバイスツリーで宣言する必要があります。 これがお役に立てば幸いです。 よろしくお願いいたします。 Salas.

The ENET1 module does not function unless the Peripheral control register (MC_ME_PCTL6) is enabled Project file: lwip_mpc5748g Development board model: 2018 NXP BV MPC5748G-GW Follow the steps in MPC5748G-GW-RDB_ExampleCodes-UserGuide to develop ENET1 However, even PING is not working at present. I have tried to add ARP table on PC according to some relevant answers in the forum, but PING is still not working. At this time, I found that there were marking errors when reading the document, but after checking the register description, I did not quite understand what kind of setting is meant by enable here. MPC5748G-GW-RDB  Re: The ENET1 module does not function unless the Peripheral control register (MC_ME_PCTL6) is enab Hi, it is done in MC_ME which allows peripheral clock gating control based on the ME_RUN_PC0…7, ME_LP_PC0…7, and ME_PCTLn registers. So the errata say you need to enable clock for MLB0 module too, so contig one of ME_RUN_PC0…7 and ME_PCTL6 and do Mode Transition. Refer to chapter Mode Entry Module (MC_ME) of the device RM for more info. If using SDK in your project it should be enough to enable MLB0 clock within clock component and regenerate PE code. CLOCK_SYS_Init and CLOCK_SYS_UpdateConfiguration called in code should set MC_ME registers accordingly. In debugger you can check MC_ME_PS0 to know MLB0 clock is active. BR, Petr

GPIO中断 IMX8MM SDK Cortex M4 在IMX8MM SDK中，很遗憾我们找不到任何关于将GPIO用作带中断输入的示例。 使用 GPIO 作为带中断的输入时，需要了解 ARM Cortex M4 中 GPIO 中断的工作机制。 在 IMX8MMRM（IMX8MM 参考手册）的表 7-2（CM4 中断摘要）中可以看到，GPIO 中断分为两部分： 组合中断指示（GPIOn 信号 0 至 15）  组合中断指示（GPIOn 信号 16 至 31）   这意味着 GPIOn 的引脚 0 至 15 由 "组合中断指示（GPIOn 信号 0 至 15）" 处理，而引脚 16 至 31 由 "组合中断指示（GPIOn 信号 16 至 31）" 处理。 在 SDK 中，这些定义可以在以下路径找到： /devices/MIMX8MM6/MIMX8MM6_cm4.h（注意这是 IMX8MM SDK 的定义） 在此示例中，我将使用 GPIO5_IO12 (ECSPI2_MISO) 作为带中断的输入，并将 GPIO5_IO11 (ECSPI_MOSI) 作为 IMX8MM-EVK 的输出。我将输出连接到输入，并观察中断在上升沿和下降沿的行为。 在此示例中，我将 ECSPI2_MOSI (GPIO5_IO11) 连接到 ECSPI_MISO (GPIO5_IO12)： 请查看以下定义： #define IN_GPIO  GPIO5  定义输入引脚的 GPIO 基地址 #define IN_GPIO_PIN 12u  定义输入引脚编号 #define IN_IRQ  GPIO5_Combined_0_15_IRQn 定义中断号（本例中为 72） #define GPIO_IRQ_HANDLER  GPIO5_Combined_0_15_IRQHandler 这是指向中断处理函数的指针  #define IN_NAME  "IN GPIO5_IO12"  仅为引脚提供名称或描述  请参阅以下定义： #define OUT_GPIO GPIO5  定义输出引脚的 GPIO 基地址  #define OUT_GPIO_PIN 11u  定义输出引脚编号 #define OUT_NAME “OUT GPIO5_IO11” 仅为引脚提供名称或描述    以下是中断处理程序（前文已定义）的实现部分：😞 GPIO GPIO_ClearPinsInterruptFlags(IN_GPIO, 1u << IN_GPIO_PIN) 对应操作 GPIOx_ISR 寄存器：   本示例的中断处理程序会在每次中断时打印 "IRQ detected ............"。 需要创建两种 GPIO 配置：输出引脚配置和带下降沿中断的输入引脚： 然后配置 GPIO 和中断： EnableIRQ 用于启用 72 号中断。   GPIO_PortEnableInterrupts 对应 配置 GPIOx_IMR 寄存器： 示例代码会将输出引脚 GPIO5_IO11 反复切换高低电平。首先配置为下降沿触发中断，随后改为上升沿触发。 （完整源码文件将附后） 可直接使用 ARMGCC 工具链编译，但推荐通过 VSCode 集成 MCUXpresso 环境开发。 生成 .bin 文件（本示例为 igpio_led_output.bin）后，可通过 UUU 工具烧录至开发板： 在您的 Linux 机器上： sudo uuu -b fat_write igpio_led_output.bin mmc 2:1 gpio.bin 在U-Boot板上： u-boot=> fastboot 0 在 U-boot 中加载至 CORTEX M4 核心的指令： u-boot=> fatload mmc 2:1 ${loadaddr} gpio.bin 7076 bytes read in 14 ms (493.2 KiB/s) u-boot=> cp.b 0x80000000 0x7e0000 0x10000 u-boot=> bootaux 0x7e0000 ## No elf image ar address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD... u-boot=> 注：为提高操作便捷性，可使用自定义启动脚本加载二进制文件。 成功加载至 M4 核心后，串口终端将显示如下日志（需保持 GPIO5_IO11 和 GPIO5_IO12 物理连接）： 当运行时断开 GPIO5_IO11 和 GPIO5_IO12 的连接时，日志显示 ： 🔴断开连接（红色） 🔵重新连接（蓝色） 我希望这能帮到您。     此致！    Salas.  i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Windows

[802.11] Wi-Fi 连接/断开连接过程 在802.11标准中，连接过程包括三个主要步骤，必须执行这些步骤才能使设备成为Wi-Fi网络的一部分并在网络中进行通信。这三个步骤是设备发现（扫描）、设备认证（连接前检查兼容性等）以及最终建立连接（关联）。展望未来，这篇文章将提供每个步骤的详细信息。连接过程中的消息交换如下图所示。   图 1 。开放系统中的连接过程   图 2.连接过程中的消息交换 图2显示了连接时客户端和AP设备之间的消息交换过程的Wi-Fi嗅探器日志，这里客户端设备是小米，AP是Marvell设备。 连接建立过程 1.扫描 要加入任何网络，首先客户端或站点需要找到该网络。在有线网络中，只要插入电缆或插孔就可以找到网络。在无线世界中，这需要在加入过程开始之前识别兼容网络。网络的这个识别过程称为扫描。 扫描过程中需要几个参数。这些参数是BSSType、BSSID、信道列表、扫描类型、MinChannelTime和MaxChannelTime。这些参数根据制造商的 Wi-Fi 驱动程序设置为默认值，但用户可以修改，即，如果要求隐藏网络，那么我们可以将扫描类型参数设置为被动扫描，因为主动扫描对隐藏网络（不广播其 SSID 的网络）没有用。 扫描方法有两种：被动扫描和主动扫描。 默认情况下，无线电对运营所在国家/地区允许的所有频道执行两种类型的扫描。虽然两种类型的扫描默认可用，但主动扫描仅由区域政府法规允许传输的频道执行。未经授权使用的频道将被排除在主动扫描之外。 被动扫描：在被动扫描中，WLAN 站根据信道列表移动到每个信道并等待信标帧。接入点（以及 IBSS 中的站点）使用信标帧进行通信或宣布自己。 接入点尝试以定义的间隔发送信标，该间隔称为目标信标传输时间 (TBTT) 然而，接入点就像小区中的任何无线设备一样。如果网络繁忙，他们就无法发送。当 AP 需要发送信标时，如果网络繁忙，AP 将延迟其信标传输，直到其能够访问媒体。 在 802.11 中，可以使用 CSMA/CA 协议检查网络是否繁忙。在 CSMA/CA 中，当帧准备就绪时，传输设备会检查信道是空闲还是繁忙，以避免冲突。如果信道繁忙，传输设备将等待随机时间并再次检查信道是否空闲。如果信道空闲，它将发送帧。Beacon帧结构如下图所示。 图 3.信标帧   信标帧的必填字段的描述。 时间戳：所有站点在收到信标帧后，都使用该时间戳更新其本地时钟。这有助于同步。 信标间隔：表示目标信标传输时间（TBTT）之间的时间单位（TU）数。默认值为 100TU（102.4 毫秒）。 能力信息：包含有关设备/网络能力的信息 SSID ：它包含网络的服务集ID。 支持的速率：此字段包含接入点支持的数据速率的信息。 请注意，此信息不仅由潜在客户在被动扫描期间使用，而且由已经与 BSS 关联的客户端使用。 被动扫描通常需要更多时间，因为客户端必须监听并等待信标，而不是主动探测以找到 AP。被动扫描的另一个限制是，如果客户端在信道上等待的时间不够长，则客户端可能会错过 AP 信标。 主动扫描：通过扫描所有可能的信道并监听信标来发现网络被认为效率不高。为了增强这一发现过程，电台经常使用所谓的主动扫描。 在主动扫描模式下，站点仍然依次通过每个信道，但不是被动地监听来自 AP 的信号，而是发送探测请求管理帧，旨在询问该信道上有哪些网络可用。如果 IBSS 中的任何 AP 或活动站正在呈现该频率，则它们应该使用探测响应帧进行应答。   图 4.扫描方法   一旦发射站发出探测请求，它就会启动探测计时器倒计时并等待答复。该探测计时器值通常比信标间隔短很多。常见值在 10 毫秒范围内。在计时器结束时，站点将处理其收到的答案。如果没有收到答复，站点将移动到下一个频道（不同的频率）并重复相同的发现过程。 探测请求的目的通常是发现 AP 及其支持的网络（SSID 和/或 BSSID）。 图 5.探测请求/响应帧 该帧主要包含两个字段，SSID和移动站支持的速率。接收探测请求的站点使用该信息来确定请求站点是否可以加入网络。 探测响应帧字段与信标帧字段非常相似，使移动站能够匹配参数并加入网络。   2. 身份验证 通过探测请求/探测响应交换或监听信标进行网络发现后，想要加入网络的站点将经历身份验证过程，与接入点交换身份验证帧。在接收到认证帧后，AP 发送确认，然后发送认证响应。 “身份验证”帧的初始目的是验证设备类型，换句话说，验证请求站是否具有适当的 802.11 功能来加入网络。 开放系统认证：使用认证请求在站和 AP 之间交换与功能相关的信息。如果请求被接受，AP 将在身份验证响应中发送“成功”。 共享密钥认证：IEEE 802.11-1997 标准包含一个 WEP 共享密钥交换认证机制，称为“共享密钥”。此共享密钥交换在默认开放系统身份验证中添加了两个帧，从而实现了四帧交换。后一种方法称为共享密钥身份验证，需要使用 WEP 加密，目前尚未得到广泛使用（也不推荐使用）。 上面描述了身份验证的第一阶段，但是当使用 WPA 或 WPA2 时，身份验证的第二阶段（即设备关联后，会发生四次握手过程。 有关开放系统身份验证和共享密钥身份验证的详细信息，请参阅 802.11 安全帖子 。 图 6 。认证框架 如上所示，认证帧由以下字段组成。 认证算法编号：0 表示开放系统，1 表示共享密钥。 身份验证交易序列号：指示当前进度状态。 状态代码：0 表示成功，1 表示未指定的失败。 挑战文本t：用于共享密钥认证框架。 3. 协会 如果 802.11 身份验证阶段完成并返回成功结果，则站点将进入关联阶段。此次交换的目的是让站点加入网络并获取关联ID [AID]。 关联请求：关联阶段发送的第一帧是由请求站发送给 AP（或 IBSS 中的站）的。该帧为关联请求帧，该帧的响应为关联响应帧。 关联请求是单播管理帧并且总是被确认。 图 7.关联请求 关联响应：一旦关联请求得到确认，AP 就会检查请求的每个字段并验证它们都与其自己的 802.11 参数匹配（参见图 6）。如果参数不匹配，AP 会检查差异是否为阻塞，并据此发送身份验证响应。 - 如果参数差异是阻塞的，则将发送状态代码为 1 的响应（拒绝关联）。 - 如果参数无阻塞差异/无差异，则将向请求站发送状态代码 0（成功）和 AP 自己的参数的响应。站点必须与 AP 的功能兼容，否则它将放弃关联过程并开始寻找另一个 AP。 图 8.关联响应 连接拆除 解除关联：一旦站与 AP 关联，任何一方都可以随时通过发送解除关联帧来终止关联。 站点可以在离开当前网络漫游/加入另一个 AP 之前发送解除关联帧。 AP 可以在多种情况下发送此帧，例如，如果站点尝试使用无效参数、AP 本身的配置发生变化、黑客攻击等。 解除关联帧 (DA) 可以是要解除关联的站点的单播 MAC 地址，如果 AP 需要解除其网络中的所有站点的关联，则可以是广播地址。对于单播帧，接收站会确认该帧，而广播帧则不会确认。 图 9.解除关联帧 分离框架相当小。它仅包含一个字段“原因代码”。 已解除关联的站点仍需经过身份验证。它可以通过发送新的关联请求帧来尝试重新关联，并保持其认证状态。漫游到另一个小区的站点也可以选择使用解除关联帧，以便能够保持其认证状态，并在其认证超时到期之前漫游回同一小区时加速该过程。   图 10 。解除关联帧交换   当参数发生变化且站或 AP 需要重新协商通信参数时也会使用此帧。   取消认证：站点或 AP 也可以发送取消认证帧。当所有通信终止时使用此帧，例如，因为 AP 必须重新启动或因为站点停止其 Wi-Fi 通信。 当在身份验证完成之前接收到帧时也会使用它。例如，如果站点在执行身份验证序列之前尝试发送关联请求或数据帧，则站点将从 AP 收到取消身份验证帧，指示必须首先执行身份验证。该帧格式与解除关联帧相同。 图 11 。解除认证帧交换   漫游 在 802.11 无线网络中，漫游是指客户端将已建立的 Wi-Fi 网络关联从一个接入点移动到同一扩展服务集 (ESS) 内的另一个接入点，而不会丢失连接的过程（例如在定义的时间间隔内（通常在几秒钟的范围内）。为了获得更好的性能，漫游时间应该更短。 在漫游过程中，移动设备会向之前关联的接入点（AP）发送解除关联帧，并通过与设备想要连接的另一个接入点交换 802.11 帧来启动重新关联过程。客户端设备扫描另一个 AP，然后交换身份验证帧，之后它将发送重新关联请求，这里使用重新关联请求代替关联，并且连接过程的前两个步骤保持不变。 图 12 。漫游过程中的消息交换   图 13 。漫游代表   连接和断开过程中使用的 Wi-Fi API 下表显示了 NXP i.MX RT SDK 中用于连接和断开连接过程的一些可用 API。   表 1 。SDK 中可用的 API API 描述 可以从 wifi_send_scan_cmd 用于扫描可用网络。它仅支持基于单个 SSID 的扫描。我们可以将其扩展为多个 SSID 的列表。 站点和 AP wlan_add_network 将特定网络配置文件添加到已知网络列表。 站点和 AP wlan_remove_network 从已知网络列表中删除特定的网络配置文件。 站点和 AP wlan_连接 连接到特定网络（AP）。 车站 wlan_disconnect 断开站点与网络（AP）的连接。 车站 wlan_start_network 启动特定网络。 AP wlan_stop_network 停止特定网络。 AP 有关此类 API 的更多详细信息，请参阅文档“ MCUXpresso_SDK_WLAN_Driver_Reference_Manual.pdf ”可在 /docs/wifi 位置找到。