低功耗模块，连续运行20天，耗电大，排查发现在周期复位

huazhen zheng

Intellectual 515 points

Other Parts Discussed in Thread: Z-STACK, CC2530

Z-Stack Core Version 2.6.3

我们的门锁，嵌入一个CC2530模块，联网后2秒polling一次。

在脱网后，程序设定1分钟会主动去联一次网，联不上就等下一分钟。通过观察电流和抓包，程序应该是符合的。

为了测试脱网下的功耗情况，将整个网络的其它设备都下电，每天操作几次密码开门和指纹开门。

如此连续运行20天，5个测试的门锁，2个在同一天报警低电量（门锁语音）。

万用表查看电流，发现CC2530模块持续8mA。

示波器观察电压，发现1秒左右，会有一个小变动，测试IO发现1秒左右会有一个跳变。

模块只有2个IO和一个串口在用，这4个IO在同一时间会跳变。

推断模块在周期的看门狗复位。示波器观察的周期不是固定的，但是大概就是1-1.5秒变化。

----------------------------------------------------------------------------------------------------------------------------

1 反复的看应用代码逻辑，不能查找到可能性。

2 加速复现，脱网后，即每日操作门锁的次数增加。未能复现。

-------------------------------------------------------------------------------------------------------------------------

各位大神，这样的问题，该如何排查

7 年多前

0 huazhen zheng 7 年多前

Intellectual 515 points

一个怀疑的方向是，flash的代码区，被破坏。

实验，人为的在入网后，将设halSleepSetTimer的头16字改写为全零，程序就会周期的复位，但是复位的时间是5秒左右。

由此推断，如果破坏的区域准确的话，那么应该会出现类似的现象。
------------------------------------------------------------------------------------------------------------------
基于此，查看所有对nv操作，在测试阶段，无写nv的操作，理论不应该是用户写flash行为破坏的。

0 Alvin Chen 7 年多前

TI__Guru 56646 points

”如此连续运行20天，5个测试的门锁，2个在同一天报警低电量（门锁语音）。“

也就说你测试在rejoin 过程中的耗电情况对吧。

你2S一次ZDApp_StartJoiningCycle和ZDApp_StopJoiningCycle转换的对吧？
你用osal_start_timerEx( );启动一个定时器做上面的逻辑看看。

0 huazhen zheng 7 年多前回复 huazhen zheng

Intellectual 515 points

之所以怀疑flash被破坏，是因为故障的模块，重新烧写了固件后，就恢复了。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

部分不正常吗？

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

2s一次是，正常联网情况下，保持和父节点的通信。

掉网后，是通过定时器，1分钟发起重连。在重连失败后，不再重连，开启一个1分钟定时器。

这个逻辑应该是没有错的。

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

是的。总共测试10个门锁。5个门锁一直保持在线状态。5个门锁为了测试故意将父节点和网络下电。

这种情况下下，连续20天，2个脱网的设备，同一天报电量低。

查看后发现是没有进入低功耗。

和复位的现象是一样的。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

也就说你故障的模块没有按照这个逻辑进行工作对吧？你的看门狗定时是多少，当你halSleepSetTimer后有去喂狗把：

WDCTL = 0xa0;
WDCTL = 0x50;

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

提到这个函数halSleepSetTimer，是为了验证，我的猜想“”flash代码区破坏“”，做的实验，把这个函数二进制编码头16字节写全零。

------------------------------------------------------------------------------------------------
正常的模块，运行到现在应该有30天了，并没有出现功耗过大的情况。

所以喂狗逻辑应该是没有问题的。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

是否都是同一个模块出现问题？

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

5个测试的模块，出现了2个。

重烧固件后，恢复。

没能复现，也找不到复现的办法。
--------------------------------------------------------------
之前其它的低功耗设备和路由设备，都没有出现过这样的现象。

0 huazhen zheng 7 年多前回复 huazhen zheng

Intellectual 515 points

因为公司没有静电测试仪器，我们就拿打火机的点火，直接打在门锁的触摸键盘和指纹上，都没有发现有异常的。打了几十次。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

是否是这两个如你所述的flash 问题，换掉这两个换两个新的也会复现吗

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

1 是不是flash问题，是我的推断。依据1：重烧固件恢复；依据2：实验破坏flash几个字节数据导致类似的现象。

2 出问题的2个模块，1个保留，1个重烧固件恢复，没有复现。其它模块也没有复现到。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

按照你的说法应该是硬件问题，出现数量不多还好。

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

那两个异常的模块，为了保留问题我们只重烧了1个，发现变正常了。那就说明模块应该是好的。因为出厂测试的模块烧录的都是lock，所以无法反读验证。

您说的，硬件问题，指的是？

因为测试阶段出的问题，我们还是比较谨慎，希望能在大规模使用前，找到问题的原因和规避的措施。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

”那两个异常的模块，为了保留问题我们只重烧了1个，发现变正常了。“这个模块后续没有复现这个问题是吧。

这样的话我也很难判断出是什么原因，不好意思。

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

问题的2个模块，1个保留，保留這个如果重新斷電上電，耗電會恢復正常嘛？

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

不会。2个模块，都重新上下电过。万用表电流都是8ma。示波器观察，4个IO周期的跳变，感觉就是看门狗复位。

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

2个异常的模块，1个保留，是为了后续发现新的想法，可以比对试验。

另外一个出问题后，进行一翻分析后，才重烧了固件，测试发现正常的，即没有再次出现问题。

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

除了耗電問題外，其他功能都能正常運作嘛？

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

不能正常工作。串口不能正常通信。

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

估计是跑飞，你的看门狗也不工作了对吧，如果看门狗都不工作那就估计是flash里面的code没了

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

根据观察到的现象，应该是看门狗一直在复位。

不知道怎么排查，是怎么出现flash的code被改写的？

如何防范。

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

有可能是因為低電壓時操作flash導致flash損毀

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

1 之前软件也是这样猜想的，硬件人员测试回复，模块前有一个ldo，而门锁的电池还能提供大于ldo输入电压，根据实际使用中电压测量，虽然报了低电量，但是实际不会出现使得ldo的输出电压低于3.2V的情况

2 假设是低压时操作flash，这有什么防范的办法吗？

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

1. 如果真的是电池低电量，應該無法保證实际不会出现使得ldo的输出电压低于3.2V的情况吧？
2. 試試應用程序在偵測到电池低电量用個while loop把程序整個擋住

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

YiKai Chen 说：
1. 如果真的是电池低电量，應該無法保證实际不会出现使得ldo的输出电压低于3.2V的情况吧？
2. 試試應用程序在偵測到电池低电量用個while loop把程序整個擋住

1 门锁使用4颗AA 5号电池串联，电压可达1.5V*4=6V，报低压时电压还有4.5V，按照经验，门锁还能正常工作几十次开锁，但是会播报低电量。硬件人员，拿一块正常的模块，在门锁上使用，示波器观测过电平变化，电源没有变化，但输出的IO有小波动。

2 CC2530的手册：

电池电量侦测，是应用周期侦测，可能不及时。

上电的时候，会采样VDD/3，可以在写flash、擦除flash前检测一下当前电压是不是满足。协议栈代码是2.0V标准，我把它提高到2.7V。

另外芯片有一个写保护功能，是不是可以把代码区写保护了。但如果要支持OTA，是不是就不行？写保护会禁止代码区擦除吗？

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

芯片有写保护是針對debugger，對從程序內的flash write是無法写保护的

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

YiKai Chen 说：
芯片有写保护是針對debugger，對從程序內的flash write是無法写保护的

Block debug commands，应该是禁止cc debugger读。

Write protect，是禁止cc debugger写吗？不是禁止所有对flash的写动作？一直没用到，我实验下。

0 huazhen zheng 7 年多前回复 huazhen zheng

Intellectual 515 points

复测发现了，问题是ZCD_NV_STARTUP_OPTION的标志位变为0x02引起的。

我的程序逻辑：上电就发起入网请求，入网后我的主机会下发一个私有配置数据。
下次上电，我会先读配置数据，如果存在，我就去执行networkStateNV = ZDApp_ReadNetworkRestoreState();不存在就重新入网。

问题是不知道什么原因，读出来的ZCD_NV_STARTUP_OPTION值不是0x00,而是0x02，这样会把nv里的网络数据清空，但此时我的配置数据还在，到后面的代码执行引起逻辑问题，导致一直复位，就一直8ma的耗电。

也就是现在的问题是，入网后ZCD_NV_STARTUP_OPTION是变为0x00，但是为什么会变成0x02 ZCD_STARTOPT_DEFAULT_NETWORK_STATE

我查了代码，只有在 if ( events & ZDO_DEVICE_RESET )下，

// Set the NV startup option to force a "new" join.
zgWriteStartupOptions( ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE );

下面两个函数会调用到上面的事件
ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );
ZDApp_ResetTimerStart( LEAVE_RESET_DELAY );

但是我只是下了父节点，让它不停的重连，为什么会发生以上两种之一的逻辑呢？

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

下了父节点，让它不停的重连?是什麼意思？

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

一个终端，一个协调器，入网后，把协调器下电，让终端1分钟重连1次。
为了测试这样重连，耗电的情况。

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

你抓包看一下問題發生的當下空中的封包是怎麼回事？

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

这次复现，一直重连，经过了6天出现的。所以正常的一次多数次重连，应该不会导致这个问题。

但是复现的方法还不确定。而且这次放了7个设备，出现了2个。

第一次试验的10个设备，保留了2个一直没动它，到目前还是好的。

所有的测试设备都是放在一起的，基本上来说，环境应该是一样的。

0 YiKai Chen 7 年多前回复 huazhen zheng

Guru 109510 points

你有沒有抓包檔可以看發生問題的那兩2个在問題發生前後的狀況？

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

这个就比较不好分析，尽量抓个包看看吧

0 huazhen zheng 7 年多前回复 YiKai Chen

Intellectual 515 points

嗯。主要是出问题都是随机的，目前测试的几次，最少要6天，最多20天。我现在复现，隔一段时间去确认一次，没问题，就把抓包缓冲去掉。

另外有遇见过，zigbee设备自己跳频的吗？

就是入网后，如果没有发指令去改协调器的信道，应该是固定的吧。

如果此时把协调器下电，设备会不会，去搜索其它信道上的父节点，如果搜不到，会不会加入当时允许加入的其它panid下的网络？

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

”zigbee设备自己跳频的吗？“ 信道是规定的. 不会加入其他的panid 网络，你可以看一下：
e2echina.ti.com/.../104629

0 huazhen zheng 7 年多前回复 Alvin Chen

Intellectual 515 points

文章中：

如果在ZDApp_RestoreNwkKey( uint8 incrFrmCnt )，读取network key错误，或者之前保存的network key已经不在的情况下，那么就发了Unsecure Rejoin的方式。
这个时候如果收到了父设备回复的Rejoin Response的话，节点不会立即就变成End Device状态。而是进入了DEV_END_DEVICE_UNAUTH，因为还没有拿到正确的network key。

那是什么原因会导致“ 读取network key错误，或者之前保存的network key已经不在”呢？

因为如果发生这个情况，进入了 DEV_END_DEVICE_UNAUTH，而最后又没有得到network key的话，ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );=》if ( events & ZDO_DEVICE_RESET )=》// Set the NV startup option to force a "new" join.
zgWriteStartupOptions( ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE );

这就发生了，我遇到的情况。start option 被改为 ZCD_STARTOPT_DEFAULT_NETWORK_STATE

0 Alvin Chen 7 年多前回复 huazhen zheng

TI__Guru 56646 points

你开启了NV对吗？我从你的描述中认为你以及开启了NV_RESTORE,这样是不会出现"读取network key错误，或者之前保存的network key已经不在的情况下，那么就发了Unsecure Rejoin的方式。"
通常是抹除了系统的NV才会出现的。
你是不是每次都是那几个设备怀疑你NV丢失了才会被强制变成一个新设备入网。