[参考译文] CC3120MOD：SL_DEVICE_EVENT_FATAL_DEVICE_ABORT 代码

为了澄清一点、我只需要在用作 AP 的器件上使用此版本、因为这是崩溃的版本。

您之前共享的日志来自基站设备、而不是 AP。

此时、工作站可以保留为非调试版本。

好的、我在 药柜上使用了一个旧的 SP (甚至是3.23.96.0有问题)、它不再崩溃。
因此、我唯一的站点会连接到 AP、发送5个 ping 并无限期地断开连接 。
它不会崩溃、但在第一次断开连接后、我的应用程序中没有任何事件(我甚至没有收到断开事件)。 但是、由于工作站可以重新连接、我让它运行一段时间。
以下是日志

仅供参考、不确定它是否重要、但在我尝试发送每一个循环的5个 ping 中、我得到的最好的是：
pReport->PacketsSent => 5.
pReport->PacketsReceived => 1.

谢谢

那么，我们能否得出结论，不是原来的问题？

从日志中我看不到卡死或总线故障、所以我猜答案是肯定的。

不确定 Ping 的损耗率、但此时不太重要。

为了更好地反映原始设置(不涉及 iPad)、我还需要执行另外两个步骤：

1. 添加更多的 SL 器件作为站、一对一、并让它们执行 ping 操作
2. 从 ping 移动到 HTTP。 如果您尝试使用真实的浏览器、只需连接到 AP IP 地址即可完成此操作、并获得存储在 ROM 中的 HTTP 页面(您可以查看状态、ping、添加配置文件等)。 在 SL 器件中、您可能需要调用 https：//xxx() API 来连接和提取信息。 请告诉我您的一方是否可行。

此致、

Shlomi

您好、Shlomi、
好的、我会这样做并告诉您。
同时、您是否在日志中看到任何内容、为什么 iPad 被"踢出"网络(并立即重新连接、有时连续几次)？
为什么我们也会获得重复的异步事件(SL_NetApp_EVENT_IPv4_Acquired )？

谢谢

您好！

我无法在日志中看到重复的异步事件、但我可以看到一个日志中有许多 iPad 断开连接。

它看起来是一个未指定的原因、但深入研究发现它已断开连接、以实现最大重试次数、这表示连接不良。 它与只有1/4个 ping 应答这一事实有点一致。 RSSI 水平是多少？ 器件之间是否距离太远或距离太近？

Shlomi

在测试过程中、它们的电表波长约为1米。 在实际情况下、情况会更糟。 我将添加 RSSI 日志以确保没有问题。

谢谢

好的、只是让您知道、当它太近时、它也不是理想的。 但是1米应该是可以的(只是不要将两者放在非常接近的位置)。

这些断开是因为新的 SP 而产生的新行为还是在官方 SP 之前观察到的新行为？

我提出这一问题是因为我在您之前捕获的日志中没有看到过这些日志。

它们应该足够远、我将添加 RSSI 日志以确保它不是硬件问题。

是的、我们一直遇到此问题、直到 iPad 应用程序被更改为请求其他设备切换到 AP 模式。 但有时、它会逐个循环所有 AP、直到用户放弃。 我要求删除此功能、仅保留1个 AP、直到我们了解导致此功能的原因。

重现此崩溃并不容易、但它仍然发生很多。

我明白了。

接下来、让我们重点讨论最初看来具有更高优先级的问题。

当您有反馈时、请告诉我。

Shlomi

您好、Shlomi、

那么、昨天我制作了一个简单的固件。 请注意、站点使用较旧的 SP (由于崩溃、无法使用当前 SP)。 AP 使用您提供的最新版本。
 - 1个接入点
 －6台其它设备作为工作站。 连接、ping (50KB)、断开连接、等待5秒、重新启动。
因此、4个站连接、而另一个站等待空闲点。 RSSI 很好、几个小时后没有问题。
我昨天遇到的 ping 问题是由于一个坏的标志、不再是问题。

今天早上我稍微升级了一下。
 -每10秒1个 AP 发出 HTTP GET 请求(与我们的应用相同)
 - 1台具有简单 HTTP 服务器的 Android 手机
 －6台其它设备作为工作站。 它们连接、发送1MB (HTTP POST)、断开连接、等待5秒、重新启动
最多3个站、因为 Android 设备、另一个站等待、与昨天相同。 一个多小时后没有问题。

我想尝试使用 iOS 设备、但我认为这没什么影响。

主应用程序中的某个内容是否会导致 NWP 崩溃？
谢谢

您好！

很高兴听到您无法使用 HTTP 和 Android 重现问题。

始终值得尝试使用 iOS、只需与原始设置保持一致。

您对主应用程序的看法是什么？ 在 AP (使用 SL 器件)上运行的一个还是在 iOS 上运行的那个？

Shlomi

我的意思是运行 AP 的那个。
例如、今天早上我看到连续发送2个 HTTP 请求而不显式读取响应主体(或在发送请求时使用标志将其丢弃)、第二个请求将在100%的时间内失败(不过没有崩溃)

嗯、我认为 AP 应用程序的错误行为不会导致 NWP 崩溃。

最坏的情况可能会导致应用本身崩溃、而不是 NWP 崩溃。

这就是"独立执行环境"的全部意义。

在您的案例中、在总线故障中、我看不到与来自 AP 应用程序的命令有任何直接关系。

您好、Shlomi、
我对 iPad 执行了相同的测试、一段时间后它崩溃。 希望日志在 这里可以。

sl_device_event_fature_device_abort
代码：0x00000000
值：0x20085B96

谢谢

您好！

至少现在它与原始错误相同。

似乎有许多设备在重新连接之前重新连接、对吧？

与其他重新连接情况相比、日志中没有什么奇怪的地方、因此至少从当前日志中无法确定根本原因。

我不确定为什么在 iOS 中会发生这种情况、而在 Android 中不会发生这种情况。 您还捕获了 Android 吗？ 您是否在与 iOS 相同的时间内执行了 Android？

Shlomi

许多重新连接是肯定的、但这是执行测试的方式、连接、发送文件、断开连接、暂停、 环路。
它在 Android 上连续运行了10小时、没有问题、在 iOS 上~40分钟后崩溃。
我没有将日志保存在 Android 上、但如果需要、可以轻松地再次执行测试。

谢谢

最好只是提供 Android 的工作参考。 可能会弹出一些内容。

对于 iOS、您提到了40分钟。 在原始测试流程中、它是否持续了这么长的时间、还是在几次重新连接后失败？

40分钟的测试、但对于我们的应用、在不到10分钟的时间内测试失败。 实际上、并非所有6个器件都可以连接、有时是3个、有时是4个、然后它会崩溃。
在该测试中、它们都在失败之前多次连接。 (但由于" ping 崩溃"问题、我在站点上刷写了较旧的 SP、而对于实际的应用程序日志、它们都使用提供的最新版本)。

自从我上次记录以来、我已使用 iPad 重新启动测试、但测试尚未崩溃(几个小时后)

您是否也可以使用此设置进行测试？ 多个 CC3120用作工作站、1个用作 AP、以及一个带有 HTTP 服务器的 iPad？ 也许您会获得更多信息？

实际上我没有 ipad、这就是我要求使用 Android 进行测试的原因。

在测试中、iOS 似乎以某种方式触发它、尽管我看不到如何触发。

它可能与 NWP 中仅在 iOS 下弹出的一些时序问题相关。

BTW、即使我有 iOS 设备、您如何控制 HTTP 服务器？ 您是否使用特定应用程序？

我没有找到 iOS 应用程序，所以我必须制作一个，它非常简单，但 Apple 是 Apple，您需要一个 Mac 来构建和推送..

不幸的是，我没有这种选择。

让我看看我们在内部还能做些什么。

如果我们无法在内部继续、这是否是继续调试的选项？

您好！
当然、让我知道我可以做些什么来提供帮助。
谢谢

谢谢、今天我们将进一步探讨、并告诉您我是否有另一位 SP 候选人。

Shlomi

您好、Shlomi、

您是否有关于此问题的新闻？ 我们必须停止所有销售以避免糟糕的用户体验。 这一问题变得越来越紧迫。

谢谢

您好！

我理解紧迫性、但还不幸运、因为这是一个非常微不足道且难以解决的问题。

我计划的是尝试并实施修补程序、以读取请求线程的栈指针、并查看我是否可以在那里找到有关程序计数器的提示、该程序计数器意味着它停留在哪里。

此致、

Shlomi

您好！

我有另一个版本、希望我可以看到更多内容。

请注意、您需要禁用 mdns 以使其像以前一样工作、因为它基于 v96。

此致、

Shlomie2e.ti.com/.../sp_5F00_3.23.95.0_5F00_2.7.0.0_5F00_2.2.0.7.bin

您好、Shlomi、
以下是日志。
此外、请注意、即使我禁用 Station > MDNS、我也无法在站点上使用此 SP、它会很早就崩溃(连接到 AP 时)、因此即使我们使其在 AP 上工作、我们也无法使用它。
此外、当我发布此帖子时、我有时会遇到崩溃(并非总是)、但对于这些较新的崩溃、每次都崩溃。

谢谢

我不要求在工作站上使用它、而是在 AP 上使用它。 该电台可以保留官方电台。

我所需要的只是 AP 日志、因为这是一个崩溃的日志。

仅当 AP 设置为无 mdns 且调试 SP 时、它是否起作用？

是的：)这是我记录的内容，您可以在上面找到新的 SP，仅在 AP 上。 这只是一个注释。
谢谢

我应该在这些日志中看到任何断言吗？

我以前没有看到任何问题、看起来很干净。

它在过去崩溃的完全相同的时间停止、因此我猜测它崩溃了。 但我的应用程序的日志失败、因此我不确定。
我尝试了3次、因为它没有崩溃(仅是断开连接问题)。 除了调试跟踪之外，此 SP 中是否有任何更改？

谢谢

无更改、只是在空闲任务中添加了一些消息(因此每10秒打印一次)、这些消息甚至不会更改计时。

最好是等待最初发生的致命错误事件。

您好、Shlomi、
我今天早上做了一些测试、没有碰撞。 但由于持续断开、我无法完成其中的任何一项。 (许多快速断开连接/重新连接导致 iPad 在连接时从操作系统获得断开的回叫)。
是否可以检查原因？ 我100%确定 RSSI 是恒定的并且非常好(大约-40/-45dBm)
以下是日志。

我觉得崩溃可能来自某些函数中花费的时间过多、例如 SimpleLinkWlanEventHandler。 没有崩溃、因为我已将此函数降至最低(打印 id)、而在 SP 端没有进行任何更改。

此外，在向 HttpClient_sendRequest 提供回调时，回调是否需要花费最大时间？ 我正在执行一些其他测试、但如果此函数仅从 RAM 发送一些数据(而不是外部闪存+调试打印)、看起来我没有断开连接。

谢谢

不用担心、忘记最后一部分、我只是在不使用此回调时遇到许多断开连接：

(11:53:10.251) SimpleLinkWlanEventHandler 3
(11:53:10.273) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(11:53:45.515) HTTPClient_sendRequest 0
(11:53:45.545) #HTTPClient_sendRequest 403
(11:53:46.336) SimpleLinkWlanEventHandler 4
(11:53:46.364) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(11:53:46.497) SimpleLinkWlanEventHandler 3
(11:53:46.522) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(11:53:48.603) SimpleLinkWlanEventHandler 3
(11:53:53.017) SimpleLinkWlanEventHandler 4
(11:53:53.046) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(11:53:53.390) SimpleLinkWlanEventHandler 3
(11:53:53.417) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(11:53:55.514) HTTPClient_sendRequest 0
(11:53:56.400) SimpleLinkWlanEventHandler 4
(11:53:56.426) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(11:54:05.876) #HTTPClient_sendRequest -3020
(11:54:09.372) SimpleLinkWlanEventHandler 3
(11:54:09.401) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(11:54:11.590) #HTTPClient_sendRequest 403
(11:54:11.621) HTTPClient_sendRequest 0
(11:54:11.644) #HTTPClient_sendRequest 403
(11:54:12.893) SimpleLinkWlanEventHandler 4
(11:54:12.925) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(11:54:15.514) HTTPClient_sendRequest 0
(11:54:25.870) #HTTPClient_sendRequest -3020

我这边有什么需要的呢？

您无法使用当前版本重新生成？

我确实需要您的帮助、我无法保持稳定的连接、甚至连5分钟都无法保持。
您说崩溃不能来自我们一侧的应用程序，但 SP 侧没有任何变化，它已经解决了吗？ 我刚才做了一个假设、但我想说一下它的底部。

谢谢你。

您能否至少检查使用 v97时是否仍然能够重现崩溃(固件从 v96开始崩溃)？

我只是不想开始调试其他内容、而只想专注于原始问题(无论如何、这一问题的优先级更高)。

如果您可以使用 v97进行复制、那么我可以只使用添加的调试消息创建新版本(不包含所有 v96和 v95调试消息、希望它仍然可以重现)。

Shlomi

我尝试过 v97，没有崩溃，但有很多断开连接。

>我只是不想开始调试其他内容、而是专注于原始问题(不管怎样、它的优先级更高)。

我理解、但另一方面、结果是相同的、过程失败、器件重新启动(从崩溃或多次断开连接)、过程从开始、反复地开始。

以下是日志。

B8：2A：A9：B5：F9：D4是 iPad。

(15:18:37.320) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:18:37.329) SimpleLinkWlanEventHandler 3
(15:18:37.340) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:18:39.565) SimpleLinkWlanEventHandler 3
(15:18:39.597) SL_WLAN_EVENT_STA_ADDED 34:15:13:DA:9D:0C
(15:18:44.106) SimpleLinkWlanEventHandler 4
(15:18:44.133) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:18:44.670) SimpleLinkWlanEventHandler 3
(15:18:44.698) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:18:48.225) SimpleLinkWlanEventHandler 4
(15:18:48.250) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:18:48.414) SimpleLinkWlanEventHandler 3
(15:18:48.447) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:18:55.120) SimpleLinkWlanEventHandler 4
(15:18:55.150) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:19:05.417) SimpleLinkSockEventHandler 1
(15:19:05.456) SlNetSock_send -1
(15:19:05.456) #HTTPClient_sendRequest -1
(15:19:05.456) SimpleLinkSockEventHandler 1
(15:19:05.493) SimpleLinkSockEventHandler 1
(15:19:05.493) SimpleLinkSockEventHandler 1
(15:19:05.493) SimpleLinkSockEventHandler 1
(15:19:05.528) SimpleLinkSockEventHandler 1
(15:19:05.528) SimpleLinkSockEventHandler 1
(15:19:05.528) SimpleLinkSockEventHandler 1
(15:19:05.528) SimpleLinkSockEventHandler 1
(15:19:05.558) SimpleLinkSockEventHandler 1
(15:19:05.558) SimpleLinkSockEventHandler 1
(15:19:05.586) SimpleLinkSockEventHandler 1
(15:19:05.586) SimpleLinkSockEventHandler 1
(15:19:05.586) SimpleLinkSockEventHandler 1
(15:19:05.617) SimpleLinkSockEventHandler 1
(15:19:05.617) SimpleLinkSockEventHandler 1
(15:19:05.617) SimpleLinkSockEventHandler 1
(15:19:05.648) SimpleLinkSockEventHandler 1
(15:19:05.648) SimpleLinkSockEventHandler 1
(15:19:05.648) SimpleLinkSockEventHandler 1
(15:19:05.682) SimpleLinkSockEventHandler 1
(15:19:05.682) post_file_body_cb retry
(15:19:06.122) SimpleLinkWlanEventHandler 3
(15:19:06.150) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:19:07.847) SlNetSock_connect sd 0
(15:19:07.876) h
(15:19:07.876) post_file_body_cb post_file_send_filename
(15:19:08.049) SimpleLinkWlanEventHandler 4
(15:19:08.080) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:19:18.403) SlNetSock_send -1
(15:19:18.433) #HTTPClient_sendRequest -1
(15:19:18.433) SimpleLinkSockEventHandler 1
(15:19:18.457) SimpleLinkSockEventHandler 1
(15:19:18.457) SimpleLinkSockEventHandler 1
(15:19:18.485) SimpleLinkSockEventHandler 1
(15:19:18.485) SimpleLinkSockEventHandler 1
(15:19:18.485) SimpleLinkSockEventHandler 1
(15:19:18.510) SimpleLinkSockEventHandler 1
(15:19:18.510) SimpleLinkSockEventHandler 1
(15:19:18.543) SimpleLinkSockEventHandler 1
(15:20:09.374) 
(15:20:09.374) HTTPClient_sendRequest 2816252
(15:20:09.398) post_file_body_cb post_file_send_filename
(15:20:09.471) SimpleLinkWlanEventHandler 4
(15:20:09.498) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:20:09.618) SimpleLinkWlanEventHandler 3
(15:20:09.659) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:20:10.535) SimpleLinkWlanEventHandler 3
(15:20:10.565) SL_WLAN_EVENT_STA_ADDED 34:15:13:DA:9D:0C
(15:20:15.888) SimpleLinkWlanEventHandler 4
(15:20:15.926) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:20:16.462) SimpleLinkWlanEventHandler 3
(15:20:16.499) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:20:20.028) SimpleLinkWlanEventHandler 4
(15:20:20.064) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:20:22.562) SimpleLinkWlanEventHandler 3
(15:20:22.600) SL_WLAN_EVENT_STA_ADDED B8:2A:A9:B5:F9:D4
(15:20:35.016) SimpleLinkWlanEventHandler 4
(15:20:35.046) SL_WLAN_EVENT_STA_REMOVED B8:2A:A9:B5:F9:D4
(15:20:44.322) SimpleLinkSockEventHandler 1
(15:20:44.352) SlNetSock_send -1
(15:20:44.352) #HTTPClient_sendRequest -1
(15:20:44.373) SimpleLinkSockEventHandler 1
(15:20:44.373) SimpleLinkSockEventHandler 1
(15:20:44.398) SimpleLinkSockEventHandler 1
(15:20:44.398) SimpleLinkSockEventHandler 1
(15:20:44.420) SimpleLinkSockEventHandler 1
(15:20:44.420) SimpleLinkSockEventHandler 1
(15:20:44.455) SimpleLinkSockEventHandler 1
(15:20:44.455) SimpleLinkSockEventHandler 1
(15:20:44.455) SimpleLinkSockEventHandler 1
(15:20:44.455) SimpleLinkSockEventHandler 1

您好！

同样、所有断开连接都是最大 TX 重试故障事件的结果。

我看不到 RSSI、但我认为它处于可接受的水平。

没有以前的总线故障。

那么、我是否可以得出这样的结论：断开连接之前和现在都是更糟糕的？

断开连接是否仅与 iPad 或其他已连接的电台相关？

我们可以在这里走两条路：

• 继续调试断开连接、这是另一个问题。 在这种情况下、我可能需要一个空气嗅探器、但启动时、MAC 记录器也很好(另一个引脚记录器)
• 回到原来的问题。 我想至少看看即使是官方 SP (无调试 SP)也能解决最初的问题。

Shlomi

使用官方版本(sp_3.22.0.1_2.7.0.0_2.2.0.7)进行了尝试、结果相同、没有崩溃、但与 iPad 有许多断开连接(我不复制日志、因为它们与之前的日志相似)。
在10分钟的测试中，工作站保持连接大约15秒，以便将文件发送到 iPad，而 iPad 应从开始到结束连接，这可能说明为什么只有 ipad 断开连接？

>所有断开连接都是最大 TX 重试失败事件的结果。
是否有方法可以在没有监听器的情况下知道哪些帧？

有没有推荐好的嗅探器？
同时、我将从另一个引脚生成一些日志

谢谢

我想、如果其他站点仅连接15秒、它可以解释为什么 iPad 会被启动、而其他设备不会被启动。

我们无法知道、因为它不是导致它的特定数据包、而是 Wi-Fi 数据包可能重新传输且速率调整为更稳定的调制等的一段时间

我个人使用的是具有许可证的 Omnipeek、但我确信有一些使用 Wireshark 软件的免费监听器。

但是、正如我说过的、从 MAC 记录器开始也很好。

顺便说一下、一个好的测试是让 iPad 在空闲连接中连接到 SL AP 几分钟、并检查它是否断开连接。

好的、我做了2个测试、 这里是日志。

我也会测试您的建议。
谢谢

您好！

请注意、我的周末是周五至周六、但通过查看 MAC 日志、我可以看到 TX_MAX_RETRY 事件。

如果在没有确认的情况下有100个连续帧发送到已连接的基站、则会触发此事件。

我不知道发送的帧是什么、为此我需要使用监听器、但这可能是 IOP 问题之一(SL 设备或 Android 不会发生这种情况、但 iOS 的行为可能会有所不同)。

此致、

Shlomi

您好、Shlomi、

我已将 iPad 连接到 AP、并保持连接而不会出现任何问题。
我一次只尝试使用1个站、但 仍然有连接问题。

我正在尝试让我的手握在嗅探器上。

谢谢

因此、如果 iPad 连接到 SL AP 而不交换数据、它将保持连接、对吧？

在这种情况下、可能会建议在交换数据时使用 iPad 使用某种 IOP。例如、从 AP 轮询帧时。

可能是省电机制运行不正常。

我们将能够在空中监听器上看到更多信息。

此致、

Shlomi

您好！

很抱歉答复迟了、但我现在已不上班几天。

但是、我确实研究了监听器捕获、似乎从 Simplelink AP 传输到 iPad 的帧正在重新传输、因为大多数情况下都没有确认(在响应之前接受一些试验)。 iPad 在 Wi-Fi 标志中明确表示它处于唤醒状态而不处于睡眠状态、因此从规范中可以有效地发送帧而不进行轮询。 监听器可能还会错过帧、但即使错过了帧、总的底线也是一样的。

例如、iPad 向 AP 发送帧的另一个方向不是这种情况。 iPad 偶尔会将帧重新传输到 AP、但这是正常情况。

最好看到其他连接的站点与 AP 交换数据并查看其行为、但大多数帧都来自 iPad。

• 是否也可以看到其他电台？
• 您还在早期测试中提到、从 iPad ping AP 的帧运行良好、并且 iPad 未断开连接。 如果是这种情况、还可以查看嗅探器捕获并验证是否可以观察到这些重传。

同样、我的回复可能会延迟。

此致、

Shlomi