標(biāo)題: 關(guān)于基于ARM7的工程開(kāi)發(fā)中遇到的DAbt異常的原因以及解決方案？ [打印本頁(yè)]
作者: 最閑的閑魚(yú)    時(shí)間: 2018-5-31 21:44
標(biāo)題: 關(guān)于基于ARM7的工程開(kāi)發(fā)中遇到的DAbt異常的原因以及解決方案？
       本人目前使用LPC23xx系列的ARM7芯片做通信的工程，整個(gè)程序只用到CAN、UART、Time幾個(gè)外設(shè)，其中UART采用中斷接收方式，Time也開(kāi)了中斷用于產(chǎn)生周期的定時(shí)信號(hào)值，串口的中斷優(yōu)先級(jí)要高于定時(shí)器的。其次主要實(shí)現(xiàn)的功能就是定時(shí)地通過(guò)CAN對(duì)CAN總線網(wǎng)絡(luò)的其他節(jié)點(diǎn)進(jìn)行收發(fā)信息操作，然后轉(zhuǎn)換成串口數(shù)據(jù)格式，再由串口進(jìn)行收發(fā)工作。這是基本情況。

      可在實(shí)際的測(cè)試過(guò)程中，當(dāng)我開(kāi)機(jī)后，采用每隔1.6s通過(guò)串口下發(fā)數(shù)據(jù)進(jìn)行查詢時(shí)，過(guò)了差不多半個(gè)小時(shí)就沒(méi)有返回?cái)?shù)據(jù)了，采用MDK在線仿真發(fā)現(xiàn)每一次都是程序陷入了啟動(dòng)代碼的DAbt行，如下圖所示。





       然后我采用http://www.torrancerestoration.com/bbs/dpj-121124-1.html 的方法對(duì)R14寄存器中的地址值減8并在Command窗口中輸入后程序跳轉(zhuǎn)到定時(shí)器中斷服務(wù)程序中，如下圖所示。


想請(qǐng)教一下，這種問(wèn)題的根本原因是因?yàn)槎褩Ｒ绯雎铮鉀Q這種問(wèn)題的思路是什么？
謝謝。





作者: 最閑的閑魚(yú)    時(shí)間: 2018-6-1 19:21
真的是醉了，查來(lái)查去原來(lái)是NXP公司給的中斷服務(wù)函數(shù)框架的問(wèn)題。
具體來(lái)說(shuō)，我是參考了MCB2300的代碼，里面的中斷服務(wù)函數(shù)框架如下所示：
void Timer0Handler (void) __irq
{  
  T0IR = 1;                        /* clear interrupt flag */
  IENABLE;                        /* handles nested interrupt */

  timer0_counter++;

  IDISABLE;
  VICVectAddr = 0;        /* Acknowledge Interrupt */
}

問(wèn)題就是出在IENABLE和IDISABLE這兩個(gè)宏定義里，其在irq.h中的宏定義如下
static DWORD sysreg;                /* used as LR register */
#define IENABLE __asm { MRS sysreg, SPSR; MSR CPSR_c, #SYS32Mode }
#define IDISABLE __asm { MSR CPSR_c, #(IRQ32Mode|I_Bit); MSR SPSR_cxsf, sysreg }
意思是對(duì)程序狀態(tài)寄存器CPSR和SPSR進(jìn)行操作使其進(jìn)入系統(tǒng)模式或IRQ模式，乍一看到?jīng)]什么問(wèn)題，可是移植進(jìn)工程里就出數(shù)據(jù)中止異常的問(wèn)題。

下午測(cè)試的時(shí)候我把定時(shí)器中斷和串口中斷中的IENABLE和IDISABLE語(yǔ)句全部注釋掉再進(jìn)行多次測(cè)試，都沒(méi)有什么問(wèn)題。

從官方框架的注釋上來(lái)看這些宏定義是用于解決中斷嵌套的，也就是說(shuō)像我這個(gè)工程中有兩個(gè)中斷必然會(huì)涉及到嵌套，不過(guò)遺憾的是ARM7貌似不太推薦中斷嵌套，周立功的《ARM嵌入式系統(tǒng)基礎(chǔ)教程》中也提到對(duì)于ARM7的中斷嵌套配置和操作較為復(fù)雜，不推薦使用。其次從代碼上來(lái)看，估計(jì)是每一次進(jìn)入中斷都要對(duì)程序狀態(tài)寄存器進(jìn)行操作，而頻繁的內(nèi)核模式切換以及程序狀態(tài)寄存器的強(qiáng)制操作（因?yàn)橐话氵@一類(lèi)最底層的寄存器都是不對(duì)用戶開(kāi)放的）導(dǎo)致了數(shù)據(jù)中止異常。

當(dāng)然上述只是我的推測(cè)而已，不知道是否正確，還請(qǐng)大牛批評(píng)指正！
作者: 最閑的閑魚(yú)    時(shí)間: 2018-6-1 19:42
該問(wèn)題以解決，在此結(jié)一下題。下面講一下我的解決思路和方法。

先說(shuō)問(wèn)題出在哪兒。我是采用了NXP官方MCB2300開(kāi)發(fā)例程給的中斷服務(wù)程序框架，如下圖所示。

原因出在IENABLE和IDISABLE這兩個(gè)語(yǔ)句上，將所有中斷服務(wù)程序中的這兩個(gè)語(yǔ)句注釋掉之后，多次測(cè)試再無(wú)異常和死機(jī)。

下面講一下我個(gè)人覺(jué)得的原因。
首先IENABLE和IDISABLE是一個(gè)宏定義，其具體定義在irq.h中，如下圖所示

仔細(xì)看可以發(fā)現(xiàn)它們是對(duì)程序狀態(tài)寄存器CPSR和SPSR進(jìn)行操作，使內(nèi)核進(jìn)入系統(tǒng)模式或者是IRQ中斷模式，乍一看貌似沒(méi)什么問(wèn)題，而且官方代碼的注釋也說(shuō)這兩個(gè)語(yǔ)句主要是為了解決中斷嵌套用的。不過(guò)不知道是因?yàn)槲覜](méi)有配置完全還是怎么的，在本工程中確實(shí)會(huì)出現(xiàn)中斷嵌套的問(wèn)題，估計(jì)沒(méi)有很好的處理中斷嵌套，從而出現(xiàn)了數(shù)據(jù)中止異常吧。

可是回過(guò)頭來(lái)想想如果是因?yàn)橹袛嗲短椎呐渲脹](méi)有做好，那為什么直接去掉這兩個(gè)語(yǔ)句，換言之就是為什么直接放棄中斷嵌套的配置，反而程序運(yùn)行流暢不會(huì)異常和死機(jī)了呢？

個(gè)人覺(jué)得吧可能原因還是出在對(duì)程序狀態(tài)寄存器的頻繁操作和對(duì)內(nèi)核模式的頻繁切換所導(dǎo)致的問(wèn)題，不過(guò)具體的原因因?yàn)閭€(gè)人所學(xué)有限目前還不能給予更加有效的正確的解釋。
上述如果有謬誤和紕漏的地方，還望大牛們批評(píng)指正。



歡迎光臨 (http://www.torrancerestoration.com/bbs/) Powered by Discuz! X3.1