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.

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.