- Mon May 25, 2015 3:33 am
#18374
Moin Angus,
thanks for the exhaustive answer!
I added my comments below!
[quote="projectgus"][quote="cal"]
How to you typically start a ocd debugging session?
Setting breakpoints upfront and then starting the hardware?
Calling into the debugger using a break op code?
Using some ctrl-c or break signal to interrupt the cpu?
[/quote]
If I'm debugging on a different platform, like ARM Cortex-M, I'll often run a 'reset halt' in openocd which resets the CPU and then halts it immediately after reset, PC still set to the reset vector address, before any instructions are executed. Once it halts you can set the breakpoints you want in gdb, and run 'continue' from gdb to get it to run.
Once the breakpoints are set, gdb will keep them set through future 'reset halt' cycles.
[/quote]
OK, thats similiar to the typical "start program and halt on main".
And - as you write below - the breakpoints will typically be set again by gdb on step/continue.
[quote]
Sometimes I'll press ctrl-c to randomly halt a running CPU 'now', if I don't understand what's happening (usually it's gotten stuck in an infinite loop somewhere).
[/quote]
Yes, thats a cool feature. I implemented that via serial break detection.
Will the ocd debugger set you at the position where your code runs or stop in the CTRL-c handler? [quote]
On esp8266, there's not a proper 'reset halt' yet (at least on openocd) so it's a bit more haphazard. My technique so far has been to halt as soon as possible after reset and set up the debugger state then.
[/quote]
Where is that? Could that be that me made earlier by modifying the boot loader?
[quote]
Which works OK as long as you're not debugging early startup code.
Also, as you've mentiond, with esp8266 you only have one hardware breakpoint so you have to keep deleting the current breakpoint after you add a new one (the breakpoints don't get written to the hardware until you 'continue'). On a "normal" platform openocd will tell gdb where the flash regions vs the RAM regions of the address space are, so gdb will automatically choose soft vs hard breakpoints depending on the target address. This isn't supported yet for openocd, it might work for xt-ocd!
[/quote]Is it possible to provide that information to gdb via config?
Providing XML files via esp8266 seems to waste precious resources IMHO.[quote]
I have once or twice used:
[code]
asm("break 0, 0");
[/code]
... to compile in a software breakpoint.
[quote="cal"]
What ways to continue after break?
[/quote]
Usually I just type 'c' in gdb.
[/code]
The PC will be on the break point instruction after break.
That would imply for me, that the debugger does implicitly advance the PC before continuing.
Something not needed for STEPI as it seems.
[code]
[quote="cal"]
Do you have to manipulate the cpu state before continue?
E.g. set $pc += 3 or the like?
I struggle with "c" (continue) vs. "Cxx" (continue with signal).
[/quote]
You can do this, but you don't need to for normal execution if you just want to continue from the next instruction.
There's also 'step', si/stepi, finish. All worth looking at (see 'help xxx' for a quick summary.
[/quote]
Yes, I used them with success.
[quote]
[quote="cal"]
What happens with interrupts when single stepping?
int 1 level interrupts execute callbacks on intlevel 0 and so single stepping may be suddenly applied to that code
if not taken care of. I wonder, how?
[/quote]
Openocd should step into an int1 interrupt handler if you're stepping and an interrupt comes. I don't know about xt-ocd.
The single higher level interrupt (NMI) is currently ignored by the debugger due to the debug level set by openocd. I want to change eventually so it's an openocd parameter, so you can into the NMI handler if you want (or alternatively you could set it so that you don't step into interrupt handlers). The NMI seems to be called a lot (it's related to the radio layer), so it can be quite confusing to constantly step into it!
[/quote]
Really the NMI?
How could that be handled if the whole content of the NMI vector is an "return from interrupt"?
[quote]
Remember that the debug (interrupt) level is a CPU state not something in the code, so if level 1 interrupt calls a callback in your code then the CPU debug level stays at level 1, until the callback returns and the interrupt handler ends. (Unless I'm misunderstanding the question.)[/quote]
Thats what I meant.
And executing the int handler on current int level is what I expecte.
But the rom int 1 exception handler (_xtos_l1int_handler) lowers the int level before
calling the registered handler:
[code]
400004ff: 0060f0 rsil a15, 0
[/code]
Do I miss something?
Cal
thanks for the exhaustive answer!
I added my comments below!
[quote="projectgus"][quote="cal"]
How to you typically start a ocd debugging session?
Setting breakpoints upfront and then starting the hardware?
Calling into the debugger using a break op code?
Using some ctrl-c or break signal to interrupt the cpu?
[/quote]
If I'm debugging on a different platform, like ARM Cortex-M, I'll often run a 'reset halt' in openocd which resets the CPU and then halts it immediately after reset, PC still set to the reset vector address, before any instructions are executed. Once it halts you can set the breakpoints you want in gdb, and run 'continue' from gdb to get it to run.
Once the breakpoints are set, gdb will keep them set through future 'reset halt' cycles.
[/quote]
OK, thats similiar to the typical "start program and halt on main".
And - as you write below - the breakpoints will typically be set again by gdb on step/continue.
[quote]
Sometimes I'll press ctrl-c to randomly halt a running CPU 'now', if I don't understand what's happening (usually it's gotten stuck in an infinite loop somewhere).
[/quote]
Yes, thats a cool feature. I implemented that via serial break detection.
Will the ocd debugger set you at the position where your code runs or stop in the CTRL-c handler? [quote]
On esp8266, there's not a proper 'reset halt' yet (at least on openocd) so it's a bit more haphazard. My technique so far has been to halt as soon as possible after reset and set up the debugger state then.
[/quote]
Where is that? Could that be that me made earlier by modifying the boot loader?
[quote]
Which works OK as long as you're not debugging early startup code.
Also, as you've mentiond, with esp8266 you only have one hardware breakpoint so you have to keep deleting the current breakpoint after you add a new one (the breakpoints don't get written to the hardware until you 'continue'). On a "normal" platform openocd will tell gdb where the flash regions vs the RAM regions of the address space are, so gdb will automatically choose soft vs hard breakpoints depending on the target address. This isn't supported yet for openocd, it might work for xt-ocd!
[/quote]Is it possible to provide that information to gdb via config?
Providing XML files via esp8266 seems to waste precious resources IMHO.[quote]
I have once or twice used:
[code]
asm("break 0, 0");
[/code]
... to compile in a software breakpoint.
[quote="cal"]
What ways to continue after break?
[/quote]
Usually I just type 'c' in gdb.
[/code]
The PC will be on the break point instruction after break.
That would imply for me, that the debugger does implicitly advance the PC before continuing.
Something not needed for STEPI as it seems.
[code]
[quote="cal"]
Do you have to manipulate the cpu state before continue?
E.g. set $pc += 3 or the like?
I struggle with "c" (continue) vs. "Cxx" (continue with signal).
[/quote]
You can do this, but you don't need to for normal execution if you just want to continue from the next instruction.
There's also 'step', si/stepi, finish. All worth looking at (see 'help xxx' for a quick summary.
[/quote]
Yes, I used them with success.
[quote]
[quote="cal"]
What happens with interrupts when single stepping?
int 1 level interrupts execute callbacks on intlevel 0 and so single stepping may be suddenly applied to that code
if not taken care of. I wonder, how?
[/quote]
Openocd should step into an int1 interrupt handler if you're stepping and an interrupt comes. I don't know about xt-ocd.
The single higher level interrupt (NMI) is currently ignored by the debugger due to the debug level set by openocd. I want to change eventually so it's an openocd parameter, so you can into the NMI handler if you want (or alternatively you could set it so that you don't step into interrupt handlers). The NMI seems to be called a lot (it's related to the radio layer), so it can be quite confusing to constantly step into it!
[/quote]
Really the NMI?
How could that be handled if the whole content of the NMI vector is an "return from interrupt"?
[quote]
Remember that the debug (interrupt) level is a CPU state not something in the code, so if level 1 interrupt calls a callback in your code then the CPU debug level stays at level 1, until the callback returns and the interrupt handler ends. (Unless I'm misunderstanding the question.)[/quote]
Thats what I meant.
And executing the int handler on current int level is what I expecte.
But the rom int 1 exception handler (_xtos_l1int_handler) lowers the int level before
calling the registered handler:
[code]
400004ff: 0060f0 rsil a15, 0
[/code]
Do I miss something?
Cal
