我被Jserv抓來回應這篇文了。
※ 引述《wei115 (ㄎㄎ)》之銘言：
: 大大們晚安
: 小弟最近在看jserv大大的mini-arm-os遇到了些問題
: 在 https://github.com/jserv/mini-arm-os/blob/master/04-Multitasking/os.c
: 其中的
: unsigned int *create_task(unsigned int *stack, void (*start)(void))
: {
: stack += STACK_SIZE - 17;
: stack[8] = (unsigned int) THREAD_PSP;
: stack[15] = (unsigned int) start;
: stack[16] = (unsigned int) 0x01000000; /* PSR Thumb bit */
: stack = activate(stack);
: return stack;
: }
: 他直接把自動push的值設定好之後(此時是特權級的thread mode),然後就直接在lr上寫入
: 0xFFFFFFFD(之後activate函式會把bx lr給pc),然後就直接用handler返回的形式跳到用
: 戶級的thread mode，並且自動pop出stack內的值回暫存器
: 而根據這張圖
: https://i.imgur.com/SpobiVy.jpg
: 由特權級的thread mode到用戶級的thread mode的方法應該只有修改CONTROL暫存器，並
: 沒辦法直接用handler mode返回的方式去到用戶級的thread mode
: 而在找資料的過程中，發現以前這個函式好像是長這樣
: unsigned int *create_task(unsigned int *stack, void (*start)(void))
: {
: static int first = 1
: stack += STACK_SIZE - 32;
: if(first) {
: stack[8] = (unsigned int) start;
: first = 0;
: } else {
: stack[8] = (unsigned int) THREAD_PSP;
: stack[15] = (unsigned int) start;
: stack[16] = (unsigned int) 0x01000000; /* PSR Thumb bit */
: }
: stack = activate(stack);
: return stack;
: }
: 有區分第一次進入用戶級的thread mode，並在第一次進入時修改CONTROL暫存器的方法，
: 之後才用從handler mode返回的方式去執行
: 這在06-Preemptive
: https://github.com/embedded2015/mini-arm-os/blob/master/06-Preemptive/os.c
: void task_init(void)
: {
: unsigned int null_stacks[32];
: init_activate_env(&null_stacks[32]);
: }
: 也有殘留(?)，可是不知道為什麼之後的版本都沒有了(除了06外)，都是直接返回到
: user_task
: 後來我又看了程式碼，發現在reset的時候有一個reset_handler的中斷，我那時就猜測
: 可能在reset時cortex m3是處於handler mode，此時用異常返回的方式進入user_task也
: 是合情合理的事
這邊我說明一下，這是我改的，當初是根據
https://github.com/jserv/mini-arm-os/commit/b4c7473db87eca03ca022fb44ffe39de953
所以決定把activate的if (first)通通都拔掉來簡化code
因為我好像(?)當初也誤認為reset_handler是一個excption，所以是在handler mode
不巧的是，reset_handler在arm的spec中有特別註明
Execution restarts as privileged execution in Thread mode
所以這就變成了在Thread mode將lr assign成EXEC_RETURN，再bx lr導致undefined behavior。
而我燒上HW看了一下，這個behavior會導致systick exception失效所以你才會看到
卡在前面兩行。
而剛好，在QEMU環境下是可以正常執行的，所以當時驗證時就沒有注意到這件事。
而我也好一陣子沒碰這個Repo了...所以就這樣都沒人發現哈哈
06-Preemptive的task_init()是用比較tricky的方式去切換到handler mode，
我個人認為這個方法並不是很好，因為會浪費一個svc handler，
這部分我之後也會修正一下。
這個BUG已經在我local端修好了，我先開一個issue隨後會把PR弄上
https://github.com/jserv/mini-arm-os/issues/27
PR會是關於reset時的thread mode轉換
最後強烈建議一下有疑問就直接到github開issue，
我相信有人有看到知道就會回答你，
不然Jserv沒寄信我根本不知道有這件事RRR
: 但在程式碼看的差不多的時候，想要上機測試看看時，卻發生了問題
: 機器沒反應.....
: 我使用的機器是STM32F103C8T6，使用04-Multitasking會有問題
: https://github.com/embedded2015/mini-arm-os/blob/master/04-Multitasking/os.c
: print_str("OS: Starting...\n");
: print_str("OS: First create task 1\n");
: usertasks[0] = create_task(user_stacks[0], &task1_func);
: task_count += 1;
: print_str("OS: Back to OS, create task 2\n");
: usertasks[1] = create_task(user_stacks[1], &task2_func);
: task_count += 1;
: print_str("\nOS: Start multitasking, back to OS till task yield!\n");
: current_task = 0;
: 傳回來的只有前面兩行
: OS: Starting...
: OS: First create task 1
: 之後載入usertask和執行的地方完全沒有畫面....
: 然後我把06-Preemptive的task_init丟進來後，就正常運作了.....
: ????????????
: 所以在開機的時候處理器的狀態是特權級的thread mode?reset handler是跑在這個模式?
: 可是如果這樣，那為什麼裡面會直接從特權級的thread mode用handler mode返回的形式
: 往PC寫入EXC_RETURN?
: 感覺好亂，沒辦法好好表達......
: 感謝