[参考译文] CC3220SF：与 Wifi CoCPU 之间的 SPI 通信不可靠

您好、

感谢您的反馈。

您似乎同时测试了 CC31xx+外部 MCU 和 CC32xx SoC、尽管 SoC 的可靠性低于 CC31xx+MCU 组合、但两者都出现了稳定性问题。

如果没有具体的日志、就很难注释（例如在两种情况下都是外部 MCU 或驱动程序日志的情况下进行 SPI 捕获）。

许多客户长期使用此芯片（自 2016 年起）、而且在整个过程中都存在问题（我们已解决和修复）、但最终该设备应该稳定且广泛部署。

如果您可以指明具体失败的位置、以及我认为您收到事件时出现的错误（例如， SL_DEVICE_EVENT_FATUAL_DEVICE_ABORT 、SL_DEVICE_EVENT_FATUAL_DRIVER_ABORT 、SL_DEVICE_EVENT_FATUAL_NO_CMD_ACK、SL_DEVICE_EVENT_FATUAL_SYNC_LOSS 等）、 我会很乐意去看看。

我将保留此内容供其他用户评论。

此致、

Shlomi

嗨、Shlomi

感谢您抽出宝贵的时间进行回复。

是的、它通常是其中一个、SL_DEVICE_EVENT_FALATAL_**。  
在多次启动时、MAC 地址全部为零或网关 IP 地址为零。
然后、在进行配置时、它也会处于奇怪的状态、在这种状态下、我们必须对器件重新编程。

当我们通过串行端口启用日志记录时的主要问题（我们在我们的应用中同时使用这两种端口）、器件在禁用时的行为会有所不同。
因此、您可以通过添加等待状态（这就是我们所能做的）来解决此问题、但删除日志记录后、其行为会有所不同。
此外、启用 wifi 统计信息会很快中断 SPI 连接。 我们需要站点的信号强度。

我将设置一个带有日志记录功能的设备、有时需要几个小时才能中断。

我会对其进行记录、然后将其发布在此处。

老实说、我们在应用程序代码上的花费不到 10%、其余的是使解决方案保持稳定。

几乎感觉主 MCU 无法处理工作、或者 Wifi MCU SPI 端口有问题。

所有线程堆栈都是正常的、并且确实认为优先级已被优化设置。

我将保留测试和问题的简要说明、以免干扰问题。

此致

您好、

您是否使用 QFN 版本或模块？  

我没有看到 CC3220SF 器件存在此类问题。 根据我的权宜之计、CC3220 器件非常稳定。 我们有 10K+设备在现场 24/7 没有任何问题。 我们有非常复杂的代码（支持 HTTPS 的多 Scoket 网络服务器、多 SOKcet Modbus TCP 服务器、SNMPv1/v2/v3、用于云连接的 HTTPS POST、用于我们专有通信的 TLS 服务器、基于 UDP 广播的查找设备、带 TLS 的 SMTP；与多个 I2C、SPI 传感器和 LCD 显示屏的通信）。 所有这些都在 CC3220SF 的 Cortex-M4 应用 MCU 内同时运行。 但我需要指出的是、我们不使用 TI 驱动程序和网络抽象层。 我们使用 driverlib 和 SL_API 调用。 我们不使用高级 TI 协议库 (MQTT、HTTP)。 代码直接相关。

也许我现在会说你可能不想听到什么。  根据我的经验、CC3220 98%的稳定性问题与代码内容错误或代码内的错误有关、这些问题与 TI 代码或 CC3220 SOC 无关。

1 月

你（们）好

很高兴听到一些可靠的反馈。

我真的很感激。
如前所述,我们的应用（服务，进程，协议，驱动程序）大多与系统库和硬件驱动程序隔离,具有非常明确和成熟的架构。

这使我们能够在 STM32、TI MSP 和各种 Atmel /微芯片处理器上运行相同的代码。

我们的 MSP432E401 器件运行的代码与 HTTP 服务器、HTTP 客户端、TCP/IP 客户端和 MQTT 客户端几乎相同。

我们没有线程堆栈溢出或卡在过载的线程。

处理器也不会太忙、因为空闲线程（我们的负载测试线程）会有足够的时间运行。

Wifi 层有自己的 statemachine 通过 SlWifiConn_功能来管理它。

话虽如此、LOL、也许您的专有代码解决了这个问题。

不稳定问题可能是由 TI 中间层驱动程序引起的，而不是我的代码；）

也许这与 TI 代码有关、也许您不想听到这个信息。

也许我的设计毕竟不是很差。
也许我只是有一个小错误:)
或者、如果您将您的专有代码调整为位、直到它变得稳定。

您好、

我与 TI 没有关系、因此我不需要“效力于 TI 团队“或不对稳定性问题说“属实“。 根据我的评论、我也不想对您造成伤害、我只想谈谈 CC3220 器件的使用体验（在 e2e 论坛上、我有 3k+帖子、主要与 CC32xx/CC31xx 平台相关）。

1 月

我所需要的就是其他人的体验！

非常感谢您的答复。

我相信硬件是稳定的。

我的问题是如何使固件保持稳定、您实际上确认了我的怀疑。

那就是两个 MCU 之间的 TI 通信层可能是问题的根源。
它可能很简单、因为我的优先级太低、我们使用示例代码作为指导。
在这一点上、我们已经花了很多时间在这个项目上、我们需要继续前进。
TI 软件根本无法按预期运行。

我忙于记录当前版本的应用、但需要一段时间才能弹出问题。

与此同时,我在这里创建了一个存储库,而不是在论坛上发布代码: https://github.com/RadicalES/tisdk-cc32xx-issues

我们很少在没有 AI 代理的情况下发展,这些天,我们用它来分析我们的工作不断。
我用 Claude 代码分析了 TI 驱动程序、我认为问题可能出在哪里。
一些报告是在几个月前完成的、但这是  我今天运行的 github.com/.../spi-wifi-thread-safety-analysis.md。

人工智能代理并不总是完美的,但它们通常会让您朝着正确的方向前进。

我按照建议进行了所有更改、并将在接下来的 24 小时内进行测试。

希望我们能够了解到这一条。

当我们进行设计时、我们无法获得模块、于是选择了芯片版本。
我们是一家敏捷的开发公司,最终并不真正关心产品,我们只需要设计一款产品来快速解决问题！

在这种情况下、我们需要匆忙通过 MQTT 将 Reefer 温度监测连接到 WIFI 网络。

最初、我们认为可能是 XTAL 和相关电路、但我认为我们在 C3220SF Launchpad 上也存在同样的问题
并且我们没有任何连接问题、这种方法非常有效。
只有 APP 处理器和 NWP 之间的 SPI 驱动程序通信会出现故障。

XTAL 可能会发挥作用？

嗨、Shlomi

测试非常顺利,超过 24 小时没有问题。

然而、之前发生了同步丢失、但首次从错误中恢复。

HTTP 启动错误是一些正常的,我总是收到错误,但网络服务器工作

现在、我对结果非常满意。

我的 WiFi statemachine 处理的很好,因为它应该从开始,并得到无线连接回线上没有重新启动.

现在、我将构建生产版本并重新进行测试、我们的服务器会在设备无响应时跟踪。

部分日志如下所示、出于兴趣原因、这种情况发生了 26 小时以上：

[HTTPC：：info]事务：地址= 16779786、端口= 80、URI =/api/v1/scada
[WIFI：：错误]致命错误：检测到同步丢失

[WIFI: INFO] COS : 12 -> 19
[wifi：：debug]有事件 29
[WIFI: WARN]致命错误计数: 1/10
[wifi：：debug]事件致命错误
[WIFI: INFO] COS : 19 -> 10.
[wifi：：debug] notify down
[WIFi：：info] COS：10 -> 4.
[wifi：：debug]停止
[wifi：：debug]已停止
[wifi：：info] COS：4 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[wifi：：debug]等待 4 次启动
[wifi：：debug]等待 4 次启动
[WIFI: INFO] COS : 3 -> 13
[WIFI：：info] COS：13 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[wifi：：debug]等待 4 次启动
[WIFI：：调试]【事件】STA 已连接到 AP - BSSID：76：4D：28：F9：A5：43、SSID：IOT-TEST
[WIFI::info][NetApp 事件]获取的 IP：IP=10.10.0.180、Gateway=0.0.0.0
[wifi：：debug]有事件 2
[wifi：：debug]有事件 3
[wifi：：debug]等待 4 次启动
[WIFI: INFO] COS : 3 -> 13
[WIFI：：info] COS：13 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[wifi：：info][SlWifiConnEventHandler]已断电
[wifi：：debug]收到事件 0
[wifi：：info][SlWifiConnEventHandler] powered_up
[wifi：：info] MAC 地址：68：E7：4a：3b：9f：67
[wifi：：debug]有事件 1
[WIFi：：info] COS：3 -> 2
[wifi：：debug]检查配置文件
[WIFi：：info] COS：2 -> 7
[wifi：：debug]启动网络
[WIFi：：info] COS：7 -> 5
[WIFI:调试]->等待 IP
[WIFi：：info] COS：5 -> 6
[WIFI::debug]->启动 NET
[WIFi：：info] COS：6 -> 8
[wifi：：debug]启动 HTTP
[WIFI:: WARN] HTTP 服务器失败
[WIFi：：info] COS：8 -> 9
[wifi：：debug] notify up
[wifi：：info]在 1 个致命错误后恢复连接
[WIFI: INFO] COS : 9 -> 12
[HTTPC：：info]事务：地址= 16779786、端口= 80、URI =/api/v1/scada
[wifi：：error]致命错误：未检测到命令确认[cmd 操作码= 0x9408]

[WIFI: INFO] COS : 12 -> 19
[wifi：：debug]有事件 29
[WIFI: WARN]致命错误计数: 1/10
[wifi：：debug]事件致命错误
[WIFI: INFO] COS : 19 -> 10.
[wifi：：debug] notify down
[WIFi：：info] COS：10 -> 4.
[wifi：：debug]停止
[wifi：：debug]已停止
[wifi：：info] COS：4 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[MQTT：：WARN] DNS 失败：10.10.0.1：1883
[wifi：：debug]等待 4 次启动
[wifi：：debug]等待 4 次启动
[WIFI: INFO] COS : 3 -> 13
[WIFI：：info] COS：13 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[wifi：：debug]等待 4 次启动
[WIFI：：调试]【事件】STA 已连接到 AP - BSSID：76：4D：28：F9：A5：43、SSID：IOT-TEST
[WIFI::info][NetApp 事件]获取的 IP：IP=10.10.0.180、Gateway=0.0.0.0
[wifi：：debug]有事件 2
[wifi：：debug]有事件 3
[wifi：：debug]等待 4 次启动
[WIFI: INFO] COS : 3 -> 13
[WIFI：：info] COS：13 -> 0
[wifi：：debug] init
[wifi：：info] COS：0 -> 1
[wifi：：debug]开始
[WIFi：：info] COS：1 -> 3
[wifi：：info][SlWifiConnEventHandler]已断电
[wifi：：debug]收到事件 0
[wifi：：info][SlWifiConnEventHandler] powered_up
[wifi：：info] MAC 地址：68：E7：4a：3b：9f：67
[wifi：：debug]有事件 1
[WIFi：：info] COS：3 -> 2
[wifi：：debug]检查配置文件
[WIFi：：info] COS：2 -> 7
[wifi：：debug]启动网络
[WIFi：：info] COS：7 -> 5
[WIFI:调试]->等待 IP
[WIFi：：info] COS：5 -> 6
[WIFI::debug]->启动 NET
[WIFi：：info] COS：6 -> 8
[wifi：：debug]启动 HTTP
[WIFI:: WARN] HTTP 服务器失败
[WIFi：：info] COS：8 -> 9
[wifi：：debug] notify up
[wifi：：info]在 1 个致命错误后恢复连接
[WIFI: INFO] COS : 9 -> 12
[HTTPC：：info]事务：地址= 16779786、端口= 80、URI =/api/v1/scada
[HTTPC：：info]事务：地址= 16779786、端口= 80、URI =/api/v1/scada

首先,似乎论坛在某些技术问题上不是很活跃,除了显而易见的是让东西工作。

如果我是 TI、我会尽快为解决可靠性问题提供支持。

这是关于...

因此、我只想添加一些注释以帮助其他人。

我们添加了一个 MQTT 主题来处理 Wifi 统计信息。

这是使用 Mikrotik AP 进行测试、静态位置、良好的接收<–50dBm

当前测试单元运行约 14 小时、未出现问题。

我们添加了正常运行时间、 NWP 致命错误、MWP 恢复和 NWP 断开的统计数据。

最大正常运行时间约为 14 小时以上、没有任何问题。

接近 24 小时,现在我们有 1 致命错误和一次恢复,没有断开连接。

所有这些都解决了问题、我们将继续测试。

产品现在首次可用。

我会将更新添加到存储库中。

回顾过去、我们花了大量时间与 WiFi 通信问题相关。

我们在 slwificon.c 中修复了相同类型的设计错误、我也会将其上传到存储库。

关于我们拥有的 CC13xx 系列的所有主要技术问题、更重要的是、我们必须自行解决。

该论坛没有带来太大的价值、也没有 TI 直接提供技术支持。

我们真的被留给自己。

您好、Jan、

这里是否有什么不同（例如添加更多修复）,使最新版本比以前更稳定,并自动恢复?

同样、不确定此处的支持在哪里失败、但通常当我们收到 E2E 帖子时、支持团队会指派合适的专家来解决问题、在某些情况下（尤其是在客户背后有 TI 销售代表的情况下）、它会在内部上报、并建立直接渠道来提供直接支持。 我明白了很多。

查看积压情况、我看到您的大多数帖子都位于 1G 和 MSP 上、这些帖子不在我的团队支持范围内、因此无法发表太多评论。

要返回到 Wi-Fi、我将查看建议的修复方案。 我们即将刷新 SDK、因此我将确保集成了修复程序。

此致、

Shlomi

嗨、Shlomi

这些是我对固件所做的唯一更改。

我可以添加我的 wifi stateemachine 到存储库,如果你也喜欢?

我们拥有一个网络驱动程序框架结构、可在任何环境下一致地管理网络。  

因此、我们能够在任何平台、TI、ST 等上拥有一致的软件

目前我的测试做得非常好。

我必须说,看看它确实有意义的变化。

SDK 示例可以正常工作、但一旦 OS/MCU 变得更加繁忙（即线程增多）、您就会开始看到错误。

个人而言、我不喜欢在 Qs 中使用挥发物、就像对 SPI 驱动程序所做的更改一样、您要么使用事件、要么使用 RTOS/邮箱

挥发物总是会在某个地方引起一个无法解释的错误。

 当我启用 WiFi 统计数据时,我仍然得到通信故障的完全丢失而没有恢复。

但是、我们现在只在短时间内启用它、并暂停所有服务、包括 HTTP 和 MQTTP。

请告诉我、我还必须添加网络驱动程序层。   

您好 Jan、

您所述的核心文件 (driver.c、spawn.c 和 slwificonn.c/h) 应该足够了、因为这是 TI 的核心驱动程序文件。

你可以添加虽然  wifi statemachine 到存储库的完整性或其他人使用.

我将审查建议的修改/修复、但我将在 2 周内离开、以便在我回来时进行。

谢谢、

Shlomi

嗨、Shlomi

我已将网络层添加到存储库中以了解更多详细信息。

我的测试设备已运行了一周、没有卡住或挂机。
明天我将去现场看看其他 20 多台设备是如何做的,那里的 WiFi 连接更具挑战性。

但到目前为止确实取得了很好的结果。

谢谢

1 月

我们的问题库有更多更新。
不要使用共享寄存器来实现重新引导持久性。

也有很多前言的挣扎。
它在执行新的固件程序之后工作。
通过 Web 删除 AP 配置文件也可以正常工作。
但通过代码实现这是一场巨大的斗争
一旦删除 AP 配置文件、基本上会在启用 MWP 通信配置后立即将设备砖化。
我们在 slwificonn.c 中实施了一个变通办法
固件现在已达到 24 小时内只有 1-2 个致命错误的程度。  

供参考：  

https://github.com/RadicalES/tisdk-cc32xx-issues/blob/main/ocp-shared-registers.md

https://github.com/RadicalES/tisdk-cc32xx-issues/blob/main/provisioning-issues.md