看反汇编比对，或者试试 bindiff。

真是见鬼了。。。
没办法，重建的没发弄，我就在原有的工程上改分组、该文件路径，发现一点一点的改（改点编译一下，一点一点的来），发现竟然程序正常了。
这时悲剧了，一不下心keil挂了，重新打开改的都没了。然后，我又按照这个重新改一次，只不过这次我是一次改完的，然后编译下载，又tm挂了。。。
此时此刻心里无比的悲愤！！！
没办法又重新一个一个文件的加，一次一次的编译测试，知道全都改完，ok正常。
此时此刻，心里万马奔腾。。。三天时间就这么过去了，我还真以为程序问题去仿真测试。。。

新发现，改变工程分组的顺序，编译出的结果会不同

security 发表于 2016-8-3 16:24
首先，祝贺一下
其次，不明觉厉
LZ 可否再详细说明一下，例如贴一些代码片段 ...

这个问题代码不重要，详情是这样的：
系统使用了os,但是os启动前有一段配置信息的代码，而该代码里定义了一个比较大局部变量。该段代码的堆栈分配在.s里（指向msp的堆栈段，与中断共用），该空间只分配的512字节。
那么问题来了，局部变量就接近400多字节，堆栈不溢出也是接近溢出的边缘。
以上都是知道原因后的分析。

其中，这个分析的过程可能是最痛苦的，一段本来没问题的（可能藏有隐患）代码，突然因为重建工程或者只改变文件的排列顺序，然后就变得不能用了。这是件很莫名其妙的事情，一
开始我是埋怨编译器的，然后想方设法恢复之前的样子。但结果不理想，恢复是恢复了，但是调整文件顺序的时候问题复现了，所以我觉得这个问题必须正视，且正面解决。先设法找到
程序崩溃的位置（1猜2屏蔽 ），发现有个指针被篡改了，然后就开始仿真，一步一步的找篡改的位置。第一次找到一个调用printf的位置（比较奇怪当时没想通），然后屏蔽，却发
现还有。第二个位置是一个函数嵌套，此时此已经猜得八九不离十了，这个问题肯定是堆栈溢出！！！然后，屏蔽了那个大局部变量，bug就没了，此时皆大欢喜。

最后，整理了一下思路，显示把大局部变量改为静态的，然后把配置信息的代码放在了系统任务里，写了一个启动任务，这样系统启动前只有驱动初始化，msp段堆栈的压力就小了很多。
这样的好处也很明显，使用系统的堆栈段，调试比之前方便。

库设置看看

mcu5i51 发表于 2016-7-28 14:51
库设置看看

只使用了cmsisi，两个版本一样的