• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 23 subscribers
  • Views 1236 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AC6 O3 Optimization while(capture_number!=2) Infinite Loop

w t
中文：我发现一个问题，当开启O3优化的时候，此代码【while(capture_number!=2){}】，capture_number在定时器中断中自加，当capture_number等于2的时候会死循环，不会往下执行。
我修改为【while(capture_number!=2){gpio_bits_write(GPIOB, GPIO_PINS_0, TRUE)；}】当capture_number等于2的能正常运行后面的程序
当开启O0优化的时候，此代码【while(capture_number!=2){}】，capture_number在定时器中断中自加，当capture_number等于2的时候程序可以正常退出循环继续往下运行
I found an issue where when O3 optimization is enabled, this code [while (capture_number!=2) {}] adds capture_numbers during timer interrupts. When capture_numbers equal to 2, it will loop and not continue to execute.
I modified it to [while (capture_number!=2) {gpio_obits_write (GPOB, GPIO-PINS0, TRUE);}] When capture_number is equal to 2, the subsequent program can run normally
When O0 optimization is enabled, this code [while (capture_number!=2) {}], capture_numbers add themselves in the timer interrupt. When capture_numbers are equal to 2, the program can exit the loop normally and continue running downwards
Parents
  • 0 Arm Employee Badge in reply to w t

    Because the compiler does not know that value of capture_number can change on external event (interrupt), so it presumes it's value will not change unexpectedly.
    You can check disassembly code to see what the compiler did, sometimes it will even throw out the code if it thinks it does nothing.

Reply
  • 0 Arm Employee Badge in reply to w t

    Because the compiler does not know that value of capture_number can change on external event (interrupt), so it presumes it's value will not change unexpectedly.
    You can check disassembly code to see what the compiler did, sometimes it will even throw out the code if it thinks it does nothing.

Children
No data