[参考译文] CC2640：器件在随机时间停止工作。

您好、Iain、

感谢您的联系。

这里的图片中包含多个元素。 请通过以下问题帮助我更好地了解案例：

1. 两个器件之间的通信方式是怎样的？ 例如、您是否使用网络处理器接口(假设 simple_np 为是)？
2. 有多少产品出现故障(%)以及进行此重置的频率(%可重现)？ 这适用于 CC2640器件、对吧？ 或者仅适用于 CC2650和  CC2640的子模块是否无法正常工作？
3. 是否所有样片共用完全相同的硬件？
4. 您能否提供一些调试日志、其中显示"与 CC2640的通信卡住- UART 和看门狗无法返回到 MSP、从而导致复位"。
5. 在第二个用例中、应用程序是否在发现后发起连接？ 扫描参数是什么？
6. 考虑到没有不必要复位并且您在发现之前未将器件保持在复位状态的情况、您能否提供一些调试日志、其中显示"随机数次、来自任何发现的器件的数据将停止发送到 MSP。、 似乎我们没有检测到 BLE。" 您是否验证过设备在这些时刻实际进行扫描？
   

您可以查看用户指南中的"调试输出"部分。

还请指定您正在使用的 SDK 版本。

此致、

大卫。

感谢您的答复。

请参阅下面的问题答案：

1. 两个器件之间的通信方式是怎样的？ 例如、您是否使用网络处理器接口(假设 simple_np 为是)？

答案 -是的,使用 NPI 通过 UART 与 MRDY 和 SRDY 提供控制。

1. 有多少产品出现故障(%)以及进行此重置的频率(%可重现)？ 这适用于 CC2640器件、对吧？ 或者仅适用于 CC2650和 CC2640的子模块是否无法正常工作？

答案 -它似乎是大约20%表现出的问题,其他人工作预期。 产品中的每个重置事件都是在从最后一个事件开始的随机时间、从0到几个小时之间。 它仅是 CC2640器件、而最新生产版本仅具有 CC2640器件。 我们之前在 CC2650中未看到该问题。   

1. 是否所有样片共用完全相同的硬件？

答案 -是的,所有的样本都是相同的硬件构建和相同的固件,并配置为相同的操作。

1. 您能否提供一些调试日志、其中显示"与 CC2640的通信卡住- UART 和看门狗无法返回到 MSP、从而导致复位"。

答案 -我们没有任何调试日志,但这里是一些逻辑分析仪轨迹的屏幕截图,显示它停止和重置的点,并放大了一个。 我们看到 MRDY 和 SRDY 线保持高电平。 第二个屏幕截图 "CC2640 Last comms before device reset.jpg"显示响应的功率初始化,然后我们发送广播,扫描响应数据,然后发送扫描数据和开始扫描命令, 我们得到正确的响应和1个长度不正确的数据块、这似乎是导致问题的原因。

1. 在第二个用例中、应用程序是否在发现后发起连接？ 什么是扫描参数

答案 -不,我们不连接我们只是寻找设备和过滤特定的数据在他们的广告信息。  扫描持续时间为829ms、间隔为97ms、窗口为65ms、4s 检测周期会自动重新启动。

1. 考虑到没有不必要复位并且您在发现之前未将器件保持在复位状态的情况、您能否提供一些调试日志、其中显示"随机数次、来自任何发现的器件的数据将停止发送到 MSP。、 似乎我们没有检测到 BLE。" 您是否验证过设备在这些时刻实际进行扫描？

答案 不,我们也没有任何日志,我们正在尝试获得一些信号等捕获在逻辑分析仪上。 在这种情况下、我们知道 MSP432仍会尝试停止和开始扫描、正如正常情况一样、但从不会接收到任何返回的数据、因为 MSP432上没有可用的数据。 恢复该错误的唯一方法是对 CC2640进行复位、同样、事件的随机时间是每次运行时、它在重新发生之前将是不同的时间。

还请指定您正在使用的 SDK 版本。

答案 -我们将 CC2640固件基于 BLE SDK 中 CC2650BP 的 simple_np。 TI BLE SDK 2.02.04.06和 TI-RTOS CC13xx/CC26xx V2.21.01.08。

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/538/CC2640-comms-with-device-reset.jpg

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/538/CC2640-last-comms-before-device-reset.jpg

您好、Iain、

感谢您提供的信息、很遗憾我看不到逻辑分析仪图像、它们非常小。 我建议直接将此轨迹的屏幕截图复制到帖子中。

Unknown 说：

1数据块的长度不正确且似乎导致了问题。

您知道它的来源是什么吗？

Br、

大卫。

在将图像粘贴到该文件中时遇到了一些问题。 数据块来自被检测器件、该器件为什么说长度为40字节、但我不知道只有38个。 这是故障发生的时间点。

这是一个缩小捕获、显示最后一次正常数据、故障、复位和重新启动。

您好、Iain、

感谢您提供的信息。

您能否具体说明(仅通过文字说明)、哪条逻辑线指的是确切内容？

此外、我认为深入探究复位的原因可能会有所帮助。 AON_SYSCTL：RESETCTL。 RESET_SRC 寄存器应该会让我们对此有更深入的了解。 您能否阅读并分享结果？ 您可以在 技术参考手册的第6.7章中阅读有关这方面的更多内容

Br

大卫。

通过查看屏幕截图并按顺序阅读信号、以了解所有与 CC2640相关的信息

UART 发送寄存器

UART RX

引导加载程序输入

复位输入

MRDY 输入

SRDY 输出

我将尝试查看是否可以获取  AON_SYSCTL：RESETCTL。 RESET_SRC 寄存器值。

您好、Iain、

我懂了。

复位输入信号背后的确切逻辑是什么？

如果您需要 AON_SYSCTL：RESETCTL.RESET_SRC 方面的帮助、请告诉我。

Br、

大卫。

其背后的逻辑是将其用作器件的一种关断。 我们会运行 BLE 以查找周围的特定信标、然后按照指定的间隔进行报告、 我们进行了大量处理、并持续观察 BLE 4秒、在剩余的间隔时间内关闭 BLE、然后将其用作减少用于延长电池寿命的功率的方法。

我没有可以连接到样本单元的调试器、因此可以帮助读取 AON_SYSCTL：RESETCTL。 请使用 RESET_SRC。

 您好、Iain、

AON_SYSCTL：RESETCTL。 存储器0x40090000中的 RESET_SRC 寄存器显示了我们可以在器件再次启动后访问的上次系统复位源。 您是否有显示信息的方法？ 您使用什么接口？  

Br、

大卫。

你好，David

主控制器 MSP432有一个我们使用的调试 UART。  MSP432与 CC2640之间的唯一连接是 UART、它用于在两者之间发送 NPI 命令和数据 、或在置于引导加载程序模式时更新新固件。  

您好、Iain、

您是否可以使用 MSP432调试 UART 来显示 RESET_SRC 寄存器信息？

在设计过程中、您是否考虑过我们的 CC13xx/CC26xx 硬件配置和 PCB 设计注意事项(修订版 G)？

Br、

大卫。

您好

响应延迟、抱歉、我一直在研究和研究目前更好的方法来调试 CC2640。

我认为还有一些困惑、因为 CC2640仅在 MSP 的控制下复位、因此可以知道它为什么进行了复位。  

我们已创建了一些固件来停止将 cc2640器件置于复位状态。在4s 周期之后、我们想要收集扫描数据、只是停止并开始扫描、我们发现在几个小时后、CC2640会在 当我们设置 MRDY 线并等待设置 SRDY 以允许发送命令数据时、SRDY 线保持低电平。

我们将创建一些固件来处理此问题、如果该线路保持低电平、则重置 CC2640。

这可能与 MSP 尝试读取数据时遇到卡滞以及其看门狗超时导致最初报告复位的原因相同。  

您好、Iain、

该固件修改将仅适用于无法正常工作(持续复位)的器件？ 考虑到只有20%的器件存在此问题、我倾向于认为这可能与硬件差异有关。

我如何进一步帮助您了解您所描述的内容？

此致、

大卫。

您好

我们更倾向于对无法正常工作的器件更新固件、同时对我们生产的所有未来器件将其作为新版本提供。

我们已在大量器件上进行了进一步测试、我们检查了500个器件、其中5%出现了问题。

提到硬件差异时、您是指可能是由于我们 PCB 上安装的组件容差不正确或 CC2640器件中存在差异而导致的硬件差异。

您好、Iain、

我的意思是在定制 PCB 级别上存在差异。 如果您认为这值得再次检查、那么我可以将此申请转发给硬件专家。

Br、

大卫。

你好，David

感谢您提供此优惠、但在这项调查中、我们的硬件设计人员已审查了我们的电路设计并与参考设计进行了比较、我们还将把一些发生故障的产品送回我们的 PCB 供应商、对其进行调查并检查、以找出任何制造问题。

我还有最后一个问题、您或许可以回答。 我们几乎使用的代码与 TI BLE SDK 2.02.04.06和 TI-RTOS CC13xx/CC26xx V2.21.01.08中的代码相同、在向 MSP432发送数据之前、我们只为配置值添加极少的额外内容并对检测到的特定 BLE 器件进行过滤、 该固件和 RTOS 的运行中是否存在导致我们所看到问题的情况？