I am debugging Cortex M0 ARM with a cross compiled GDB on windows, connecting to my target with Segger J-Link. I am able to attach debugger and automatically reset/halt/restore my image to the device RAM on debugger attach with a GDB init file.
My init file also set the PC to the start of my init code (function _start()), which uses constants defined in my linker script to zero out the BSS section in RAM, then it calls main().
If I step once the debugger comes up in this state, the debugger takes off instead of stepping into my code. I can then pause the execution and start stepping without issue, although at that point it's way beyond where I want to step through execution.
I can also set a breakpoint past the init code (in my GDB init file... at main()), then when the debugger comes up, click "play", it runs to the breakpoint and then I can step without issue.
I just can't step from that initial starting point (_start()) without the debugger "taking off".
I turned on debug logging and see where I try to step and the debugger takes off. I see:
GDB handle_event: *stopped,reason="end-stepping-range",....
then immediately I see:
GDB session: RESUME
GDB resume: START, timeout=0
GDB resume: sending -exec-continue
GDB send: command-exec-continue
Anyone have any ideas why this is happening when all I want is to step?
If I call my GDB exe from the command line and step using the same GDB ini file (without the breakpoint at main()), I can step instruction (si) without issue and step through the entire init sequence. Using the SlickEdit debugger gives different behavior.
Thanks for any ideas or suggestions.