Debugger stuck on random line

[Adrian Adamson]

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]

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]

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.

[Ozone]

>... 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.

[waclawek.jan]

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]

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

[Adrian Adamson]

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.]

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]

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

[Adrian Adamson]

I'm using the STM32Cube IDE, and stlink debuggers built into development boards. I agree that somewhere there is some hidden code/data that is causing the debugger to halt where it's not wanted.

I don't think software breakpoints are supported with my configuration, or where I would disable them if they were.

I can make a fresh project from CubeMX with the same Cube MX configuration, but when I move my source code into that fresh project and rebuild, the problem moves with it. And to reiterate, source code builds that used to run fine are now also subject to this problem. I just need to figure out where the corruption is and replace that part.

Also a key point is that a colleague can debug the same source code without problems.

[Uwe Bonnes]

Does some WFI or (deep) sleep interfere perhaps?

[Adrian Adamson]

Thanks for responding, but I'm only using a lower-clocked run mode when I want to save power, I'm not using sleep or WFI.

[Adrian Adamson]

My colleague pushed a new version of source code and .ioc file , I updated the CubeMX to the latest version, and magically, I can debug again. See you all in another few months, probably.

[Pavel A.]

Then it looks like the other case discussed here, where re-import of the project into eclipse workspace helped.

-- pa

[Adrian Adamson]

The phantom breakpoints came back. I tried changing my source code, but it's still stuck. I also tried using CubeMX to update the project file. Maybe I need to delete and re-install the IDE? Does anyone know in what file breakpoints are stored?

[waclawek.jan]

Some of the answers in https://stackoverflow.com/questions/7178096/eclipse-stops-at-non-existent-breakpoint or https://stackoverflow.com/questions/723199/why-does-my-eclipse-project-have-phantom-debugger-breakpoints won't help?

E.g. this one:

1. I opened breakpoint tab (you will see this if you are in debug perspective)
2. I saw there were two breakpoints enabled for the same line of code one of them was already unchecked but another was checked

JW