On Mon, May 2, 2011 at 4:11 AM, Eric Cooper e...@cmu.edu wrote:
On Mon, May 02, 2011 at 03:24:00AM +0200, Øyvind Harboe wrote:
Also, don't you need to flush the data cache somehow before
invalidating the data cache?
Good question. I thought the arm926ejs write code, which feroceon
uses, was
Hello Drasko,
The end goal it's to have a safe state of the used JTAG adapter at the
end of the executable file.
With this patch = Fix: Correctly exit function: ft2232_init when an
error occurred
I wish correct the status at the end of ft2232_init function when an
error occured.
At
Hi,
I encountered an issue when using OpenOCD with GDB. After GDB connects to
OpenOCD and halt the target, info reg command returns all zeros for all
registers. I took a look at the related code and found that when GDB
requests register values from OpenOCD, OpenOCD does not read register from
Hello,
please tell us more about your target platform.
Regards,
Mathias
Am 02.05.2011 18:06, schrieb Jie Zhang:
Hi,
I encountered an issue when using OpenOCD with GDB. After GDB connects to
OpenOCD and halt the
target, info reg command returns all zeros for all registers. I took a look
Thank you for your reply!
I'm adding a new target to OpenOCD. But I think all existing targets in
OpenOCD have this issue. Maybe I missed something...
Jie
On Mon, May 2, 2011 at 12:13 PM, Mathias K. kes...@freenet.de wrote:
Hello,
please tell us more about your target platform.
Regards,
If you stop the target you should store the target context into the local
register cache and if you
resume the target you need to restore the context. This is why the target
registers never read again
if the target already halted.
Am 02.05.2011 18:22, schrieb Jie Zhang:
Thank you for your
This solves my problem. Thank you!
I have another related issue, but I will start a new thread.
Jie
On Mon, May 2, 2011 at 12:33 PM, Mathias K. kes...@freenet.de wrote:
If you stop the target you should store the target context into the local
register cache and if you
resume the target you
On Mon, May 02, 2011 at 12:26:21PM +0200, Øyvind Harboe wrote:
If it is possible, I'd like to see the breakpoint cache handling
done in the breakpoint code rather than the generic memory write
code...
The feroceon code currently just uses its parent arm7_9 code to set
and unset breakpoints.
When GDB connects to OpenOCD, OpenOCD does not halt the target by default.
To halt the target, users have to add halt to gdb-attach event hook in
target configuration file or type the command monitor halt from GDB
command line interface. The latter method caused some confusion for me.
Since
Short story: creates other nasty problems.
You can easily add a monitor halt + stepi to your gdb init
sequence.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale
Perhaps you can add a polymorphism hook where the
current behavior for handling software breakpoints
is the default?
You can then do something before or after by
subclassing the current behavior and if needed
copy and paste and modify if the behavior is sufficiently
different that it makes more
After connecting GDB to OpenOCD, you need to issue a stepi to sync
GDB and OpenOCD.
The advantage of this approach is (amongst many other things) that
attaching to the target does *nothing*. Via monitor commands, you can
easily manipulate the target, e.g. issuing a monitor halt.
--
Øyvind
On Mon, May 2, 2011 at 3:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Short story: creates other nasty problems.
You can easily add a monitor halt + stepi to your gdb init
sequence.
Thank you for your reply. But what are the other nasty problems?
Jie
On Mon, May 2, 2011 at 9:43 PM, Jie Zhang jzhang...@gmail.com wrote:
On Mon, May 2, 2011 at 3:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Short story: creates other nasty problems.
You can easily add a monitor halt + stepi to your gdb init
sequence.
Thank you for your reply. But
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.
It's not a good idea to force
On Mon, May 2, 2011 at 3:35 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
After connecting GDB to OpenOCD, you need to issue a stepi to sync
GDB and OpenOCD.
This is not documented in the manual.
The advantage of this approach is (amongst many other things) that
attaching to the target
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.
Advantage of a gdb-attach is that you can add that to the onfig
script, whereas monitor commands, while more
What are the other advantages? If they are important, we can consider
changing GDB not to expect target halted when it connects to OpenOCD.
IMHO, a quixotic undertaking.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
On 02.05.2011 21:57, Jie Zhang wrote:The advantage of this approach is
(amongst many other things) that
attaching to the target does *nothing*. Via monitor commands, you can
easily manipulate the target, e.g. issuing a monitor halt.
I would say that this is confusing for a new user, like me,
On Mon, May 02, 2011 at 09:33:33PM +0200, Øyvind Harboe wrote:
Perhaps you can add a polymorphism hook where the
current behavior for handling software breakpoints
is the default?
If I understand what you mean by a polymorphism hook, that would
mean adding new methods for set/unset_breakpoint,
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
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
Michael Trensch wrote:
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.
It's a huge usability deficiency. :\
//Peter
___
Openocd-development mailing list
On 02.05.2011 23:07, Peter Stuge wrote:
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.
It's a huge usability deficiency. :\
I don't think so. The provided scripts work out of the box and are working.
But I
24 matches
Mail list logo
