如果考慮多級中斷，必須注意到中斷開關(guān)級別的控制是一個重要的信息，在關(guān)閉中斷之前需要將這個信息保存起來，在對應的開中斷時恢復這個中斷級別控制信息。最容易想到的方法是用一個全局變量存存這個信息。

使用這個方法的程序如下：
#define OS_EXIT_CRITICAL() asm move SR_TEMP,sr；
#define OS_ENTER_CRITICAL() asm move.w SR,SR_TEMP;
asm ori.w #0x0700,SR;

接著構(gòu)造兩個任務，每個任務分別向屏幕輸出一句話，同時修改內(nèi)核的代碼，讓空閑任務也輸出一句話。運行內(nèi)核，通常在幾分鐘內(nèi)會發(fā)現(xiàn)內(nèi)核停止調(diào)試，只有空閑任務不停地向屏幕輸出。這種情況非常麻煩，因為根據(jù)無法通過調(diào)試手段判斷何時何處導致內(nèi)核停止調(diào)度。

分析一下，當只有空閑任務運行時，代碼為：
move.w sr,sr_temp
ori.w #0700,sr
addi.1 #1,OSIdleCtr
move.w sr_temp,sr
jmp ****

這5句語句在循環(huán)運行，而中斷（這時只有定時中斷）可以在任意一句語句中間切入。那么，如果在MOVE.W SR，SR_TEMP的時候產(chǎn)生了中斷，就會執(zhí)行中斷（因為正要關(guān)中斷，但還沒有關(guān)上）；而中斷程序調(diào)用的OSIntENTER和OSIntEXIT都會調(diào)用 OS_ENTER_CRITICAL（）來關(guān)閉中斷，遞增中斷嵌套層數(shù)全局變量。這時，再次執(zhí)行MOVE.W SR，SR_TEMP變量就被改寫成關(guān)中斷的值，當從中斷返回到IDLE任務執(zhí)行MOVE.W SR_TEMP，SR時，就關(guān)閉了中斷，而不是恢復原來的狀態(tài)寄存器。這樣就導致內(nèi)核無法響應中斷，無法調(diào)度任務，只有IDLE任務在運行。

如何解決？最容易想到的方法是再增加一個全局變量，用來保存進入中斷時的中斷開關(guān)信息，退出中斷恢復這個信息；但如果考慮到中斷嵌套，相同的情況又出現(xiàn)了，并且如果一個任務在執(zhí)行MOVE.W SR，SR_TEMP時被中斷打斷并且發(fā)生了任務調(diào)度，那么當個任務恢復時，它使用的中斷信息SR_TEMP可以已經(jīng)是被其他任務更改后的值了。內(nèi)核無法響應中斷，無法調(diào)度的任務可能依然存在。

給每個任務和中斷都定義一個這樣的全局變量，在不考慮中斷嵌套的情況下似乎可以解決問題，但想象一下為每一個任務和中斷提供一個單獨的OS_ENTER_CRITICAL（）和OS_EXIT_CRITICAL（）函數(shù)所帶來的工作量。顯然這不一個好辦法。

將中斷信息推入堆棧是一個好主意，但我們會看到由此帶來的一些更加隱蔽而復雜的問題。實現(xiàn)這個方法的程序代碼如下：
#define OS_ENTER_CRITICAL() asm move SR,-(A7);
asm ori.w #0x0700,SR;
#define OS_EXIT_CRITICAL() asm move (A7)+,sr;

這樣，每次調(diào)用OS_ENTER_CRITICAL（），都將當前的中斷開關(guān)信息保存到當前任務堆棧或系統(tǒng)堆棧中斷OS_EXIT_CRITICAL（）時，恢復這個信息。

使用了這個方法后，必須小心地計算堆棧的使用情況，修改OS_CPU_A.ASM和 OS_CPU_C.C文件里的函數(shù)。以OSIntCtxSw()函數(shù)為例，這個函數(shù)將導致中斷級的任務調(diào)度，即被中斷打斷的程序不能繼續(xù)運行，退出中斷中另一個優(yōu)先級更高的任務得以運行。在這個函數(shù)中必須對被中斷的任務堆棧進行清理，使得這個任務的堆棧看起來和一次正常的任務切換后的情況相同，這樣，才能保證這個任務被正確地恢復運行。OSIntCtxSw()函數(shù)僅僅在 OSICntExit()函數(shù)中被調(diào)用。

須指出的是，在中斷發(fā)生時，CPU32已經(jīng)將全部的寄存器和狀態(tài)寄存器，PC指針內(nèi)容保存到了堆棧中，這樣已經(jīng)為被打斷的任務的恢復作好了準備。如果按照正常的中斷流程，在退出中斷時，被打斷的任務應該恢復運行。現(xiàn)在，由于執(zhí)行了中斷級的任務切換，被打斷的任務不能立刻恢復，而是被掛起，這就要求在執(zhí)行任務調(diào)度前調(diào)整堆棧，使得被中斷打斷的任務處于隨時可以被恢復的狀態(tài)。

在中斷處理程序中，當執(zhí)行到OSIntExit（）時，堆棧的情況和剛剛進入中斷還是相同的，是能夠隨時恢復被打斷的任務的情況。那么，只需要忽略 OSIntExit（）函數(shù)造成的堆棧變化。首先，是OSIntExit（）函數(shù)本身的返回地址，長度為2個字；調(diào)用OS_ENTER_CRITICAL （）壓入堆棧的狀態(tài)寄存器，長度為1個字；最后，是OSIntCtxSw()函數(shù)的返回地址，長度為2個字。那么在OSIntCtxSw()進行任務切換時，首先要把這5個字的堆棧的內(nèi)容清除，才能保證被中斷任務的正確恢復。該語句如下：
ADDA #10，A7；

在完成了這些調(diào)整后，由于開關(guān)中斷可能導致的內(nèi)核調(diào)度死鎖的可能已經(jīng)不存在了。但是在這種情況下，另一個更加隱蔽的問題會出現(xiàn)，這個問題又是和使用的C編碼器相關(guān)的。

問題出現(xiàn)在使用OSSemPend()函數(shù)時，一旦調(diào)用這個函數(shù)，CPU就會出現(xiàn)地址錯誤而進入異常處理，內(nèi)核被終止。這個問題相當奇怪，因為， OSSemPend()函數(shù)完全是一個C語言寫成的子函數(shù)，函數(shù)本身不應出現(xiàn)地址錯誤。通過閱讀編譯器編譯出來的目標碼發(fā)現(xiàn)了問題。EmPend()函數(shù)，發(fā)現(xiàn)這個函數(shù)沒有任何局部變量。在進入OSSemPend()函數(shù)時，編譯器不需要產(chǎn)生LINK指令來提供局部變量空間。所有的參數(shù)都是使用帶偏移量的地址寄存器間接尋址方式直接從堆棧中取得，而且使用的地址寄存器就是A7寄存器。問題可能就在這里，OS_ENTER_CRITICAL（）和 OS_EXIT_CRITICAL（）對堆棧的操作都會調(diào)整A7寄存器，這就會導致下面的語句在利用A7作寄存器間接尋址時發(fā)生錯亂，出現(xiàn)地址錯誤。

這需要詳細研究編譯器的特性。我們使用的HIWARE的編譯器實際上已經(jīng)考慮到了這一點，當調(diào)用 OS_ENTER_CRITICAL（）或 OS_EXIT_CRITICAL（）函數(shù)更加了A7寄存器后，使用A7的地址寄存器間接尋址也會做出相應的調(diào)整，保證仍然能夠得到函數(shù)調(diào)用時傳遞的變量。每出現(xiàn)一個OS_ENTER_CRITICAL（），接下來的A7寄存器間接尋址的偏移量就會加2；每出現(xiàn)一個OS_EXIT_CRITICAL （），接下來的A7寄存器間接尋址的偏移量就會減2。但是問題卻依然存在，對OSSemPend()的調(diào)用會導致地址錯誤，這應該是一個更深層次的錯誤。

這個問題的解決方法是：定義一個局部變量，迫使編譯器生成LINK指令，構(gòu)造內(nèi)部參數(shù)尋址指針A6，這樣調(diào)用OS_ENTER_CRITICAL（）或OS_EXIT_CRITICAL（）時，更動的只是A7，而對參數(shù)尋址用的是A6，不受影響。

如果強迫編譯器在調(diào)用函數(shù)時都加上LINK和UNLINK指令也可以解決這個問題，但是又會面臨最先提到的編譯器的優(yōu)化選項問題?？梢钥闯?，編譯器的特性對移植μC/OS-II是非常重要的，并且往往這些特性是相互制約的。

在移植和運行μC/OS-II的過程中，也許還會有新的問題出現(xiàn)，遇到問題時只要仔細分析，分析堆棧的使用、中斷的影響，分析編譯生成的代碼，就可以實現(xiàn)μC/OS-II的穩(wěn)定可靠運行.