嵌入式设备的踩内存问题定位分析总结

　　现象

　　51交换机中移入ERPS功能后，通过ping设备抓包发现设备的mac地址的后两位并不是设备的原先的地址，原先的mac地址为 fc:19:d0:01:02:03，但是设备arp应答的地址却是

　　fc:19:d0:01:05:07，设备arp应答的地址时通过uip_ethaddr该全局变量获取的。故pc发送icmp的目的mac地址

　　fc:19:d0:01:05:07，不为设备的mac地址，设备无法命中对应的ACL规则，导致ping设备不通.

　　初步怀疑是新增ERPS代码导致

　　故通过添加调试打印的方式进行跟踪查看该全局变量uip_ethaddr的mac地址是何时被修改的，从设备初始化开始加，最后发现在main函数中的while循环中，当第一个10ms定时器出发后，进入Drv_Port_IsolateApply（）该函数的调用后uip_ethaddr该内容的后面两个字节就被修改了。当时感觉很不可思议，怎么无缘无故就发生变化了呢。

　　则通过注释ERPS的新增代码发现，当注释到uip_ERPS_PduHandle函数时发现能够正常ping通设备。并且经过测试发现当将某个全局变量改大或者改小的话，问题也不会出。这就更加感觉离谱了，然后就怀疑是存储变量的xdata区域是否有界限限定，但是咨询后发现xdata区域大小是48K，所以并没有超出范围。

　　借助MAP文件分析

　　通过咨询得到可以通过Keil编译生成的MAP文件进行查看uip_ethaddr该变量前后是否出现相关其他变量，是否出现内存越界问题。借助MAP文件，经过测试发现当问题出现时总是发生在指针地址为02007FF6H地方，并且是从02007FFAH的位置开始踩内存，踩内存的大小为6个字节。

　　根据这一现象，则怀疑是否我们原先代码就是存在这样的问题的，然后从库上下载代码，并且通过调整几个变量的大小，使得 uip_ethaddr的位置刚好落在02007FF6H处。最后验证发现确实是同样存在问题的，uip_ethaddr的内存的最后两个字节被修改为05，07。然后再次调整，将某个全局变量落在该指针处，通过将该指针的内容打印方式进行确认是否是在该问题02007FFAH的往后6个字节被踩掉了。结果验证确实如此，该全局数组的数据从指针地址02007FFAH开始的往后6个字节被修改了。

　　故猜想是否只要有内存落在该地址区间，这片内存就会被改变，根据该猜想进行验证，通过查找文档发现，可以直接指定某个变量在某个地址区间，Keil C可以让你指定变量的存储地址例如 你想定义一个整型变量 并把它初始化为0x4050 用C是不能够把变量指定在某个地址的 另外你也不能指定位变量的地址 但是 对于不需要初始化的变量 你可以使用关键字_at_来指定地址，故根据文档设置全局变量如下： uint8 xdata ucString2［64］ _at_ 0x7FF6; 并且通过调试手段将该内存的内容给打印出来。经过测试发现，正如我们猜想的，还是在同一个位置地址02007FFAH处被踩了6 个字节。根据上述现象，我们就想采取使用占用地址的方式来规避该问题。