[参考译文] CC3235MODSF：从 HTTPS 服务器下载文件失败

您好！

我个人还没有使用 AT 命令库、而是直接调用 API。

首先、由于 TCP 窗口指示0 (我假设在客户端、请验证)、这意味着数据包到达网络堆栈并保持、直到主机将其拉取。 将窗口降至0意味着主机无法足够快地提取这些数据包。 由于它在非安全版本上运行良好、因此可能是主机由于某种原因而卡住。 您是否能够调试主机侧以指示它是否卡住以及具体位置？

此致、

Shlomi

您好、感谢您的回答。  在本例中、CC32350MODSF 是下载文件的客户端。  TCP 接收窗口会很快填充、然后客户端会发送 TCP Zero 窗口。  这种情况在整个下载过程中经常发生。  下面是下载失败前 Wireshark 捕获的快照：

是的、这就是我的想法。

作为快速检查、对于非安全 HTTP、它看起来是什么样的？ 窗口是否也会下降到0？

此外，您能否给我显示与 TCP SYN 的初始握手的屏幕截图？ 我想查看设备的 MSS 和初始窗口是什么。

使用 http 进行测试时、下载成功完成、窗口也会下降到0、但一个有趣的观察结果是窗口大小保持相对较小(<7300)、而使用 https 时、窗口大小有时会跳至14600、因为它恰好在故障发生前发生。  我在整个下载过程中绘制了两个窗口的大小图形：

下面是 TCP SYN 屏幕截图、MSS 是1460、客户端(CC3235)公布的初始接收窗口是33580。  在前12个段之后、该窗口大小下降得很快。

您好！

感谢您提供所有信息。 对于 HTTP 类型、窗口也降至0是合理的。 同样、这与主机拉电阻不够快相关。 AT 命令可能会更慢、因为它通过相对较慢的 UART 连接到另一个发送命令的处理器。 连接两个处理器的 UART 的速度是多少？

窗口以33580开头的事实是、NWP 在池中具有所有23个可用缓冲区(每个缓冲区为1460)、当它降为零且主机开始拉取时、它会以1460字节的分辨率增加。 在 HTTPS 中、它分配10、而在 HTTP 中、它分配的较少。 我不认为这是吸烟枪所在的地方。

我可以尝试查看一下、看看在涉及安全与非安全的情况下、我是否可以看到不同的过程/流程。

此致、

Shlomi

您好、Shlomi、

我有一些有关确切故障模式的新信息。  我们的主机控制器在 UART 接口上发送和接收 AT 命令、即超时。  我在 UART 接口上捕获了流量、当 WiFi 模块发生故障时、似乎没有响应超过250ms、通常它在2ms 内以768字节进行响应、但当它没有响应超过200ms 时、我们的主机控制器会进入错误状态。

简而言之，WiFi 模块似乎响应了 httppreadresponse，但有时它比预期的要长得多。  我们仍然存在一个主要问题、即我们无法在现场的这些单元上对固件进行 OTA、因此我仍想了解此延迟的原因、以及是否有任何方法可以减少服务器端的此延迟。

此外、如果这种偶尔的延迟是预期行为、您可以提供最坏的情况吗？  主机控制器应等待多长时间、直至设置错误条件？

谢谢！

您好！

尽管主机控制器超时时间比平常稍长(只要由于某种原因而未被卡住)、但我不希望它中断 TCP 连接。 您是否在非安全 TCP 连接中看到类似的行为？ 您使用什么设置进行 UART 连接？

此时最好的方法可能是获取 NWP 日志、并希望看到可能导致根本原因的结果。 您是否熟悉此过程？  您可以在我们的 NWP 程序员指南中找到该过程、 请参阅。 SWRU455第20章。 请告诉我是否清楚。

此致、

Shlomi

您好、UART 波特率为115200、未使用硬件流控制。  为了明确此行为、请执行以下操作：

• 主机每200ms 发送一次 httppreadResponse 消息
• 如果主机在200ms 内未看到 WiFi 模块的响应、则假设连接已断开并发送一个 httpdisconnect

因此、如果主机只是等待 WiFi 模块响应的时间更长、我认为 TCP 连接仍然可以。  我们现在将对此进行测试。  不过，我的问题仍然是，造成这种延迟的时间比预期的要长，以及我们预期的最长延迟是多少，要硬编码超时时间。

此外、我们也熟悉启用 NWP 日志的过程、但我们很难使用新 SDK 构建电路板并对其进行编程： e2e.ti.com/.../4150279