在创建移植工程时，我发现我需要创建一个基础环境，于是就顺手搭建了一个小的工程，简单到只有一个功能，就是运行systick，然后维护一个变量自加。结果发现，这个程序居然怎么都无法正常运行。
中断中的断点无法触发，变量不发生变化，我整个人都无语了，在网上查了很多资料，排除了debug的问题，boot引脚的问题，然后我做了一个尝试，将之前测试通过的源码拿回来，重新编译调试，这个时候出现了另一个奇怪的现象，中断中的断点依然无法触发，但是中断维护的变量居然开始正常自加了。
我开始怀疑是跟工程配置有关，于是将自己的源码完全拷贝到这个新的工程下，然后注释掉原有的代码，发现也无法工作。
这个时候我开始去检查中断向量表，发现地址0x08000000开始的地址上确实有一些地址，而且我在这些地址上打下的断点也确实会被触发，说明整个中断向量表的机制是正常的，但是很奇怪的是这些中断向量表中的地址都不是我创建的函数的地址。于是我怀疑是否是IAR编译器的问题，是否它在识别weak标识的时候出现了问题呢？于是我又试着卸载了IAR软件并重装，然而问题依旧。
这个时候我已经无奈了，于是我打算对中断向量表的地址创建过程进行详细的了解，在《cotex_m3 m4权威指南》里，看到了这么一段话：
于是我打开了IAR的option-linker选项，发现里面有一份.icf的文件，打开这个文件所在的文件夹以后，发现这个文件路径下，还存在另一个GD32F405的文件，我对比了两个文件的区别，发现他们的中断向量表的地址和ROM区域的起始地址是不同的，我瞬间意识到我可能知道问题的根因了。
于是我试着加载了一下另一个icf文件，程序立即运行正常了，断点也正常触发了，重要的是我在flash地址区域上明显看到一个标志：vector-table，而之前我从来没有看到过。
在错误的配置文件中，我的中断向量表和flash的起始地址都修改成了0x0802000，而这个地址的修改需要与vtor中的偏移匹配起来的，但是我却没有在程序中去做这个偏移，于是就导致了，程序依然是从0x08000000的位置去获取中断向量表。
同时由于我从别人那里拷贝过来的代码里包含了之前的flash地址空间的二进制代码，IAR在编译的时候，没有去修改这部分的代码。在这份代码中，运行的是对中断调用函数的汇编代码，其中变量是通过PC偏移来实现的，而当代码的修改不涉及到变量地址的变化时，那段代码的汇编指令运行过程中会产生将内存地址修改的效果。于是就会产生，断点打不进去，但是却可以看到变量生效的现象。