这轮要调的是全志T527平台上的AP6256，一颗非常常见的WiFi+BT二合一模组。BSP调试系列写到第16篇，前面把电源、时钟、相关外设理得差不多了，这次的目标很纯粹：让板卡起来之后能稳定识别wlan0，能扫描、能连接、能跑满吞吐，同时蓝牙打开时不把WiFi拖死。这篇就把整个调试过程拆开讲，从驱动选型、设备树配置，到固件nvram踩坑，再到实测跑流的排查思路，一条线捋下来。适合正在做Linux/Android BSP的工程师参考，也适合刚入行嵌入式驱动、想知道一份正经WiFi调试报告里到底该关注哪些细节的朋友。
1. 项目背景：为什么是AP6256，板级方案怎么搭
1.1 T527与AP6256这套组合在做什么
全志T527定位的是工业级、AI边缘侧的应用处理器，Cortex-A55架构，外设接口很全，多路SDIO/MMC、以太网、显示和摄像头都有，常见于工控HMI、电力网关、边缘计算盒子这类产品。WiFi选型往往会看成本和驱动成熟度，AP6256恰好卡在这个平衡点上。
AP6256是支持2.4GHz和5GHz双频的802.11a/b/g/n模组，蓝牙5.0，WiFi走SDIO接口，蓝牙走UART接口。从芯片体系来说，它属于Cypress/Infineon那一脉的方案，很多全志BSP里默认就带了对应驱动目录，固件包也是现成的。对你来说意味着不需要从零移植，主要工作集中在设备树配置、固件加载、射频调优和稳定性验证。
这套组合的最典型应用场景是“系统跑Linux，WiFi做数据回传，蓝牙做近距离配置或者音频链路”。T527算力足够，AP6256的WiFi速率虽然上限是802.11n，但对大多数物联网设备和工业HMI来说已经够用。真正需要花精力的不是速率上限，而是信号稳定性和共存表现。
从调试角度，我习惯先做一张硬件信息速查表，把关键信号、供电轨、GPIO编号、时钟来源全部列出来。原因很简单：软件问题可以靠log定位，硬件连接问题会让你在log里来回绕圈，越早确认物理层越省时间。
| 信号 | 方向 | 说明 |
|---|---|---|
| SDIO_CLK/CMD/D0-D3 | WiFi数据 | 4-bit SDIO，频率一般50MHz左右 |
| WL_REG_ON | 输入 | 控制WiFi子系统的电源/复位，高有效 |
| BT_REG_ON | 输入 | 控制蓝牙子系统的电源/复位 |
| HOST_WAKE/DEV_WAKE | 中断 | 用于SDIO带内唤醒和主机交互 |
| UART_TX/RX | 蓝牙HCI | 蓝牙数据通道，常用1.5Mbps或4Mbps |
| 32.768kHz | 输入 | 低功耗时钟，休眠时保持 |
这张表不复杂，但每次调试前我都会重新对着原理图核对一遍。AP6256这类模组，翻车高发区往往不是主数据通路，而是控制GPIO和供电时序。
1.2 硬件与上电时序：调试前先看明白物理层
做BSP调试，第一件事不是改内核，而是确认上电时序。AP6256对电源时序有明确要求，大致流程是：先给主电源，再给IO电源，然后等电源稳定，最后拉高WL_REG_ON。如果是用同一个GPIO同时控WiFi和蓝牙的复位，还要额外确认两个子系统的先后关系。
全志平台里比较省事的做法是用mmc-pwrseq-simple，在设备树里声明reset-gpios，让内核在SDIO探测前自动完成上下电。但前提是硬件上WL_REG_ON必须接到这个GPIO上，并且供电轨已经由PMIC或LDO默认打开。我遇到过好几次“dmesg里完全没有mmc设备”的案例，问题根源都是WL_REG_ON被外部拉低或者供电轨没有真正使能，跟驱动半毛钱关系没有。
时序上还有一个容易被忽略的点：32.768kHz时钟。AP6256在低功耗模式、蓝牙扫描和WiFi休眠唤醒时依赖这颗时钟。如果时钟没起振，表现往往很神秘，比如休眠后唤醒概率性失败，或者蓝牙连接后一段时间就断开。调试时不要只看WiFi log，要拿示波器确认晶体波形，或者查驱动里关于low power clock的日志。
另一个物理层重点是SDIO的信号质量。4-bit SDIO跑50MHz，对走线长度和串阻匹配还是比较敏感的。T527这类处理器SDIO控制器本身驱动能力不弱，但如果板子上SDIO走线过长、过孔太多，或者串阻选得过大，都会导致高速读写出错。这类问题在WiFi场景下的表现不是一开始就报错，而是吞吐忽高忽低、长时间传输后挂掉，非常容易误判成驱动bug。
我的建议是：拿到新板子，先用示波器看一眼SDIO_CLK和CMD线上的信号沿，特别是上升沿和振铃。如果边沿明显畸变，优先调整串阻阻值或SDIO时钟频率，再往下走软件调试。
2. 内核驱动选型与设备树配置
2.1 bcmdhd还是brcmfmac：驱动选型的取舍
全志T527的SDK里，对AP6256这类模组通常预置的是bcmdhd驱动，这是博通/赛普拉斯体系在老Android和全志方案中常见的驱动，特点是功能全、私有命令丰富，支持AP模式、P2P、WOW等，很多物联网方案都用它。主线内核里对应的则是brcmfmac驱动，风格更Linux化，和cfg80211框架整合得更好。
这两条路我都走过。用bcmdhd的好处是，全志的BSP已经把固件路径、GPIO映射、SDIO探测这些封装好了，拿到手一般能快速跑起来，而且它支持很多方便的量产测试命令，比如查看速率、调整发射功率、开启FTP模式做工厂射频校准。坏处是它和主线内核的API容易脱节，升级内核版本时可能得自己打补丁。
用brcmfmac则更贴近社区，开发资料多，但有些AP6256特有的私有参数和FTM测试能力不一定完整支持。如果你量产的产线依赖特定命令测射频指标，一定要先确认驱动是否支持，否则后期还得切回bcmdhd重测一遍。
我在这个项目里最终选了bcmdhd，主要原因是产线需要稳定的FTM测试模式，而且全志SDK中配套的内核补丁、配置文件、固件对较好，可以省去很多适配时间。对纯Linux产品、不依赖私有命令的场景，我反而推荐直接试brcmfmac，主线驱动的好处后续维护时会慢慢体现出来。
驱动选型一旦定了，后续所有调试都围绕它展开，所以这是第一个要认真拍板的点，不要只凭“哪个看着新”做选择。
2.2 dts中WiFi节点的完整配置思路
设备树是整个WiFi调试里最具体、也最需要对着原理图改的部分。以典型全志平台为例，WiFi模组挂在mmc2控制器上，配套一个mmc-pwrseq节点负责控制WL_REG_ON。一个可以跑通的参考结构类似下面这样：
/ { wifi_pwrseq: wifi_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&wifi_wl_reg_on>; reset-gpios = <&pio 4 7 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <10>; }; }; &mmc2 { status = "okay"; vmmc-supply = <®_vcc_wifi>; vqmmc-supply = <®_vcc_wifi_io>; mmc-pwrseq = <&wifi_pwrseq>; bus-width = <4>; non-removable; cap-sdio-irq; keep-power-in-suspend; };这段代码里的GPIO编号、regulator名称必须根据实际原理图修改。reset-gpios在模块上通常接到WL_REG_ON，低有效还是高有效要看模组手册，AP6256一般是高有效启动，但有些板子中间加了反相电路，所以不要想当然。
有几个设备树属性值得专门说。non-removable告诉内核这块SDIO设备不是可插拔的，避免系统做热插拔检测和轮询，否则每次扫描都会多出一些不必要的时间开销。cap-sdio-irq让内核允许SDIO设备通过D1中断唤醒主机，这是WiFi芯片向主机上报接收事件的重要机制，不加的话可能会出现在低负载时吞吐很低或者延迟偏高的情况。keep-power-in-suspend则是让系统休眠时不要切断WiFi电源，保证可以配置Wake-on-WLAN。
还有一个容易忽略的配置是vqmmc，也就是SDIO IO域电源。这个电压必须和AP6256的IO电平匹配，常见的是1.8V或3.3V，同时还关联到内部电平转换。如果vqmmc配错，现象通常很诡异：内核能枚举到SDIO卡，也能加载固件，但一旦传输数据量大一点就报CRC错误或者直接卡死。我习惯在调试初期就把vmmc/vqmmc对应的电压实际量一遍，确认和dts里写的一致。
pinctrl也不只是摆设。mmc2_pins要确保SDIO的CLK、CMD、D0-D3四个IO都被正确复用成mmc功能，而且上下拉状态不能冲突。SDIO总线有些信号是需要上拉的，如果被复用成其它外设或者默认下拉，会导致识别不到设备或者识别不稳定。
2.3 内核配置项：哪些必须打开
dts配好之后，内核编译选项不对等于白搭。bcmdhd路径下要特别留意几个开关：
CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_BT=y CONFIG_BT_HCIUART=y CONFIG_BCMDHD=y CONFIG_BCMDHD_SDIO=y CONFIG_WIFI_BROADCOM_BEAMFORMING=y CONFIG_CFG80211=y CONFIG_MAC80211=y如果走的是brcmfmac路线，则对应换成CONFIG_BRCMFMAC=y和CONFIG_BRCMFMAC_SDIO=y。WiFi始终绕不开CFG80211，这个一定要开启，否则应用层工具iw、wpa_supplicant都跑不起来。
蓝牙部分也值得提前确认。AP6256的蓝牙走UART，需要开启CONFIG_BT_HCIUART，并在内核启动参数或设备树里声明蓝牙UART节点。很多调试者只关注WiFi，蓝牙迟迟不通，最后发现是HCI UART的中断没配，或者GPIO的BT_REG_ON一直处于低电平。所以在这一步就把蓝牙的dts也一并检查，不要等到WiFi调完再回头折腾。
另外全志平台通常还有电源管理相关的配置，比如CONFIG_PM、CONFIG_PM_SLEEP，它们直接关系到WiFi休眠唤醒是否可用。如果产品需要低功耗待机，这些选项也要提前确认，不然后续做功耗时发现WiFi无法进入低功耗状态，又得回来补配置。
3. 固件与nvram管理：最容易翻车的文件细节
3.1 固件加载路径与排错顺序
AP6256这种模组，芯片本身不带WiFi固件，所有协议栈、射频参数都得靠系统启动时加载的固件和nvram。固件文件一般包括WiFi主固件、nvram配置、以及蓝牙的HCD补丁文件。在全志SDK里，常见的放置路径是/lib/firmware/ap6256/或者/vendor/firmware/，具体以SDK和模组厂商给定的包为准。
调试的时候，我最先看的永远是dmesg里固件加载相关的日志。正常的probe过程大致会看到这类信息：
mmc2: new high speed SDIO card at address 0001 bcmsdh_sdmmc: bcmsdh_sdmmc_probe enter bcm_wlan_get_oob_irq: host_wake dhd_module_init: firmware path = /lib/firmware/ap6256/ dhd_attach: ... dhd_wlan_init: ...如果log停在某一步没有下文，优先检查这个路径下文件是否存在、文件名是否匹配、以及rootfs是否有权限读取。有一个常见坑：文件在SD卡或独立分区里，但驱动probe时rootfs还没挂载好，导致firmware request失败。这时候可以看dmesg里有没有fallback提示，或者直接fwk加载失败。全志的BSP通常会把这些文件编进rootfs，但如果你改了分区表或rootfs打包方式，就很容易踩中。
固件加载失败不要上来就调驱动。先把驱动源码里firmware_path的默认值和dmesg实际打印的路径对齐，再确认文件MD5和原始固件包一致。尤其是从旧板子拷贝固件、或者从网上随手下载固件的情况，版本不一致会带来很多莫名其妙的问题。AP6256的固件目录在驱动里可能写死，也可能会读取dts里的firmware_path属性，改动后记得重新编译和打包。
蓝牙固件同样有加载顺序问题。WiFi和蓝牙共用同一个模组，但固件加载分成两条链路。WiFi固件由SDIO驱动负责，蓝牙固件的HCD补丁通常由蓝牙UART驱动在打开蓝牙时加载。很多板卡出现“蓝牙设备能注册，但一连接就断开”的问题，就是因为HCD补丁版本和主WiFi固件不匹配。我的建议是统一从模组厂商拿一套完整的固件包，不要混搭不同batch的文件。
3.2 nvram参数中值得关注的几个关键项
nvram是AP6256调试里最容易出“玄学”问题的地方。它本质是一份文本格式的射频驱动参数表，驱动加载固件后会读入这些参数来配置信道、功率、天线、晶体频率等。不同板厂、不同天线设计的nvram差异极大，直接复制参考板的有时候也能跑，但性能和稳定性不会好。
| 参数 | 作用 | 调试时的影响 |
|---|---|---|
| macaddr | MAC地址 | 如果缺失或全0，部分驱动会生成随机MAC，影响管控类设备注册 |
| ccode | 国家码 | 决定可用信道和最大发射功率，影响扫描信道列表 |
| xtalfreq | 晶体频率 | 单位kHz，常见26000或37400，写错会导致频偏和断链 |
| boardrev | 板级版本 | 驱动内部射频参数索引，不同板号对应不同校准策略 |
| pa0maxpwr | 2.4G射频功率上限 | 影响信号强度和吞吐，调节不当可能导致实际发射功率异常 |
| pa1maxpwr | 5G射频功率上限 | 5G频段同理，通常还关联多个功率分级参数 |
这几个参数里，xtalfreq是我认为最值得第一个检查的。AP6256模组一般用26MHz或37.4MHz的晶体，如果nvram里写的值和实际晶振频率不一致，WiFi可能还能连上，但蓝牙会频偏明显，而且WiFi在长时间运行后出现偶发断链。这种问题非常坑，因为用仪器测射频指标时可能一切正常，跑长时间老化就露馅。
ccode同样要重视。如果你在中国大陆销售，通常设成CN；如果做出口，就要按目标市场设置。ccode不对会导致扫描不到某些信道，或者5G频段很多热点不可见。很多人以为“WiFi能扫到就是ccode没问题”，其实5G频段的可用信道差异非常大，必须按法规和运营商需求逐一核对。
量产阶段，nvram里的macaddr一般不会直接生效，而是由工厂在量产工具或UBOOT阶段写进OTP/分区。但研发阶段你可能需要固定一个MAC来调试网络应用，这时可以用ifconfig临时设置，或者让驱动支持从dts读取mac。我建议在调试初期就确认量产写MAC的方案，别等到量产阶段才发现驱动根本没实现读取接口。
4. 实测全流程图：从probe到跑流量的关键节点
4.1 启动阶段的log检查
软件配置全部就位后，第一次启动一定要盯着dmesg看完整流程。不要急着打开wpa_supplicant，先把SDIO枚举、驱动attach、固件加载、网卡注册这几个阶段全部确认清楚。
我常用的检查顺序是：
dmesg | grep -i "mmc2" dmesg | grep -i "dhd\|brcm" ls -l /sys/bus/sdio/devices/ ifconfig -a第一眼要看的是mmc2是否像预期那样枚举出了SDIO卡。如果这里就失败了，说明问题在电源、时钟、SDIO总线或pinctrl，固件和驱动根本还没参与进来。可以继续用cat /sys/kernel/debug/mmc2/ios查看当前SDIO速率和电压，帮助判断总线是否初始化正常。
看到SDIO卡地址之后，再确认驱动是否attach成功。bcmdhd的日志通常会打印firmware path和nvram path，此时如果文件路径不对，报错信息非常直接。网卡注册成功的标志是出现wlan0接口，这一步之后才轮到应用层调试。
有一个容易被忽略的点是驱动里“power down after probe”的逻辑。部分SDK驱动为了省电，会在启动阶段先探测设备再马上关电，等用户执行ifconfig wlan0 up时才真正拉高WL_REG_ON。如果你用ifconfig wlan0 up后仍然看不到设备，不要只查硬件，重点看驱动log里有没有关于power state的切换。
启动阶段的log我通常会保存一份完整的基线，后续每次改动都拿新log和基线对比。这样做有两个好处：一是出问题能快速定位是哪一段变化引起的，二是做现场支持时不用反复复现全套流程，一份基线log就能说明大半问题。
4.2 扫描、连接、DHCP的日常调试
wlan0起来之后，日常调试的第一步是扫描测试。手动操作时比较直接：
ip link set wlan0 up iw dev wlan0 scan | head -50如果扫描结果为空，第一个怀疑对象是信道或国家码问题。把ccode改成当地规范再看；如果还是扫不到，就要看天线是不是没接、或者射频电路是否存在异常。AP6256是双频模组，5G扫描需要在driver里启用band，某些驱动的默认配置可能只启用2.4G，这时5G AP就完全看不到。
扫描正常后开始连接。这里我建议直接用wpa_supplicant手动起一个临时进程，比依赖NetworkManager一层层排查更快：
wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf udhcpc -i wlan0wpa_supplicant.conf里填写正确的SSID和psk，注意加密方式要匹配。AP6256驱动对WPA2-PSK支持很成熟，但如果AP是WPA3-only，就要确认驱动和wpa_supplicant版本是否支持SAE，否则会出现“能扫描到但连不上”的经典现象。
连接阶段最常见的log提示是4-way handshake timeout或者反复的CTRL-EVENT-DISCONNECTED。这类问题大概率不在驱动本身，而是AP侧配置和客户端能力不匹配，比如AP开启了PMF强制、同时禁用了WPA2兼容。调试时先用手机或电脑连同一个AP确认AP本身没问题，再回来查设备端。
DHCP环节也有一个常见坑：如果板子网络配置了静态IP，或者多网口场景下默认路由被其它网口抢走，会出现“WiFi显示已连接但ping不通网关”的现象。我习惯先用ip addr看wlan0是否拿到地址，再检查ip route确认默认路由走的是不是wlan0。这一点在全志这类多网口平台上非常常见。
4.3 吞吐与射频性能实测
连接正常之后，别急着宣布调完。WiFi调试的核心指标是吞吐和稳定性，我用iperf3做局网测试，服务端和客户端分别放在两台设备上：
iperf3 -s # 在AP侧或PC上运行 iperf3 -c 192.168.1.100 -t 60 # 在板卡上运行测吞吐时要注意几点。第一，确保无线环境干净，尽量使用5G频段和40MHz带宽，周围不要有太多同频AP。第二，关闭TCP offload相关的干扰，先测UDP摸到物理层上限，再测TCP看协议栈表现。第三，把传输功率固定好，不要在自动功率调节下对比数据，否则数值忽高忽低很难分析。
802.11n的两条流，理论上2.4G链路速率能到72Mbps或150Mbps，5G链路能到300Mbps左右。实际吞吐会因为距离、天线、干扰掉一截，但如果UDP吞吐连理论速率的一半都达不到，就需要往射频方向查了。先看速率协商结果：
iw dev wlan0 link确认当前协商的tx/rx位速率和带宽。AP6256在802.11n下如果只协商到20MHz带宽，吞吐必然受限。这时可以检查AP侧的频宽设置和驱动是否启用了HT40。
天线的影响最容易忽略。AP6256参考设计通常预留了两路天线，如果其中一路没接或者天线弹片接触不良，接收灵敏度会明显劣化。表现就是近距离测试时吞吐还可以，稍微远一点或者隔一堵墙就掉得厉害。我测过的一些板子，天线方向装反导致后续测试反复异常，最后用衰减器做固定衰减对比才定位出来。
射频性能还涉及发射功率检查。bcmdhd驱动提供了一些私有工具和debugfs接口，可以在固定功率下做验证。产线上的FTM模式一般是在驱动加载后进入工厂测试模式，通过专用串口或网络工具读取RSSI、频偏、发射功率和接收灵敏度。这部分强烈建议在研发阶段就让产线工程师介入一起验证，别等到量产才发现测试工具和驱动版本不兼容。
4.4 蓝牙共存：为什么开了BT后WiFi掉速
AP6256是WiFi和蓝牙二合一模组，两者共用天线和射频前端。2.4G WiFi和蓝牙在同一个频段内工作，同时收发时必然存在冲突，芯片内部有一套共存仲裁机制。如果你的产品必须同时高频使用蓝牙和WiFi，这部分一定不能跳过。
最常见的现象是：蓝牙连接耳机或进行音频传输时，WiFi吞吐明显下降，甚至出现周期性丢包。这不一定说明WiFi有问题，可能是共存策略没有配置成适合你产品形态的模式。bcmdhd驱动一般会通过模块参数或私有命令调整共存策略，比如给蓝牙音频更高优先级、或者反过来保证WiFi数据优先。
AP6256的共存协调主要依赖芯片内部机制和驱动配置，但板级设计也会影响效果。蓝牙UART的流量如果占用过高、或者HCI层频繁重传，会加剧2.4G频段的拥挤。遇到掉速问题时，建议先把蓝牙源换成固定间隔的短数据包测试，比如简单的蓝牙HCI日志或音频回环，观察WiFi吞吐的变化曲线。
我最开始测试时也踩过这个坑。WiFi单独跑iperf很稳定，一旦蓝牙连接音箱，WiFi吞吐掉到原来的三分之一。排查了一整天，最后发现是板子上WiFi和蓝牙的天线匹配网络有个元件贴错位置，导致共存隔离度下降。也就是说，如果你排除了驱动策略问题，还是要回到射频电路层面去看隔离度。
5. 量产前最值得做的一轮稳定性检查
5.1 稳定性测试清单
研发阶段“能连上、能跑通”只是第一步，真正决定项目能否量产的是稳定性。WiFi模组在使用环境里会面对各种干扰、温度变化和电源波动，很多问题要跑几个小时甚至一整天才能复现。
我习惯在量产前做这么一轮检查：
| 测试项 | 时长/次数 | 通过标准 |
|---|---|---|
| 长时间iperf UDP传输 | 12小时 | 无断流，吞吐波动小于10% |
| TCP混合传输与外网下载 | 2小时 | 无明显卡死或重连 |
| 多个AP漫游切换 | 30次 | 切换后可自动重连 |
| 休眠唤醒后WiFi重连 | 50次 | 唤醒后30秒内恢复 |
| 蓝牙+WiFi并发 | 2小时 | 蓝牙音频不卡顿，WiFi吞吐不低于额定值 |
| 温度循环（-20℃到60℃） | 3轮 | 全程不出现固件加载失败 |
这个清单看着繁琐，但每一项背后都有实际教训。12小时UDP测试主要揪出SDIO时序问题，这类问题在高负载下会积累CRC错误，最终导致模块挂掉。漫游切换则验证驱动和wpa_supplicant的事件处理是否存在卡死路径。休眠唤醒项对IoT设备尤其重要，很多设备平时处于低功耗模式，唤醒后网络能不能快速恢复直接决定产品可用性。
测试期间要保留完整日志。我会用串口把内核log输出到文件，同时用脚本周期性记录iw dev wlan0 link和dmesg tail，这样出问题时能回看是哪个时间点、哪个环节开始异常。不要等到设备完全断网才去抓log，WiFi问题很多时候是“先出现大量重传，再彻底断掉”，早期日志才是定位关键。
5.2 几个“玄学”问题与真实根因
做WiFi调试久了，会遇到一些看起来特别玄学的问题。这里分享三个我实际碰到过、并且最终都找到了明确根因的案例。
第一个是“传大文件必死，但小包完全正常”。现象是iperf跑几秒就断，甚至整个设备死机。排查到最后是SDIO时钟频率过高，板子上的信号完整性不足以支撑高速模式。解决办法是把mmc控制器频率从高速档降到稳定档，并加上合适的串阻。类似问题不一定是驱动bug，有时候降低一档传输速率，系统反而稳定得多。
第二个是“温度一高就搜不到网”。板卡在低温环境下一切正常，温度上升到60℃左右WiFi就开始扫描为空或频繁断开。最后查下来是模组附近的一个LDO在高温下输出纹波变大，导致射频灵敏度恶化。这类问题用万用表静态量电压是量不出来的，必须拿示波器在高温箱里抓实际波形。所以我会在量产前明确要求测试电源纹波，特别是3.3V和1.8V两路WiFi供电轨。
第三个是“同一个板子，第一批正常，第二批全挂”。这种往往是物料批次差异或者生产装配问题。有一回我遇到一整批板子WiFi吞吐偏低，排查很久发现是天线FPC的型号被替换成了不同阻抗的版本，虽然接口一样，但匹配完全不对。这个教训说明：量产前的关键物料变更一定要重新做射频验证，不要认为“连接器一样就能互换”。
玄学问题的共同点是表象很难解释，但根因基本都是物理层或者物料层面的确定性缺陷。我的处理原则是：当软件参数已经调到文档建议范围，问题依旧时，马上把注意力转回硬件，而不是继续在驱动里盲目试参数。
6. 压箱底的调试习惯
做BSP调试这么多年，我越来越觉得WiFi模组的适配没有太多黑魔法，就是一套可重复的排查顺序：先电源时序，再SDIO枚举，再固件加载，再扫描连接，再吞吐，再共存，最后量产稳定性。每一步都有明确的通过标准，不满足就回到上一个环节找原因，这样能少走很多弯路。
另外有一个习惯很值得养成：每次调试进展到一个稳定状态，就用脚本把当前内核配置、dts、nvram、固件版本完整记录到一个变更文件里。不要只记录“我改了某个参数”，要记录改前改后的log和测试数据。因为WiFi问题很多时候是多因素叠加，你回头看时如果缺少基线，根本说不清到底是哪一步挽救了这个项目。
AP6256在全志T527上的这次调试，最后能顺利收尾，很大程度归功于前面几篇BSP调试打下的基础。电源、时钟、SDIO这些基础节点如果前期没有确认好，WiFi层的排查就会变成无底洞。这里也建议大家在做这类带射频模组的项目时，把前期的硬件信号完整性检查和系统基础外设调试都当成WiFi调试的一部分来做，很多所谓“WiFi问题”，其实在更底层就已经埋下隐患。
