Debugger stuck on random line

Adrian Adamson · ‎2020-01-25

The debugger is getting stuck on a random line about 350 lines into main(). There is nothing particular about this line of source code except its location, because if I comment out that line it just stops on the next one, and if I add a line it stops earlier. When the debugger is not active, the source runs just fine without stopping in that area. I have deleted all breakpoints and watchpoints. I have set the optimizations to "off". When the debugger is stuck on that line, its status is "running."

This is my first time debugging this project after converting from TrueStudio. I may need to switch back if I can't find anything else to try.

Any suggestions?

Markus GIRDLAND · ‎2020-01-27

I would double check that you're debugging what you think you're debugging by mass erasing the target and flashing the code again.

If it doesn't help then if you could enable GDB traces it might help you diagnose the issue.

It's enabled through Windows -> Preferences -> C/C++ -> Debug -> GDB -> Enable GDB traces with character limit:

Adrian Adamson · ‎2020-01-27

Good suggestion, I have tried debugging the wrong target before. However in this case that wasn't the problem.

I have had a similar problem starting a couple of weeks ago that seemed to be source-dependent (https://forum.atollic.com/viewtopic.php?f=6&t=1966&p=4738#p4738), so I tried reverted to a slightly earlier build, and for now it is debugging fine with STMCubeIDE.

My previous problem was that when running the debugger, it would get stuck on a line in the load process, or would get stuck on the first main breakpoint. Nothing worked except making small, unrelated changes to the source. I suspect that whatever this problem is, it is still lurking. I'll update if it comes back. Thanks for your help.

waclawek.jan · ‎2020-01-27

You did not tell us which mcu.

Single-step in disasm. Then look at around the place where it gets stuck, in conjunction with the content of related registers.

JW

Adrian Adamson · ‎2020-01-28

Jan,

The MCU is the STM32L082. I haven't done much of anything with assembly before, but that sounds like a good idea if/when this pops up again for me.

-Adrian

Ozone · ‎2020-01-28

>... or would get stuck on the first main breakpoint. Nothing worked except making small, unrelated changes to the source.

This might be related to issues in the startup code before reaching main (data initialization & clock setup).

Besides of the mentioned hints, disable any "Run to main" setting to check the startup.

Adrian Adamson · ‎2020-03-25

The problem popped up again for me today, after being gone for months. Yesterday I accidentally added too many breakpoints once, and ever since then the debugger is getting stuck on random lines. I have removed all breakpoints and the problem persists. I also tried checking out a previously working version of source code, and I'm getting the same problem but at a different place in the code. I'm currently looking for how to single-step in disasm, but considering how previously working builds are getting stuck in debug now, it seems like there is something about the gdb debugger configuration that is messed up. I'm tempted to de-install and re-install the IDE. First I will try changing debug adapters.

Pavel A. · ‎2020-03-25

Have been with similar behavior several times.

Advises vary from doing full chip erase to rebuilding Eclipse workspace.

Yes, I can confirm this often correlates with setting too many breakpoints.

In this state disassembly/instruction step mode does not help. I click step, and PC just won't move.

-- pa

waclawek.jan · ‎2020-03-26

Maybe this is result of the debugger trying to be overtly smart, hiding its action from the user.

There are just so many breakpoints supported by the on-chip debug interface (these are usually called "hardware breakpoints"). The IDE might want to use so called

software breakpoints, i.e. replace the instruction where you want to break by BKPT instructions; and then put back the original instruction when trying to proceed. This is relatively simple when program runs from RAM, but awfully complex if not impossible when running from FLASH, potentially leading to "funny" results.

Disable "software breakpoints" in your IDE, if possible - it will bark at you when you'll try to use too many breakpoints, but that's maybe better than unexpected behaviour.

I loathe eclipsoids so I can't help you with the particularities of those.

JW

Uwe Bonnes · ‎2020-03-26

Does some WFI or (deep) sleep interfere perhaps?