知道CU的牛人多，请教各位大牛，关于iAR编译器开“优化”选项带来的问题。

cobras

也许应用是动态加载也不一定。要不怎么用个变量来保存地址。

nicozhou

cobras 发表于 2014-04-17 17:07
也许应用是动态加载也不一定。要不怎么用个变量来保存地址。

谢谢参与！
appl_fixed_vector是指定program ROM上的一个4byte的地址（比如：0xBFFC-0xBFFF，这个是在link文件中定义的），这个地址存放的是appl的入口地址（编译appl的时候会把appl的入口地址放在）。

MCU是16位的单片机，非ARM

nicozhou

folklore 发表于 2014-04-17 16:31
回复 9# cobras

已经确认在这个函数之前已经关掉整个片子的中断了（晶振起振前）。应该不是因中断而起。

nicozhou

重复了，不能删，CU还是和6年前一样。

群雄逐鹿中原

folklore 发表于 2014-04-17 16:31
如果是字节序问题， 问题应该是会一直再现，而不是1/10000吧？

这是好思维，对bug有敏感的洞察力！

群雄逐鹿中原

这个问题，可能跟优化关系不大。

我合理怀疑下，比如 ---

优化时，程序跑的快，导致和时间敏感的部分出故障。
例如某些晶振还没来得及稳定，flash抓数据很偶然的出了错误。

不开优化，程序跑的慢，等到跑到楼主这段跳转的时候，一切都稳定了，于是不出问题。

还可以构造很多的可能性，就靠楼主的猜想和求证了。

这种鸟程序，不能以常理来度之。

我还碰到插个耳机时，程序乱跳转的情况。也是关了中断、单线程顺序运行，不可能有跳转的机会。
结果最后澄清，原因是硬件没设计好，耳机插入时，造成了短路，程序掉电重启了。
直接用仿真器和打印信息看，看到的就是乱跳转而已。

nicozhou

群雄逐鹿中原 发表于 2014-04-18 23:16
这个问题，可能跟优化关系不大。

我合理怀疑下，比如 ---

不好意思，回复晚了，谢谢！。

真得佩服你！能根据简单描述，指出这一点。

我们再次review了一下启动代码，也确实发现了这个问题。供应商给我们的参考代码，晶振稳定时间只有5个nop指令（内部晶振）。

我们现在高度怀疑这个时间不够（我们用的是外部晶振）。

昨天改好代码，让它跑个周末看看。

倘若不重现的话，客户还得要我们计算精确的代码运行时间，证明在晶振未稳定的时候操作flash会带来风险。

唉，但愿下周一过去，板子没挂，还是活的。

nicozhou

群雄逐鹿中原 发表于 2014-04-18 23:16
这个问题，可能跟优化关系不大。

我合理怀疑下，比如 ---

稳定时间增加到5ms，跑了一个周末没挂。
看来有效果。

hejianet

1.对比优化和不优化的asm语句
2.把可疑函数继续分隔成几个函数，分别优化+不优化

快乐的土豆

mark,有点意思。