Skip to main content
turboscrew
turboscrew
Senior III
June 3, 2019
Solved

Atollic TrueStudio stopped single-stepping

  • June 3, 2019
  • 4 replies
  • 1167 views

Any idea what could have happened?

I'm working with a small system: CubeMX, FreeRTOS, a couple of tasks. I debugged a task resume loop last week, and now I'm setting up another variant. Same processor, slightly different peripherals. Now that I try to single step through the loop - even if instructionwise, I suddenly jump into idle task. The loop is done within "atomic block", and there are no interrupts active. The system seems to run fine, though.

This topic has been closed for replies.
Best answer by turboscrew

The mystery seems solved.

The cause seemed to be copy-edit mistake, where bit was edited, but register was not.

First DBG_STANDBY and DBG_STOP bits were set in DBGMCU_CR, then DBG_IWDG_STOP was set, but in DBGCMU_CR, not in DBGMCU_APB1_FZ as it should have.

The DBG_IWDG_STOP-bit (bit 12) was "reserved" in DBGMCU_CR and it seemed to cause weird behaviour.

4 replies

turboscrew
turboscrewAuthor
Senior III
June 3, 2019

Forgot to mention, that the optimization is off (-O0) and basic debug level is used (-g).

Oh, and the Atollic is 9.2.0.

Bob S
Bob S
Super User
June 3, 2019

Just a wild guess - Did you change the debugger settings that halt system clocks when the debugger halts the program?

turboscrew
turboscrewAuthor
Senior III
June 3, 2019

I didn't change anything, but obviously something has changed.

I'll check that next. Thanks.

And any ideas are welcome.

turboscrew
turboscrewAuthor
Senior III
June 4, 2019

From bad to worse: I set a breakpoint in a FOR-loop, where the system stopped, but the loop index was a huge number, even if I set FreeRTOS the default stack size about 4-fold of that needed.

Atollic TrueStudio seems not to be very reliable... Although at the moment, probably a bit more reliable than CubeIDE.

turboscrew
turboscrewAuthorAnswer
Senior III
June 4, 2019

The mystery seems solved.

The cause seemed to be copy-edit mistake, where bit was edited, but register was not.

First DBG_STANDBY and DBG_STOP bits were set in DBGMCU_CR, then DBG_IWDG_STOP was set, but in DBGCMU_CR, not in DBGMCU_APB1_FZ as it should have.

The DBG_IWDG_STOP-bit (bit 12) was "reserved" in DBGMCU_CR and it seemed to cause weird behaviour.

Terms & ConditionsAccessibility statement