cancel
Showing results for 
Search instead for 
Did you mean: 

Atollic TrueStudio stopped single-stepping

turboscrew
Senior III

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 discussion is locked. Please start a new topic to ask your question.
1 ACCEPTED SOLUTION

Accepted Solutions
turboscrew
Senior III

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.

View solution in original post

5 REPLIES 5
turboscrew
Senior III

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
Principal

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

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

I'll check that next. Thanks.

And any ideas are welcome.

turboscrew
Senior III

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
Senior III

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.