rt_system_scheduler_start()返回

发布于 2013-11-27 17:08:24 浏览：10574 订阅该版

最初是前天串口老是乱码（在评估环境，其它几个都是OK的），昨天也不知道怎么好了，但总是启动后
出异常。具体的异常信息参考意义不是很大了，今天我调了一下，大概是这里无法产生中断而返回：
rtthread_startup() -> rt_system_scheduler_start() -> rt_hw_context_switch_to() :
```	LDR		R0, =ICSR				/* trigger the PendSV exception (causes context switch) */
	LDR		R1, =PENDSVSET_BIT
	STR		R1, [R0]

CPSIE	I						/* enable interrupts at processor level */

/* never reach here! */```

用的是bspstm32f10x，修改不多，目前主要是修改了一下编译器使用GNU Tools ARM Embedded 4.7 2013q3版本，
另外把application.c中的两个任务改为空循环了。
我看了一下CoOS中的代码，和这里基本上是一样的，不知道为什么它跑起来是正常的：
```void SwitchContext(void)
{
  __asm volatile
  (
      " LDR     R3,=NVIC_INT_CTRL  
"
	  " LDR     R3,[R3]            
"
	  " LDR     R2,=NVIC_PENDSVSET 
"
	  " LDR     R1,[R2]            
"
      " STR     R1, [R3]           
"
      " BX      LR               
"   
  );
 
}```
（它里面用的是变量，所以多了一级LDR操作。）
看手册有这样一句话：
Use CPS only from privileged software, it has no effect if used in unprivileged software
但打印出CONTROL寄存器发现是privileged mode。
现在还不会搭RT-Thread的调试环境，所以是用设置一些值再打印出来调试的，目前定位到这里不好再
找下去了。希望各位大神支招，看一下可能是哪个方面的原因，是不是还有一些配置没做对？
下载附件 [bsp_stm32f10x.tar.bz2](https://oss-club.rt-thread.org/uploads/6223_ce7db975a7459f077c1dac8def3a6de7.bz2)

![1.png](https://oss-club.rt-thread.org/uploads/3230_a32a3b9e16baa4429e3288afc39de07d.png)

![2.png](https://oss-club.rt-thread.org/uploads/3230_c05921741080622dab15516ee4f45640.png)

![3.png](https://oss-club.rt-thread.org/uploads/3230_c41aefc8344ba1b05c19ea2c9184a6bb.png)

下载附件 [stm32f10x-mod.zip](https://oss-club.rt-thread.org/uploads/3230_7422cc4a58c9c378233dc3a415c9536c.zip)

下载附件 [stm32f10x_mini.7z](https://oss-club.rt-thread.org/uploads/3230_b362efb881cc62bf685f2570592a6818.7z)

28 个回答

bernard 2013-11-27

这家伙很懒，什么也没写！

prife 2013-11-28

这家伙很懒，什么也没写！

Cyberman 2013-11-28

这家伙很懒，什么也没写！

Cyberman 2013-11-28

这家伙很懒，什么也没写！

prife 2013-11-28

这家伙很懒，什么也没写！

prife 2013-11-28

这家伙很懒，什么也没写！

Cyberman 2013-11-28

这家伙很懒，什么也没写！

prife 2013-11-29

这家伙很懒，什么也没写！

Cyberman 2013-11-30

这家伙很懒，什么也没写！

>如果用arm gcc的话，可以用arm-none-eabi-gcc。 
>一般情况下，如果出现bsp使用gcc编译崩溃而mdk编译不崩溃的话，这一般属于代码中存在隐蔽的bug，这种情况我遇到过。上一楼代码提供裁剪过得bsp使用gcc来编译也是可以的。在公司的时候没安装gcc toolchain也没有板子，因此就没有测试。

---

昨天病休，又遇到家里停电，今天才调试了一下。这个问题有些怪异，最终发现是这样的：
如果用J-Flash下载bin文件之后没有disconnect，然后直接reset板子就出现无法切换的情况，
遇到这种情况有两种办法解决：
1. 下载之后disconnect。
2. 板子掉一下电。

用MDK编译的话不disconnect最终会shell的finsh>>无法打印出来，一直吊着，一旦
disconnect马上就运行下去了。
有可能和这两种编译器采用的不同的初始化代码有关系？

两种编译器简单对比了一下，发现你给我的示例中增加的 --gnu --split_sections
选项对于armcc编译后的大小影响比较大，加了这个明显变小。在这个的基础上，同样的
-O3优化两个编译器编译结果的大小差不多，而如果GCC用-Os则会小一些（不知道armcc
有没有类似的选项）。
而-O0则两者差异比较大，GCC编译出来的大许多，似乎和以前在VxWorks上用GCC和
Diab的区别是一样的。
本来想看一下MDK5的编译器有优化有没有更好一些，结果编译失败了，没再去弄。

另外你给我的代码中，也出现和我发到邮件列表中一样的问题，这个问题前天我在弄
FreeRTOS是知道原因了，简单改一下就可以了：

```
__attribute__( ( optimize("O0")) )
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
   uint32_t result=0;
  
   __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   return(result);
}

__attribute__( ( optimize("O0")) )
uint32_t __STREXH(uint16_t value, uint16_t *addr)
{
   uint32_t result=0;
  
   __ASM volatile ("strexh %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   return(result);
}
```

比较奇怪的是，RT-Thread 1.1.1中直接的那个bspstm32f10x编译则不会遇到这个问题，
而这两个文件又是完全一样的，还没弄清楚是哪触发的问题。
这个问题似乎以前在许多地方出过的，应该是优化时因为value用的是r0，而返回值也是r0，
所以编译器直接把%0和%2都优化为它了，而在ARM的规范中这两条指令是不允许这样用的。