[参考译文] CC3350：当使用 RTOS 通过 SDIO 控制 CC3350 时、IRQ_WL 在 BFFC 之后不会设置为 L（状态读取）

我会发布信号的图片。

步骤 1 到步骤 4 的所有中断信号

BFFC 命令开始（读取命令）

你好 Satosi-san！

对延误表示歉意。

我们正在研究这一点、同时您能否为我们提供：

- mcu？

- SDK？

此致、

AB

您好 AB-SAN！

我认为这是一个 MCU 问题。

在我的最后一个帖子之后、我回顾了主机发送到 CC3351 的命令是否正确。

我发现了一些错误、但尚未解决。

我发现、将“IOE1 (SDIO Func1 Enable)“设置为 1 后、即使等待一段时间、“IOR1 (SDIO Func1 Ready)“也不会变为 1。

下面是我当前程序中主机和 CC3351 之间的所有 CMD 交换。

有什么错误吗？

我还注意到、使用写入命令 53 将似乎是流控制的波形插入 DAT0 线路中。

此致。

MPU

 Renesas RZ/A1H (Arm Cortex-A9)

SDK 中找到

 https://www.ti.com/tool/CC33XX-SOFTWARE

 CC33XX-RTOS-MCU 提供同步降压控制器  

 CC33xx MCU 封装 R5 版本

您好 AB-SAN！

我在上一篇文章的表 中发现了一个错误,其中 sdioAdapt_read () 或 sdioAdapt_write () 发送的 ARG 中的“函数编号“是 0 而不是 1。
这与“IOR1（SDIO Func1 就绪）“不变为 1 的问题无关。

此致。

您好、

您能分享一下 Saleae RAW 捕捉的逻辑吗？

Shlomi

你好 Shlomi-San！

这是逻辑 Saleae 原始捕获结果。

e2e.ti.com/.../saleae.zip

在我上次发布后、我在 Linux 驱动程序中找到了以下代码：

static int sdio_cc33xx_probe(struct sdio_func *func,
				  const struct sdio_device_id *id)
{

	/* We are only able to handle the wlan function */
	if (func->num != 0x02)
		return -ENODEV;

我意识到 Wi-Fi 功能编号是 2、而不是 1。
这是正确的吗？

通过将函数编号设置为 2 来测量 Saleae 捕获数据。
在 CMD53 中读取 BFFC 后、IRQ_WL 立即变为低电平。  这很好。
但是、在下一个 CMD53 中写入 BFFA 后、似乎进入了意外的 IRQ。
序列停止了。

我还注意到、使用写入命令 53 将似乎是流控制的波形插入 DAT0 线路中。

此致。

您好、

是的、Wi-Fi 功能是 2。 BLE 功能为 1。

我不太熟悉 SDIO 流程、因此我需要深入研究。

顺便说一下,你有一个解析器/分析器上的 SDIO 可以共享吗?

此致、

Shlomi

你好 Shlomi-San！

我通过以下 GitHub 链接在 Saleae 上获得了 SDIO 分析仪：
github.com/.../v1.0

此致。

谢谢、我们会进行研究。

Shlomi

你好 Shlomi-San！

我仍在检查、发现了一些提示。

调用 sdioAdapt_write () 函数时的大小为 936 字节。
在我的 SDIO 系统中、一个块为 128 字节、因此系统将 936 字节的数据拆分为两个 CMD53：“7 个块“和“剩余 40 个字节“。
检查 Linux 操作系统中 SDIO 的行为、它会发送一个 CMD53：“8 块“。

我发送“8 块“它似乎已经进展到下一步。

我不知道这是否正确。

此致。

您好、

由于我们尚未通过外部 MCU 实现 SDIO、因此我假设这是正确的。

如果它让你前进到下一个阶段,那么这肯定是正确的方法。

那么、现在您可以得到更远的距离、但直到什么点？

您是否能够完成引导加载程序的编程？

此外、最好使记录器并行运行、这样我们就可以知道 FW 如何处理从主机获取的块。

我们拥有带 Logger 选项的专用工具箱。 如果您已经熟悉此工具、或者需要指导、请告诉我。

此致、

Shlomi

你好 Shlomi-San！

感谢您的建议。

第 2 个加载程序传输完成后、固件传输在中间停止。
停止的时间因时间而异。

在停止之前、我发现 SDIO CMD 线路上的信号在发送“BFF0"时“时下降到 L 仅 1 位、如图所示。

这是逻辑 Saleae 原始采集和 CC3350 Wireshark 日志。

e2e.ti.com/.../20250709_5F00_4.zip

此致。

你好 Shlomi-San！

当 SDIO 速度降至 520kHz 时、似乎可以成功启动。
我认为硬件问题（波形失真）可能是原因。

生成了以下日志。 可以说 SDIO 移植已完成吗？

1029082 ---- 容器验证成功----------------------------
10291 65 nabHostIf_wait4IdleTransport：等待主机空闲
10292 75-------------------------------- 调用 WSOC 固件--------------------------------
10293 37 [0x80]已添加到命令队列
1029463 扫描 Module_Config ProbeReqIEs：IES len 0 超过限制 0
10295 81 TX 状态计数器：失败计数：0x0、到期计数：0x80、交换计数：0x0
10296 47 RX STA 角色多播帧计数器：0
10297 63 扫描 Module_Config ProbeReqIEs：Ies len 0 超过限制 0

是否需要观察到 SDIO 特有的任何其他时序？

此致。

您好、

有没有机会你可以做一些操作,如扫描和连接,看看我们是否可以实际工作?

Shlomi

你好 Shlomi-San！

当然。

我将检查扫描和连接等操作、并执行吞吐量测量。
在此之前、还需要解决我的硬件问题。

请稍候。

当然、感谢您的更新。

Shlomi

你好 Shlomi-San！

CtrlCmdIniParams() Fw_Download 函数的初始参数设置未完成。

发出 BFF8 读取命令后、总线会保持繁忙状态、直到读取命令完成。 我假设应针对该图的第三个 IRQ 发送的 BFFC 命令处于挂起状态。

这是逻辑 Saleae 原始采集和 CC3350 Wireshark 日志。

e2e.ti.com/.../20250711_5F00_1.zip

此致。

您好、

是的、我可以看到 HINT_FW_WAKEUP_COMPLETE 已经到达、但随后 0xBFFc 在最后一个中断时不会被触发、因此会失败。

发生了什么变化？ 现在是使用更高的 SDIO 时钟吗？

Shlomi

感谢您的跟进。

我没有更改处理中断事件的器件的源代码。
SDIO 时钟为 2MHz。 即使将速度减慢至 520kHz、也会得到相同的结果。

CtrlCmdIniParams() Fw_Download 函数返回 OSI_OK。

我已经确认随后调用了两次中断处理程序、可能是：
-BFF0 (DownloadIniParams 的 ACK)
HINT_FW_Download_INI_PARAMS_COMPLETE。

FW Event_Wait (HINT_FW_Download_INI_PARAMS_COMPLETE) 永远不会完成。

我发现 SDIO 总线始终处于繁忙状态（读取了 0x55）。
cc33xx_fw.bin 发送到 CC3350 是否存在任何额外的时序或其他条件、以便与 SDIO 正常工作？

此致。

您好、

从我看到的开始、最后一个中断一直没有得到处理、因为我看不到任何读取中断的 0xBFFC（您应该获得提示 FW_Downloading_INI_Params_complete） 。 尚不清楚在没有从主机触发 0xBFFC 的情况下如何将中断置为无效。

此时固件日志并没有太大说明。

也许应该打开一些驱动程序日志、但我不确定它会显示什么。 未调用中断处理程序的任何原因？

Shlomi

你好 Shlomi-San！

我成功地将配置数据发送到 CC3350。
使用 SDIO 时、由于块大小、内核状态读取位置偏移、导致 PROCESSOR_EVENT_AND_CMD_RESULT () 返回无效值 (0x55555555)。
此问题已解决。

发送配置数据后、CC3350 记录错误、Wlan_Connect () API 超时。
Wlan_Start ()、Wlan_Set () 和 Wlan_Role UppSTA() 成功。

10370 2025年07月16日 12:00:39.133587 ------------ 容器验证成功----------------------------
10371 2025年07月16日 12:00:39.133587 nabHostIf_wait4IdleTransport:等待主机空闲
10372 2025年07月16日 12:00:39.133587 -------------- 调用 WSOC 固件--------------------------------
10373 2025年07月16日 12：00：39.136579 [0x80]已添加到命令队列中
10374 2025年07月16日 12:00:40.166422 错误：线程正在运行时 ASU 快速恢复
10375 2025年07月16日 12：00：41.964174 错误：LtxpQueues_init：OSI_LockObjCreate 失败、RC = 0

这些错误表示什么？ 有什么解决方案吗？

此致。

您好、

这是您在记录器上看到的所有命令、还是您正在稀释消息？

我在您提到的日志命令中没有看到像传递 Wlan_Start  ()、Wlan_Set () 和 Wlan_Role UppSTA() 这样的命令。

我可以获取完整日志吗？

还可以查看主机端的日志。

无论如何、都有一个新版本的 R7、其比 R5 更成熟。

此致、

Shlomi

你好 Shlomi-San！

是的。 这些是所有日志、显示在记录器中。

WLAN_START 命令的 BFF0 发生 IRQ (Accept)、但似乎没有对 BFF8 做出响应。 IRQ (DONE) 应再次发生。
我假设 CC3350 未从 SDIO 执行 WLAN_START 命令。
这就是为什么没有 像 Wlan_Start () 这样的日志命令。

这是逻辑 Saleae 原始采集和 CC3350 Wireshark 日志。

 e2e.ti.com/.../20250717_5F00_2.zip

我将继续试用 R7 版本。 这需要一些时间。
如果您注意到任何情况、请告诉我。

此致。

您好、

记录器没有显示任何有趣的部分。

我假设可能是因为 logger.bin 解析器与编程的固件不对齐。

要对齐、您需要使用 Exact logger.bin。

您使用的是哪个版本？

每个 SDK 都有一个/ttols/wifi_fw 目录 、您可以在其中找到 logger.bin 文件。

然后、在工具箱上选择自定义记录器并选择此文件。

对于驱动程序日志、您能否打开 以下定义并重新编译 host_driver lib？

• commands.h 上的 debug_commands
• fw_event_if.h 上的 DEBUG_FW_EVENT_LOG

此致、

Shlomi

你好 Shlomi-San！

上一篇文章使用的是 R5 版本、因此没有 logger.bin。
我已更新至版本 R7.1。

更新至 R7.1 后、扫描正常、CC3350 似乎已成功连接到 AP。

CC3350 发送 ARP 请求、但它似乎没有收到响应。
我将用上面的层来调查我的移植情况。 您注意到日志中有任何内容吗？

AP 的 SSID 为“2GHzAP"，“，通道、通道为 10。

这是逻辑 Saleae 原始采集和 CC3350 Wireshark 日志。

e2e.ti.com/.../20250723_5F00_2.zip

此致、

你好 Shlomi-San！

在接收时调用回调函数时出错。
我修复了它、UDP 数据包的发送/接收过程工作正常。 感谢您的跟进。

当尝试通过 SDIO 测量通信速度时、rx_GetDESC () 函数中的第二个 assert (0) 在上传和下载速度组合超过 2Mbps 时执行。

我将继续调查、但如果您有任何信息、请告诉我。

此致、

你好 Shlomi-San！

我调查了执行 rx_GetDesc() 中第二个 assert (0) 的原因。

当主机从 SDIO 执行 BFF0 读取命令时、主机可能偶尔读取损坏的数据。 当同时执行发送和接收并且通信数据包的数量很大时、数据损坏的可能性会增加。

 图 1 显示了损坏数据的示例。 这是由 sdioAdapt_read() 函数读取的数据。 大小为 896 字节。NAB 标头中的 DEVICE_SYNC_PATTERN (0xABCDDCBA) 正确。

RX IF 描述符和有效载荷损坏、长度为 0、因此 assert () 在 rx_GetDESC () 中执行。

数据末尾的核心状态可能是正确的。

 将图 2 中的 saleae 波形与图 1 中的转储数据进行比较、结果与之匹配。 我想 CC3350 正在向主机发送损坏的数据。

这是日志和数据。

e2e.ti.com/.../20250730_5F00_1.zip

20250730_1_SDIO_rxdata.bin：转储数据损坏

20250730_1.Sal：逻辑 Saleae 原始捕获

20250730_1.pcapng：CC3350 Wireshark 日志。

20250730_1.log：报告调试日志

此致、

您好、

很抱歉晚才回复。

对于您共享的前一个记录器、它看起来正常。 我可以看到正在接收扫描和与信标的连接、因此至少从固件捕获开始、您就可以正确设置了信标。 我看不到任何与 ARP 相关的问题,只是因为不是所有内容都打印到记录器,所以不幸的是,我不能说太多。

让我们重点看最新的断言。 让我试着分析一下、一旦我得出结论、我将作出回应。

此致、

Shlomi

你好 Shlomi-San！

这是与我上一篇文章中的问题相关的附加信息、在使用 BFF0 命令调用时、可能会读取损坏的数据。
我发现、如果将 CC3350 连接的接入点配置为不使用 802.11ax 和 40MHz 频段、则损坏的可能性会降低。
当 Wi-Fi 拥塞时、这种情况似乎更容易发生。

我还发现了一个完全不同的问题。
如果 BFFC 命令设置 IRQ 时的时序和 IRQ 设置为 H 时的时序太接近（图 24ns）、则我的 MPU (RZ/A1h) 无法检测到中断。 我想、许多 MPU 都是相同的。
发生这种情况时、不再发出 BFFC 命令、从而导致接收过程停止。

CC3350 固件如果可以保持最小 L 周期（μ 秒？）、这会很有帮助。 规格。
作为临时解决方案、监视 IRQ 是否保持在 H 长周期并调用 FwEvent_IRQ_HANDLER () 是正确的吗？

此致、

您好、

由于我们使用的黄金基准是 SPI、因此很难判断您看到的具体问题是否与 SDIO 有关、尤其是当您说它在较低频率下运行得更好时。

对我来说、这是一个可以接受的临时解决方案、但我不知道在没有真正的中断的情况下、如果向芯片发送虚假的 0xBFFC 会发生什么情况。 据我所知、它没有进行仿真。

我将与 Fujinaka-San Over Email 交流。

此致、

Shlomi

你好 Shlomi-San！

当 IRQ 将 H 置为有效时、Wi-Fi 数据包接收过程是否完全完成？

或者、在处理后续 BFFC 命令时、解密和其他接收过程是否并行发生？

在后一种情况下、通过 SDIO（测量值为 22us）发送 BFFC 命令的速度快于通过 SPI（测量值为 169us）。

因此、通过 SDIO 连接、即使在 BFFC 命令完成后、接收处理也可以继续、主机可能会使用 BFF0 命令读取不完整的数据。

我仍在测试此情况、但如果在主机发送 BFFC 命令后将处理延迟 100us、即使使用 802.11ax、主机也可以保持稳定连接一小时以上。

其他信息：另一个小组报告了 802.11ax 问题、即使是 SPI 连接。 我不知道详细信息、但可能是、即使使用 SPI 连接、也没有足够的时间。

此致、

您好、

如何定义处理命令所需的时间？ 我们使用快速 SPI、因此时间远低于您提到的时间。

我将尝试找出答案、但我认为、除非数据已经准备就绪、否则中断不会被置为有效。

至于中断时序、轮询中断没有任何好处、因此即使芯片侧没有任何待处理的内容并且您进行轮询、您也会获得最后一个状态、因此您的建议可以生效。

此致、

Shlomi

你好 Shlomi-San！

测量结果是使用 16MHz SPI 连接获得的。 BFFC 命令为 256 字节、因此计算需要 128us。 包括开销、我认为 169us 的实际测量数据是合理的。
请检查数据就绪和中断置为有效的时序。

我计划结合使用中断和轮询。

此致、

你好 Shlomi-San！

我之前发布过“另一个团队报告了 802.11ax 问题、即使是 SPI 连接也是如此。 我不知道该怎么办。“

我已经听说过 SPI 团队的详细信息、所以我在这里发布了这些信息。

当使用 BFF0 命令读取的数据包含两个或多个描述符时、在极少数情况下、描述符之间会插入 16 字节间隙。 间隙数据通常为零、但情况并非总是如此。

每个描述符的大小不包括 16 字节的间隙、这会导致在用 rx_GetDesc() 解释第二个和后续描述符时出现错误。

该图显示了 发生问题时的 SPI 数据。

我们认为、SDIO 连接也可能出现此问题。

-你有任何信息吗?
-当这个问题发生时,在 rx_GetDesc() 中的 assert() 之后访问一个 NULL 指针。
请通过为参数（如 rawBufferLen after assert()) 设置适当的值并避免访问 NULL 指针来提高软件的稳健性。

此致、