On 02.05.2011 22:44, Jie Zhang wrote: > On Mon, May 2, 2011 at 3:52 PM, Michael Trensch <mtren...@googlemail.com> > wrote: >> I often use openOCD and GDB/Insight to attach to a running target that I >> don't want to halt, or even cannot halt it during my debugging session. >> I just want to take to see the call stack and program counter when it >> crashes or when it reaches a special code line. > I think you can still connect to the target to look at the call stack > and PC after it crashes. But i cannot set a breakpoint before I've attached to the target, or I would need to set it via telnet interface after having fiddled out the address through the .map / .lst files.
> When I want to look at the call stack and PC at a special code line, I > usually set a breakpoint from GDB, that will requires to halt the > target first. No you can always set a HW breakpoint while the CPU is running without halting the target, or enable vector catches at least on the ARM CPU's I am usually working with. Never had problems setting these at runtime. >> In your case I think it would be the best to write a "gdb-attach" event >> in your script and you can do whatever you want, like resetting the CPU, >> blink LED's in this script. > This is what I'm currently doing. But I'm not sure if it's the correct > thing to do since most of the board config files have "reset init" for > their gdb-attach event, not "halt", except u8500.cfg. I think this is the right way, but as scripts come from different persons, who all have different needs, they may really be different at that point. Calling "reset init" in gdb-attach has a similar result as "halt" as the CPU is halted and in a defined state (usually). The only difference is the additional reset to the hardware, which might help in case the CPU has stalled at some point while debugging (I had that on our ARM bases controller when I tried to access memory areas that are internally not connected and result in a AHBL timeout). So as you can see this might be hardware / controller dependent and also vary from the debugging goal you have. I think most of the scripts show how to work with openOCD but you will need to override some functions to make them fit your needs. I am usually using the scripts and define some custom reset init / gdb attach events depending if I want to load an application or just attach to a running CPU. Regards, Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
