ADuC7023在keil uVision5环境下,程序优化导致进入异常中断(ADuC7023 in the keil uVision5 environment, program optimization leads to an abort.)

ADuC7023在keil uVision5环境下,程序优化导致进入异常中断。

在keil中选择优化等级(Optimization)为等级2(level 2(-O2))或等级1(level 1(-O1))时,芯片在长时间运行过程中(包括IIC通讯)会出现定时器0(time 0)不工作情况。增加异常中断后,调试发现会进入DAbt_Addr或PAbt_Addr中断。

将优化等级设置为等级0(level 0(-O0))时,则不出现进入异常中断的情况。



ADuC7023 in the keil uVision5 environment, program optimization leads to an abort.

When the optimization level (Optimization) is selected as level 2 (level 2 (-O2)) or level 1 (level 1 (-O1)) in the keil,  the timer 0 will not work during long-term operation ( including IIC communication ). After adding an abort,it will enter the DAbt_Addr or PAbt_Addr interrupt.

When the optimization level is set to level 0 (level 0 (-O0)), no abnormal interrupt is entered.

I would like to ask, what causes the abrupt interruption of DAbt_Addr or PAbt_Addr? Does the compiler have a high probability of optimizing the program to cause an address overflow?
Thank you!

  • 0
    •  Analog Employees 
    on Feb 28, 2019 9:24 AM


    In general, for these type of issues, it is not that the compiler optimization is breaking anything. Typically, it is that there is an issue in their code and they are “getting away with it” with the lower optimization.

    Things are slower, happening at a different time or the RAM usage is different….something is different.  The optimizer is not doing anything to break it. It is extremely unlikely to come across an issue that could be blamed on the “compiler” or on the “optimization” in a mature toolchain.

    You can check the memory allocated to the stacks in the system. In the absence of any other information, it is generally stack corruption to check first that causes this type of abort…the stack has spilled over into the space that the variables are located, the interrupt modifies a variable which contains a return value or pointer….crash happens when this is accessed later.

    A good tip to zone in on whether it is a stack issue is to initialize the RAM where the stacks are located with a known and recognizable value. You will be able to recognize how deep the stacks went to by looking for the pattern after the program has been running for a while. There should be some remnant of that pattern still present at the bottom of the stack. If it has been changed, then your stack has overflowed. If this has happened, then something will have been corrupted, and depending on what was corrupted, a data abort will result.