困扰了我很久的TIM1时钟走慢的问题终于找到原因了

Alexkey · 发表于 2011-7-29 12:57:45

在使用STM32的过程中，经常发现TIM1定时器莫名奇妙的走慢，以前一句一句的查看代码，怕晶振没起振，拿示波器看，都没有发现问题，但TIM1就是走慢了，后来只能尽量避免使用TIM1，今天再次下定决心要找到原因，最后终于发现是MDK的优化造成的。
如果默认使用Level 2 (-O2)优化级别，勾选Optimize for Time 和One ELF Section per Function ，TIM1就会变慢很多，其他定时器都正常。
使用Level 0 (-O0)优化级别，勾选Optimize for Time 和One ELF Section per Function
或者使用Level 2 (-O2)优化级别，只勾选One ELF Section per Function ，则TIM1能正常工作，目前虽然能解决问题了，但是还没有仔细研究不同的优化之间的区别，到底编译器把哪部分代码给优化掉了，才造成TIM1定时器走慢呢，这个还有待进一步研究，现在要忙手头上的项目，暂且先放一放吧。

j-link · 发表于 2011-7-29 13:09:26

STM32F10x_StdPeriph_Driver 换新版

旧版都使用 u32 或 u16
新版已经改 vu32 或 vu16

Alexkey · 发表于 2011-7-29 13:16:46

不是一楼所说的问题，我用的是3.5.0版本的库

gwdong · 发表于 2011-7-29 13:55:28

听起来似乎MDK在作弊...它把TIMER调慢了好显示在TIMER计数了相同的计数时它优化的代码做了更多的事情....

money_2011 · 发表于 2011-7-29 14:00:37

唉。。。怎么现在的工程师水平越来越差。timer走慢还会与程序优化级别人关。有脑子想想就知道是自己没用对才出这种问题。

j-link · 发表于 2011-7-29 15:23:33

回复【2楼】Alexkey
不是一楼所说的问题，我用的是3.5.0版本的库
-----------------------------------------------------------------------
现在好像是 V4.4.0

Mleaf · 发表于 2011-7-29 15:39:38

标记一下

Alexkey · 发表于 2011-7-29 16:09:42

4楼，你说话有没有根据，我这个是有根据的，不同的优化选项，编译出来的hex文件本来就是有区别的

money_2011 · 发表于 2011-7-29 16:15:10

芯片的运作是逻辑化的，它严格按着寄存器的配置工作，你认为变慢了就是寄存器的配置值没对。好好检查一下吧。keil有着很好的查看功能。别认为世界只有你一个人用芯片，别认为ST公司或keil是垃圾公司。

121212 · 发表于 2011-7-29 16:19:04

要查汇编了。

同情lz，这事情要是4楼碰到也不一定能知道怎么回事情。心静下来还是看汇编，虽然很痛苦的说

Alexkey · 发表于 2011-7-29 16:23:51

再次确认，最新版本的固件库就是3.5.0，不存在什么4.4.0

Alexkey · 发表于 2011-7-29 16:34:14

我为什么说困扰了很久，就是因为仔细查看了RCC，TIM1的每个寄存器的配置，确认了硬件和软件没有问题，我也确认了TIM1的内部时钟就是72M，而且我开发了很多产品，并不是所有的都有这个问题，就算是在开发过程中，也是有时是正常的，有时不正常，今天再次比较了正常的程序和不正常的程序，发现代码是一样的，唯一的区别就是优化选项不一样。我只相信客观的事实，这才是工程师应有的态度，MDK不过就是一个工具，我也没有说MDK很垃圾，只是想告诉大家使用的时候要注意的事项，不想再跟你争论，请就此打住。
我发这个帖子的目的也是为了做个记录，以后要是遇到同样的问题，我就知道原因了。

money_2011 · 发表于 2011-7-29 16:55:25

唉。。。

你比较两个程序区别干嘛。
你要做的是运行程序，然后看看tim1的寄存器的值的区别，看哪个寄存器的值不同了。
而不是关注着优化改变了哪里。

你或者可以看着不能正常工作的程序运行后寄存器的值，对照资料看哪里出错了。
这种问题一会儿就能处理掉。

Alexkey · 发表于 2011-7-29 17:02:43

money_2011，要买个动车票给你坐坐么

money_2011 · 发表于 2011-7-29 17:29:38

好啊。记得买高铁的。留个电话，下次要坐时让你代买。

说哪么多，是要批驳你散播不正确的解决问题思想。有事没事就先怀疑芯片，怀疑工具有问题。
这就是菜鸟的表现。看到不少贴子就是这样，难道新生代的工程师就这鸟水平，不是指技术，是指态度。

Alexkey · 发表于 2011-7-29 18:24:34

真是无语了，还新生代，TIM1的每个寄存器的每一位我都研究过了，要是没有相当的调试手段我根本就得不出这个结论，你以为用个jlink单步执行一下程序，看看寄存器的变化就能把所有问题都解决了？程序在全速执行的时候跟单步执行是不完全一样的，仿真工具能给调试程序带来方便，但很多时候只会把问题掩盖掉，经常发生的事情就是单步跑程序是对的，全速跑程序就不对了。
我说的这个现象，是可以完全重现的，同样的程序不同优化级别编译出来汇编代码是完全不一样的，你在这跟我扯什么寄存器，你懂不懂哦，上面已经有人提到了要查看汇编代码，我只是说现在没时间，已经知道是编译器把部分不该优化的代码给优化了，只是我还没找到是哪一部分，你在这跟我瞎扯什么呀，自己水平差还以为别人水平都差，08年STM32刚出来的时候我就开始用STM32开发项目了，STM32的参考手册我都快背下来了，自己水平菜还不谦虚。
我不自认为自己水平有多高，但至少遇到的所有问题我都通过各种手段查到了原因，并解决了问题，你在这扯来扯去的，这问题丢给你，你倒是给我解决看看，真是莫名其妙！

kevin_ares · 发表于 2011-7-29 18:37:02

我也被优化害过.....

毕竟电脑不是人,它优化是根据规则来的,所以有可能得到不想要的效果

别理那个 money_2011

明显是没做过复杂东西 ,只会夸夸其谈想当然的

不过也要检查一些变量是不是加上了volatile

hetao7241 · 发表于 2011-7-29 18:49:44

个人觉得主要检查变量，我现在写程序，60-80K，程序上分模块，我把局部变量和全局变量分得很清楚的，否则容易出错。

我曾经优化也优化掉近6-7K，但是程序正常运行，没有仔细分析过内部怎么优化的。

yinqiu009 · 发表于 2011-7-29 18:56:56

回复【16楼】kevin_ares
-----------------------------------------------------------------------
兄弟，你要不加"不过也要检查一些变量是不是加上了volatile "，我就要拍你了。
你那根本不是被优化等级害了，你是被自己害的，好伐？

另外money_2011 说的很对。
从我从业至今，我没有找出过任何一个芯片的bug，也没有找出过任何一个工具的bug。很多次我都以为我成功的发现了它，但是慢慢都被时间证明是我自己的理解错了、看资料不仔细或者超常规使用造成的。
另外说句题外话，我对高度依赖仿真器持排斥态度，特别是基于多级流水线的高级cpu上，只要串口及其他输出信息端口打通，我就会停止使用仿真器调试后面程序。

hittiger · 发表于 2011-7-29 19:58:32

定时器应该没有走慢，可能是你程序里调用的函数什么的可能由于优化，没有执行，所以你觉得慢了。通常优化时加入 volatile

TigerRay · 发表于 2011-7-29 20:05:11

其实前些时间我也遇到一样的问题，程序优化后还是有一些影响的！具体要看你做什么！
我遇到的情况是，写的程序是一样的，用的优化级别不一样，最后得到的结果也是不一样的！

kevin_ares · 发表于 2011-8-9 11:01:08

回复【18楼】yinqiu009
-----------------------------------------------------------------------

从我从业至今，我没有找出过任何一个芯片的bug，也没有找出过任何一个工具的bug。很多次我都以为我成功的发现了它，但是慢慢都被时间证明是我自己的理解错了、看资料不仔细或者超常规使用造成的。
另外说句题外话，我对高度依赖仿真器持排斥态度，特别是基于多级流水线的高级cpu上，只要串口及其他输出信息端口打通，我就会停止使用仿真器调试后面程序。
-------------------------------------------------------------------------

还是那句话,没做过复杂东西的人喜欢想当然,
不然也不至于连什么叫"勘误手册"都不知道,

要么你用的芯片少得可怜,要么这些厂商出勘误表都是多此一举

再说,优化这是一个电脑根据规则进行的一种动作,
在复杂的情况下,他可能进行一些与写程序的人的意图相异的动作
这也是为什么人工智能不能代替人来写程序的根本原因
规则都是对的,得到的却不是你要的结果

算了,浪费口水

yinqiu009 · 发表于 2011-8-9 12:15:55

回复【21楼】kevin_ares
回复【18楼】yinqiu009
-----------------------------------------------------------------------
从我从业至今，我没有找出过任何一个芯片的bug，也没有找出过任何一个工具的bug。很多次我都以为我成功的发现了它，但是慢慢都被时间证明是我自己的理解错了、看资料不仔细或者超常规使用造成的。
另外说句题外话，我对高度依赖仿真器持排斥态度，特别是基于多级流水线的高级cpu上，只要串口及其他输出信息端口打通，我就会停止使用仿真器调试后面程序。
-------------------------------------------------------------------------
还是那句话,没做过复杂东西的人喜欢想当然,
不然也不至于连什么叫"勘误手册"都不知道,
要么你用的芯片少得可怜,要么这些厂商出勘......
-----------------------------------------------------------------------
你的这个回复充满了臆想、猜测和攻击，你吐的真的是口水。
只要写入到勘误手册里面的东西就不能算是bug，而是芯片的缺陷，用户必须规避对应的缺陷，更不能算你发现的bug。
如果你个人先于勘误手册发现的新问题，并且提交给厂家加入下一版本的勘误手册里面，这个才算发现了bug。这样的事你完成过？
“做过复杂的东西”，这个话你说过几次了，咱能不能不这么搞笑啊？

xtx8962 · 发表于 2011-8-9 12:23:38

我也被优化害过一次，呵呵

kevin_ares · 发表于 2011-8-13 22:30:57

回复【22楼】yinqiu009
只要写入到勘误手册里面的东西就不能算是bug，而是芯片的缺陷，用户必须规避对应的缺陷，更不能算你发现的bug。
如果你个人先于勘误手册发现的新问题，并且提交给厂家加入下一版本的勘误手册里面，这个才算发现了bug。这样的事你完成过？
“做过复杂的东西”，这个话你说过几次了，咱能不能不这么搞笑啊？
----------------------------------

哈哈,看来大家以后可以跟客户说,那叫缺陷,不叫BUG,你们必须规避,

还是那句,没做过复杂东西不要在这 "臆想、猜测和攻击"

优化造成的问题不是一个volatile 那么简单的

zouyf12 · 发表于 2011-8-13 23:34:07

还没有出过这种问题。但是我也觉得TIM走慢和优化等级没关系吧。至少TIM模块走时的快慢只和自己的配置寄存器有关，个人同意19楼的看法，估计是你程序里有操作TIM的操作，然后优化把你那句给干掉了，没有及时操作，到时TIM走慢，这个是可以理解的，51的定时器就可以弄出这样的效果。归根结底还是你程序的问题，有些地方表示不清楚，让编译器自作聪明。

rita · 发表于 2011-8-14 00:16:23

楼主可以弄个你的程序tim核心程序加少少输出指示（点灯），减少不必要的程序，看看不同优化有什么不同？一步步分析编译器是优化什么地方~~否则大家谁也说服不了谁，大家都是从自己的经验出发的

solidsky · 发表于 2011-8-14 11:25:08

4楼开始的表现就是认定别人是菜鸟。但是，优化可以导致程序运行结果改变，这是常识。我很奇怪，4楼写过多少代码？就没碰到过优化导致的问题吗？反正我碰到过不少。大多数后来都找到原因了，但其中一个2个星期找不到原因，反映到MSDN上后，有人说那是微软已经确认的Bug（这个很有意思，Debug版程序崩溃，但Release版没有问题，区别仅在于链接哪个库）。

LZ说的话很简单：开启优化后运行结果改变。由于时间原因没有找到具体的原因，但至少关掉优化可以凑活工作。找原因也要从对比优化前后代码入手。有了LZ的这个帖子，至少说明了，如果将来碰到定时器走慢了（或走快了），可以试着调整一下优化等级，花不了2分钟时间，但也许能节省几天甚至几个星期的时间。如果不能认识到这一点，一头扎进自己的代码和手册里，花费多少时间都无法解决问题。

24楼说的好，优化造成的问题不是一个volatile 那么简单的。编译器和系统库的Bug是非常少的，但编译器和系统库的“奇怪行为”却并不是那么少见。如果肯花时间，总能为这些“奇怪行为”找到解释。但是很多时候我们没有那么多时间，简单的将其避开也是个不错的选择。如果性能要求不高，干脆不进行优化不失为一个安全的选择。

victor275 · 发表于 2011-8-14 16:13:55

mark

Achin · 发表于 2011-8-17 13:26:30

优化和编译器本身的Bug会害死人，mdk4.12和mdk4.21编译同一个完全没差别的程序，生成的code，执行结果不一样。平台是lpc2478。
ps工程配置什么的，都是完全一样的。

vacd · 发表于 2011-8-17 17:05:05

这个帖子中的争论让我这个菜鸟也学习到很多东西。楼主把自己的经验分享出来很值得赞扬，我个人认为即使是错误的，大家进行抨击，也是好的，互相学习嘛，何必面红耳赤

lxd_youxi · 发表于 2011-8-17 20:57:27

赞同27楼！前段时间也遇到tim1走慢的问题，后来改用tim2了，工作时间紧，还没来的急查找原因呢！
感谢楼主提供一个解决方法，等有时间再好好研究！

xiangxiaowei · 发表于 2011-8-17 22:22:31

还没遇到过呢，试试看如何

Ian11122840 · 发表于 2011-8-17 22:52:46

有吗！？
一直觉得tim1挺准的飘过…

ahfong2006 · 发表于 2011-8-17 23:17:12

真的有吗？是不是TIM1 寄存器被改变或者被不改变了呢？优化能改变你的程序不按照你原来意图行事我相信，能让TIM1变慢真的很难理解，希望ST的FAE也能来分析一下

heky · 发表于 2011-8-17 23:25:49

stm32的timer1，2，3，4都经过深入使用。lz你怀疑的话可以用逻辑分析仪等工具好好查一查。有没有代码使用的例子，我帮你看看也没关系。

shdjdq · 发表于 2011-8-18 08:06:28

能不能指定某个函数优化？在程序里加上某个语句？

wxx116zh · 发表于 2011-8-18 08:36:21

菜鸟学习了。

cbeeee · 发表于 2011-8-18 08:39:29

如果是对比汇编代码能够分析出不同来那就是优化的问题了。
这问题该赖谁呢？要么赖你没有按严格的标准写代码，要么赖编译器的优化功能。
一般人都喜欢赖后者，当然其实其中大多数其实是因为前者造成的。

另：先于errata发现哪个芯片的bug的事情我还真没碰到过

visharn · 发表于 2011-8-18 08:43:56

我觉得优化不会导致你所说的问题，你先自己检查一下把。

visharn · 发表于 2011-8-18 08:47:50

优化可能会让编译器不给局部变量分配空间，直接分配寄存器，所以你看到的值都是不准确的，但是运行结果正确。

优化可能会让程序执行时间变短，导致一些硬件时序被破坏。

优化可能导致全局变量在外部被更改后，不能被函数发现。

优化可能使一条语句直接被优化没了。

解决优化后变量问题的一个解决方法是在变量声明前面假如 volatile关键字，指明该变量不优化。

关键是自己的代码一定要够强壮

xingliu · 发表于 2011-8-18 09:51:23

我觉得这个优化随着CPU越来越快，渐渐的会不需要优化。
所以我一般都不选择优化，优化后麻烦很多。花些时间去找这个错误很累。
宁愿多花点钱，用好一点的CPU。

qwerttt · 发表于 2011-8-18 11:17:57

不知为什么要研究MDK的优化，到底是为了节省空间还是节省时间
还是说写的程序不合理，所以要使MDK优化

说TIM1时钟慢的，那怕真的是优化导致，
慢了多少，有没量化的解释

如果我说优化后TIM1快了，你们信么？呵呵不管你们信不信，反正我信了

huatong · 发表于 2011-8-18 12:16:13

末试过这种问题,或者楼主发个工程出来给大家试试?

shdjdq · 发表于 2011-8-18 13:15:23

优化是快不少。我选了Level 1比Level 0快了很多，代码也少不少。前提是，把U16或u32全改成vu16,vu32。

clingos · 发表于 2011-8-19 09:29:46

一般不使用优化！只相信自己的飘过！

xfdr · 发表于 2012-12-6 22:00:42

yinqiu009 发表于 2011-8-9 12:15
回复【21楼】kevin_ares
回复【18楼】yinqiu009
---------------------------------------------------- ...

有时候用串口把一些要查看的变量发回来，也很方便的

eehong · 发表于 2012-12-16 21:51:41

这帖子的火药味很浓啊，都是讨论，淡定点哈

lkl10800139 · 发表于 2012-12-17 08:56:06

我用stm32f4的 TIM3 ,程序是移植官方的 C 例程，没有看汇编，也不会看.今天看到楼主发的帖子,做了测试，优化级别不同，计时效果不同。

xjtyOnly51 · 发表于 2013-12-6 10:53:13

mark, thanks

ourdemo · 发表于 2017-7-12 18:33:13

这个问题也困扰我一周，没在线调试真不容易发现问题

3050311118 · 发表于 2017-7-12 20:19:51

攻城狮不能想当然，也不能说一定。凡事都有可能

AVRTDK · 发表于 2017-7-12 21:51:57

一般不使用优化！

lingdianhao · 发表于 2017-7-12 22:35:05

重来不用优化的路过。

hefq · 发表于 2017-7-12 23:01:27

从来都是开最高等级优化,

ljy99731 · 发表于 2017-7-12 23:02:15

定时器就那几个寄存器设定，编译器不会傻到把寄存器设置也优化吧？

hd12 · 发表于 2017-7-13 00:23:52

从来都是开最高优化，有几次也是发现开最高优化会导致程序不正常，开低就好，最后证明是因为优化后有些程序执行太快，而导致后面时序或配置等待时间不够，配置的信息不够时间更新进去。相信不是因为优化导致程序出错，而是某些细节没注意到，导致的优化后的程序没按自己意图一步步执行

myxiaonia · 发表于 2017-7-13 08:25:58

从来都是O3优化的路过，有时在调试阶段O3优化会打乱程序顺序不方便调试，改成O2或者O0，调试好又改成O3的

如果用寄存器编程，一般是不太可能出现被优化掉操作的问题，因为，这些寄存器在定义时都被正确的增加volatile标志

但是用库的话就未必了，库函数内部有很多花样，未必会直接操作寄存器，如果不熟悉参考手册的话很容易就掉坑里了

RAMILE · 发表于 2017-7-13 09:04:23

也遇到这个问题，，全局时钟都慢了

beihai326 · 发表于 2017-7-13 09:30:47

是不是芯片问题？我也有开编译优化，没发现这样的问题

xld826 · 发表于 2017-7-13 12:07:14

吓死宝宝了，还好宝宝用定时器习惯性不用TIM1

OneRain · 发表于 2017-7-13 15:28:23

重来都是开最高优化的路过！！！！你要说优化可以是程序时间执行变慢或者快，还可以相信，但是Time是硬件！！！除非硬件出现问题，否则不可能变慢！！！！当然了正如58楼所说的，使用库开优化的时候，或许某些时间配置没有按照自己的意思来！！！！

困扰了我很久的TIM1时钟走慢的问题终于找到原因了

阿莫论坛20周年了！感谢大家的支持与爱护！！