2019-06-03 9:48 AM
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.
Solved! Go to Solution.
2019-06-04 8:59 AM
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.
2019-06-03 9:57 AM
Forgot to mention, that the optimization is off (-O0) and basic debug level is used (-g).
Oh, and the Atollic is 9.2.0.
2019-06-03 1:37 PM
Just a wild guess - Did you change the debugger settings that halt system clocks when the debugger halts the program?
2019-06-03 2:08 PM
I didn't change anything, but obviously something has changed.
I'll check that next. Thanks.
And any ideas are welcome.
2019-06-04 3:59 AM
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.
2019-06-04 8:59 AM
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.