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

51-SWITCH踩内存问题定位分析

• 现象

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设备不通.

• 问题分析过程

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

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

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

 

2.2、借助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个字节。

根据上述现象，我们就想采取使用占用地址的方式来规避该问题。

2.3、分析STARTUP.A51

STARTUP.A51文件主要工作是对设备上电后的一些初始化工作，文件中定义了相关内存的大小，如idata、xdata，设置堆栈等一些信息，最后跳转到用户程序main函数中。

其中有一段内容比较可疑：

; secondary stack initial position in 0x8000

                MOV     SSPL, #00H

                MOV     SSPH, #80H

这段汇编从注释可疑看出是跟栈有关,然后联想到每次踩内存都是在0x8000前面的6个字节，即从02007FFAH开始，是否会跟该栈的设置有关，所以大胆猜想可能会随着该地址的改变而改变。根据上面的猜想，我们将该stack地址改为 MOV SSPL, #10H, MOV SSPH, #80H

查看该踩内存现象是否会发生偏移。最后验证发现，踩内存地址是往前移动了，所以基本确认是由于这个stack的设置，会出现在该stack前的6个字节被踩。从这里可以分析我们在调试打印的时候，发现进入某个函数后，那块内存空间的内容被修改,所以跟这个应该有着直接的关系。

• 解决方案

由于缺少芯片厂商的支持,并且缺少对相关知识的储备,无法定位出为何在该stack的前6个字节被踩掉.所以基于上述分析,我们采用全局变量占用该块地址的方式进行修改，具体修改以及注释如下：

防止该地址区域指向其他变量而导致异常。

• 总结

从这个问题的定位解决来看，我们首先想到的是新增加的ERPS的问题，是否跟配置相关，发现当增大或减少某个变量大小后，该问题就不会出现,排除掉ERPS从而转移到XDATA内存上中。进一步确认出现问题时,从MAP文件中看出xdata memory 中uip_ethaddr该指针地址是固定在某个位置才会出现的。然后确认该地址是否一定会出现踩内存现象。进而得出解决问题的方案。

刚开始觉得这个踩内存问题有点棘手,找不到方向,则需要与他人多沟通交流,听取他人意见，从多方面角度进行考虑，敢于猜想，并且需要一步一步对猜想进行验证。

从处理这个问题最后结果来看,我们是采用规避的方法进行处理,从这一点也看出我们缺少对51芯片内部架构、rom、ram以及堆栈等内容的学习理解，需要进一步借助相关文档进行学习总结。