[参考译文] CC3120：严重错误处理程序中的 sl_Stop 返回-2005

您好、Kobi、

是否确定通过处理程序报告的所有致命错误都需要完全重启主机 MCU？ 我知道、sl_device_event_fature_device_abort、sl_device_event_fature_no_cmd_ACK、sl_device_event_fature_sync_loss 和 sl_device_event_fature_cmd_timeout 可以通过 NWP 重新启动(sl_Stop ()/sl_Start ())恢复。 如果发生错误、则必须重新启动主机 MCU SL_DEVICE_EVENT_FSAFY_DRIVER_ABORT。 swru455提供了类似的信息。

我100%确定、并且已经测试了通过 NWP 重启可以恢复 sl_DEVICE_EVENT_FATAL_DEVICE_ABORT。 我已经使用 CC3220SF 以及最新的 SDK 和 ServicePack 进行了测试。

1月

是的、Jan、你是对的！

我最近没有遇到致命错误...

我再次阅读此内容、问题似乎与 sl_in_device_started 状态有关。  

假设驱动程序调用了致命回调(当 NWP 关闭时)-解决此问题的唯一方法似乎是通过 MCU 复位。

BR、

Kobi

您好、Kobi、

是的、我本来想添加器件的硬复位(数据表的 CFR 4.13.2器件复位)、但它没有帮助。
注意：我‌认为简单地调用 sl_Stop()和 sl_start()应该通过调用 sl_DeviceDisable()和 sl_DeviceEnable()来切换休眠引脚。

我的处理程序(不需要的无限循环)如下所示：

int ret；
do｛
ret = sl_Stop (200)；
CC3120_reset_low；
usleep (250000)；//至少200ms 复位低
电平 CC3120_reset_high；
ret = sl_Start (NULL、NULL、NULL)；
｝while (ret < 0)； 

当 slFatalErrorEvent->ID 为 SL_DEVICE_EVENT_FSAFY_SYNC_LOSS 或 SL_DEVICE_EVENT_FSAFY_DEVICE_DEVICE_ABORT 时，问题看起来是相同的，如 Jan 所述，NWP 重新启动应执行该作业。

当然、更好的方法是找出错误的根本原因。 但是、如果出现意外错误、我希望能够在不重新启动主机的情况下进行恢复。

此致、

皮埃尔

您好、Kobi、

很抱歉、回复太晚了、我以为上周发了一条回复、但没有显示在主题中。

我经常会遇到致命错误(主要是 SL_DEVICE_EVENT_FATAL_SYNC_LOSS、有时是 SL_DEVICE_EVENT_FATAL_NO_CMD_ACK)。 我的代码中似乎存在一些时序问题，因为当只更改 SPI 波特率或添加一些 printf()时，可能会使情况变得更好或更糟。 它可以在初始化期间或在运行时定期发送数据时挂起。 有时几秒钟后、有时几十分钟后。 很难重现。

在将 SPI 上的字节写入 CC3120MOD 后、通常不会出现 IRQ。 信标正暂挂20秒，然后转至 SimpleLinkFatalErrorEventHandler()。

如果您能帮我解决这个问题、那将会很好。

否则、如果我修补驱动程序以强制对 sl_iS_Restart_required 进行复位、是否足以复位驱动程序或更好地重新启动 MCU？

此致、
皮埃尔。

您好、Pierre、

我刚刚了解到，主机驱动程序中最近有一个修复程序，用于解决竞争条件，从而使您无法在 SimpleLinkFatalErrorEventHandler()内重置 NWP。 问题在于、该修复程序目前仅存在于最新的 CC3220 SDK 中、而不存在于 CC3120插件中。

您可以下载最新 的 simplelink_cc32xx_sdk_3_20_00_06并将 simplelink 驱动程序(在 source/ti/drivers/net/wifi 下)复制到您的插件(然后重新构建)。

但我认为、首先、您应该重点了解您经常遇到的错误的根本原因。

问题似乎与您的 SPI 移植有关、但您需要对此进行验证。

您使用的是什么主机？ 哪个插件版本？

您能否提供 SPI 线路的逻辑分析仪捕捉？

您能否提供原理图？

您是否在运行我们的示例时或仅在运行您的应用程序时遇到相同的错误？

BR、

Kobi

您好、Kobi、

感谢您的解决。
我想找出问题的根本原因、但我有点困惑。

我在 MSP432P4011上使用的是 TI SIMPLELINK 主机驱动程序版本3.0.1.46。
我重写 SPI_Read()和 SPI_Write()，并使用 DMA。

我对命令的 SPI 线路进行了一些捕获

sl_WlanPolicySet (sl_WLAN_policy_connection、sl_WLAN_connection_policy (0、1、0、0)、NULL、0)； 

这是 sl_Start (NULL、NULL、NULL)之后发送给模块的第一条命令。

切换输出以点亮 LED 或在该指令之前添加一些 nops 这一简单事实使 CC3120发送中断或不发送中断。

我可以看到主机正在向 CC3120MOD 发送3个4字节的数据包：
0x21 0x43 0x34 0x12
0x86 0x8C 0x04 0x00
0x10 0x00 0x02 0x00

当它工作时、经过一段时间后、主机获得中断并发送0x65 0x87 0x78 0x56、CC3120做出响应。 当它不起作用时、永远不会接收到中断、并且4个字节永远不会被发送。

SPI 工作时的波形(第一次捕捉：第1和第2个数据包-第2次捕捉：第2和第3个数据包)：

无中断时的 SPI 波形：

我可以看到的唯一区别是接收中断时、4字节数据包之间的延迟稍高一点。

CC3120MOD 在接收到的数据包之间是否存在一些时间限制？

这似乎不是因为我可以重现问题、即使我在 SPI_Write()函数顶部添加了延迟(数据包之间为+/- 20 µs)。

感谢你的帮助。

对此，

皮埃尔。

您好、Pierre、

SPI 线路看起来正常。

SPI 驱动器是否是您更改过的唯一组件？  

原始 SPI 代码是否正常工作？

您是否尝试更改 SPI 时钟速度？ 使用 MSP432P4时、我们在高于12MHz 时遇到了一些问题。

BR、

Kobi

您好、Kobi、

我有两个版本的代码。 第一个版本、仅修改 SPI (所有函数在 cc_pal.c 中以 SPI_开头)
在第二个版本中、我还尝试通过按照 swru455g.pdf 第19章中的说明重写信标和计时器来删除对北区的依赖。
两个版本都显示在"较高"时钟速度下运行不稳定。

这个问题似乎也与 SPI 时钟速度相关、也许是我的代码或者 CC3120模块中的一些时序问题？
我尝试了 SPI 的各种比特率(1、2、3、4、6、 8、12MHz)。 我在测试时使用的器件每十秒发送一次+/- 25KB 的数据包。 对于仅修改了 SPI 的版本、它在3MHz 及以下频率下工作。 对于另一个版本、我必须将频率降低至2MHz。 这两个器件都以良好的时钟速度连续工作5天以上(我可以在不同的电路板上观察到相同的行为)。
如果我设置更高的比特率、器件将进入致命错误处理程序(或者有时卡在具有无限超时的信标上)、或者(非常频繁)、它开始消耗16-17mA 的平均电流(当未发送数据时)、而不是3mA (当一切正常时)。 有时会出现两种问题：首先是过度消耗、然后是致命错误处理程序。 我不知道 µC 或 Wifi 模块是否会出现功耗过高的情况、但我怀疑 CC3120存在问题。 您是否知道 CC3120MOD 为什么会消耗更高的电流？

当我有时间时、我想尝试开发板上的原始代码。 现在、我将继续使用较低的 SPI 时钟开发我的软件、希望找到解决方案。

此致、

皮埃尔。

您好、Pierre、

您对此有任何更新吗？

BR、

Kobi  

您好、Kobe、

感谢后续行动。 我的方面没有更新。 系统在2MHz 下与 SPI 配合使用。 在2.4 MHz 及更高频率下也会出现问题。 (如果使用 nortos 库、则为3MHz、频率为4MHz 时出现问题)。
因此、现在我必须进一步了解代码的其他部分、这样我就没有时间在不久的将来对此进行调查。 我将坚持使用2MHz 的频率、交叉手指不会开始崩溃。 由于使用不同版本的代码在过去两周内不会发生崩溃、因此它看起来相当稳定。

如果收到您的消息、我认为您一方也没有更新？ 遗憾的是、必须将频率限制在如此低的规格范围内。 此外、我对系统并不是100%有信心、我也不知道问题来自哪里(自己的代码、TI Simplelink 库、CC3120模块上的嵌入式代码？)。

此致、
皮埃尔。

您好、Pierre、

我们这边没有其他更新。

驱动程序代码已经过测试、支持更高的速率、因此我假设它是移植或主机配置中的一种。

如果您有更多信息、请告知我们(在本主题或新主题中)。

我现在要关闭这个线程。

BR、

Kobi