[参考译文] cc3300：cc3300 数据记录

什么是错的?

> WiFi 打开

0：00：23.091 debug FreeRTOS OS_TASK_NEW 传输 0x9008f131 (0x0)
0：00：23.100 调试 CC3300 和 If_Hw 可用：硬件可用
0：00：23.100 调试 CC3300 HandleSmEvent： --> nextState =0
0：00：23.106 debug CC3300 寄存器客户端：tmr_HandleExpiry uContextId：0
0：00：23.107 debug FreeRTOS OS_TASK_NEW eventThread 0x9009022d (0x0)
0：00：23.115 debug CC3300 寄存器客户端：Fw Event_New uContextId：1
0：00：23.124 debug CC3300 寄存器客户端：CMD_SM uContextId：2
0：00：23.135 debug CC3300 Transport_Thread ：该系统正在运行
0：00：27.133 调试 CC3300 硬件初始化完成！

0：00：27.134 debug CC3300 正在获取器件信息…

0：00：27.140 debug CC3300 命令：cmd_Send、replace context：2！
0：00：27.141 debug CC3300 trnspt_RequestSchedule Transfer: Requested schedule client 2.
0：00：27.142 debug CC3300 cmd_Send 命令：新命令、正在等待...
0：00：27.144 debug CC3300 trnspt_Task：客户端：2 aClientEnabled：1 收到的事件
0：00：27.145 debug CC3300 CommandSM：传输命令
0：00：27.145 debug CC3300 bus_sendWriteCommand：0x0750BFF0 addr=0xbff0 len=936
0：00：27.147 调试 CC3300 SendTransactions：Status = 4、Params=0x49、HWADDR=0xbff0、Len0=936、Len1=0 Len2=0、Len3=0
0：00：27.147 debug CC3300 trnspt_Task：DONE 处理事件：2
0：00：32.145 调试 CC3300 计时器中断功能：超时：2！
0：00：32.145 debug CC3300 trnspt_RequestSchedule Transfer：Requested schedule client 2.
0：00：32.146 debug CC3300 trnspt_Task：客户端：2 aClientEnabled：1 收到的事件
0：00：32.146 debug CC3300 CommandSM：将上下文替换为：2
0：00：32.146 debug CC3300 trnspt_RequestSchedule Transfer：Requested schedule client 2.
0：00：32.147 debug CC3300 CommandSM：pSyncObjComplete
0：00：32.147 debug CC3300 CommandSM：cmdCB->currentCommand = NULL
0：00：32.147 debug CC3300 trnspt_Task：done handle event：2
0：00：32.147 debug CC3300 cmd_Send：命令完成！ cmdStatus：–1
0:00:32.149 debug CC3300 命令: cmd_Send, replace context :2！
0：00：32.149 debug CC3300 trnspt_RequestSchedule Transfer：Requested schedule client 2.

0：00：32.154 debug CC3300 错误：无法读取 CC33XX 设备信息！

0:00:32.159 debug CC3300 命令: cmd_Send, replace context :2！
0：00：32.160 debug CC3300 trnspt_RequestSchedule Transfer: Requested schedule client 2.
0：00：32.161 debug CC3300 cmd_Send 命令：新命令、正在等待...
0：00：32.162 debug CC3300 trnspt_Task：客户端：2 aClientEnabled：1 收到的事件
0：00：32.163 debug CC3300 CommandSM：传输命令
0：00：32.163 debug CC3300 bus_sendWriteCommand：0x0750BFF0 addr=0xbff0 len=936
0：00：32.165 debug CC3300 SendTransactions：Status = 4、Params=0x49、HWADDR=0xbff0、Len0=936、Len1=0、 Len2=0、Len3=0
0：00：32.165 debug CC3300 trnspt_Task：Done handle event：2
0:00:37.163 debug CC3300 计时器中断函数:timeout:2！
0：00：37.163 debug CC3300 trnspt_RequestSchedule Transfer：Requested schedule client 2.
0：00：37.164 debug CC3300 trnspt_Task：客户端：2 aClientEnabled：1 收到的事件
0：00：37.164 debug CC3300 CommandSM：将上下文替换为：2
0：00：37.165 debug CC3300 trnspt_RequestSchedule Transfer：Requested schedule client 2.
0：00：37.165 debug CC3300 CommandSM：pSyncObjComplete
0：00：37.165 debug CC3300 CommandSM：cmdCB->currentCommand = NULL
0：00：37.166 debug CC3300 trnspt_Task：done handle event：2
0：00：37.166 debug CC3300 cmd_Send：命令完成！ cmdStatus：–1
0：00：37.166 debug CC3300 命令：cmd_Send、replace context：2！
0：00：37.166 debug CC3300 trnspt_RequestSchedule Transfer：请求的计划客户端 2.

0：00：37.176 debug CC3300 命令：cmd_Send、replace context：2！
0：00：37.177 debug CC3300 trnspt_RequestSchedule Transfer：请求的计划客户端 2.
0：00：37.178 debug CC3300 cmd_Send 命令：新命令、正在等待...
0：00：37.179 debug CC3300 trnspt_Task：客户端：2 aClientEnabled：1 收到的事件
0：00：37.179 debug CC3300 CommandSM：传输命令
0：00：37.180 debug CC3300 bus_sendWriteCommand：0x0750BFF0 addr=0xbff0 len=936
0：00：38.387 调试 CC3300 SPI 无响应！

0：00：38.388 错误 CC3300 在 0x9008c977 中置为有效

HOST_IRQ_WL 在复位后变为高电平并保持此状态。

您好团队：

内部讨论的其他问题。

函数 WLSendFWGetDeviceInfoCommand() 将 CMD_BM_READ_DEVICE_INFO 命令发送到 CC3300。

答案应该是什么？ 您能否针对此命令检查 SPI 数据的正确性：

其中来自顶部：解码的 MISO MOSI 字节、SPI 时钟、MISO、MOSI、CS。

我不明白这种机制,哪里是接收请求的数据的实际读取命令,它是否涉及 wifi 芯片的中断?

0：00：32.145 调试 CC3300 计时器中断功能：超时：2！

代码好像错过了 CC3300 中的中断（并且 HOST_IRQ_WL 上没有活动）。

请帮助加快设计进度。

谢谢、

Aida

您好 Aida、

我们现在正在解析数据。

您使用的时钟速率是多少？
就字节序而言、它是固定的。 但如果默认情况下不正确、您可以在主机端翻转它。

此致、

您好、

我们尚未尝试移植到 STM、因此我无法分享任何见解、但您应该期望的是在您发送  WLSendFWGetDeviceInfoCommand () 后使 IRQ 生效。

此外、当器件上电时、您应该会看到一个中断置为有效、然后发送 init 命令和 0xBFFC。 接下来、您应该会看到中断变为低电平（已确认）。 “你怎么知道的?

您能看到完整的逻辑吗？ 例如、不仅仅是屏幕截图。  

我使用的是 Saleae 逻辑。

您可以在附件中找到 Saleae 的工作参考资料。

这是您应该期望的流程。

此致、

Shlomie2e.ti.com/.../initialization_5F00_ThickMAC_5F00_v301_5F00_100msec_5F00_delay_5F00_between_5F00_BTLand-FW_5F00_good.sal

尊敬的 Shlomi：

我正在查看您的分析器跟踪。 如果我在代码中没有发现任何可疑内容、我将以 csv 或 DSlogic 格式发送我的跟踪。 在我的迹线中我已经注意到：没有中断、我在每条命令后将 CS 拉高、第一条 SPI 命令是“写入不读取“- 07 50 BF F0。

谢谢、

Volodymyr。

尊敬的 Shlomi：

CMD0 中的“Interrupt Ploarity“=1 是否意味着应在下降沿生成中断？

我已通过晶体管将 HOST_IRQ_WL 连接到 STM32、可能这是问题以及 TI SDK 代码状态似乎取决于一些初始 IRQ 信号/事件这一事实。

CMD0 中的“中断开漏“是否可以更改为 0？

此致。

您好、

这意味着当从 0 变为 1 时、器件会使中断生效（因此 1 表示中断）。

您应该会看到中断触发。

您是否有取走记录器的选项？

它有一个引脚、可用于连接电平转换器、然后连接到 PC 并使用工具箱来获取日志消息。

如果在上电期间器件检测到 IRQ 为 1、则它会进入测试模式、并且不会工作。

这是 SOP 模式（电源检测）、另外两条线路是 BLE IRQ 线路和记录器。

您可以在 https://www.ti.com/lit/ug/swru612/swru612.pdf?ts =1751431243904&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FCC3351 中阅读相关信息

Shlomi

您好、

我知道 HOST_IRQ_WL 和 Logger 拉取、它们可以。 我已解决 IRQ 处理中的一个问题、但最后仍会收到断言 问题是我无法在中断控制器中禁用/启用 IRQ（它是多路复用的）、尝试在软件中修复它。 以下是 CVS 格式的日志和分析器跟踪：

e2e.ti.com/.../cc3300_log.3.zip

e2e.ti.com/.../DSLogic-la-250702-171523.zip

SDK 代码中继到上电期间产生的中断、这很奇怪。

此致

我没有遵循你的意思,最终得到断言

您能否在此处附加日志、而不是通过链接附加日志？ 链接已断开。

Shlomi

您好、通过电子邮件 (Aida) 向您发送分析仪跟踪。 有两个 IRQ 信号、一个记录在 CC3300 附近、另一个记录在微控制器附近、复位反相。

您好、

我无法下载记录器和逻辑视图。

我会向 Aida 提问、然后进行分析。

此致、

Shlomi

您好、

在终端日志上、我认为打开这么多日志可能会改变时间。

我在过去有过这种情况、所以我对我的开场白非常有选择性。

您能否只在 FW_EVENT_IF.h 上打开 DEBUG_FW_EVENT_LOG 和 DEBUG_FWEVENT？

至于 gLogger、我知道您目前没有 gLogger。

至于逻辑捕获、我看到您收到了 ROM 引导加载程序中断、但时钟似乎不稳定（或者可能只是工具问题）。  

例如、请参阅下面的捕获图、其中我预计结果为 0x2、但本节周围没有 SPI 时钟。

Shlomi

您好、

Saleale 25MHz 采样率太慢、我会将 SPI 时钟降低到 6MHz、并进行另一个跟踪和日志。

谢谢

好的、谢谢。

另外、最好查看带有  DEBUG_FW_EVENT_LOG 和 DEBUG_FWEVENT 的驱动程序日志。

同时、我们可以拨打电话、我将 ping Aida。

Shlomi

您好、

我有一些问题：

• 功率指的是什么？ 只有器件的电源轨？
• 我假设复位是 nRESET 引脚、对吧？ 如果是、我会认为它会保持高电平而不会切换、您能解释一下吗？
• 我们在过去看到了在 IRQ 线路上使用晶体管的问题、因为它速度不是很快、还可能会影响器件在启动期间看到晶体管的水平。 我还可以看到器件端 IRQ 线路上有许多波动。 不知道原因。 可能是由于晶体管的原因
• 您是否可以选择将记录器引脚提取到电平转换器？

Shlomi

尊敬的 Shlomi：

是、电源是使能信号发送到为 WIFI 芯片提供 3.3V 电压的电源开关。 从该 3.3V 开始、LDO 使电压为 1.8V。

Reset 被反转（我已写下）。

IRQ 1.8V HOST_IRQ_WL、这就是出现波动的原因（逻辑分析仪配置为 3.3V）。

-IRQ 是输入微控制器的 3.3V 反相 IRQ 信号（在晶体管之后）。

我可以使用样本记录器、但这需要进行一些焊接。 我将在今天晚些时候给您发送新的跟踪信息。

您是否查看过 SPI 数据、是否正确？

谢谢、

Volodymyr

SPI 数据看起来正常、就像在我的例子中一样。

我唯一能想到的是等待 ROM 引导加载程序中断、我们在代码后面实际发生的代码中等待该中断。

可能在您的系统中信号丢失、然后在代码中当您在此信标上等待时、信号会中止？

我所说的代码是：

if(fwEvent_Wait(OSI_WAIT_FOR_SECOND * 2,HINT_ROM_LOADER_INIT_COMPLETE) == -1)

该信标的实际信令处于早期阶段（实际上是 nRESET 变为高电平后的第一步）。

在代码中,您可以找到它@Fw Event_Call Handlers ()。 代码段是：

initEvents = pFwEvent->uEventVector
                & (HINT_ROM_LOADER_INIT_COMPLETE
                        | HINT_SECOND_LOADER_INIT_COMPLETE
                        | HINT_FW_WAKEUP_COMPLETE
                        | HINT_FW_DOWNLOADING_INI_PARAMS_COMPLETE);

        if (initEvents)
        {
            fwEvent_Signal(initEvents);
        }

Shlomi

最后一次 IRQ 从低电平到高电平的转换发生在上次写入的上一个读取 — 写入-读取 — 写入周期期间。 读写后、IRQ 信号是否与某事有关？

SPI 中的最后一个活动是：Read-（在该 IRQ 变为低电平之后）- Write-Read。 IRQ 保持低电平、没有写入、因此我假设代码读取的是阻止其继续执行的异常内容。 我错了吗？

您好、

上次读取操作不应该发生、因为没有 IRQ、因此不清除。

但我查看的是终端日志、它显示它没有收到 HINT_ROM_LOADER_INIT_COMPLETE。

代码中的此事件为 0x8、您只能在第一次中断时捕获开始时获得一次该事件。

所有其余部分都将显示 0x2、而不是 0x8。

这就是为什么我问这一事实是否已经在代码中的早期发出信号、如果操作系统在发出信号后很长时间在这个信标上等待、它会有什么行为？

Shlomi

尊敬的 Shlomi：

我想我已经修复了中断、但开始收到错误：

0：00：14.717 debug CC3300 starting software download…
0：00：14.717 调试 CC3300 和 Event_Wait 0
0：00：14.719 debug CC3300 ----------------  下载 RAM-BTL
0:00:14.720 debug CC3300 命令: cmd_Send, replace context :2！
0：00：14.721 debug CC3300 cmd_Send 命令：新命令、正在等待...
0：00：14.723 debug CC3300 CommandSM：传输命令
0：00：14.731 调试 CC3300 CommandSM：将上下文替换为：2
0：00：14.731 debug CC3300 CommandSM：pSyncObjComplete
0：00：14.731 debug CC3300 CommandSM：cmdCB->currentCommand = NULL
0：00：14.732 debug CC3300 cmd_Send：命令完成！ cmdStatus：–17769

17760 (0x4560) 是什么意思？

谢谢。

您好、

您使用的是哪个 SDK 版本？ 可能您使用的是旧版本。

我问道、因为 0x4560 实际上并不是错误、而是您读取状态时的有效返回值。

请查看最新版本 R7、具体而言、您将能够在 commands.c 文件中看到此错误、具体而言在 cmd_ReadCompleteExternal () API 下看到。

可以找到一个名为 CMD_BOOT_ERROR_ANTIVATE 的定义、它正是该值、因此应该允许您在编程阶段继续操作。

请告诉我该怎么做。

此致、

Shlomi

您好、

当然、我正在使用 R5（R7 发布日期：2025 年 6 月 30 日）。 会尝试新版本。

谢谢、请告诉我。 我认为 R5 没有修复这个问题。

通过此修复、错误 0x4560 不是错误、可以视为良好。

尊敬的 Shlomi：

我已经得到了这个：

> WiFi 打开
0：00：07.224 调试 FreeRTOS OS_TASK_NEW 传输 0x90088929 (0x0)
0：00：07.228 debug FreeRTOS OS_TASK_NEW eventThread 0x90089e19 (0x0)
0：00：09.233 调试 CC3300 WLAN_TurnOnWlan
0：00：09.234 调试 CC3300 硬件初始化完成！
0：00：09.237 调试 CC3300 获取器件信息
0：00：09.251 debug CC3300 -----
0：00：09.251 debug CC3300 CC33XX 器件信息：PG 版本：2 金属版本：0 引导 ROM 版本：1
0：00：09.253 debug CC3300 Fuse_ROM_Structure_version：1 器件型号：0
0：00：09.254 debug CC3300 主机版本：3.0.1.34
0：00：09.254、调试 CC3300 FW MAC 地址：0x10 0xca 0xbf 0xdb 0x48 0x82
0：00：09.255 调试 CC3300 FW MAC 地址：0x12 0xca 0xbf 0xdb 0x48 0x82
0：00：09.256 调试 CC3300 FW MAC 地址：0x12 0xca 0xbf 0xdb 0x48 0x83
0：00：09.257 调试 CC3300 FW MAC 地址：0x10 0xca 0xbf 0xdb 0x48 0x83
0：00：09.258 调试 CC3300 -----
0：00：09.307 debug CC3300 starting software download…
0：00：09.308 调试 CC3300 -------- 下载 RAM-BTL
0：00：09.431 调试 CC3300 dnld 偏移：6 –4472-768
0：00：09.569 dnld dnld 偏移：6 –12152-768
0：00：09.701 debug CC3300 dnld 偏移：6 –19832-768
0：00：09.829 dnld dnld 偏移：6 –27512-768
0：00：09.961 debug CC3300 dnld 偏移：6 –35192-768
0：00：10.092 debug CC3300 dnld 偏移：6-42872-768
0：00：10.221 dnld dnld 偏移：6 –50552-768
0：00：10.351 debug CC3300 dnld 偏移：6 –58232-768
0：00：10.483 debug CC3300 dnld 偏移：6 –65912-768
0：00：10.665 debug CC3300 CommandSM：cmdStatus：CMD_ERR_TIMEOUT
0：00：10.665 debug CC3300 cmd_Send：命令完成、出错！ cmdStatus：0x8000581c
0：00：10.667 debug CC3300 --------------------  等待 RAM BTL 上升
0：00：10.708 调试 CC3300 ----------------  下载固件
0：00：10.827 dnld CC3300：4 –4976-536
0：00：10.971 debug CC3300 dnld 偏移：5-12424-768.
0：00：11.106 dnld dnld 偏移：5 –20104-768.

。 。 。 已跳过

0：00：20.086 dnld dnld 偏移：7 –533820-768
0：00：20.221 dnld dnld 偏移：7-541500-768
0：00：20.360 debug CC3300 dnld：7-549180-760
0：00：25.378 debug CC3300 CommandSM：cmdStatus：CMD_ERR_TIMEOUT
0：00：25.379 debug CC3300 cmd_Send：命令完成、出错！ cmdStatus：0x8000581c
0：00：25.389 debug CC3300 Fw Event_Call 处理程序：收到常规错误事件！ 固件卡住
0：00：25.389 错误 CC3300 在 0x90089e5f 中置为有效

我理解 CMD_ERR_TIMEOUT 是否正常、但 cmdStatus:0x8000581c 是什么？

谢谢。

您好、

没有这样的错误、就像我们之前使用 0x4560 看到的错误。

此外、我不会期待超时。

我还可以看到这种情况下的逻辑吗？

另外,如果你能让记录器工作,那么我们就知道在 FW 的引擎盖下发生了什么。

此致、

Shlomi

您好、我已通过电子邮件将文件发送给 Aida。

至于 CMD_ERR_TIMEOUT、我在代码中看到了这一点：

/*---------------------------------------------------------------------------------------------------------
* 30/01/23, Osprey_LDB-1212: RAM BM 下载错误解决方法:
*对于每个容器块,ROM BM 发送具有内核状态的 CMD_COMPLETE。
*一旦发送最后一个 RAM BM 容器块,ROM BM 发送 CMD_COMPLETE ,清除 SPI 接口
*并调用 RAM BM。 如果主机在此之后读取有故障的内核状态、这可能会导致主机读取该内核状态
*已清洁。
*为了解决这个问题,我们通过减少超时和禁用中断来忽略最后一个 CMD_COMPLETE
*在发送最后一个块之前,然后重新启用它们。
*--------------------------------------------------------------------------------------------------------- */
if (isLastRecord &&(0 == OS_strcmp（“ramblr"，“，containerName、containerName)))
｛
   /*将命令完成超时设置为 100ms 并禁用中断。 */
   CMD_SetTimeoutMs (100)；
   WLAN_IRQDisableInt ();
}

禁用中断会导致 100ms 后超时（至少在 ramblr 情况下）。

你好,我不知道什么“记录器“是,请解释。

尊敬的 Volodymyr：

至少从逻辑的角度来看、波形看起来是可以的。

您可以看到第二个引导加载程序下载的第一部分进展顺利。

在逻辑上观察到让处理器复位、加载和执行引导加载程序的 100mSec 延迟。

您可以看到、~40mSec（因此总计 140mSec）后得到的是表示 hint_second_loader_init_complete 的 0x10 statis。

为了说明这一点、中断被禁用 100mSec、然后再次启用、以确保读取内核寄存器没有故障。

您继续进行固件下载这一事实表明 收到了 HINT_SEsecond_loader_init_full。

固件下载完成后的下一部分是接收 HINT_FW_WAKEUP_COMPLETE (0x20)。

我也可以在最后的逻辑分析仪中看到它、以响应 0xBFFC。

因此、我认为主机端出现了故障、但只是为了完成图片、记录器是从固件中传出的消息。

您需要将一个称为记录器的专用引脚连接到电平转换器并连接到 PC。

然后使用工具箱 Logger 选项。

https://www.ti.com/product/CC3351#software-development

一目了然、只需选择器件部分、 UART COM 端口和记录器解析器文件。

记录器文件需要与实际固件匹配、并且工具箱附带了默认记录器、当工具箱发布时该记录器与固件匹配。

因此、取决于您正在使用的软件包、并将 logger.bin 与固件进行匹配。

基本上、当消息传出时、您应该会在 Wireshark 上看到可解码的消息（这是消息的 GUI）。

此致、

Shlomi

嗨、Slomi

我不使用评估板、因此在这种情况下“一目了然“不起作用。 该 UART 的哪些参数（比特率等）可以由逻辑分析仪解码？

因此、消息 hint_FW_wakeup_complete 返回一些错误代码？ 它是什么,错误的 FW CRC 或什么? 发生错误的阶段是什么？

此致

您好、

波特率为 3000000、无法通过逻辑解码、只能使用我在调用中显示的工具箱。

这与 CRC 错误无关、只是在固件下载结束时添加的额外数据包。

此致、

Shlomi