cancel
Showing results for 
Search instead for 
Did you mean: 

Debug does not stop on breakpoint when timer interrupt frequency is high, how to fix it?

itsrabbit
Associate II

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:

  • CubeIDE 1.16.1
  • STM32F746 Discovery board.
  • TIM1 interrupt enabled and interrupt period is 1MS. (ARR = 21600-1, PSC = 10-1)
  • I change my OUTPUT pins connected to inputs on same board with some delays (delays are between 100 and 1000 ms)
  • Try to see the variables on debug mode after pin changes.
  • There is a state machine working on interrupt routine.

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Bob S
Principal

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.

View solution in original post

2 REPLIES 2
Bob S
Principal

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.

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.