Re: [Openocd-development] jtag newtap -expected-id query
Is this the expected behaviour now, as previous versions would fail silently if no id was given. I changed that when I changed it to make sure it didn't drop messages in various cases. I think it's better to get the config files updated, so startup verification can do a better job, but I might be persuaded otherwise. It should at least be *possible* not to check the ID's even if one is strongly encouraged(kind word and a gun) to add them... Who knows what boards are out there? I tend to agree that we need to handle the case of no id - as per previous versions. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Best regards,
Magnus
===
.
.
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
sleep 100
jtag tapenable omap3530.dap
targets
# General Cortex A8 debug initialisation
cortex_a8 dbginit
# Enable DBGU singal for OMAP353x
omap3.cpu mww 0x5401d030 0x2000
poll on
}
set PRM_RSTCTRL 0x48307250
proc omap3_reset { } {
# Global software reset
# RST_GS bit in PRM_RSTCTRL
mww $PRM_RSTCTRL 2
omap3_dbginit
halt
}
omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
omap3.cpu configure -event reset-end omap3_dbginit
Index: tcl/target/omap3530.cfg
===
--- tcl/target/omap3530.cfg (working copy)
+++ tcl/target/omap3530.cfg (revision 2768)
@@ -2,9 +2,9 @@
# http://focus.ti.com/docs/prod/folders/print/omap3530.html
# Other OMAP3 chips remove DSP and/or the OpenGL support
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
set _CHIPNAME omap3530
}
@@ -42,6 +42,7 @@
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
+ reset
sleep 100
jtag tapenable omap3530.dap
@@ -53,17 +54,3 @@
poll on
}
-set PRM_RSTCTRL 0x48307250
-
-proc omap3_reset { } {
- # Global software reset
- # RST_GS bit in PRM_RSTCTRL
- mww $PRM_RSTCTRL 2
- omap3_dbginit
- halt
-}
-
-omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
-omap3.cpu configure -event reset-end omap3_dbginit
-
-
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the patch in attachment? It has to be done the
inverse? I.e.
--- tcl/target/omap3530.cfg(revision 2768)
+++ tcl/target/omap3530.cfg(working copy)
instead of
--- tcl/target/omap3530.cfg(working copy)
+++ tcl/target/omap3530.cfg(revision 2768)
This was done for me by the diff program in kdesvn, and I didnt read
carefully.
Additionally:
I can't find any difference (whitespace only?) in
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
There was a whitespace patch from Dave that I had not applied on the tcl
directory.
And:
omap3.cpu configure -event reset-end omap3_dbginit
should call omap3_reset instead of omap3_dbginit? Or who calls
omap3_reset? Or why call omap3_dbginit from omap3_reset, too?
At the end of the reset handling we reinitialise the tap and the debug
interface with omap3_dbginit
omap3_reset is really reset+reinit+halt and you call it if you want to
debug the loading of u-boot by the X-Loader
New patch attaced.
Regards,
Magnus
Index: tcl/target/omap3530.cfg
===
--- tcl/target/omap3530.cfg (revision 2768)
+++ tcl/target/omap3530.cfg (working copy)
@@ -42,7 +42,6 @@
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
- reset
sleep 100
jtag tapenable omap3530.dap
@@ -54,3 +53,17 @@
poll on
}
+set PRM_RSTCTRL 0x48307250
+
+proc omap3_reset { } {
+ # Global software reset
+ # RST_GS bit in PRM_RSTCTRL
+ mww $PRM_RSTCTRL 2
+ omap3_dbginit
+ halt
+}
+
+omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
+omap3.cpu configure -event reset-end omap3_dbginit
+
+
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OUT macro redefined under MinGW
Below is the error output(SVN top, 2768): etm.c:189:1: OUT redefined In file included from C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../inclu de/rpc.h:40, from C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../inclu de/windows.h:82, from C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../inclu de/winsock2.h:22, from ../../src/helper/system.h:51, from ../../config.h:267, from etm.c:21: C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../include/rpcdce.h:14:1: this is the location of the previous definition In etm.c, OUT is defined to initialize struct etm_outputs. In rpcdce.h, OUT is also defined: #ifndef _NO_W32_PSEUDO_MODIFIERS #define IN #define OUT #ifndef OPTIONAL #define OPTIONAL #endif #endif I recommend to change OUT in etm.c to ETM_OUT? Similar change can also be applied to ADDR_COMPARATOR, DATA_COMPARATOR, COUNTER and SEQ. -- Best Regards, SimonQian http://www.SimonQian.com http://www.simonqian.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] cannot halt CPU
Hi list, I've used openocd for burning bootloader several months and I woks well. But recently I got a very strange problem I cannot solved. My operations as following: 1. power on the board 2. run openocd It show CPU matches successful. 3. telnet localhost $port then I type halt to stop CPU message like this(forget copy the log message): timeout halted Error run command.c line XXX The first command is failure so I can't go on. And it confused me that I didnot change anything as before. Why it cannot be haltted. I can match CPU ID, so it must not die. Does anybody have the same problem? Any hints? Thanks in advance. Regards -- zeal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
Magnus Lundin wrote:
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the patch in attachment? It has to be done the
inverse? I.e.
--- tcl/target/omap3530.cfg(revision 2768)
+++ tcl/target/omap3530.cfg(working copy)
instead of
--- tcl/target/omap3530.cfg(working copy)
+++ tcl/target/omap3530.cfg(revision 2768)
This was done for me by the diff program in kdesvn, and I didnt read
carefully.
Additionally:
I can't find any difference (whitespace only?) in
-if { [info exists CHIPNAME] } { - set _CHIPNAME $CHIPNAME
-} else { +if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
There was a whitespace patch from Dave that I had not applied on the tcl
directory.
And:
omap3.cpu configure -event reset-end omap3_dbginit
should call omap3_reset instead of omap3_dbginit? Or who calls
omap3_reset? Or why call omap3_dbginit from omap3_reset, too?
At the end of the reset handling we reinitialise the tap and the debug
interface with omap3_dbginit
omap3_reset is really reset+reinit+halt and you call it if you want to
debug the loading of u-boot by the X-Loader
Do you mean omap3_reset should be called 'manually' if needed, same
like omap3_dbginit?
New patch attaced.
Tested with 2771 and LEDblink example. No differences seen to svn version.
Best regards
Dirk
Btw.: We still have the issue that first load of LEDblink with gdb fails:
-- cut --
...
Info : 113 7057 server.c:79 add_connection(): accepting 'gdb'
connection from 0
Debug: 114 7058 breakpoints.c:160 breakpoint_clear_target(): Delete
all breakpoints for target: cortex_a8
Debug: 115 7058 breakpoints.c:287 watchpoint_clear_target(): Delete
all watchpoints for target: cortex_a8
Debug: 116 7058 target.c:829 target_call_event_callbacks(): target
event 26 (gdb-attach)
Debug: 117 7058 gdb_server.c:788 gdb_new_connection(): New GDB
Connection: 1, Target omap3.cpu, state: unknown
Debug: 118 7058 gdb_server.c:2047 gdb_input_inner(): received packet:
'qSupported'
Warn : 119 7058 gdb_server.c:582 gdb_get_packet_inner():
acknowledgment received, but no packet pending
Debug: 120 7059 gdb_server.c:2047 gdb_input_inner(): received packet:
'?'
User : 121 7059 gdb_server.c:96 gdb_last_signal(): undefined debug
reason 6 - target needs reset
Debug: 122 7059 gdb_server.c:2047 gdb_input_inner(): received packet:
'Hc-1'
Debug: 123 7059 gdb_server.c:2047 gdb_input_inner(): received packet:
'qC'
Debug: 124 7060 gdb_server.c:2047 gdb_input_inner(): received packet:
'Hg0'
Debug: 125 7060 gdb_server.c:2047 gdb_input_inner(): received packet:
'g'
Debug: 126 7060 gdb_server.c:2047 gdb_input_inner(): received packet:
'm0,4'
Debug: 127 7060 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0x, len: 0x0004
Debug: 128 7060 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0x
Error: 129 7060 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 130 7061 gdb_server.c:2047 gdb_input_inner(): received packet:
'mfffc,4'
Debug: 131 7061 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0xfffc, len: 0x0004
Debug: 132 7061 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0xfffc
Error: 133 7061 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 134 7061 gdb_server.c:2047 gdb_input_inner(): received packet:
'm0,4'
Debug: 135 7061 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0x, len: 0x0004
Debug: 136 7061 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0x
Error: 137 7061 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 138 7062 gdb_server.c:2047 gdb_input_inner(): received packet:
'mfffc,4'
Debug: 139 7062 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0xfffc, len: 0x0004
Debug: 140 7062 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0xfffc
Error: 141 7062 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 142 7062 gdb_server.c:2047 gdb_input_inner(): received packet:
'm0,4'
Debug: 143 7062 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0x, len: 0x0004
Debug: 144 7062 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0x
Error: 145 7062 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 146 7062 gdb_server.c:2047 gdb_input_inner(): received packet:
'm0,4'
Debug: 147 7063 gdb_server.c:1182 gdb_read_memory_packet(): addr:
0x, len: 0x0004
Debug: 148 7063 target.c:1190 target_read_buffer(): reading buffer of
4 byte at 0x
Error: 149 7063 target.c:1194 target_read_buffer(): Target not
examined yet
Debug: 150 7063 gdb_server.c:2047 gdb_input_inner(): received packet:
'm0,4'
Debug: 151 7063
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader Do you mean omap3_reset should be called 'manually' if needed, same like omap3_dbginit? Yes, try to use reset and omap3_reset in a telent session and see what happens, also check the output from BeagleBoard console window connected to the serial port. New patch attaced. Tested with 2771 and LEDblink example. No differences seen to svn version. Best regards Dirk Btw.: We still have the issue that first load of LEDblink with gdb fails: Are you running gdb from a script ? Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
Magnus Lundin wrote: At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader Do you mean omap3_reset should be called 'manually' if needed, same like omap3_dbginit? Yes, try to use reset and omap3_reset in a telent session and see what happens, also check the output from BeagleBoard console window connected to the serial port. New patch attaced. Tested with 2771 and LEDblink example. No differences seen to svn version. Best regards Dirk Btw.: We still have the issue that first load of LEDblink with gdb fails: Are you running gdb from a script ? No. I just do arm-none-linux-gnueabi-gdb with cat .gdbinit echo Setting up the environment for debugging gdb.\n # This connects to OpenOcd at localhost: target remote localhost: # Increase the packet size to improve download speed. set remote memory-write-packet-size 1024 set remote memory-write-packet-size fixed #omap3_dbginit must be run in OpenOCD after every reset monitor omap3_dbginit # Load the program executable called LEDblink load LEDblink # Load the symbols for the program. symbol-file LEDblink Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cannot halt CPU
On Tuesday 29 September 2009, jie zeng wrote: timeout halted Error run command.c line XXX What hardware? I've seen such issues with the OMAP5912, which has what seems to be an early ARM926 core. The most strange thing is that the EmbeddedICE unit seems to misbehave ... as in, the debug_status register likes to read as zero after it halts. Meanwhile the debug_ctrl register seems to indicate that it has inded halted. Yet ... CPSR is garbaged, reporting that it's in ARM state (not so!) and that the core mode (svc/fiq/user/abort/etc) is some unknown value. That is, *sometimes* it gets into those wierd modes. A few other times it's behaved normally. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OUT macro redefined under MinGW
On Tuesday 29 September 2009, simon qian wrote: In etm.c, OUT is defined to initialize struct etm_outputs. In rpcdce.h, OUT is also defined: #ifndef _NO_W32_PSEUDO_MODIFIERS #define IN #define OUT #ifndef OPTIONAL #define OPTIONAL #endif #endif I recommend to change OUT in etm.c to ETM_OUT? Would OUTPUT work? Similar change can also be applied to ADDR_COMPARATOR, DATA_COMPARATOR, COUNTER and SEQ. Do they need it though? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Monday 28 September 2009, Øyvind Harboe wrote: Is this the expected behaviour now, as previous versions would fail silently if no id was given. I changed that when I changed it to make sure it didn't drop messages in various cases. I think it's better to get the config files updated, so startup verification can do a better job, but I might be persuaded otherwise. It should at least be *possible* not to check the ID's even if one is strongly encouraged(kind word and a gun) to add them... By not check you must mean some more complex conditional than is there now ... it'd obviously have to check to see whether it should not check! Else it'd be never check. Maybe you just want to suppress the warning? There seem to be several basic cases, combinining the two TAP options (BYPASS vs IDCODE) vs two config options (no options for -expected-id vs one-or-more): 1 BYPASS-only TAP a no IDs listed b IDs listed but (obviously) not found 2 IDCODE support a no IDs listed b IDs listed ... one is found c IDs listed ... no match Now, I'd contend that all those are handled well just now. Would handling -expected-id 0 as a match anything wildcard suit, as an explicit stifle warnings option for (2a) or, in fact, any branch of (2)? - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tuesday 29 September 2009, Spencer Oliver wrote: I tend to agree that we need to handle the case of no id - as per previous versions. How do we *not* do so now? And which previous versions? Repository history shows diagnostics came from some... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cannot halt CPU
On Tue, Sep 29, 2009 at 11:14 PM, David Brownell davi...@pacbell.net wrote: What hardware? Board is vsc7501(vitesse) which used ARM926ejs core. I've seen such issues with the OMAP5912, which has what seems to be an early ARM926 core. The most strange thing is that the EmbeddedICE unit seems to misbehave ... as in, the debug_status register likes to read as zero after it halts. Meanwhile the debug_ctrl register seems to indicate that it has inded halted. Yet ... CPSR is garbaged, reporting that it's in ARM state (not so!) and that the core mode (svc/fiq/user/abort/etc) is some unknown value. I cannot halt it but after type `regs' command it shows me almost registers are 0x. debug_ctrl is not zero(no log now). Others I'm not sure. That is, *sometimes* it gets into those wierd modes. A few other times it's behaved normally. Yes, I can remember that 3 months ago I got same matter. But it disappeared quickly(retry one more time) so we didnt notice that is a problem. Unfortunately, it's in the abnormal mode several days. Regards -- zeal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tue, Sep 29, 2009 at 5:57 PM, David Brownell davi...@pacbell.net wrote: On Monday 28 September 2009, Ųyvind Harboe wrote: Is this the expected behaviour now, as previous versions would fail silently if no id was given. I changed that when I changed it to make sure it didn't drop messages in various cases. I think it's better to get the config files updated, so startup verification can do a better job, but I might be persuaded otherwise. It should at least be *possible* not to check the ID's even if one is strongly encouraged(kind word and a gun) to add them... By not check you must mean some more complex conditional than is there now ... it'd obviously have to check to see whether it should not check! Else it'd be never check. Maybe you just want to suppress the warning? not check means simply list the TAP ID (if any) and not to fail examine. Now, I'd contend that all those are handled well just now. It's not what we think of that will get us, it's what we don't think off. E.g. I can easily think of a situation where it is not practical to check for the id code, or in the future where we want to *read* the id code and have some conditional behavior scripted. Would handling -expected-id 0 as a match anything wildcard suit, as an explicit stifle warnings option for (2a) or, in fact, any branch of (2)? Don't override the meaning of integers, use a separate keyword :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
I once argued that it should be possible to write a piece of tcl code that decides what to do with the IDCODE(if any). One of the things that such a script could do is to fail. Obviously such a script should be able to do nothing, silent success in all cases.. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OUT macro redefined under MinGW
Hi, OUTPUT doesn't conflict with system header files. But I recommend to use MODULE_X to define a macro, so it will never conflict with anything. After all, IN, OUT, OUTPUT, INPUT and COUNTER are commonly used. 2009/9/29 David Brownell davi...@pacbell.net On Tuesday 29 September 2009, simon qian wrote: In etm.c, OUT is defined to initialize struct etm_outputs. In rpcdce.h, OUT is also defined: #ifndef _NO_W32_PSEUDO_MODIFIERS #define IN #define OUT #ifndef OPTIONAL #define OPTIONAL #endif #endif I recommend to change OUT in etm.c to ETM_OUT? Would OUTPUT work? Similar change can also be applied to ADDR_COMPARATOR, DATA_COMPARATOR, COUNTER and SEQ. Do they need it though? -- Best Regards, SimonQian http://www.SimonQian.com http://www.simonqian.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OUT macro redefined under MinGW
On Tuesday 29 September 2009, Øyvind Harboe wrote: I loathe macros as much as the next guy, a nasty feature of C if there ever was one that I wanted to pick on... Macros can be fine ... if you've ever used syntax macros in LISP, you should know what I mean. C macros ... have issues. But they're the best solution for eliminating a *LOT* of error-prone repetitive crap. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tuesday 29 September 2009, Øyvind Harboe wrote: Would handling -expected-id 0 as a match anything wildcard suit, as an explicit stifle warnings option for (2a) or, in fact, any branch of (2)? Don't override the meaning of integers, use a separate keyword :-) There's long been special handling for -expected-id 0; I'm aiming for a minimal patch. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rft] arm11 memwrite ... bug fixes
On Saturday 26 September 2009, David Brownell wrote: Fix glitches in ARM11 command handling: commands were supposed to have been arm11 memwrite ... not memwrite Get rid of obfuscatory macros. Re-alphabetize. Add docs for arm11 vcr. --- Someone with an ARM11 based board, please verify ... I've got one but it's not currently set up. doc/openocd.texi | 15 +- src/target/arm11.c | 76 +-- 2 files changed, 52 insertions(+), 39 deletions(-) I committed this ... if there are glitches, they'll be more easily fixed. NOTE: this means some folk may need to update their scripts to include the arm11 prefix. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tuesday 29 September 2009, David Brownell wrote: There's long been special handling for -expected-id 0; I'm aiming for a minimal patch. ... which is now checked in. Only -expected-id nonzero causes checks, matchin the existing docs. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] doc updates
commit 07c86fdf5eaa3439d48e03fc0a4850bc0b7d0a7e
Author: dbrownell dbrown...@b42882b7-edfa-0310-969c-e2dbd0fdcd60
Date: Tue Sep 29 18:20:30 2009 +
Doc updates: add section on target software changes, minor fixes
git-svn-id: svn://svn.berlios.de/openocd/tr...@2774
b42882b7-edfa-0310-969c-e2dbd0fdcd60
diff --git a/doc/openocd.texi b/doc/openocd.texi
index e4609e4..716c452 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -845,6 +845,54 @@ the main bootloader code (which won't fit into that SRAM).
Other helper scripts might be used to write production system images,
involving considerably more than just a three stage bootloader.
+...@section Target Software Changes
+
+Sometimes you may want to make some small changes to the software
+you're developing, to help make JTAG debugging work better.
+For example, in C or assembly language code you might
+use @code{#ifdef JTAG_DEBUG} (or its converse) around code
+handling issues like:
+
+...@itemize @bullet
+
+...@item @b{ARM Wait-For-Interrupt}...
+Many ARM chips synchronize the JTAG clock using the core clock.
+Low power states which stop that core clock thus prevent JTAG access.
+Idle loops in tasking environments often enter those low power states
+via the @code{WFI} instruction (or its coprocessor equivalent, before ARMv7).
+
+You may want to @emph{disable that instruction} in source code,
+or otherwise prevent using that state,
+to ensure you can get JTAG access at any time.
+For example, the OpenOCD @command{halt} command may not
+work for an idle processor otherwise.
+
+...@item @b{Delay after reset}...
+Not all chips have good support for debugger access
+right after reset; many LPC2xxx chips have issues here.
+Similarly, applications that reconfigure pins used for
+JTAG access as they start will also block debugger access.
+
+To work with boards like this, @emph{enable a short delay loop}
+the first thing after reset, before real startup activities.
+For example, one second's delay is usually more than enough
+time for a JTAG debugger to attach, so that
+early code execution can be debugged
+or firmware can be replaced.
+
+...@item @b{Debug Communications Channel (DCC)}...
+Some processors include mechanisms to send messages over JTAG.
+Many ARM cores support these, as do some cores from other vendors.
+(OpenOCD may be able to use this DCC internally, speeding up some
+operations like writing to memory.)
+
+Your application may want to deliver various debugging messages
+over JTAG, by @emph{linking with a small library of code}
+provided with OpenOCD and using the utilities there to send
+various kinds of message.
+...@xref{software Debug Messages and Tracing}.
+
+...@end itemize
@node Config File Guidelines
@chapter Config File Guidelines
@@ -2462,7 +2510,7 @@ If necessary, disables the tap
by sending it a @option{tap-disable} event.
Returns the string 1 if the tap
specified by @var{dotted.name} is enabled,
-and 0 if it is disbabled.
+and 0 if it is disabled.
@end deffn
@deffn Command {jtag tapenable} dotted.name
@@ -2470,13 +2518,13 @@ If necessary, enables the tap
by sending it a @option{tap-enable} event.
Returns the string 1 if the tap
specified by @var{dotted.name} is enabled,
-and 0 if it is disbabled.
+and 0 if it is disabled.
@end deffn
@deffn Command {jtag tapisenabled} dotted.name
Returns the string 1 if the tap
specified by @var{dotted.name} is enabled,
-and 0 if it is disbabled.
+and 0 if it is disabled.
@quotation Note
Humans will find the @command{scan_chain} command more helpful
@@ -5600,7 +5648,7 @@ as used by Linux with CONFIG_DEBUG_ICEDCC;
otherwise the libdcc format is used.
@end deffn
-...@deffn Command {trace history} (@option{clear}|count)
+...@deffn Command {trace history} [...@option{clear}|count]
With no parameter, displays all the trace points that have triggered
in the order they triggered.
With the parameter @option{clear}, erases all current trace history records.
@@ -5608,7 +5656,7 @@ With a @var{count} parameter, allocates space for that
many
history records.
@end deffn
-...@deffn Command {trace point} (@option{clear}|identifier)
+...@deffn Command {trace point} [...@option{clear}|identifier]
With no parameter, displays all trace point identifiers and how many times
they have been triggered.
With the parameter @option{clear}, erases all current trace point counters.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OUT macro redefined under MinGW
On Tuesday 29 September 2009, simon qian wrote: OUTPUT doesn't conflict with system header files. I checked in a fix. But I recommend to use MODULE_X to define a macro, so it will never conflict with anything. After all, IN, OUT, OUTPUT, INPUT and COUNTER are commonly used. The real bug here is that the MinGW system headers (or is it Win32?) chose to pollute global namespaces. The general policy is that *system* code should be clearly split out from application code, using such name prefixes. A name like OUT doesn't look even vaguely system-specific ... a classic app-space name. Another general policy is that system headers should not pull in unrelated crap. Like, say, DCE ... which isn't even used by OpenOCD. Yeah, I know it's unrealistic to expect standard coding discipline from the Win32 system headers. But it's fair to point out the root causes of bugs. ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tue, Sep 29, 2009 at 7:52 PM, David Brownell davi...@pacbell.net wrote: On Tuesday 29 September 2009, Ųyvind Harboe wrote: Would handling -expected-id 0 as a match anything wildcard suit, as an explicit stifle warnings option for (2a) or, in fact, any branch of (2)? Don't override the meaning of integers, use a separate keyword :-) There's long been special handling for -expected-id 0; I'm aiming for a minimal patch. Overloading meaning of integers rarely leads to anything good. Even if it was done this way before, doesn't make it good design... I'd rather see that with *no* -exepected-id's listed, no check happens. But I should look a bit more into the syntax before jumping to conclusions here... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
On Tuesday 29 September 2009, Øyvind Harboe wrote: Overloading meaning of integers rarely leads to anything good. Even if it was done this way before, doesn't make it good design... Well enough; but that'd be a lot bigger change. I'd rather see that with *no* -exepected-id's listed, no check happens. I'd rather interpret that one as ... no IDs expected, this TAP doesn't support the IDCODE instruction. After all, there *does* need to be a way to say that such a TAP is expected in the scan chain, and to report errors when such a tap is missing ... or is unexpectedly present. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag newtap -expected-id query
After all, there *does* need to be a way to say that such a TAP is expected in the scan chain, and to report errors when such a tap is missing ... or is unexpectedly present. I think open source truly shines here in that we can wait until we do encounter real world problems before we implement a scheme... The current implementation should be more than powerful enough meanwhile. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] updated scripts for c100 - arm1136 core
Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Strip gdb config options from target/board scripts
I didn't strip a gdb_breakpoint_override hard I found in mini2440.cfg
as I can see configuration of breakpoints to be legitimate to have in
a board config script.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
### Eclipse Workspace Patch 1.0
#P openocd
Index: tcl/target/at91sam3uXX.cfg
===
--- tcl/target/at91sam3uXX.cfg (revision 2777)
+++ tcl/target/at91sam3uXX.cfg (working copy)
@@ -37,11 +37,6 @@
reset_config srst_only
-# GDB can use this
-gdb_memory_map enable
-# And GDB can flash the chip
-gdb_flash_program enable
-
$_TARGETNAME configure -event gdb-flash-erase-start {
halt
}
Index: tcl/board/mini2440.cfg
===
--- tcl/board/mini2440.cfg (revision 2777)
+++ tcl/board/mini2440.cfg (working copy)
@@ -123,11 +123,7 @@
# GDB Setup
#-
-gdb_port
-gdb_detach resume
gdb_breakpoint_override hard
-gdb_memory_map enable
-gdb_flash_program enable
#
# ARM SPECIFIC
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] If no -expected-id's listed then do not check
If no -expected-id's listed then do not check ID's.
The code has not been tested, just posting for comments.
No 0 is wildcard ref. my do not override the meaning
of integers hobbyhorse.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/core.c
===
--- src/jtag/core.c (revision 2777)
+++ src/jtag/core.c (working copy)
@@ -955,14 +955,19 @@
/* Loop over the expected identification codes and test for a match */
uint8_t ii;
+
+ if (tap-expected_ids_cnt == 0)
+ {
+ jtag_examine_chain_display(LOG_LVL_WARNING, NO CHECK,
+ tap-dotted_name, tap-idcode);
+ /* no id's to match against */
+ return true;
+ }
+
for (ii = 0; ii tap-expected_ids_cnt; ii++)
{
if (tap-idcode == tap-expected_ids[ii])
return true;
-
- /* treat -expected-id 0 as a don't-warn wildcard */
- if (0 == tap-expected_ids[ii])
- return true;
}
/* If none of the expected ids matched, warn */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
