2022-10-18 04:58 AM
Hello dear ST community,
I am working on ST boards for a while. However, this is my first time on community questions, sorry for any mistakes.
Facts:
Problem:
While trying to see variable values, I put breakpoints in while() loop. However, if the interrupt frequency is as high as 1000 Hz, my debug mode stops in breakpoints and when I click resume debug stays in same breakpoint and nothing changes. But when I remove breakpoints and resume, code flows correctly (I can see values changing if I stop run or remove and put debug points).
When IT frequency is low as 1, 2, 5... Hz I can see debug stops on breakpoints and resumes.
Thoughts:
I am thinking that, high frequency of TIM IT is causing very fast interrupts that cannot be caught in debug mode. Or running a state machine instead of just simply changing any flags in IT can cause IT process took so long.
More Detailed:
I have watched TIM1 status register -> Update Interrupt Flag and UIF cant be seen as 0 when problem is on. It is somehow not cleared or can not be visualized in debug mode because of the speed.
I would be appreciate if you could help!
Have a great day.
Solved! Go to Solution.
2022-10-18 10:21 AM
There is a single step bug in some M7 cores. See https://community.st.com/s/question/0D50X00009XkgAOSAZ/problem-with-single-step-stmf7
The answer is usually to use a Segger and Keil debugger as those have work-arounds built in to them. I don't know if the newer STLink V3 also have that fix.
2022-10-18 10:21 AM
There is a single step bug in some M7 cores. See https://community.st.com/s/question/0D50X00009XkgAOSAZ/problem-with-single-step-stmf7
The answer is usually to use a Segger and Keil debugger as those have work-arounds built in to them. I don't know if the newer STLink V3 also have that fix.
2022-10-19 12:56 AM
Thank you for information, at least I understand the problem.I am not able to use Keil debugger due to lciense issues. It seems like there is nothing I can do on that but expecting ST to fix that bug.