在測(cè)試MF固件時(shí)，發(fā)生一個(gè)非常詭異的異常，代碼如下：

CLR_DBG_Commands::Monitor_EraseMemory* cmd = (CLR_DBG_Commands::Monitor_EraseMemory*)msg->m_payload;debug_printf("EraseMemory addr=0x%08x len=%d\r\n", cmd->m_address, cmd->m_length);

指定第二行代碼時(shí)，會(huì)跳到異常處理程序，發(fā)生了6號(hào)異常（用法異常Usage Fault）

我對(duì)ARM還是非常陌生，不知道怎么可能發(fā)生這個(gè)問(wèn)題。
在今天之前，這行代碼執(zhí)行了無(wú)數(shù)次也未曾出錯(cuò)，最近也沒(méi)有修改該函數(shù)或者相關(guān)函數(shù)的代碼，昨天倒是大量修改了其它代碼。

1，百度找資料
關(guān)鍵點(diǎn)是用法異常Usage Fault，以此為關(guān)鍵字搜索。有資料（http://www.docin.com/p-633872264.html）指出，用法異常包括：執(zhí)行未定義指令、非對(duì)齊操作、除零。
前后兩個(gè)顯然不可能，中間這個(gè)非對(duì)齊操作倒是引起了我的注意。因?yàn)殚喿xMFPK代碼的時(shí)候看到很多對(duì)齊操作的設(shè)計(jì)。

2，Keil調(diào)試
在Keil中調(diào)試這兩行代碼

0x080071DA 6A74 LDR r4,[r6,#0x24]1350: debug_printf("EraseMemory addr=0x%08x len=%d\r\n", cmd->m_address, cmd->m_length); 1351: 0x080071DC A012 ADR r0,{pc}+4 ; @0x08007228 0x080071DE E9D41200 LDRD r1,r2,[r4,#0] 0x080071E2 F001FD93 BL.W debug_printf (0x08008D0C)

拋出異常的是0x080071DE這一行，代碼是LDRD r1,r2,[r4,#0]，大意是把r4開(kāi)始，偏移#0的數(shù)據(jù)加載到r1，下一個(gè)字加載到r2
從寄存其中看到，r4此時(shí)是0x200006D2，這是半字對(duì)齊而不是字對(duì)齊。
奇怪了，MDK為啥編譯一個(gè)半字對(duì)齊的呢？
回到第一行代碼的msg->m_payload，它是關(guān)鍵。因?yàn)樗褪?/span>0x200006D2，如果r4沒(méi)有字對(duì)齊，那么肯定跟這個(gè)msg->m_payload有關(guān)。
我們看看msg->m_payload是哪里分配的！

3，尋根
從代碼中看到msg->m_payload來(lái)自msg->m_payload = pThis->m_receptionBuffer;
而m_receptionBuffer的聲明

?

COM_HANDLE m_port;UINT8 m_receptionBuffer[ 2048 ];UINT32 m_flags;UINT32 m_lastPacketSequence;WP_Controller m_controller;

?

到這里，就明白了！
因?yàn)槲易蛱彀?span style="color:#0000FF;">typedef INT32 COM_HANDLE;改為了typedef INT16 COM_HANDLE;

非對(duì)齊操作相關(guān)資料
http://www.docin.com/p-218037008.html

?

轉(zhuǎn)載于:https://www.cnblogs.com/nnhy/p/7462758.html

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的ARM非对齐操作异常解决过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。