Re: [問題] cortex m3的handler mode返回問題

看板ASM (組合語言)作者james33312 (建)時間6年前 (2018/09/25 01:00)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串2/2 (看更多)

我被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? : 感覺好亂，沒辦法好好表達...... : 感謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.16.184 ※ 文章網址: https://www.ptt.cc/bbs/ASM/M.1537808430.A.B06.html