[参考译文] WL1837MOD：WiFi 在数天或数周后失败。 重启无法*恢复-需要关闭电源。

您好、Nick。

您正在使用的固件版本相当旧、您是否可以将其更新到8.9.0.0.90并重试？

以下是指向.90的特定提交的链接： https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/tree/?id=d2588c16809ecca8e0dc7ea011fc6180c7b08a92

使用最新的固件也需要驱动程序补丁、因此是此版本。

你好， Sabeeh Khan1.

 我所描述的一个已知的问题与.86固件?

我也很乐意更新驱动程序-您能告诉我在哪里找到补丁说明和最新固件吗？

谢谢。

-尼克

您好、Nick。

我们有补丁、但这些补丁是针对内核4.19创建的。 本指南指导您如何构建和编译补丁： https://www.ti.com/lit/swru561 

尽管该指南适用于 TI 器件、但 它们也应该适用于您的器件、因为内核驱动程序是相似的、注意到内核版本差异。  

你好， Sabeeh Khan1.

由于此问题可能需要数周的时间才能显现、因此我可以在重启器件之前做些什么来深入了解出现了什么故障？ 如前所述、重新启动无法恢复 WiLink 芯片。 WL_EN 在重新启动期间瞬间变为高电平、然后返回低电平。 似乎根本没有检测到芯片、因此通常由驱动程序提供的诊断不可用。  

对于此状态下的芯片、是否可以学习到任何内容？ 由于 MTBF 很长、因此进行更改和观察结果的做法不是一个有吸引力的选择。

再次感谢、

-尼克

您好、Nick。

重要的是、重启无法恢复 WiLink 芯片、即使在 WL_EN 变为高电平并变为低电平后也是如此。 在此状态下，是否可以提供重新启动的完整 dmesg 日志？

我想确认操作是否正确、就像我在电源复位之前所说的那样。  

嗨、Nick

此日志的奇怪之处是 mmc1探针根本未检测到卡。 我们应该会看到"mmc1：在地址 xxx 处检测到 SDIO 卡"或类似内容的打印输出。 一般来说、这会指向硬件问题、但奇怪的是、它是在第一次上电时工作的。

是否确定进入 WL18x 正在切换？ 重新启动时 SDIO 线路的状态与完整下电上电之间是否存在问题？  

您是否能够探测 CMD 和 CLK？  

命令是、CLK 编号

CMD 在启动期间会摆动(再次出现黄色轨迹)。  我将看到我能否在更高的速度下获得更好的捕获效果...

在1ms/div 条件下也是如此。

另一方面、SDIO 硬件实际上是 FPGA IP、FPGA 会复位、其位流会在重新启动时重新加载。 因此、SDIO 信号出现问题的可能性非常低。

我拿回来、SDIO 接口不是 FPGA IP、是分立的组件、只是 SoC 的一部分。  但是、它们应该在引导时进行重置和重新配置、而另一个 SDIO 接口是系统可靠引导的接口。

您好、Nick。

实际上、我想知道 Zynq SoC 及其 MMC 驱动程序是否存在问题。 在 Linux 中重新启动驱动程序应该可以顺利启动驱动程序、除非 WL_EN 或其他组件在硬件中存在问题(这种情况并非您正在切换的情况)。 SLOW_CLK 是由 SoC 生成还是由指定的 CLK 生成？

您是否可以尝试取消绑定 MMC 驱动程序并将其绑定回出现故障和工作状态？  

您好、Nick。

如果您能够、我建议在逻辑分析仪上探测 CMD、CLK 和 WL_EN。 我们需要了解所有这一切的时间安排、看看到底发生了什么。 您之前提供的 CMD 图表明 WL18x 芯片未同时启用。

你好， Sabeeh Khan1.

这将 是一个有点挑战、但我会尝试一下。

谢谢。

-尼克

你好， Sabeeh Khan1.

好的、不是我们要求的那样、但可能已经足够了。

我一次只能记录两个通道- 与两个或三个逻辑分析仪捕捉器相比、将两个示波器探针放到适当的测试点上要容易得多。

第一个迹线为 WL_EN (黄色)和 WL_CLK (红色)。

第二个迹线为 WL_EN (黄色)和 WL_CMD (红色)。

这足以表明 WL_EN 处于高电平、同时其他 总线活动正在进行。

我还尝试了探测 WL_IRQ、即使在重新启动过程中、它也会持续处于高电平。

WL_UART_DBG 在这里是否有用？

谢谢。

-尼克

WL_UART_DBG 在这里是否有任何用途？

很可能。 UART 线路仅在 FW 完成并将器件置于 DBG 模式后输出任何内容。

最好将 UART_DBG 作为完整性检查、但线路上不应有任何内容、因为器件的 WL_EN 已按复位状态进行切换。

我也尝试过探测 WL_IRQ，它连续为高电平

我对此有点怀疑。 我假设上电时、这条线路为低电平、但我无法解释为什么即使在将 WL_EN 设置为低电平后也会如此。 您是否会将该中断线路直接馈入 SoC？ 两者之间是否有缓冲器？ 您是否在 SoC 上启用了内部上拉电阻器？

你好， Sabeeh Khan1.

我将尝试看看 UART_DBG、以防万一。

WL_IRQ 直接连接到 SoC。 它具有外部10K 上拉电阻、最高可达1.8V、无内部上拉电阻。  

谢谢。

-尼克

好的、听起来不错。

就软件而言、您能再看一下 unbind 命令吗？ 在我的 AM335x 器件上、我可以使用以下命令解除绑定和绑定、如果有类似的内容、可以在此驱动程序目录中检查吗？  

$ CD /sys/bus/platform/drivers/sdhci-omap

$ echo 481d8000.mmc >解除绑定

$ echo 481d8000.mc > bind

你好， Sabeeh Khan1.

好的、我找到了 /sys/bus/platform/drivers/sdhci-arasan：

# ls -l
总计0
这家酒店

您可以找到这些内容、这样就可以进行调试了、而不必每次都重新启动。

很抱歉未指定、但您可以在工作板上尝试一下吗？ 一切都正常吗？

你好， Sabeeh Khan1.

很抱歉我自己没有想到这一点! ：-)

在一个工作设备上,unbind 关闭 wlcore 和 bind 使一切重新启动 -我想说它工作正常。 这 肯定会让测试更简单！

谢谢。

-尼克

你好， Sabeeh Khan1.

不幸的是、我的示波器探头有点笨拙、并且意外地导致 电路板暂时掉电。 这将重置 WiLink8、而 现在该器件当然正常工作。 我必须等待另一次失败。 :-/

它现在正在运行此固件：

chip.fw_ver_str =版本8.9.0.0.90
chip.phy_fw_ver_str =版本8.2.0.0.246

如果您能在失败前思考需要注意的问题、请告诉我。

我会联系...

谢谢。

-尼克

您好、Nick。

您是否可以共享 SoC 和 WL18x 原理图的一部分？

你好， Sabeeh Khan1.

原理图是开源的。 下面是 GitHub 上 PDF 的链接: Kortkl snickerdoodle。  

在我覆盖板之前、我无法探测 DBG_UART 信号、但 通过启用其输出有什么有用的东西可以学习吗？ 如果可以、我该怎么做？

谢谢。

-尼克

您好、Nick。

我看到您在 WL_IRQ 引脚上有一个上拉电阻器、因此 DBG_UART 将在正常运行时打印输出这些内容。 我们有一个公共工具、用于打印日志以用于固件调试。 我想要了解的是、在 WL_EN 切换后固件是否仍在运行。  

在你的 DTS ,你可以删除"wlcore"和"1831"或"1837"之一吗? 此外、我看到这里的数字"4"、它指向哪个中断类型？ 我想这是在上升吗？

wlcore：wlcore@0｛
    兼容="wlcore"、"ti、wl1831"、"ti、wl1837"；
    寄存器=<0x2>；
    INTERRUPT-PARENT =<&GPIO0>；
    中断=<0 4>；
  }；

你好， Sabeeh Khan1.

下面是我的更改：

中断类型4是电平敏感型、高电平有效。  

wlcore：wlcore@0｛
  兼容="ti、wl1837"；
   寄存器=<0x2>；
   INTERRUPT-PARENT =<&GPIO0>；
   中断=<0 4>；
}；

以下是更改前的 lsmod：

 更改后：

您可以将中断类型更改为上升沿吗？ 我想知道是否错过了中断以及导致了初始问题。 但这并不能解释为什么在 WL_EN 切换后 IRQ 保持高电平。  

以下是软件调试工具：

https://www.ti.com/lit/ug/swru435a/swru435a.pdf 

https://www.ti.com/tool/WILINK-BT_WIFI-WIRELESS_TOOLS 

你好， Sabeeh Khan1.

好的、/proc/interrupts 以前：

58：942401 0 Zynq-GPIO 0级 wl18xx

之后：

57：237 0 Zynq-GPIO 0 Edge wl18xx

"之前"来自不同的器件、因此 IRQ 编号不同。

不幸的是、我们正处于等待失败的状态、因此 很难仅仅因为它还没有失败就宣称事情进展得更好。 但 目前我们真的没有更好的选择。

我会看一下调试工具、并尝试检查调试 UART 的输出(如果有)。

谢谢。

-尼克

您好、Nick。

我会查看你的日志,并在下周回到你,因为感恩节假期。  不过、在执行这些命令期间是否有输出输出？

Zhijun Li2 said:

# echo e0101000.sdhci >解除绑定
#睡眠1
# echo e0101000.sdhci > bind

而且为了确认、unbind / bind 命令在工作单元上可以正常运行？

你好， Sabeeh Khan1.

命令不输出，但在 syslog 中：

11月22日21:31:02 localhost kernel:[1199301.057440] sdhci-arasan e0101000.sdhci:查找消费者 CD 的 GPIO
11月22日21:31:02 localhost kernel:[1199301.057460] sdhci-arasan e0101000.sdhci：使用设备树进行 GPIO 查找
11月22日21:31:02 localhost kernel:[1199301.057505] of_get_named_gpiod_flags:不能解析节点/amba/sdhci@e0101000[0]的'CD-GPIOs'属性
11月22日21:31:02 localhost kernel:[1199301.057541] of_get_named_gpiod_flags:不能解析节点/amba/sdhci@e0101000[0]的'CD-GPIO'属性
11月22日21:31:02 localhost kernel:[1199301.057564] sdhci-arasan e0101000.sdhci:使用查找表进行 GPIO 查找
11月22日21:31:02 localhost kernel:[1199301.05757575757] sdhci-arasan e0101000.sdhci:没有找到 GPIO 消费者 CD
11月22日21:31:02本地主机内核:[1199301.057595] sdhci-arasan e0101000.sdhci:使用程序的 GPIO 查找
11月22日21:31:02 localhost kernel:[1199301.057608] sdhci-arasan e0101000.sdhci：使用设备树查找 GPIO
11月22日21:31:02 localhost kernel:[1199301.057642] of_get_named_gpiod_flags:不能解析节点/amba/sdhci@e0101000[0]的'wp-gpios'属性
11月22日21:31:02 localhost kernel:[1199301.057676] of_get_named_gpiod_flags:不能解析节点/amba/sdhci@e0101000[0]的'wp-gpio'属性
11月22日21:31:02 localhost kernel:[1199301.057697] sdhci-arasan e0101000.sdhci:使用查找表进行 GPIO 查找
11月22日21:31:02 localhost kernel:[1199301.057711] sdhci-arasan e0101000.sdhci:没有找到 GPIO 使用者 WP
11月22日21:31:02 localhost kernel:[1199301.170194] mmc1：e0101000.sdhci [e0101000.sdhci]上的 SDHCI 控制器使用 ADMA

谢谢、祝您假期愉快。

-尼克

看起来是这样的。 这是来自目前没有使用 WiFi 的设备：

root@MUGS8-2002：/sys/bus/platform/drivers/sdhci-arasan # ip link show wlan0
6：wlan0： MTU 1500 qdisc noop 状态关闭模式默认组默认 qlen 1000
链路/以太网90：70：65：01：2c：cf brd ff：ff：ff：ff：ff：ff

root@MUGS8-2002：/sys/bus/platform/drivers/sdhci-arasan # echo e0101000.sdhci > unbind

root@MUGS8-2002：/sys/bus/platform/drivers/sdhci-arasan # ip link show wlan0
器件"wlan0"不存在。

root@MUGS8-2002：/sys/bus/platform/drivers/sdhci-arasan # echo e0101000.sdhci > bind

root@MUGS8-2002：/sys/bus/platform/drivers/sdhci-arasan # ip link show wlan0
7：wlan0： MTU 1500 qdisc noop 状态关闭模式默认组默认 qlen 1000
链路/以太网90：70：65：01：2c：cf brd ff：ff：ff：ff：ff：ff

您好、Nick。

查看这些日志、我看到的问题是、由于某种原因、Zynq 主机与 WL18xMOD 失去通信。 切换 ENABLE 引脚将清除 WL18x 的 RAM 并允许再次重新上传固件。 WL_EN 切换后、sdhci 驱动程序应立即探测 SDIO 器件(即 WL18x)、然后加载 wlcore 驱动程序。 然而，这种情况并没有发生，我们应该调查原因。

但是、我知道此问题仅在 WL18x 驱动程序发生崩溃时发生、unbind/bind 命令适用于未崩溃的 Wi-Fi 板。 WL18x 驱动程序可能存在错误、您能否将其中一个电路板更新为更新的内核？ 至少5.10？

你好， Sabeeh Khan1.

我drivers/net/wireless/ti从 Xilinx 的"xlnx_rebase_v5.15_LTS_2022.1_update"分支复制了目录的内容、并重建内核。 行为没有变化。  

 /sys/kernel/debug/mmc1/ios 中显示的电压不匹配是否不是问题？

root@MPM4-6001:/sys/kernel/debug/mmc1 cat ios
时钟：50000000Hz
实际时钟：49999999 Hz
VDD：7 (1.65 - 1.95V)
总线模式：2 (推挽)
芯片选择：0 (无关)
功率模式：2 (开)
总线宽度：2 (4位)
时序规格：2 (SD 高速)
信号电压：0 (3.30V)
驱动器类型：0 (驱动器类型 B)

谢谢。

-尼克

您好、Nick。

是的、信号电压电平无关紧要。 wlcore 驱动程序不会检测到它，也不会更改它的行为。 该值由较低级别的 MMC 驱动程序决定。

你好， Sabeeh Khan1.

之前讨论 WL_UART_DBG 时、可能发生了错误通信。 我指的是引脚42、数据表中将其描述为"选项：WLAN 记录器"。 我刚刚意识到、 GPIO 1和2 (引脚27和26)上提供了另一个 UART 功能 WL_RS232_TX/RX。 我尚未探测 TX 引脚-我目前正在等待 SBC 制造商关于相关测试点位置的消息。

数据表几乎不承认它的存在、只是说它"仅用于调试"。  是否有任何文档描述了此通信通道的使用？  

谢谢

-尼克

遗憾的是、测试点位于 SBC 的背面、难以接近。 我可以将引线焊接到测试点、但这需要切断器件电源并等待其再次出现故障。  

UART 信号会路由到 SBC 的"平台控制器"MCU。  另一种选择是 尝试处理那里的 通信、尽管从 Linux 到 MCU 没有方便的通信通道。

因此、首先要确定是否值得尝试通过 UART 接口与 WiLink 进行通信。

嗨、Nick、  

我不建议对 WL_RS232线路进行连接处理。 这些行用于连接到主机 PC、在其中用户可以运行名为"RTTT"的工具： https://www.ti.com/lit/ug/swau085f/swau085f.pdf 

它是一个用于校准和射频调试的工具。 这与您尝试使用通过 SDIO 进行通信的 Linux 处理器进行调试的活动无关。  

实际上、我有兴趣查看该器件是否响应任何 MMC 探头。 您之前分享了这张照片： /cfs-file/__key/communityserver-discussions-components-files/968/pastedimage1699564007248v2.png 如果您有逻辑分析仪、您能否在启动时放大显示 CMD 和 CLK 信号？ 了解器件是否有响应将有所帮助、因为它现在看起来像是刚刚完全断电了。  

Hi Sabeeh Khan1

我已成功在逻辑分析仪中捕获 WL_SDIO_CLK 和 WL_SDIO_CMD。 我有一个1.1 MB .csv 文件(从558 MB 减少),没有人希望我在这里张贴。

我在寻找什么？ 总捕获时间大约为7秒。 有两个部分 CLK 处于激活状态、一个部分 的时长约为26ms、另一个部分的时长约为21ms。 它们之间的间隙约为95ms。

第一个时钟从大约15ms 的400kHz 时钟开始、然后 CMD 上的第一个活动开始。 第二个示例类似、在任何 CMD 活动之前大约有12.5ms 的时钟。

如何判断芯片是否在响应？ 我是否还需要查看 WL_SDIO_D0？

谢谢。

-尼克

您好、Nick。

从捕获结果中、我们需要了解器件是否有响应。 主机 MMC 驱动程序将发送 CMD0和 CMD8等值、并且 WL8应对此做出响应。 如果 WL8做出响应、则主机 MMC 驱动程序存在问题。  

Hi Sabeeh Khan1

(经过编辑以包含正确的位流)。

我太了解了。 我的问题是如何识别来自芯片的响应、而不是来自驱动器的命令。  芯片会在 WL_SDIO_CMD 还是在 WL_SDIO_D0上响应？

这 是 WL_SDIO_CMD 的活动。 这两个本节之前、之间和之后都有许多1。

11001111110011000000000000000000000000000000000000000000001111000000000000000000000000000000000000111111000011111

11001111110011000000000000000000000000000000000000000000001111000000000000000000000000000000000000111111000011111

谢谢。

-尼克

Hi Sabeeh Khan1

我认为这些位模式仍然是错误的 -它们 会显示每一位两次。 如果我仅在 CLK 从低电平转换为高电平后查看 CMD、我会得到以下位模式：

11111111 011101000000000000000000000011000000000000111001 11111111

至少在正确的位置获得起始位和停止位、并且帧可以解析为 CMD52：

0 -启动
1 -发送

110100 -索引(CMD52、IO_RW_DIRECT)

0 - r/w (是否为0A 读取？)
000 -功能0
0 -原始标志
0 -物料
00000000000000110 -寄存器地址(6)
0 -物料
00000000 - 写入数据

0011100 - CRC
1 -停止

如果正确、则第二个位模式为：

0 -启动
1 -发送

110100 - CMD52

1 - r/w (1必须是写入)
000 -功能0
0 -原始标志
0 -物料
00000000000000110寄存器地址(6)
0 -物料
00001000 -写入数据

1001111 - CRC
1 -停止

drivers/net/wireless/ti/wlcore/sdio.c 定义  

静态结构 wl1271_if_operations SDIO_ops =｛
  .read = wl12xx_SDIO_RAW_READ、
  .write = wl12xx_SDIO_RAW_WRITE、
  .power = wl12xx_SDIO_SET_POWER
  .set_block_size = wl1271_SDIO_set_block_size、
}；

 wl12xx_sDIO_RAW_WRITE 使用了 CMD52、因此这可能是合理的。

不过、在两种情况下、芯片似乎都没有任何响应。

我找到了一些描述 CMD52的 SDIO 文档、写入0x6 = 0x8是一个复位命令。

-尼克

您好、Nick。

我同意该部分似乎没有回应。 这使我认为32kHz 慢时钟在器件重新启用时不工作。  根据数据表中的时序图、这是必要的元件：

我在原理图上对这部分进行了更深入的研究、我有点困惑。 在我看来、慢速 CLK 由晶体供源、此晶体驱动 WiLink 和 Zynq SOC。 那个时钟 电路是否可能出现问题？ 晶体的使能引脚是否会改变状态？   

我认为晶体已暂时禁用、从而导致了一些时序问题、因此需要重新上电。 在进行研究的同时、作为一个调试项目、您可以将晶体从 Zynq SOC 中分离并馈入外部晶体、然后运行多日测试以查看问题是否再次出现？  

我还想、 由于晶振也在为 Zynq 供源、Zynq 也会出现问题、但是它听起来并不像这样。  

你好， Sabeeh Khan1.

32KHz 振荡器仅为 WiLink 和 STM32 MCU 提供时钟信号。  STM32实际上并不用于其当前配置中的任何东西。 我已要求制造商确定 TP123的位置。 如果可以从电路板的正面接触到它、我将在它上面粘上一个示波器探针、看看是否有信号。

该假设与观察到的行为一致-重新启动器件 仅影响 ARM 处理器、而不影响 STM32 MCU、而移除电源显然会影响一切。

谢谢。

-尼克

你好， Sabeeh Khan1.

遗憾的是、一切都在电路板的背面、不容易接近。 为了完成更多工作、我可能必须关闭设备电源、这意味着要等待再次发生故障。 当我有更多的事情需要报告时、我会告诉您。

谢谢。

-尼克

Hi Sabeeh Khan1

我有新闻和一些问题。

我修改了 STM32平台控制器的固件、以允许 在运行时更改 GPIO 引脚的状态。 其中一个引脚是32KHz 振荡器的"使能"输入。 这允许我随意禁用和重新启用它。  

我发现、禁用振荡器(至少、将 控制其使能输入的 GPIO 引脚取消置位)有时会导致 WiLink8失败、但并非总是如此。 如果没有失败、我可以让振荡器保持禁用状态、然后使用 unbind/bind 尝试重置芯片的 WiFi 端、使其失败。 这最终会导致芯片发生故障、从而产生一个至少似乎与我们一直在研究的无端故障相同的状态。  

即使重新启用32kHz 振荡器、解除绑定/绑定也不会恢复芯片；但是...

如果我将控制 BT_EN 输入的 GPIO 输出设置为0、则可以通过 unbind/bind 恢复 WiFi 功能。 如前所述、我还没有机会在单独发生故障的器件上尝试该功能、但这确实引发了一个关于 BT_EN 在这一切中的作用的问题。

这是预期行为吗？  在使用 WIFI_EN 重新加载芯片固件之前、是否应该必须取消置位 BE_EN？

我们根本不使用 BT、因此无需将 BT_EN 置位。

是否有任何这种方法可以让您了解正在发生的情况？

谢谢。

-尼克

您好、Nick。

BT 是完全独立的内核、因此我不认为这是问题所在。 不过、如果您不使用 BT、则可以将该线路置为无效。  

我不知道此类问题、但我想从您的测试中了解禁用 BT 是否能解决您的问题。 如果是、这是我们必须进一步研究的问题。  

你好， Sabeeh Khan1.

我会一直提醒您。  

我想弄清楚、对 BT_EN 取消置位是否代表了针对尚 不太了解的故障的权变措施、或者它是否可以完全防止故障发生。 无论是哪种情况、我都认为了解 问题的根本原因非常重要。

我首先计划确定 当器件发生故障而又没有由于禁用32KHz 振荡器而引起的情况下、取消置位 BT_EN 是否可以恢复 WiFi 功能。 如果成功、我将在启动时使 BT_EN 无效、并开始等待、以查看这是否可以防止失败。 由于通常是在发生故障前数天、因此可能需要一段时间来确定测试是否成功。

谢谢。

-尼克

Hi Sabeeh Khan1

我 再次观察到失败,并能够 执行几乎我计划的过程。 遗憾的是、我只在重启设备后才发现 WiFi 故障、我认为应该没有什么区别、但仍然不是我想要的。

在演示过上述解除绑定/绑定过程无法恢复器件后、我将 BL_EN 取消置位并重复此过程。 这次它成功地恢复了 WiFi 功能。 我确实需要运行 netplan 来启动接口、但这是 预期的行为、因为使用非功能 WiFi 芯片重新启动设备。

所以- 似乎 BT_EN 确实影响了芯片的 WiFi 端。 这可能代表故障的权变措施、但当然不能解释故障原因。 这可能需要 TI 进一步关注。

我仍然需要测试两种情况。 首先是尝试恢复 WiFi 功能后无故丢失,但没有中间重新启动。 其次是在启动时使 BT_EN 无效、然后查看是否根本发生故障。 我的其中一台设备似乎在一周内可靠地(如果是正确的话)出现故障。

谢谢。

-尼克