闲谈NativeSample的启动模式

//=====================================================================
//TITLE:
//    闲谈NativeSample的启动模式
//AUTHOR:
//    norains
//DATE:
//    Friday  22-October-2010
//Environment:
//    KEIL MDK 4.0
//    .NET Micro Framework Porting 4.1
//    RedCow Board
//=====================================================================

 

     如果大家调试过NativeSample的话，会发现其启动方式和ARM建议的稍微有点不同。不过在说这个之前，我们先来看看ARM建议的CORTEX-M3的启动模式。

 

     对于CORTEX-M3而言，上电复位后PC指针指向的是地址0x0000 0000，ARM公司建议向量表（Vector Table）放置于该地址。对于STM32F10x来说，如果选择的是从FLASH启动，那么该FLASH则会印射到0x0000 0000。也就是说，只要我们的向量表放置的地址是出于FLASH的初始地址0x0800 0000，并且启动模式是FLASH的话，那么启动后PC指针指向的就是向量表。

 

     指向了向量表，那如何跳转到main函数呢？向量表的第一项指向的是Stack Top的地址，而第二项指向的则是main。当PC执政指向向量表的第二项时，接下来就会直接跳转到main函数中，如图：

 

     但.Net Micro Framework的NativeSample的启动方式就和此大为不同。FirstEntry.s是执行的第一个文件，而该文件却并不包含向量表。那么向量表在哪里呢？放在VectorsTrampolines.s文件中。而偏偏这两个文件编译时却不是在一起的，这个在相应的散列配置文件中就能够看出来，如图：

 

     换句话来说，以微软的这个散列文件编译出来的系统，一旦复位，PC指针指向的并不是向量表的位置，而是FirstEntry的初始值。更为有意思的是，在散列文件中指出VectorsTampolines映射到0x2000 0000位置，但实际上编译器不会帮你做这些事情。换句话来说，如果采用微软的散列文件，那么必须自己写代码来构造向量表。以流程图来表示，大概是这样：

 
     如果以微软的方式，那么在BootstrapCode之前的代码必须慎之又慎，因为这时候向量表是没有正常工作的，所以我们不能在此之前开中断。不仅如此，如果代码有误，引发的错误，由于向量表并没有构造完成，很可能会造成莫名其妙的结果。不过，微软在此之前的代码写得很精简，除非我们认为添加了代码，否则应该不至于会出错。

 

     当然了，如果你觉得微软的这个散列文件不地道，想以ARM建议的方式，用编译器生成向量表放在最初的位置，也不是不可以，只不过灵活性会稍微降低，特别是需要重新设置中断函数的情况下。如果各位对这种方法感兴趣，可以看我的另一篇文章：《修正STM32F103ZE的散列文件》（http://blog.csdn.net/norains/archive/2010/10/20/5954256.aspx）