我被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?
: 感觉好乱，没办法好好表达......
: 感谢