繼續上一篇文章的工作。上文說到已經有了原始的ucos底層系統，因此將ucos系統剝離出來，獨自編譯，下載到晶片中，注意下載方式選擇只擦除當前頁不要選全部擦除。在編譯器可以看出來，目前ucos系統大約佔140k的RO空間，26.4k的RW空間。通過觀察scf檔案，可以知道，把棧頂分配到了0x40008000，堆分配到了0x40000000。因為需要使用IAP功能，參照ARM說明書，需要把0x40008000向下的32個位元組空間保留出來，建議修改使用者堆疊，因此在Startup.s中修改分配棧的函式，原程式為：

InitStack    
        MOV     R0, LR

;Build the SVC stack
;設定中斷模式堆疊
        MSR     CPSR_c, #0xd2
        LDR     SP, StackIrq
;Build the FIQ stack    
;設定快速中斷模式堆疊
        MSR     CPSR_c, #0xd1
        LDR     SP, StackFiq
;Build the DATAABORT stack
;設定中止模式堆疊
        MSR     CPSR_c, #0xd7
        LDR     SP, StackAbt
;Build the UDF stack
;設定未定義模式堆疊
        MSR     CPSR_c, #0xdb
        LDR     SP, StackUnd
;Build the SYS stack
;設定系統模式堆疊
        MSR     CPSR_c, #0x1f
        LDR     SP, =StackUsr

        MOV     PC, R0
 

這裡為ARM的6種模式都分配了SP，其中我們僅關心StackUsr，因為其值為0x40008000，將其修改為

        LDR     SP, =StackUsr - 1024

這裡減去1024位元組而不是32位元組是因為留一些空間另作他用。因此修改後的棧頂變為0x40007c00。

由於ucos佔用了部分記憶體和flash，且本應用沒有用到虛擬記憶體，因此在上一篇文章中，將編譯器RO設定為0x29c00，RW設定為0x40003000，這樣可以保證燒寫得時候不會把ucos的程式覆蓋，且記憶體空間不會重疊。

將上一篇文章生成的程式碼直接燒寫入晶片，果然僅燒寫了2個page，通過除錯工具可以看到兩段程式碼並沒有重疊（512k的flash都可以當作記憶體觀察）。

在ucos燒寫前，加入呼叫使用者程式的入口：

typedef int (*UsrMain)();
...
    UsrMain p; 
    p = (UsrMain)(0x29c00); 
    (*p)();
...

通過單步除錯，程式可以正確的進入0x29c00執行。

但是，全速執行程式並不能實現想要的結果（在0x40004000中連續寫入數字）。通過觀察發現，基本上定位死在了上一篇文章中沒有分析的神祕的swi附近，彙編程式碼如下：

__user_initial_stackheap
$a
0x00029f28:    e92d4000    [email protected]    STMFD    r13!,{r14}
0x00029f2c:    e24dd014    ..M.    SUB      r13,r13,#0x14
0x00029f30:    e1a0100d    ....    MOV      r1,r13
0x00029f34:    e28d2004    . ..    ADD      r2,r13,#4
0x00029f38:    e5812000    . ..    STR      r2,[r1,#0]
0x00029f3c:    e3a00016    ....    MOV      r0,#0x16
0x00029f40:    ef123456    V4..    SWI      0x123456
0x00029f44:    e59d0004    ....    LDR      r0,[r13,#4]
0x00029f48:    e59d100c    ....    LDR      r1,[r13,#0xc]
0x00029f4c:    e59d2008    . ..    LDR      r2,[r13,#8]
0x00029f50:    e59d3010    .0..    LDR      r3,[r13,#0x10]
0x00029f54:    e3500000    ..P.    CMP      r0,#0
0x00029f58:    059f000c    ....    LDREQ    r0,0x29f6c
0x00029f5c:    e28dd014    ....    ADD      r13,r13,#0x14
0x00029f60:    e8bd4000    
 
[email protected]    LDMFD    r13!,{r14}
0x00029f64:    e12fff1e    ../.    BX       r14

通過上篇文章分析，這些程式碼都是一些初始化記憶體空間，以及測試程式是否能正確執行的操作，因此這裡SWI 0x123456應為測試軟中斷，觀察ucos的軟中斷，發現沒有對0x123456的軟中斷進行處理，其具體影響就是系統進入了svc(系統)模式，SP切換到了系統使用的SP，而0x123456沒有對應的軟中斷，因此係統直接返回了，返回後為系統模式（這裡應該算是個bug，使用者態隨意就能切換到系統態了），sp不對，下面的出棧得到的返回地址就不對了，因此程式跑飛了。因此對ucos的swi程式作如下修改：

;軟體中斷
SoftwareInterrupt

        ;CMP        SP, #0
        ;BEQ        continue1
        ;STMFD   SP!, {R1}
        ;LDR        R1, =0x40007c00
        ;STR        SP, [R1]
        ;LDMFD   SP!, {R1}

continue1       
        LDR     SP, StackSvc            ; 重新設定堆疊指標
        STMFD   SP!, {R0-R3, R12, LR}
        MOV     R1, SP                  ; R1指向引數儲存位置

        MRS     R3, SPSR
        TST     R3, #T_bit              ; 中斷前是否是Thumb狀態
        LDRNEH  R0, [LR,#-2]            ; 是: 取得Thumb狀態SWI號
        BICNE   R0, R0, #0xff00
        LDREQ   R0, [LR,#-4]            ; 否: 取得arm狀態SWI號
        BICEQ   R0, R0, #0xFF000000

                                        ; r0 = SWI號，R1指向引數儲存位置
        LDR     R3, =0x123456
        CMP     R0, R3
        BEQ     Swi123
        MRS     R3, SPSR

        CMP     R0, #1
        LDRLO   PC, =OSIntCtxSw
        LDREQ   PC, =__OSStartHighRdy   ; SWI 0x01為第一次任務切換

        BL      SWI_Exception

        LDMFD   SP!, {R0-R3, R12, PC}^

StackSvc           DCD     (SvcStackSpace + SVC_STACK_LEGTH * 4 - 4)
Swi123          ;123456呼叫切換回使用者模式,且r1=sp+0x20
                LDMFD   SP!, {R0-R3, R12, LR}
                MRS     R0, SPSR
                BIC     R0, R0, #0x1f
                ORR     R0, R0, #USR32Mode  
                MOV     R1, R14
                MSR     CPSR_c, R0
                MOV     LR, R1
                ADD     R1, SP, #0x20
                STR     R1, [SP, #0x0c]
                MOV     PC, LR

        MOV     PC, LR

如果標號為0x123456則切換回使用者態，且根據呼叫程式碼分析，還要把SP向上12個位元組位置中寫入SP+0x20的值才能正確執行。

經過以上修改後，重新分別下載ucos和使用者程式，程式能夠正確執行。

但在添加了一些c的程式碼後，程式又不能夠正確運行了，仔細查詢的編譯後的程式裡面的swi，發現了swi 0xab這個呼叫，是一個THUMB指令，通過在網上搜索swi 0x123456 0xab，終於發現了蛛絲馬跡，原來這兩個軟中斷是ads為了與電腦上位機通訊保留的軟中斷，但我們實際的程式中並沒有實現此軟中斷，因此需要關閉這個選項。

ADS中並沒有提供關閉通訊軟中斷的選項，而swi命令又是編譯器自行新增的程式碼，我們無法控制，參照網上所說的，以及別人的程式碼的分析，進行如下步驟可以讓編譯器不產生軟中斷。下面是詳細的分析：

首先在程式加入如下程式碼：

    #include <stdio.h>

    #pragma import(__use_no_semihosting_swi);//保證使用者程式不呼叫semihostSWI；

通過stdio.h裡面觀察有如下的註解：

extern void __use_no_semihosting_swi(void);
    /*
     * Referencing this symbol will cause a link-time error if any
     * library functions that use semihosting SWI calls are also
     * present in the link, i.e. you define it if you want to make
     * sure you haven't accidentally used any such SWIs.
     */

引用此符號後，如果任何庫函式使用了swi呼叫的話，將會產生連結錯誤，也就是說，如果你不使用任何預期以外的swi的話可以使用此功能

新增此程式碼後，再次編譯程式，果然報錯了。去掉此函式（編譯報錯則不生成彙編），編譯出彙編結果，通過查詢彙編程式碼，發現swi出現的段落為：

1. __user_initial_stackheap
2. _sys_exit

按照網上所說的，新增如下彙編程式碼：

     AREA ||.text||, CODE, READONLY
__user_initial_stackheap
       LDR r0, =0x40003000 
       MOV PC,LR
     EXPORT __user_initial_stackheap
       END

此段程式碼將0x40003000（可根據自己的程式進行修改）作為返回值賦予r0，並匯出__user_initial_stackheap，使用者程式並沒有用到__user_initial_stackheap符號，因此匯出不匯出無所謂。
如此看來，編譯器在編譯時檢測到__user_initial_stackheap段，將會自動替代該段。

編譯後再次檢查，發現__user_initial_stackheap段果然變成了我們自己新增的內容。

將檢查swi的程式碼添加回程式，編譯，仍然報錯。檢查程式碼發現在_sys_exit段仍有呼叫。觀察底層系統的程式碼，發現如下的程式碼段：

        void _sys_exit(int returncode)
{
    returncode = returncode;
}

新增後發現因為有了_sys_exit符號，因此編譯器同樣使用我們的程式替換了彙編程式碼中的_sys_exit。

如此，再次加入檢查swi的語句，編譯成功。將此前修改的底層軟中斷處理函式恢復原樣,仍可正常執行.