Silicon Labs Zigbee 3.0标准温度传感器项目复盘（EFR32MG12P）

芯片：EFR32MG12P系列

Stack：EmberZNet 5.10.0

产品简介：符合ZigBee3.0标准和IControl标准的温度计，与其他设备绑定后定期上报温度，带有IAS Zone报警功能

主要开发内容：内部ADC采样（温度、电源电压），按键IO口中断配置和LED控制等

主要难度：芯片，Z3协议都是最新的，官方旧版stack对一些芯片没有适配带来的一系列问题

I.开发前期阶段遇到的问题（用DK板建Demo工程）：

前期使用DK板开发，所以写完一些逻辑后基本上就可以完成项目的Demo了，遇到的问题也是一些新工具使用的问题：

a. 折腾了很久，发现新的DK板子不支持抓包功能（不支持切换信道）,官方后面在论坛发文说EFR系列抓包暂时不可用，建议使用EM357

b. EFR32系列只能使用Simplicity Studio来配置工程，但是由于“Device”列表的右键菜单是动态加载的，经常会出现没有“Lounch Console”或者“Upload Application”的情况，很让人蛋疼，解决方法一般是先检查软件上设置的核心板和底板型号是否与你连接的DK板保持一致，如果不一致“右键-Device Configuration”--“Device hardware”标签下设置对应的模组型号/SOC型号/底板型号，有一些型号的SOC没有对应的模组，那么只需要选Soc和底板型号就可以了，确认信息无误后还连接不上可以拔掉DK板的usb线后重新插上，或者重启Simplicity Studio软件。

c. 烧录程序需要先右键-disconnect，然后烧写，这个与之前Ember Desktop软件使用逻辑是相反的

d. Z3的设备可以加入到HA 的网络中，但是HA的设备加入到Z3的网络中会被踢掉，因为HA的设备无法更新TC-LINK key

e. Z3的Router支持组建分布式加密网络，但不是强制的，可根据实际需求选择是否支持

f. Z3的ZigBee 3.0的Router和Coordiantor必须支持Green Power（endpoint 242），EndDevice类型的设备需要根据硬件设计来选择是否支持Green Power(通过将其他机械能/光能转化为电能给设备供电的，Green Power协议的通讯数据量也非常小)。

II.开发中期遇到的问题（根据电路图设计建立工程）

在原来DK建立的Demo功能基础上，根据电路图，修改实际项目中使用的SOC型号，IO口配置，遇到的问题大部分与Stack、simplicity studio和硬件设计有关

a. simplicity studio没有生成EFR32MG12P相关的board.h文件，造成生成的IAR工程报错，stack5.10.0解决这个问题

b. stack5.9.2里面的各个plugin关联还是以前HA的逻辑，在选用的时候造成不必要的麻烦，stack5.10.0中解决了这个问题

c. stack 5.10.0在选用虚拟串口为port0时会出现程序运行异常的问题

d. 遇到一些奇怪的bug会导致程序跑飞，调试方法：先找到程序跑飞的地方（仿真断点调试或者通过屏蔽部分代码来找）->然后使用相同硬件去跑官方Demo程序，如果还是一样的地方出现程序跑飞，那么很可能是Stack本身的问题，需要尝试卸载Stack，重新安装原版Stack，并在原版Stack上建立工程去调试，我有一些奇奇怪怪的问题都是这么弄的

f. 按键IO口中断问题，stack是通过PIN脚注册中断服务程序的，所以硬件设计上按键IO口应该避开重复Pin脚，如PF2和PA2，这样会导致无法产生中断，同时避开系统自用的一些debug口：PIN0、1，这种问题一旦前期没有发现，到中后期改硬件会非常麻烦，所以在项目开始硬件设计时，软件工程师应该给出合适的建议，告诉硬件工程师按键、LED的合适的IO口设置，而我们最简单和保险的办法就是参考官方DK板的按键、IO口布局。

g. stack5.10.0中电源电压测量的plugin在DK板上正常使用，但到了自己的（同系列，不同型号）板子上却出现问题，这个问题是由于stack对于不同型号的soc，一些API参数不同，却没有明确的告知用户造成的，这种问题非常棘手，通常只能求助官方技术支持，但我们在soc选型的时候对此类问题进行规避，我们的soc尽量和选用官方DK板上同一型号的soc，因为这种soc一般都是跑Demo程序没有问题的，不会出现适配的问题，因此在硬件工程师设计硬件时，我们应该提出意见尽量使用DK板上搭载的Soc

h.adc采样通道配置问题，这个问题的根本原因是stack对EFR32系列的ADC采样API适配问题，参数在某个API中被错误赋值导致后面采样的值出错，最简单有效的办法就是去查看ADC相关的寄存器，看我们赋值API的值设置的寄存器对不对，参照官方文档里面ADC寄存器介绍，那里不对改哪里。

i.电压低于2.4V设备无法正常使用，但是soc最低工作电压是1.8V，原因在于内部DC-DC供电的工作最低电压为2.4V

III.大批量生产时遇到的问题（SBR出厂测试）

a.发现在禁用DC-DC初始化，并使用VBAT供电方式后，发现有7%左右的产品睡眠电流不达标（7~20微安），这个将直接导致产品寿命打折扣，后与silicon技术支持沟通是EFR32内核在漏电，需要在halConfigInit里面配置一下EMU：

  EMU_EM23Init_TypeDef em23init = EMU_EM23INIT_DEFAULT;
  em23init.vScaleEM23Voltage = emuVScaleEM23_LowPower;
  EMU_EM23Init(&em23init);

（他们的做法是将睡眠电流大的样机EFR32芯片移植到正常的样机pcb板子上，如果依然大，那么说明是芯片问题，而非外围电路导致的）

另外，我也发现在睡眠的时候串口也在工作，由于我们这项目没有用到串口，于是屏蔽掉宏开关EMDRV_UARTDRV_HW_FLOW_CONTROL_ENABLE
b.为了进一步优化功耗，我们调整了keep alive的机制，使用poll control cluster的check in（每隔30分钟设备发一次），如果Coordiantor没收到30分钟 一次的check in则判断设备掉线，此外利用好poll control的相关功能，在不同情况下调整long poll和Short poll，也可以优化功耗，延长产品寿命。如：作为一个sensor，一般都是发送数据，很少接收数据，那么long poll可以设置长一点，如1分钟，如：在做OTA的时候可以将short poll设置成最小0.25s，可以大大加快OTA时间

c.为了更进一步优化产品掉线后的功耗，调整了rejoin机制，当设备网络状态变为No Parent时周期性 rejoin时间是依次递增的：前半个小时每5分钟rejoin一次，然后一个小时里每10分钟一次，然后再30分钟执行一次

d.发现部分设备在50℃左右时电压会从3.0V下降到2.5V，然后出现低电报警，给人第一感觉是个别电池质量存在问题，于是做了一个实验，将设备用3.0V电池供电，然后一同放置到恒温器中加热到50℃，并且并联一个电压表，发现电压表测量值为3.0V，而设备上报的电压值变为了2.5V，说明第一个假设不成立，不是电池质量问题。接下来选取两组测试样本（两台问题样机，两台正常样机），全部重新烧录最新的软件，采用稳压电源供电后放置恒温器中加热到50℃,测试结果与之前的一致，将坏的两台样机重新擦除FLASH并烧录早前的软件，发现问题依然存在，让人怀疑是不是硬件本身的问题，于是将带程序的坏机芯片移植到正常的设备上，发现问题是跟着芯片跑的，因此可以排除外围电路设计的问题，联系技术支持，技术支持基于demo工程进行测试，并且每隔1s检测一次电压，发现坏机并不会出现电压下降的问题，这说明很可能是软件方面的问题，我与之比较，发现我的代码与之存在的主要不同是他采用的是定时器调用采样代码，而我则是通过通讯产生的RTX中断，触发电池采样，于是我将工程里面这部分代码改成定时器定时采样的方式，发现烧录到坏机里面依然存在这个问题，说明这个和调用采样的方式关系不大，于是再思考一下我的工程与Demo工程的其他区别在于我这个还需要调用温度采样，让人怀疑会不会跟温度采样有关，于是我屏蔽掉温度采样这个模块的代码，并且采取定时器定时1s采样的方式，重新测试，发现这个问题不会出现了，为了确认这个问题与温度采样有关，排除电池采样方式不同的影响，我将采样方式恢复成之前的，并且屏蔽掉温度采样模块代码，发现这个问题在以前有问题的设备上不会出现了。检查代码发现一个问题，电池采样和温度采样都是调用同一个ADC0，确认这个问题和电池采样和温度采样互相影响引起的，最后通过逐渐缩小范围的方式，将温度采样模块的代码逐渐缩小，直到找到那个导致出现问题的那条代码（halInternalSleepAdc();中的 ADC_Reset(ADC0);），看了下ADC_Reset(ADC0)的API实体，主要是将ADC0的寄存器的值全部恢复成默认值，也就是说下次调用ADC0之前需要重新初始化全部ADC0的寄存器才行，而电池采样只初始化了部分寄存器，这个就是问题所在，导致电池采样错误。

IV.ZigBee 3.0认证阶段遇到的问题

待更新。。。