[参考译文] CC3301：卡在 ctrlCmd Fw_Container Download (&quot；ramblr&quot；)-等待提示_second_loader_init_complete

您好、

文件应该正常。

基本上、未接收到 IRQ 的情况只能是时序问题导致的。

我们等待100ms、让 RAM 引导加载程序得到验证并执行。 之所以需要执行、是因为执行涉及 SPI 初始化、因此我们在此期间屏蔽中断、并在超时之后重新启用中断。

你能把完整的逻辑联系起来吗?

Shlomi

e2e.ti.com/.../CC3301_5F00_spi_5F00_data.csv

时钟速度应为8MHz

以500 MS/s 的速度收集数据

您好、

很抱歉我出去了。

我可以获取 saleae 原始文件而不是 csv 以便在 GUI 中本地打开它吗？

此致、

Shlomi

好的、您可以：
e2e.ti.com/.../CC3301_5F00_capture_5F00_saleae.zip

您好、

引导加载程序编程看起来正常。

我在逻辑中缺少了中断线、也应该获取该中断线。

仅根据日志就很难确定主机是否卡在某个位置。 我希望在下一个0xBFFC 上看到0x10状态、这种情况不会出现在您的捕获中。

我可以建议如下：

• 将 IRQ 添加到您的逻辑中
• 尝试将延迟从100mSec 增加到1秒、然后重新测试
• 从日志引脚添加记录器捕获。 只需将电平转换器连接到 PC 和工具箱即可。 只需使用工具箱中的 logger 选项并使用附加的 logger.bin 解析器进行 R5解析

Shlomie2e.ti.com/.../7776.logger.bin

主机在以下行等待信标时卡住'init_device.c'、我可以在 IAR 中通过调试器看到：

if(fwEvent_Wait(OSI_WAIT_FOREVER,HINT_SECOND_LOADER_INIT_COMPLETE) == -1)

我附上了一个 zip 文件 e2e.ti.com/.../CC3301_5F00_capture_5F00_saleae_5F00_w_5F00_int_5F00_and_5F00_log.zip、其中包含 SPI 通信、中断引脚和日志引脚的数据捕获、并持续了几种不同的延迟(包括100ms 和1s)

我不确定我是否了解如何使用解析器、因此如果您详细说明这一点、会有所帮助

您好、

您需要对解析器执行的操作是将其用作工具箱的一部分。

您可以从 https://www.ti.com/tool/SIMPLELINK-WIFI-TOOLBOX 下载 并安装。

在文档下、您应该会看到一份用户指南、但要在这里进行详细说明、安装和连接外部电平转换器后、您应该执行它、选择 Logger 并选择 COM 端口。 然后,在解析器选项下,只需选择一个自定义解析器选项,并将其定向到我附加的 logger.bin。 这一点很重要、因为记录器解析器紧密连接到在 R5上运行的固件。

然后、简单地执行它、应该打开 Wireshark 并弹出来自固件的所有消息。

这将提供一些细节和所发生的事情的提示。

您可以使用常规的100mSec 延迟。

此致、

Shlomi

e2e.ti.com/.../CC3301_5F00_logger.zip

我附加了 Wireshark 和逻辑捕获、它们似乎配置正确、但是我看不到任何警告或错误

您好、

记录器似乎很奇怪,不是我所期望的。

我预计会看到按块划分的块(大小约为768字节)、而不是描述的那样。

不确定这是否是驱动程序与 FW/BL 之间的不匹配、因为这些需要匹配。

您能否详细说明它是否适用于  CC3351、而现在不适用于 CC3300器件？ 因为这是我在原始线程上看到的。

此外、最好获取您正在使用的实际第2个引导加载程序、FW 和 conf 文件。

Shlomi

您好、

 CC3351和 CC3300都没有提到这两个问题、因为我认为原始线程中的问题本质上与我一直遇到的问题类似： CC3300：驱动程序兼容性和固件上传- Wi-Fi 论坛- Wi-Fi - TI E2E 支持论坛

但是、我们使用的是 CC3301


我们使用的文件： e2e.ti.com/.../cc3301_5F00_files.zip

好的、所以它似乎是一个干净的 R5。

您是否还可以附加您正在使用的 conf.h 头文件？

这也是非常奇怪的,记录器没有按预期打印。

您甚至可以在比较您连接的不同记录器捕获时看到它。

还有很多缺失的日志消息。

您使用什么电平转换器？

e2e.ti.com/.../conf.h

是什么  TXS0108EQPWRQ1 -所以信号值是~3.6 V (可以在附加的 saleae 捕获中看到)

我还注意到、对于 WLAN_IRQDisableInt 和 WLAN_IRQEnableInt、它显示"仅在低电平有效时才需要实施"、因此我还附加了另一个捕获、其中注释掉了这些函数的内容。

e2e.ti.com/.../100ms_5F00_IRQ_5F00_ASSERTION_5F00_HIGH.zip

尊敬的 Albert：

当 IRQ 置为高电平时、您实际更改了器件的 SOP 模式。 您可以在记录器中看到、SOP 现在是0x3 (而不是0x1)、这意味着器件进入测试模式(用于调试分析)。 但是,至少我现在可以看到更多的消息,不知道为什么。 在任何情况下、 似乎已经验证并执行了第二个引导加载程序、但只观察到单个中断(对于命令完成- 0x2) 、但未看到指示第二个引导加载程序完成的完成中断。

您使用的平台是什么？

中断是否设置为边沿？ 等级？

我记得与另一位客户进行类似的分析、我们也做了同样的延长超时时间的实验。 我记得、我们总是在~140mSec 后看到一个中断、这应该表示第二个引导加载程序的完成和执行、但由于我们等待了1秒、我们得到了另一个中断、但这次是第二个引导加载程序中断、即0x10、而不是0x2、这是您得到的。 此外、当我们使用100mSec 进行测试时、我们可以观察到2个中断(100mSec 之后为0x2、另一个40mSec 之后为0x10)。 在您的情况下、我们不会获得第二个中断。

这是合理的、因为我们在您的情况下没有看到中断在~140mSec 后重新置为有效、因此我想知道第2个引导加载程序在您的情况下是否成功、但如果没有可正常工作的记录器、很难知道(同样、不知道为什么它在您的情况下不起作用)。

只是为了您的参考,我附加了工作记录器箱与100mSec 延迟,所以你看它应该是如何看起来.

此致、

Shlomie2e.ti.com/.../initialization_5F00_ThickMAC_5F00_R5.pcapng

开发平台：IAR RX 4.10.2

检测方法：上升沿

感谢您的参考、我来看一看。 如果成功的 DEVICE_INIT 捕获了 SPI 通信、我也想看看这一点

当然、请找到随附的 SPI 捕获、默认为100mSec delay.e2e.ti.com/.../3884.cc33xx_5F00_MCU_5F00_full_5F00_platform_5F00_init_5F00_network_5F00_terminal.sal

我已经研究了 Wireshark 日志和成功启动的 SPI 通信、但我还需要设置 HINT_SECOND_LOADER_INIT_COMPLETE-flag

但是、我发现了一些奇怪的 SPI 通信行为：
1.  (请参阅两个实际逻辑捕获中的 P0时序标记)：  从 CC3301接收到的测量状态与参考值不同
2.  ( 请参阅两个示例逻辑捕获中的 P1时序标记)：  前两个字节(由于位移、我认为长度乘以2)与引用不同- 0x7228 而不是  0x69E8
3.  (请参阅两个示例逻辑捕获中的 P2时序标记)：  从 CC3301在测量中发送的数据会重复进行 0x55 、直到传输结束、这意味着状态不可读、 tsf字节无意义

我附上了三个文件： 2627.files.zip
1. wirehark-log.pcapng 是我捕获的解析日志(我认为我上次日志中不存在大量信息的原因是由于连接松动)
2. logic_capture_with_markers_and_comments.sal 我的捕获与上面解释的三种"奇怪的行为"对应的标记和评论
3. ti_reference_with_markers.sal 捕获是在父问题中发送的、标记与我在自己的捕获中设置的标记相对应

我的问题是：

• 相对  P0时序标记  状态是否必须与参考中的状态相同？ 如果是、您是否知道为什么状态不等于参考值？
• 相对  P1正时标记  为什么长度设置为另一个值？
• 相对  P2时序标记  为什么 CC3301继续发送 0x55、而不是状态和 tsf？

我还创建了一个 Excel 文件、用于更快速地概述本文中 Wireshark 日志与父级问题(用作参考)中的参考 Wireshark 日志之间的差异： wireshark-comparison.zip

根据各个日志行是否相等/不相等/未接收到彩色绿色/红色/橙色、"I"列为 true/false/Unknown。 测量日志上的某些日志线路可能由于连接不良而丢失。

提前感谢您、
  Albert

尊敬的 Albert：

感谢您的信息。

P0：这毫无意义、因为状态仅为16位、在这两种情况下都是0。

您可以在代码中看到、core_status 与此掩码(core_status->rx_status 和 RX_byte_COUNT_mask)进行了与运算。

P1：好问题、虽然我也可以在您的日志中看到0xBFF8的所有其他情况下的此值。 在我的例子中、长度对应于1268个字节、在本例中对应于2324个字节。 我对它没有很好的解释。

P2：这可能是由于程序在此处结束、因此不会触发 TSF (即副作用、而不是根本原因)。

现在记录器正常、您可以删除 IRQ 的高置位、因为只要 SOP 为0x3、就不会继续下载固件。

对于 P1、您能否打开以下调试标志并发回 CLI 日志？

•  fw_event_if.h 中的 DEBUG_FW_EVENT_LOG 和 DEBUG_FWEVENT
• commands.h 中的 debug_commands

此致、

Shlomi

您可以访问： e2e.ti.com/.../cc33xx_5F00_terminal.log

您好、

很难判断出什么是错的。

您尝试了更高的 SPI 时钟吗？

我从您使用1.25MHz 的逻辑中看到了吗？

Shlomi

您好、
是的,我尝试了不同的时钟速率,然而,结果是相同的。 如果有任何进展或出现其他问题、我将继续深入探讨该问题、并再次在此主题上写下

您好、

只是想更新一下、上面 P1上看到的差异不是问题。

我再次进行了记录、看到的值与您看到的值相同。

我之前分享的捕获来自较旧版本的主机驱动程序和固件、因此这个大小可能已更改、应该可以。

我也在这里继续我的调查,并会告诉你,如果我能够操纵和以某种方式复制你所看到的。

此致、

Shlomi

尊敬的 Shlomi：

我正与阿尔贝就这一问题共同努力、我只有几个问题。

我已将捕获结果附加了标记。

e2e.ti.com/.../5736.Capture.zip

我的问题是：

1. w.r.t P0时序标记：  当您接收 MISO 时、MOSI 似乎变低、但我们的 MOSI 保持高电平。
2. w.r.t P1时序标记：  每4个字节、您会收到 SPI 使能信号会变为高电平、而我们的不会变为高电平  

这可能是个问题吗？  我将与 您于2016年4月发送的捕获数据进行比较。

此外、您还提到这次对您的捕获来自较旧版本的主机驱动程序和固件。 您是否使用 R5进行了新的捕获？

此致、

Casper

您好、

我目前正在出差、但我可以为您的问题提供一些答案。

基本上、CS 线路每4个字节变为低电平是特定于主机的情况。 这是通过我们的一个控制 CC33xx 的 CC26xx 主机捕获的。

几周前、我再次使用 AM243捕获了该视频、并且 CS 线路对于该视频始终为低电平、但仍然运行良好、因此这可能不是您遇到的问题。 请参阅随附的。

我认为 MOSI 也不是一个问题、因为它在第二个引导加载程序部分期间确实有效。

我必须说、最后一次捕获不同于之前已共享的捕获、因为读取邮箱(通过0xBFF8)会返回预期值。

过去、它返回 SYNC 模式、后跟全部0x0。 这次我看到了预期的操作码+长度以及返回的代码。 不清楚为什么您没有额外的 IRQ 来表示 RAM 引导加载程序完成。

此时、需要再次使用固件记录器(希望它不会丢失任何消息)。

此致、

Shlomi

e2e.ti.com/.../networkTerminal_5F00_init_5F00_R6_5F00_noDebug_5F00_good.sal

尊敬的 Shlomi：

您的附件显示 R6 -这应该有所不同吗？  

我将最新的捕获结果和日志附加到了 R5中

e2e.ti.com/.../CC3301_5F00_logs_5F00_20_5F00_05.zip

此致、

Casper

不,这不应该是问题。 它是较新的版本、但不应该有所作为、因为 R5也应该起作用。

它还显示了0xBFF8邮箱读取上的预期输出、因此您应该没问题。

我们即将发布一个新的包, e/o 这个月,但如果加载不是工作在你身边,我怀疑新的版本是否会。

我需要咨询其他事情可以发生在你身边,但一个记录器会真的有帮助。

记录器需要使用工具箱进行记录、而不是像您那样记录到逻辑中。

您应该熟悉此过程、因为您已经完成了此过程。

此致、

Shlomi

尊敬的 Shlomi：

记录器也是所附 zip I 的一部分。 该文件名为"CC3301 _记录器_20_05.pcapng"、我还使用了工具箱。 我使用了4月10日发送的.bin 文件。

请告诉我您是否有其他意义。

此致、

Casper

尊敬的 Shlomi：

我修改了 IRQ 线路、现在显示 SOP=0x1。

我相信它现在可以工作,但你可以通过查看附加的文件确认吗?  

e2e.ti.com/.../26_5F00_05_5F00_capture.zip

在记录器中似乎有很多"丢字节"是重要的吗?

编辑：

我可以看到我附加的记录器文件中没有 SOP 模式= 0x1。 有时我们不会得到记录器中的所有软件包。 可能是由于一些噪声、但我不知道。 我附加了另一个 zip、其中 SOP 模式= 0x1。

e2e.ti.com/.../SOP_5F00_1_5F00_capture.zip

此致

Casper

谢谢 Casper、

所以我现在感到困惑。

我们由此 SOP 问题开始、然后我要求恢复它、以便根据需要获得 SOP=0x1、并且它不起作用。

现在有什么不同？

似乎它现在起作用了。

您是否能够继续使用该器件？

此致、

Shlomi

尊敬的 Shlomi：

显然、我们的应用必须将 IRQ 置为高电平。 因此、我必须在激活 CC3301时将其设为低电平以使其 SOP=0x1、然后在之后恢复为高电平。

现在似乎我们可以继续使用器件。  

非常感谢您的贡献。

此致、

Casper

当然、感谢您的更新。

Shlomi