请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：CC3235SF 主题中讨论的其他器件：CC3235MODASF、 CC3235MODAS、 CC3220MOD、CC3200
我们有上万种设备配备了 cc3235 (CC3235modas 和 cc3235modasf)。 它们大部分情况下都可以正常工作、但存在一个低发生率的错误、这使得器件停止通信、并在大约 三天内消耗电池电量。
它每年影响大约7%的器件。 它足够高、足以让人感到痛苦、但太低、无法轻松复制和调试。 因此、我将分享我们的思考和调试过程。 希望我们可以获得一些帮助/有用的指针。
我们的电池供电设备通常会使用慢时钟从休眠中唤醒、连接到接入点、连接到 http 服务器、执行一些请求、然后在几秒至24小时的时间内返回休眠状态。 当错误发生时、我们看到器件未在预期时间内连接、但电池耗电非常快。 当我们的电池拉杆观察程序电路重置 cc3235时、它随后可以正常运行(持续几周、直至电池电量完全耗尽)。
由于 看门狗捕获了其他错误、因此很可能是与启动/关闭相关的错误。 每次看门狗复位后、我们都会有一个 指数退避 休眠持续时间 、该时间可防止耗尽电池电量。
在进入休眠模式退出时、在 sl_start 和 任务创建之前、看门狗会立即启动。
我们的电池为3000mA、这使得在错误状态下消耗的40mA 大于或小于4gb。
此时、我们怀疑发生了其中一件事：
- 器件以 uartload 模式启动
- sl_start 失败、看门狗在50秒后复位、依此类推。
- 在初始化看门狗之前、处理器启动但无法正确初始化。
- 当看门狗已停止(或看门狗损坏)时、器件无法进入休眠状态
- 指数退避处理前的看门狗三角
遗憾的是、我们不可能得到显示错误的 NWP 日志、因为我们必须测量大量器件才能可靠地捕获错误。
我们可以通过 OTA 更新固件、从而使其更加稳健、或添加一些调试信息、以尝试找出问题的根本原因。
谢谢！
塞德里克
