[参考译文] CC3300MOD：有关从主机上载 CC3300MOD 二进制文件的查询

尊敬的 Yogesh：

IRQ 确认 (0x62、0x00、0xBF、0xFC) 在 3.5 秒后出现的原因可能是什么 在 TI 提供的波形中、函数将立即出现。

我不太确定您在这里的意思。 从“ThickMAC_R9_init_roleUp_SCAN_CONNECT.Sal“文件中、我看到第一个数据大约在 6.6 秒内出现。

我认为应该会有一些延迟、因为 在 initHostDriver 中启用了 IRQ、该驱动程序调用 init_device、 对于每个 fw Event_Wait、该驱动程序似乎都暂时禁用、然后重新启用 IRQ。  

]我们的代码在“ctrlCmdBtl_get_device_info_cmd“中保留很长时间、然后结果显示出来的原因可能是什么。 我们如何诊断两种观察结果的根本原因和解决方案。

特别是在 ctrlCmdBtl_get_device_info_cmd 中、您遇到了什么问题？ 我想知道 init_device 是否需要大量时间才能完成、我在 AM243 设置上运行网络终端示例时会看到类似的时间线。

[引述 userid=“496917“ url=“~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640736/cc3300mod-queries-for-uploading-cc3300mod-binaries-from-host/6326455

• 在 TI 提供的附加波形（如下所示）中、请帮助我们找到 ctrlCmdBtl_get_device_info_cmd 和 ctrlCmd Fw_Container Download（“ramblr“）；
• e2e.ti.com/.../ThickMAC_5F00_R9_5F00_init_5F00_roleUp_5F00_scan_5F00_connect.sal

[/报价]

ctrlCmdBtl_GET_DEVICE_INFO_cmd 应以 0x5C 0x5C 0x5C   0x00 0x20 0x00 0x23 开头、在.Sal 中为 6s：678ms：741us

CtrlCmd Fw_Container Download（“ramblr“）应从 0x5C 0x5C 0x5C 0x5C  0x00 0x24 0x00 0x23 开始、在.Sal 中为 6s：716ms：5us

在“WriteSync“函数中、我们要求在移植到 STM32 时添加“//交换每个 32 位字“。 由此、我们发现在 MISO 变为低电平时初始序列正常工作。 无法完全理解对这种代码的需求。 如果您对该代码的要求以及我们需要添加相同代码的其他地方有一定的了解、那么这将会很有帮助。

我的 cc33xx_RTOS_MCU_PACKAGE_R8_1 中的 spi_adept.c 文件中没有此代码片段。 不确定添加源、因此我无法回答这个问题。

完整的 SDK 涉及主 SDK 代码、传输线程、事件线程、 Fw Event_State、机器等 如果您有一些文档描述了 bus_sendInitCommand 和 ctrlCmdBtl_get_device_info_cmd 这些模块的角色、则 plz share。

我没有任何涵盖此内容的文档。

在我看来、您的实施总体上似乎正常工作、迁移过程中是否遇到器件无法正常工作的具体问题？  

此致、

Josh Prushing

你好 Josh Prushing 

我们还感觉非常接近为我们的应用实现 SDK 移植。

我想我们坚持一个小点。

根据 bus_sendInitCommand 和 ctrlCmdBtl_get_device_info_cmd 的时序、查找以下 TI 波形分析。

根据 bus_sendInitCommand 和 ctrlCmdBtl_get_device_info_cmd 的时序、找到我们的测试分析如下。

如我们的测试所示、对于 bus_sendInitCommand (reserved、0)  、我们尚未观察到 IRQ_ACK 和 CC3300 中的其他命令以及第一个有效序列、也未立即观察到。  当“ctrlCmdBtl_get…μ s“时、在 4 秒后会观察到这些值。 进行设置。

我们想、IRQ 配置有一些问题。

函数 int cmd_Send(char *in、uint32_t inLen、 char *out、uint32_t outLen)-->中还有一个观察结果：在 commands.c 文件中、我们收到“trnspt_RequestSchedule“的计时器启动错误失败  

我们的疑问：

1)“IRQ_ACK“是否从“Fw Event_State Machine“触发？

2) 4 秒后观察到“IRQ ACK“的可能性是什么

3) 为什么“IRQ ACK“会针对“ctrlCmdBtl_get_device_info_cmd“触发、而不是在 TI 用例中的“bus_sendInitCommand“之后立即触发

4) 您认为  我们的 IRQ 配置有什么问题吗? 您的建议是什么。

5) 在 “trnspt_RequestSchedule“中,我们是“无法启动计时器错误“。

 5.a) 计时器在“trasport Thread“中的作用是什么  

 5.b) 计时器在未获得 IRQ_ACK 的任何角色

如果我们要上传 Salae 逻辑分析仪捕获结果、那么我们如何上传相同的结果。 我试过。 但不支持文件。

谢谢...

尊敬的 Yogesh：

您是否在实施中编辑了 wlan_if.c、init_host.c 或 init_device.c？ 如果是、您可以在此处上传这些文件（如果需要，可作为 txt 文件）、以便我了解 IRQ 时间与您的实施有何不同。

[引述 userid=“496917“ url=“~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640736/cc3300mod-queries-for-uploading-cc3300mod-binaries-from-host/6328153

5) 在 “trnspt_RequestSchedule“中,我们是“无法启动计时器错误“。

 5.a) 计时器在“trasport Thread“中的作用是什么  

 5.b) 计时器在未获得 IRQ_ACK 的任何角色

[/报价]

此处返回的 RetVal 错误是什么？ 我在您的终端屏幕截图中没有看到这一点。 这将说明 导致此错误的原因。 对于 CommandSM 来说、这也是很好的理解。

如果我们要从我们这边上传 Salae 逻辑分析仪捕获结果、那么我们如何上传相同的结果。 我试过。 但不支持文件。

您可以通过 j-prushing1@ti.com 直接将文件发送给我。  

此致、

Josh Prushing

尊敬的 Yogesh：

感谢您通过电子邮件发送文件。

发送电子邮件：请确认我们的理解级别是否会触发 TI AM243 中断。

[JP]：AM243 情况 为上升沿触发。 我 在这里对您的输出感到困惑、您能帮助我理解吗？ 之前、您已声明您看到 IRQ 确认：

IRQ 确认 (0x62、0x00、0xBF、0xFC) 在 3.5 秒后出现的原因可能是什么

但现在,我看不到你发送给我的照片。 您的代码在今天和收到 IRQ 确认之间发生了什么变化？ 我想知道是否所有 IRQ 命令都从 AM243 设置程序移植到了 ST 设置。

发件人电子邮件：  

• 我们还在分析为什么计时器处于运行状态以及为什么未能停止
• 请您向我们提供一些意见、这样有助于分析和找到问题的根本原因。
• 计时器的作用是什么

[JP]：  

该计时器是 Wi-Fi 命令的超时看门狗、实际上、如果计时器在停止之前到期、这表示存在一些固件问题或 IRQ 错误（这给定第一个问题可能意味着 IRQ 的某些内容设置不正确）。  

根据您提供的图像、我不理解为什么错误没有返回错误编号。 对我来说、这表明计时器的初始化存在问题、但我不确定。 也许它只是与 IRQ 错误有关、一旦我们解决 IRQ 错误、就会消失。

此致、

Josh Prushing

您好、Josh、

下面是我们的代码、其中的“WLAN_IRQEnableInt“执行 IRQ 例程状态机需要执行。 但复位后 IRQ 变为高电平。 因此、这表示在 AM243 中、IRQ 配置为“Level‑Triggered“、这有助于“WLAN_IRQEnableInt“触发 IRQ 例程状态机。

   /*向初始化总线发送命令*/

   Bus_sendInitCommand（保留，0）；

    /*启用 IRQ 中断*/

   WLAN_IRQEnableInt()；

今天、我们模拟了 STM32 的类似行为、并发现初始序列工作正常、在初始化后、我们立即发现 IRQ ACK、IRQ 也变为低电平。 我向您发送了电子邮件、要求您完成序列捕获。

请确认我们的波形是否正确。

现在、我们未观察“读取设备信息“的命令。

以下是从 TI 收到的“Read Device Infor“参考命令

该命令由 SEQ1 (0x07)、0x50 0xBF 0xF0 、Seq2) 0x00、0x00 0x00 0x00 Seq3) 实际读取器件信息命令组成。

在我们的测试中、我们遵守 Seq 1 Seq 2 而不是 Seq3

我们还没有找到根本原因。  

• 您能否解释一下没有获得序列 3 的可能原因。
• 我们理解‘Transfer’是发送 Seq3 的地址。 请确认。
• 如何触发‘Transfer’（传输）以发送序列 3

谢谢。。

尊敬的 Yogesh：

我会在星期四结束前回复您。 感谢您的耐心。

此致、

Josh Prushing

尊敬的 Yogesh：

因此、这表示如果是 AM243、则 IRQ 配置为“Level‑triggered“、这有助于“WLAN_IRQEnableInt“触发 IRQ 例程状态机。

AM243 是边沿触发的、但可能是 ST 主机是电平触发的。  这可能是您收到计时器错误的原因。

请确认我们的波形是否正确。

MOSI 线路在初始序列后开始低电平并结束低电平、此时 TI MOSI 线路从高电平开始并结束高电平。 此外、您的占空比在每个 CLK 周期之间似乎略有变化。  

[引述 userid=“496917“ url=“~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640736/cc3300mod-queries-for-uploading-cc3300mod-binaries-from-host/6333165

• 您能否解释一下没有获得序列 3 的可能原因。
• 我们理解‘Transfer’是发送 Seq3 的地址。 请确认。
• 如何触发‘Transfer’（传输）以发送序列 3

[/报价]

您在此处的“转接“是什么意思？

SEQ1 0x07 0x50 0xBF 0xF0 是写入操作、0x62 0x00 0xBF 0xFC 是读取操作。 因此、seq3 看起来会有所不同、因为它是一个不同的操作。

此致、

Josh Prushing

您好、Josh、

感谢您的意见。

对 Get device info 命令有一些进一步的查询

按照我们的理解、“ctrlCmdBtl_get_device_info_cmd“ consi

此命令由 SEQ1 ( 0x07) 0x50 0xBF 0xF0 Seq2 ) 0x00、0x00 0x00 0x00 0x00 Seq3) 实际读取器件信息命令从 SYNC 模式 0x5C 0x5C 0x5C 0x5C 0x5C 启动

对于 Seq3) 我们理解、

• ctrlCmdBtl_get_device_info_cmd > cmd_Send > que_Enqueue (cmdCB->pMsgQ、cmdNode) 将 seq 3) 放入队列 cmdCB->pMsgQ。
• CMD_SM > que_Dequeue (cmdCB->pMsgQ)、从队列中获取数据并通过 SPI 发送数据

     我们的疑问：

     请确认我们的理解。

     在本例中、我们不遵守此序列 3)。 我们将进一步分析此问题、并回复您进行任何查询。

对于 Seq1 和 Seq2、我们有以下问题。

• 请告知我们使用 Seq1 和 Seq 2 进行触发的位置
• 它是否使用相同的'cmdCB->pMsgQ'与 que_Enqueue 和 que_Dequeue

谢谢。。

尊敬的 Yogesh：

ctrlCmdBtl_get_device_info_cmd > cmd_Send 准备要发送到固件的命令。

que_Enqueue (cmdCB->pMsgQ, cmdNode)将命令添加到队列中。  cmdCB 是包含队列 (pMsgQ) 的控制块。

CMD_SM > que_Dequeue (cmdCB->pMsgQ) 从队列中检索下一个命令。

实际命令与 bus_sendWriteCommand() 一起发送。 这会构建 Seq1、等待器件准备就绪（当 Seq2 完成时）并写入数据 (Seq3)。 它是在 cmd_sm () 中调用的,但只是想为您阐明这一点。

我希望这能为您澄清。

此致、

Josh Prushing

您好、Josh、

您与“bus_sendWriteCommand()“相关的输入对我们有很大帮助。

我们能够完全实现“获取器件信息“命令。

从下周开始、我们将开始将二进制文件上传到 CC3300 MOD 活动。 我们也会回复您。

对 TI 的参考波形有几个疑问。

1) 我们理解以下“set_device_fuse_mac_addr“补丁。 请确认相同。 我通过电子邮件向您发送了命令。

2) 在 “set_device_fuse_mac_addr“中确切处理哪些活动。

谢谢。。

您好、Josh、

我们告诉您、我们正在处理从主机到 CC3300 的二进制文件上传

我们将二进制转换为 C 数组。

将这些 C 数组复制到单独的项目中、并将这些二进制文件写入闪存中的特定地址。

替换了 SDK 工程中的新地址并正在测试上传二进制逻辑。

e2e.ti.com/.../cc33xx_5F00_2nd_5F00_loader.c

我们希望得到您的帮助。  

您是否可以确认是否在 C 数组中正确转换的附加引导加载程序二进制文件。

我正在发送“cc33xx_2nd loader.bin“、我们通过电子邮件将其提及。

谢谢。。  

你好 Josh Prushing 

我们方面有一个好消息。 我们能够通过以下观察结果将引导加载程序二进制文件上传到 CC3300 MOD。

进行确认后、存储在外部闪存中的二进制文件格式正确。

我们的意见：

在上传二进制文件时、我们遇到了以下错误、程序没有出现“ctrlCmd Fw_Container 下载“

对于第一次尝试中的测试、我们注释了 IRQ 启用（橙色突出显示）、第二次尝试注释了突出显示的黑框代码。

在这两种情况下 、程序都会发出“ctrlCmd Fw_Container．Download“。 但是、程序会进入“Report（“\n\rdad not receive RAM hint_second_loader_init_fully“）、如下所述。

对于尝试的代码、程序会出现以下错误。

我们的疑问：

1) 什么可能是错误的原因,它出现在最后一个块,而不修改代码.

RX_STATUS count：、headers_len、next read 总长度：read-unaligned size：！！

[NO_TAG]  减少前的 Rx 长度、长度：！！！

 [NO_TAG] SPI 无响应！

[NO_TAG] ASSSSEEEERRRTTT！！！

2) 什么是突出显示的黑盒代码的必要性。 为什么 IRQ 在发送最后一个块之前禁用、在之后启用。 同样、超时。

谢谢...

尊敬的 Yogesh：

很抱歉、由于反应迟来、我自星期四 Night 以来就已离职。 我很高兴听到您的二进制文件现在被正确存储！   

2) 高亮黑盒代码的必要性是什么。 为什么 IRQ 在发送最后一个块之前禁用、在之后启用。 同样、超时。

ROM 引导管理器 (BM) 在每个容器块之后发送 CMD_COMPLETE。 在最后一个 RAM BM 容器块之后、ROM BM 发送另一个 CMD_COMPLETE、清理 SPI 接口并调用 RAM BM。 这可能会导致在清除后读取有故障的核心状态。  

若要解决此问题、可通过减少超时并在发送最后一个容器块之前禁用中断、然后在之后重新启用来忽略最后一个 CMD_COMPLETE。 这就是 上面黑色框中突出显示的两个代码片段的用途。

1) 在不修改代码的情况下、最后一个块出现错误的原因可能是什么。

 由于 ST 速度差异、我想象一下 CLK 主机需要不同的超时长度。  

您是否仍有与“set_device_fuse_mac_addr“相关的问题、或者这些问题是否已解决？

此致、

Josh Prushing

您好、Josh、

我又回来工作了。

正如我们上周提到的、我们成功上传了 RAM 引导加载程序。  

但“等待 RAM BTL 上升“无法正常运行、并且程序已重新启动。 按如下所示记录。

我的同事 Ashok 问您以下问题：

1) RAM BTL Up 的工作方式以及主机如何了解 RAM BTL Up。

2) 我们还要求 在您一方共享的波形中突出显示 RAM BTL 上升的时间周期。

您让 Ashok 分享 RAM BTL 上升的波形。

查找用于 ram 引导加载程序上传的随附跟踪。

e2e.ti.com/.../RAM-Bootloader-Trace.zip

未初始化 RAM 引导加载程序时的日志。

请为我们提供一些建议、说明在我们的情况下没有初始化 RAM 引导加载程序的原因。

再移动一点、在日志中观察到的数据中、移动一个半字节。 我们已经向 Salae 提出了问题以了解这个问题。 请分析这个 1 半字节移位的波形。

谢谢。。

欢迎回来 Yogesh！

请输入我们为什么在本例中没有初始化 RAM 引导加载程序。

只是为了确认、您是否   在读取最后一个块后调用 OSI_fclose (containerFileHandle) 和 OS_free (buffer)？  这似乎基于“RX_TX_BUFFER 溢出的地方出现的 Rx length before decimation“错误、但我不确定为什么错误 msg 不包含缓冲区的长度。

我看到有很多打印语句被注释掉。 是否可以在未注释的情况下显示输出？ 很难准确理解为什么没有初始化 RAM btlr。 例如、设备似乎正在下载 btlr、但尚未完全初始化。 是否可以在 fw Event_Wait 中添加 PRINT 语句来确定错误发生的确切位置？ 是超时还是提示_second_loader_init_fullet ==–1？

打印有用的语句：

• 在 FW Event_Wait 中
  • 打印确认哪个事件中断了交换机
  • 如果 OSI 操作失败
• 在 CtrlCmd Fw_Container 下载中
  • 在正确读取最后一个数据块之前确认数据块
  • 确认最后一个块设置超时并禁用中断
  • 读取最后一个块后确认超时设置回 0 并重新启用中断
  • 确认在最后一个块之后调用 OSI_fclose 和 OS_FREE
• 确认 调用了 ctrlCmdBtl_get_device_info_cmd
• 确认 调用了 fw Event_Set DuringInit

我不确定为什么波形会移动一个半字节、在最后一次捕获之间的代码是否有任何变化？  

此致、

Josh Prushing

您好、Josh、

•   在读取最后一个块后、我们将调用 OSI_fclose (containerFileHandle) 和 OS_free (buffer)
• 我们不理解您的以下消息。

         “这似乎基于 RX_TX_BUFFER 溢出的“RX 长度之前的 Rx length“错误、但我不确定错误 msg 为什么不包含缓冲区的长度。“

        1) 在 RX_TX_BUFFER 溢出的地方出现“减小前的 Rx 长度“错误是什么意思？

        2)“为什么错误消息不包含缓冲区的长度

• 带有 PRINT 语句的最新最终阶段日志未 作如下评论。
• 
• 我们观察到了 TI 参考波形。 我们观察到 IRQ 在最后一个块之后变为高电平。 在本例中、IRQ 保持低电平。 IRQ 是否变为高电平表示 RAM 引导加载程序已启动？  如果答案为“是“、则在这种情况下、RAM BL 不会初始化、IRQ 不会变为高电平。
• “FW Event_Wait “函数在内部调用“OSI_SyncObjWait“、该函数返回–1。“OSI_SyncObjWait“在内部等待信标。 我想在 IRQ 上 RAM BL 初始化后、该信标将被释放并接收到 “OSI_SyncObjWait“。 我们的理解是否正确？
• 
• 

谢谢。。

尊敬的 Yogesh：

最新的最后阶段日志 、其中 PRINT 语句未作如下注释。

“fw Event_Wait “函数在内部调用返回–1 的“OSI_SyncObjWait“。“OSI_SyncObjWait“在内部等待信标。 我猜在 IRQ 上 RAM BL 初始化后、此信标将被释放并接收到 “OSI_SyncObjWait“

感谢您提供更详细的日志！ 如您在此处所述、OSI 操作失败、因为在 2 秒超时内未获取信标。

您能否检查以下内容：

• init_device.c 中前面的 fw Event_Wait 是否成功？ 以下命令使用提示 ROM_LOADER_INIT_COMPLETE。
• ctrlCmdc Fw_Container Download () 的返回值是多少？
• 在 FW Event_Signal 中、能否在 OSI_SyncObjSignal 之前和之后放置 PRINT 语句以确认该传递符合预期？

如果这一切都符合预期、则可能由于时钟速度差异而需要增加超时。

IRQ 是否变为高电平、表示 RAM 引导加载程序已启动？  如果答案为“是“、则在这种情况下、RAM BL 将不会初始化、IRQ 将不会变为高电平。

是、IRQ 应为高电平。 请参阅上述原因、了解 RAM BL 未初始化的原因。

此致、

Josh Prushing