現象

　　51交換機中移入ERPS功能后，通過ping設備抓包發(fā)現設備的mac地址的后兩位并不是設備的原先的地址，原先的mac地址為 fc:19:d0:01:02:03，但是設備arp應答的地址卻是

　　fc:19:d0:01:05:07，設備arp應答的地址時通過uip_ethaddr該全局變量獲取的。故pc發(fā)送icmp的目的mac地址

　　fc:19:d0:01:05:07，不為設備的mac地址，設備無法命中對應的ACL規(guī)則，導致ping設備不通.

　　初步懷疑是新增ERPS代碼導致

　　故通過添加調試打印的方式進行跟蹤查看該全局變量uip_ethaddr的mac地址是何時被修改的，從設備初始化開始加，最后發(fā)現在main函數中的while循環(huán)中，當第一個10ms定時器出發(fā)后，進入Drv_Port_IsolateApply（）該函數的調用后uip_ethaddr該內容的后面兩個字節(jié)就被修改了。當時感覺很不可思議，怎么無緣無故就發(fā)生變化了呢。

　　則通過注釋ERPS的新增代碼發(fā)現，當注釋到uip_ERPS_PduHandle函數時發(fā)現能夠正常ping通設備。并且經過測試發(fā)現當將某個全局變量改大或者改小的話，問題也不會出。這就更加感覺離譜了，然后就懷疑是存儲變量的xdata區(qū)域是否有界限限定，但是咨詢后發(fā)現xdata區(qū)域大小是48K，所以并沒有超出范圍。

　　借助MAP文件分析

　　通過咨詢得到可以通過Keil編譯生成的MAP文件進行查看uip_ethaddr該變量前后是否出現相關其他變量，是否出現內存越界問題。借助MAP文件，經過測試發(fā)現當問題出現時總是發(fā)生在指針地址為02007FF6H地方，并且是從02007FFAH的位置開始踩內存，踩內存的大小為6個字節(jié)。

　　根據這一現象，則懷疑是否我們原先代碼就是存在這樣的問題的，然后從庫上下載代碼，并且通過調整幾個變量的大小，使得 uip_ethaddr的位置剛好落在02007FF6H處。最后驗證發(fā)現確實是同樣存在問題的，uip_ethaddr的內存的最后兩個字節(jié)被修改為05，07。然后再次調整，將某個全局變量落在該指針處，通過將該指針的內容打印方式進行確認是否是在該問題02007FFAH的往后6個字節(jié)被踩掉了。結果驗證確實如此，該全局數組的數據從指針地址02007FFAH開始的往后6個字節(jié)被修改了。

　　故猜想是否只要有內存落在該地址區(qū)間，這片內存就會被改變，根據該猜想進行驗證，通過查找文檔發(fā)現，可以直接指定某個變量在某個地址區(qū)間，Keil C可以讓你指定變量的存儲地址例如 你想定義一個整型變量 并把它初始化為0x4050 用C是不能夠把變量指定在某個地址的 另外你也不能指定位變量的地址 但是 對于不需要初始化的變量 你可以使用關鍵字_at_來指定地址，故根據文檔設置全局變量如下： uint8 xdata ucString2［64］ _at_ 0x7FF6; 并且通過調試手段將該內存的內容給打印出來。經過測試發(fā)現，正如我們猜想的，還是在同一個位置地址02007FFAH處被踩了6 個字節(jié)。根據上述現象，我們就想采取使用占用地址的方式來規(guī)避該問題。