docs: fix html anchor xref links
makeinfo has a long outstanding bug that means @anchors are not correctly formatted for split html, see: http://lists.gnu.org/archive/html/bug-texinfo/2012-06/msg00000.html The issue relates to using spaces or hyphens in the @anchor name. Issue also reported via Trac #44 Change-Id: Id72e23375dd167674b2ae5b314e8242b90a72a5f Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk> Reviewed-on: http://openocd.zylin.com/1244 Tested-by: jenkins Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>__archive__
parent
1da9e595ec
commit
b7e0cd48f0
241
doc/openocd.texi
241
doc/openocd.texi
|
@ -321,8 +321,8 @@ RTCK support? Also known as ``adaptive clocking''
|
||||||
|
|
||||||
@section Stand alone Systems
|
@section Stand alone Systems
|
||||||
|
|
||||||
@b{ZY1000} See: @url{http://www.ultsol.com/index.php/component/content/article/8/33-zylin-zy1000-jtag-probe} Technically, not a
|
@b{ZY1000} See: @url{http://www.ultsol.com/index.php/component/content/article/8/33-zylin-zy1000-jtag-probe}
|
||||||
dongle, but a standalone box. The ZY1000 has the advantage that it does
|
Technically, not a dongle, but a standalone box. The ZY1000 has the advantage that it does
|
||||||
not require any drivers installed on the developer PC. It also has
|
not require any drivers installed on the developer PC. It also has
|
||||||
a built in web interface. It supports RTCK/RCLK or adaptive clocking
|
a built in web interface. It supports RTCK/RCLK or adaptive clocking
|
||||||
and has a built in relay to power cycle targets remotely.
|
and has a built in relay to power cycle targets remotely.
|
||||||
|
@ -428,7 +428,9 @@ AT91SAM764 internally.
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
@section USB RLINK based
|
@section USB RLINK based
|
||||||
Raisonance has an adapter called @b{RLink}. It exists in a stripped-down form on the STM32 Primer, permanently attached to the JTAG lines. It also exists on the STM32 Primer2, but that is wired for SWD and not JTAG, thus not supported.
|
Raisonance has an adapter called @b{RLink}. It exists in a stripped-down form on the STM32 Primer,
|
||||||
|
permanently attached to the JTAG lines. It also exists on the STM32 Primer2, but that is wired for
|
||||||
|
SWD and not JTAG, thus not supported.
|
||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
@item @b{Raisonance RLink}
|
@item @b{Raisonance RLink}
|
||||||
|
@ -699,7 +701,7 @@ you'll probably need more project-specific setup.
|
||||||
OpenOCD starts by processing the configuration commands provided
|
OpenOCD starts by processing the configuration commands provided
|
||||||
on the command line or, if there were no @option{-c command} or
|
on the command line or, if there were no @option{-c command} or
|
||||||
@option{-f file.cfg} options given, in @file{openocd.cfg}.
|
@option{-f file.cfg} options given, in @file{openocd.cfg}.
|
||||||
@xref{Configuration Stage}.
|
@xref{configurationstage,,Configuration Stage}.
|
||||||
At the end of the configuration stage it verifies the JTAG scan
|
At the end of the configuration stage it verifies the JTAG scan
|
||||||
chain defined using those commands; your configuration should
|
chain defined using those commands; your configuration should
|
||||||
ensure that this always succeeds.
|
ensure that this always succeeds.
|
||||||
|
@ -723,8 +725,8 @@ itself), use the @option{-d} command line switch. This sets the
|
||||||
@option{debug_level} to "3", outputting the most information,
|
@option{debug_level} to "3", outputting the most information,
|
||||||
including debug messages. The default setting is "2", outputting only
|
including debug messages. The default setting is "2", outputting only
|
||||||
informational messages, warnings and errors. You can also change this
|
informational messages, warnings and errors. You can also change this
|
||||||
setting from within a telnet or gdb session using @command{debug_level
|
setting from within a telnet or gdb session using @command{debug_level<n>}
|
||||||
<n>} (@pxref{debug_level}).
|
(@pxref{debuglevel,,debug_level}).
|
||||||
|
|
||||||
You can redirect all output from the daemon to a file using the
|
You can redirect all output from the daemon to a file using the
|
||||||
@option{-l <logfile>} switch.
|
@option{-l <logfile>} switch.
|
||||||
|
@ -934,7 +936,7 @@ need help from OpenOCD to discover what's on the board.
|
||||||
Once you find the JTAG TAPs, you can just search for appropriate
|
Once you find the JTAG TAPs, you can just search for appropriate
|
||||||
target and board
|
target and board
|
||||||
configuration files ... or write your own, from the bottom up.
|
configuration files ... or write your own, from the bottom up.
|
||||||
@xref{Autoprobing}.
|
@xref{autoprobing,,Autoprobing}.
|
||||||
|
|
||||||
@item You can often reuse some standard config files but
|
@item You can often reuse some standard config files but
|
||||||
need to write a few new ones, probably a @file{board.cfg} file.
|
need to write a few new ones, probably a @file{board.cfg} file.
|
||||||
|
@ -986,7 +988,7 @@ and @command{cortex_m3 vector_catch}) can be a timesaver
|
||||||
during some debug sessions, but don't make everyone use that either.
|
during some debug sessions, but don't make everyone use that either.
|
||||||
Keep those kinds of debugging aids in your user config file,
|
Keep those kinds of debugging aids in your user config file,
|
||||||
along with messaging and tracing setup.
|
along with messaging and tracing setup.
|
||||||
(@xref{Software Debug Messages and Tracing}.)
|
(@xref{softwaredebugmessagesandtracing,,Software Debug Messages and Tracing}.)
|
||||||
|
|
||||||
@item
|
@item
|
||||||
You might need to override some defaults.
|
You might need to override some defaults.
|
||||||
|
@ -996,7 +998,7 @@ work area if your application needs much SRAM.
|
||||||
@item
|
@item
|
||||||
TCP/IP port configuration is another example of something which
|
TCP/IP port configuration is another example of something which
|
||||||
is environment-specific, and should only appear in
|
is environment-specific, and should only appear in
|
||||||
a user config file. @xref{TCP/IP Ports}.
|
a user config file. @xref{tcpipports,,TCP/IP Ports}.
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
@section Project-Specific Utilities
|
@section Project-Specific Utilities
|
||||||
|
@ -1153,7 +1155,7 @@ Your application may want to deliver various debugging messages
|
||||||
over JTAG, by @emph{linking with a small library of code}
|
over JTAG, by @emph{linking with a small library of code}
|
||||||
provided with OpenOCD and using the utilities there to send
|
provided with OpenOCD and using the utilities there to send
|
||||||
various kinds of message.
|
various kinds of message.
|
||||||
@xref{Software Debug Messages and Tracing}.
|
@xref{softwaredebugmessagesandtracing,,Software Debug Messages and Tracing}.
|
||||||
|
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
|
@ -1482,8 +1484,8 @@ In summary the board files should contain (if present)
|
||||||
|
|
||||||
@enumerate
|
@enumerate
|
||||||
@item One or more @command{source [target/...cfg]} statements
|
@item One or more @command{source [target/...cfg]} statements
|
||||||
@item NOR flash configuration (@pxref{NOR Configuration})
|
@item NOR flash configuration (@pxref{norconfiguration,,NOR Configuration})
|
||||||
@item NAND flash configuration (@pxref{NAND Configuration})
|
@item NAND flash configuration (@pxref{nandconfiguration,,NAND Configuration})
|
||||||
@item Target @code{reset} handlers for SDRAM and I/O configuration
|
@item Target @code{reset} handlers for SDRAM and I/O configuration
|
||||||
@item JTAG adapter reset configuration (@pxref{Reset Configuration})
|
@item JTAG adapter reset configuration (@pxref{Reset Configuration})
|
||||||
@item All things that are not ``inside a chip''
|
@item All things that are not ``inside a chip''
|
||||||
|
@ -1619,7 +1621,7 @@ are included here.
|
||||||
Instead, look at the board config files distributed with OpenOCD.
|
Instead, look at the board config files distributed with OpenOCD.
|
||||||
If you have a boot loader, its source code will help; so will
|
If you have a boot loader, its source code will help; so will
|
||||||
configuration files for other JTAG tools
|
configuration files for other JTAG tools
|
||||||
(@pxref{Translating Configuration Files}).
|
(@pxref{translatingconfigurationfiles,,Translating Configuration Files}).
|
||||||
@end quotation
|
@end quotation
|
||||||
|
|
||||||
Some of this code could probably be shared between different boards.
|
Some of this code could probably be shared between different boards.
|
||||||
|
@ -1643,7 +1645,7 @@ access uses the CPU or to prevent conflicting CPU access.
|
||||||
Before your @code{reset-init} handler has set up
|
Before your @code{reset-init} handler has set up
|
||||||
the PLLs and clocking, you may need to run with
|
the PLLs and clocking, you may need to run with
|
||||||
a low JTAG clock rate.
|
a low JTAG clock rate.
|
||||||
@xref{JTAG Speed}.
|
@xref{jtagspeed,,JTAG Speed}.
|
||||||
Then you'd increase that rate after your handler has
|
Then you'd increase that rate after your handler has
|
||||||
made it possible to use the faster JTAG clock.
|
made it possible to use the faster JTAG clock.
|
||||||
When the initial low speed is board-specific, for example
|
When the initial low speed is board-specific, for example
|
||||||
|
@ -1671,19 +1673,21 @@ also supports it. Otherwise use @command{adapter_khz}.
|
||||||
Set the slow rate at the beginning of the reset sequence,
|
Set the slow rate at the beginning of the reset sequence,
|
||||||
and the faster rate as soon as the clocks are at full speed.
|
and the faster rate as soon as the clocks are at full speed.
|
||||||
|
|
||||||
@anchor{The init_board procedure}
|
@anchor{theinitboardprocedure}
|
||||||
@subsection The init_board procedure
|
@subsection The init_board procedure
|
||||||
@cindex init_board procedure
|
@cindex init_board procedure
|
||||||
|
|
||||||
The concept of @code{init_board} procedure is very similar to @code{init_targets} (@xref{The init_targets procedure}.)
|
The concept of @code{init_board} procedure is very similar to @code{init_targets}
|
||||||
- it's a replacement of ``linear'' configuration scripts. This procedure is meant to be executed when OpenOCD enters run
|
(@xref{theinittargetsprocedure,,The init_targets procedure}.) - it's a replacement of ``linear''
|
||||||
stage (@xref{Entering the Run Stage},) after @code{init_targets}. The idea to have spearate @code{init_targets} and
|
configuration scripts. This procedure is meant to be executed when OpenOCD enters run stage
|
||||||
@code{init_board} procedures is to allow the first one to configure everything target specific (internal flash,
|
(@xref{enteringtherunstage,,Entering the Run Stage},) after @code{init_targets}. The idea to have
|
||||||
internal RAM, etc.) and the second one to configure everything board specific (reset signals, chip frequency,
|
spearate @code{init_targets} and @code{init_board} procedures is to allow the first one to configure
|
||||||
reset-init event handler, external memory, etc.). Additionally ``linear'' board config file will most likely fail when
|
everything target specific (internal flash, internal RAM, etc.) and the second one to configure
|
||||||
target config file uses @code{init_targets} scheme (``linear'' script is executed before @code{init} and
|
everything board specific (reset signals, chip frequency, reset-init event handler, external memory, etc.).
|
||||||
@code{init_targets} - after), so separating these two configuration stages is very convenient, as the easiest way to
|
Additionally ``linear'' board config file will most likely fail when target config file uses
|
||||||
overcome this problem is to convert board config file to use @code{init_board} procedure. Board config scripts don't
|
@code{init_targets} scheme (``linear'' script is executed before @code{init} and @code{init_targets} - after),
|
||||||
|
so separating these two configuration stages is very convenient, as the easiest way to overcome this
|
||||||
|
problem is to convert board config file to use @code{init_board} procedure. Board config scripts don't
|
||||||
need to override @code{init_targets} defined in target config files when they only need to to add some specifics.
|
need to override @code{init_targets} defined in target config files when they only need to to add some specifics.
|
||||||
|
|
||||||
Just as @code{init_targets}, the @code{init_board} procedure can be overriden by ``next level'' script (which sources
|
Just as @code{init_targets}, the @code{init_board} procedure can be overriden by ``next level'' script (which sources
|
||||||
|
@ -1864,7 +1868,7 @@ $_TARGETNAME configure -work-area-phys 0x00200000 \
|
||||||
-work-area-size 0x4000 -work-area-backup 0
|
-work-area-size 0x4000 -work-area-backup 0
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
@anchor{Define CPU targets working in SMP}
|
@anchor{definecputargetsworkinginsmp}
|
||||||
@subsection Define CPU targets working in SMP
|
@subsection Define CPU targets working in SMP
|
||||||
@cindex SMP
|
@cindex SMP
|
||||||
After setting targets, you can define a list of targets working in SMP.
|
After setting targets, you can define a list of targets working in SMP.
|
||||||
|
@ -1887,7 +1891,7 @@ In SMP only one GDB instance is created and :
|
||||||
@item resume command triggers the write context and the restart of all targets in the list.
|
@item resume command triggers the write context and the restart of all targets in the list.
|
||||||
@item following a breakpoint: the target stopped by the breakpoint is displayed to the GDB session.
|
@item following a breakpoint: the target stopped by the breakpoint is displayed to the GDB session.
|
||||||
@item dedicated GDB serial protocol packets are implemented for switching/retrieving the target
|
@item dedicated GDB serial protocol packets are implemented for switching/retrieving the target
|
||||||
displayed by the GDB session @pxref{Using openocd SMP with GDB}.
|
displayed by the GDB session @pxref{usingopenocdsmpwithgdb,,Using OpenOCD SMP with GDB}.
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
The SMP behaviour can be disabled/enabled dynamically. On cortex_a8 following
|
The SMP behaviour can be disabled/enabled dynamically. On cortex_a8 following
|
||||||
|
@ -1963,7 +1967,7 @@ slower clock than they will use later.
|
||||||
That means that after reset (and potentially, as OpenOCD
|
That means that after reset (and potentially, as OpenOCD
|
||||||
first starts up) they must use a slower JTAG clock rate
|
first starts up) they must use a slower JTAG clock rate
|
||||||
than they will use later.
|
than they will use later.
|
||||||
@xref{JTAG Speed}.
|
@xref{jtagspeed,,JTAG Speed}.
|
||||||
|
|
||||||
@quotation Important
|
@quotation Important
|
||||||
When you are debugging code that runs right after chip
|
When you are debugging code that runs right after chip
|
||||||
|
@ -1973,17 +1977,19 @@ OpenOCD verifies the scan chain after reset,
|
||||||
look at how you are setting up JTAG clocking.
|
look at how you are setting up JTAG clocking.
|
||||||
@end quotation
|
@end quotation
|
||||||
|
|
||||||
@anchor{The init_targets procedure}
|
@anchor{theinittargetsprocedure}
|
||||||
@subsection The init_targets procedure
|
@subsection The init_targets procedure
|
||||||
@cindex init_targets procedure
|
@cindex init_targets procedure
|
||||||
|
|
||||||
Target config files can either be ``linear'' (script executed line-by-line when parsed in configuration stage,
|
Target config files can either be ``linear'' (script executed line-by-line when parsed in
|
||||||
@xref{Configuration Stage},) or they can contain a special procedure called @code{init_targets}, which will be executed
|
configuration stage, @xref{configurationstage,,Configuration Stage},) or they can contain a special
|
||||||
when entering run stage (after parsing all config files or after @code{init} command, @xref{Entering the Run Stage}.)
|
procedure called @code{init_targets}, which will be executed when entering run stage
|
||||||
Such procedure can be overriden by ``next level'' script (which sources the original). This concept faciliates code
|
(after parsing all config files or after @code{init} command, @xref{enteringtherunstage,,Entering the Run Stage}.)
|
||||||
reuse when basic target config files provide generic configuration procedures and @code{init_targets} procedure, which
|
Such procedure can be overriden by ``next level'' script (which sources the original).
|
||||||
can then be sourced and enchanced or changed in a ``more specific'' target config file. This is not possible with
|
This concept faciliates code reuse when basic target config files provide generic configuration
|
||||||
``linear'' config scripts, because sourcing them executes every initialization commands they provide.
|
procedures and @code{init_targets} procedure, which can then be sourced and enchanced or changed in
|
||||||
|
a ``more specific'' target config file. This is not possible with ``linear'' config scripts,
|
||||||
|
because sourcing them executes every initialization commands they provide.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
### generic_file.cfg ###
|
### generic_file.cfg ###
|
||||||
|
@ -2007,12 +2013,13 @@ proc init_targets @{@} @{
|
||||||
@}
|
@}
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
The easiest way to convert ``linear'' config files to @code{init_targets} version is to enclose every line of ``code''
|
The easiest way to convert ``linear'' config files to @code{init_targets} version is to
|
||||||
(i.e. not @code{source} commands, procedures, etc.) in this procedure.
|
enclose every line of ``code'' (i.e. not @code{source} commands, procedures, etc.) in this procedure.
|
||||||
|
|
||||||
For an example of this scheme see LPC2000 target config files.
|
For an example of this scheme see LPC2000 target config files.
|
||||||
|
|
||||||
The @code{init_boards} procedure is a similar concept concerning board config files (@xref{The init_board procedure}.)
|
The @code{init_boards} procedure is a similar concept concerning board config files
|
||||||
|
(@xref{theinitboardprocedure,,The init_board procedure}.)
|
||||||
|
|
||||||
@subsection ARM Core Specific Hacks
|
@subsection ARM Core Specific Hacks
|
||||||
|
|
||||||
|
@ -2025,7 +2032,7 @@ Some ARM cores are equipped with trace support, which permits
|
||||||
examination of the instruction and data bus activity. Trace
|
examination of the instruction and data bus activity. Trace
|
||||||
activity is controlled through an ``Embedded Trace Module'' (ETM)
|
activity is controlled through an ``Embedded Trace Module'' (ETM)
|
||||||
on one of the core's scan chains. The ETM emits voluminous data
|
on one of the core's scan chains. The ETM emits voluminous data
|
||||||
through a ``trace port''. (@xref{ARM Hardware Tracing}.)
|
through a ``trace port''. (@xref{armhardwaretracing,,ARM Hardware Tracing}.)
|
||||||
If you are using an external trace port,
|
If you are using an external trace port,
|
||||||
configure it in your board config file.
|
configure it in your board config file.
|
||||||
If you are using an on-chip ``Embedded Trace Buffer'' (ETB),
|
If you are using an on-chip ``Embedded Trace Buffer'' (ETB),
|
||||||
|
@ -2053,7 +2060,7 @@ Examples:
|
||||||
@item pxa270 - again - CS0 flash - it goes in the board file.
|
@item pxa270 - again - CS0 flash - it goes in the board file.
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
@anchor{Translating Configuration Files}
|
@anchor{translatingconfigurationfiles}
|
||||||
@section Translating Configuration Files
|
@section Translating Configuration Files
|
||||||
@cindex translation
|
@cindex translation
|
||||||
If you have a configuration file for another hardware debugger
|
If you have a configuration file for another hardware debugger
|
||||||
|
@ -2100,7 +2107,7 @@ The commands here are commonly found in the openocd.cfg file and are
|
||||||
used to specify what TCP/IP ports are used, and how GDB should be
|
used to specify what TCP/IP ports are used, and how GDB should be
|
||||||
supported.
|
supported.
|
||||||
|
|
||||||
@anchor{Configuration Stage}
|
@anchor{configurationstage}
|
||||||
@section Configuration Stage
|
@section Configuration Stage
|
||||||
@cindex configuration stage
|
@cindex configuration stage
|
||||||
@cindex config command
|
@cindex config command
|
||||||
|
@ -2126,7 +2133,7 @@ may access or activate TAPs.
|
||||||
After it leaves this stage, configuration commands may no
|
After it leaves this stage, configuration commands may no
|
||||||
longer be issued.
|
longer be issued.
|
||||||
|
|
||||||
@anchor{Entering the Run Stage}
|
@anchor{enteringtherunstage}
|
||||||
@section Entering the Run Stage
|
@section Entering the Run Stage
|
||||||
|
|
||||||
The first thing OpenOCD does after leaving the configuration
|
The first thing OpenOCD does after leaving the configuration
|
||||||
|
@ -2184,7 +2191,7 @@ This is done by calling @command{jtag arp_init}
|
||||||
(or @command{jtag arp_init-reset}).
|
(or @command{jtag arp_init-reset}).
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{TCP/IP Ports}
|
@anchor{tcpipports}
|
||||||
@section TCP/IP Ports
|
@section TCP/IP Ports
|
||||||
@cindex TCP port
|
@cindex TCP port
|
||||||
@cindex server
|
@cindex server
|
||||||
|
@ -2246,16 +2253,16 @@ the port @var{number} defaults to 4444.
|
||||||
When specified as zero, this port is not activated.
|
When specified as zero, this port is not activated.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{GDB Configuration}
|
@anchor{gdbconfiguration}
|
||||||
@section GDB Configuration
|
@section GDB Configuration
|
||||||
@cindex GDB
|
@cindex GDB
|
||||||
@cindex GDB configuration
|
@cindex GDB configuration
|
||||||
You can reconfigure some GDB behaviors if needed.
|
You can reconfigure some GDB behaviors if needed.
|
||||||
The ones listed here are static and global.
|
The ones listed here are static and global.
|
||||||
@xref{Target Configuration}, about configuring individual targets.
|
@xref{targetconfiguration,,Target Configuration}, about configuring individual targets.
|
||||||
@xref{Target Events}, about configuring target-specific event handling.
|
@xref{targetevents,,Target Events}, about configuring target-specific event handling.
|
||||||
|
|
||||||
@anchor{gdb_breakpoint_override}
|
@anchor{gdbbreakpointoverride}
|
||||||
@deffn {Command} gdb_breakpoint_override [@option{hard}|@option{soft}|@option{disable}]
|
@deffn {Command} gdb_breakpoint_override [@option{hard}|@option{soft}|@option{disable}]
|
||||||
Force breakpoint type for gdb @command{break} commands.
|
Force breakpoint type for gdb @command{break} commands.
|
||||||
This option supports GDB GUIs which don't
|
This option supports GDB GUIs which don't
|
||||||
|
@ -2264,7 +2271,7 @@ GDB behaviour is not sufficient. GDB normally uses hardware
|
||||||
breakpoints if the memory map has been set up for flash regions.
|
breakpoints if the memory map has been set up for flash regions.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{gdb_flash_program}
|
@anchor{gdbflashprogram}
|
||||||
@deffn {Config Command} gdb_flash_program (@option{enable}|@option{disable})
|
@deffn {Config Command} gdb_flash_program (@option{enable}|@option{disable})
|
||||||
Set to @option{enable} to cause OpenOCD to program the flash memory when a
|
Set to @option{enable} to cause OpenOCD to program the flash memory when a
|
||||||
vFlash packet is received.
|
vFlash packet is received.
|
||||||
|
@ -2277,7 +2284,7 @@ requested. GDB will then know when to set hardware breakpoints, and program flas
|
||||||
using the GDB load command. @command{gdb_flash_program enable} must also be enabled
|
using the GDB load command. @command{gdb_flash_program enable} must also be enabled
|
||||||
for flash programming to work.
|
for flash programming to work.
|
||||||
Default behaviour is @option{enable}.
|
Default behaviour is @option{enable}.
|
||||||
@xref{gdb_flash_program}.
|
@xref{gdbflashprogram,,gdb_flash_program}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@deffn {Config Command} gdb_report_data_abort (@option{enable}|@option{disable})
|
@deffn {Config Command} gdb_report_data_abort (@option{enable}|@option{disable})
|
||||||
|
@ -2287,7 +2294,7 @@ The default behaviour is @option{disable};
|
||||||
use @option{enable} see these errors reported.
|
use @option{enable} see these errors reported.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Event Polling}
|
@anchor{eventpolling}
|
||||||
@section Event Polling
|
@section Event Polling
|
||||||
|
|
||||||
Hardware debuggers are parts of asynchronous systems,
|
Hardware debuggers are parts of asynchronous systems,
|
||||||
|
@ -2328,7 +2335,7 @@ which is normally done in the background.
|
||||||
|
|
||||||
@deffn Command poll [@option{on}|@option{off}]
|
@deffn Command poll [@option{on}|@option{off}]
|
||||||
Poll the current target for its current state.
|
Poll the current target for its current state.
|
||||||
(Also, @pxref{target curstate}.)
|
(Also, @pxref{targetcurstate,,target curstate}.)
|
||||||
If that target is in debug mode, architecture
|
If that target is in debug mode, architecture
|
||||||
specific information about the current state is printed.
|
specific information about the current state is printed.
|
||||||
An optional parameter
|
An optional parameter
|
||||||
|
@ -3038,7 +3045,7 @@ The Serial Peripheral Interface (SPI) is a general purpose transport
|
||||||
which uses four wire signaling. Some processors use it as part of a
|
which uses four wire signaling. Some processors use it as part of a
|
||||||
solution for flash programming.
|
solution for flash programming.
|
||||||
|
|
||||||
@anchor{JTAG Speed}
|
@anchor{jtagspeed}
|
||||||
@section JTAG Speed
|
@section JTAG Speed
|
||||||
JTAG clock setup is part of system setup.
|
JTAG clock setup is part of system setup.
|
||||||
It @emph{does not belong with interface setup} since any interface
|
It @emph{does not belong with interface setup} since any interface
|
||||||
|
@ -3057,7 +3064,7 @@ It can then be reconfigured to a faster speed by a
|
||||||
@code{reset-init} target event handler after it reprograms those
|
@code{reset-init} target event handler after it reprograms those
|
||||||
CPU clocks, or manually (if something else, such as a boot loader,
|
CPU clocks, or manually (if something else, such as a boot loader,
|
||||||
sets up those clocks).
|
sets up those clocks).
|
||||||
@xref{Target Events}.
|
@xref{targetevents,,Target Events}.
|
||||||
When the initial low JTAG speed is a chip characteristic, perhaps
|
When the initial low JTAG speed is a chip characteristic, perhaps
|
||||||
because of a required oscillator speed, provide such a handler
|
because of a required oscillator speed, provide such a handler
|
||||||
in the target config file.
|
in the target config file.
|
||||||
|
@ -3094,7 +3101,7 @@ and is normally less than that peak rate.
|
||||||
For example, most ARM cores accept at most one sixth of the CPU clock.
|
For example, most ARM cores accept at most one sixth of the CPU clock.
|
||||||
|
|
||||||
Speed 0 (khz) selects RTCK method.
|
Speed 0 (khz) selects RTCK method.
|
||||||
@xref{FAQ RTCK}.
|
@xref{faqrtck,,FAQ RTCK}.
|
||||||
If your system uses RTCK, you won't need to change the
|
If your system uses RTCK, you won't need to change the
|
||||||
JTAG clocking after setup.
|
JTAG clocking after setup.
|
||||||
Not all interfaces, boards, or targets support ``rtck''.
|
Not all interfaces, boards, or targets support ``rtck''.
|
||||||
|
@ -3122,7 +3129,7 @@ Every system configuration may require a different reset
|
||||||
configuration. This can also be quite confusing.
|
configuration. This can also be quite confusing.
|
||||||
Resets also interact with @var{reset-init} event handlers,
|
Resets also interact with @var{reset-init} event handlers,
|
||||||
which do things like setting up clocks and DRAM, and
|
which do things like setting up clocks and DRAM, and
|
||||||
JTAG clock rates. (@xref{JTAG Speed}.)
|
JTAG clock rates. (@xref{jtagspeed,,JTAG Speed}.)
|
||||||
They can also interact with JTAG routers.
|
They can also interact with JTAG routers.
|
||||||
Please see the various board files for examples.
|
Please see the various board files for examples.
|
||||||
|
|
||||||
|
@ -3179,9 +3186,9 @@ halted under debugger control before any code has executed.
|
||||||
This is the behavior required to support the @command{reset halt}
|
This is the behavior required to support the @command{reset halt}
|
||||||
and @command{reset init} commands; after @command{reset init} a
|
and @command{reset init} commands; after @command{reset init} a
|
||||||
board-specific script might do things like setting up DRAM.
|
board-specific script might do things like setting up DRAM.
|
||||||
(@xref{Reset Command}.)
|
(@xref{resetcommand,,Reset Command}.)
|
||||||
|
|
||||||
@anchor{SRST and TRST Issues}
|
@anchor{srstandtrstissues}
|
||||||
@section SRST and TRST Issues
|
@section SRST and TRST Issues
|
||||||
|
|
||||||
Because SRST and TRST are hardware signals, they can have a
|
Because SRST and TRST are hardware signals, they can have a
|
||||||
|
@ -3282,7 +3289,7 @@ of your combination of JTAG board and target in target
|
||||||
configuration scripts.
|
configuration scripts.
|
||||||
|
|
||||||
Information earlier in this section describes the kind of problems
|
Information earlier in this section describes the kind of problems
|
||||||
the command is intended to address (@pxref{SRST and TRST Issues}).
|
the command is intended to address (@pxref{srstandtrstissues,,SRST and TRST Issues}).
|
||||||
As a rule this command belongs only in board config files,
|
As a rule this command belongs only in board config files,
|
||||||
describing issues like @emph{board doesn't connect TRST};
|
describing issues like @emph{board doesn't connect TRST};
|
||||||
or in user config files, addressing limitations derived
|
or in user config files, addressing limitations derived
|
||||||
|
@ -3401,7 +3408,7 @@ to find a sequence of operations that works.
|
||||||
@xref{JTAG Commands}.
|
@xref{JTAG Commands}.
|
||||||
When you find a working sequence, it can be used to override
|
When you find a working sequence, it can be used to override
|
||||||
@command{jtag_init}, which fires during OpenOCD startup
|
@command{jtag_init}, which fires during OpenOCD startup
|
||||||
(@pxref{Configuration Stage});
|
(@pxref{configurationstage,,Configuration Stage});
|
||||||
or @command{init_reset}, which fires during reset processing.
|
or @command{init_reset}, which fires during reset processing.
|
||||||
|
|
||||||
You might also want to provide some project-specific reset
|
You might also want to provide some project-specific reset
|
||||||
|
@ -3511,7 +3518,7 @@ Here's what the scan chain might look like for a chip more than one TAP:
|
||||||
@end verbatim
|
@end verbatim
|
||||||
|
|
||||||
OpenOCD can detect some of that information, but not all
|
OpenOCD can detect some of that information, but not all
|
||||||
of it. @xref{Autoprobing}.
|
of it. @xref{autoprobing,,Autoprobing}.
|
||||||
Unfortunately those TAPs can't always be autoconfigured,
|
Unfortunately those TAPs can't always be autoconfigured,
|
||||||
because not all devices provide good support for that.
|
because not all devices provide good support for that.
|
||||||
JTAG doesn't require supporting IDCODE instructions, and
|
JTAG doesn't require supporting IDCODE instructions, and
|
||||||
|
@ -3534,7 +3541,7 @@ and so forth.
|
||||||
Note that @emph{the order in which TAPs are declared is very important.}
|
Note that @emph{the order in which TAPs are declared is very important.}
|
||||||
It must match the order in the JTAG scan chain, both inside
|
It must match the order in the JTAG scan chain, both inside
|
||||||
a single chip and between them.
|
a single chip and between them.
|
||||||
@xref{FAQ TAP Order}.
|
@xref{faqtaporder,,FAQ TAP Order}.
|
||||||
|
|
||||||
For example, the ST Microsystems STR912 chip has
|
For example, the ST Microsystems STR912 chip has
|
||||||
three separate TAPs@footnote{See the ST
|
three separate TAPs@footnote{See the ST
|
||||||
|
@ -3610,7 +3617,6 @@ reusing those scripts on boards with multiple targets.
|
||||||
@section TAP Declaration Commands
|
@section TAP Declaration Commands
|
||||||
|
|
||||||
@c shouldn't this be(come) a {Config Command}?
|
@c shouldn't this be(come) a {Config Command}?
|
||||||
@anchor{jtag newtap}
|
|
||||||
@deffn Command {jtag newtap} chipname tapname configparams...
|
@deffn Command {jtag newtap} chipname tapname configparams...
|
||||||
Declares a new TAP with the dotted name @var{chipname}.@var{tapname},
|
Declares a new TAP with the dotted name @var{chipname}.@var{tapname},
|
||||||
and configured according to the various @var{configparams}.
|
and configured according to the various @var{configparams}.
|
||||||
|
@ -3658,7 +3664,7 @@ linked in to the scan chain after a reset using either TRST
|
||||||
or the JTAG state machine's @sc{reset} state.
|
or the JTAG state machine's @sc{reset} state.
|
||||||
You may use @code{-enable} to highlight the default state
|
You may use @code{-enable} to highlight the default state
|
||||||
(the TAP is linked in).
|
(the TAP is linked in).
|
||||||
@xref{Enabling and Disabling TAPs}.
|
@xref{enablinganddisablingtaps,,Enabling and Disabling TAPs}.
|
||||||
@item @code{-expected-id} @var{number}
|
@item @code{-expected-id} @var{number}
|
||||||
@*A non-zero @var{number} represents a 32-bit IDCODE
|
@*A non-zero @var{number} represents a 32-bit IDCODE
|
||||||
which you expect to find when the scan chain is examined.
|
which you expect to find when the scan chain is examined.
|
||||||
|
@ -3673,7 +3679,7 @@ tell when the scan chain it sees isn't right. These values
|
||||||
are provided in vendors' chip documentation, usually a technical
|
are provided in vendors' chip documentation, usually a technical
|
||||||
reference manual. Sometimes you may need to probe the JTAG
|
reference manual. Sometimes you may need to probe the JTAG
|
||||||
hardware to find these values.
|
hardware to find these values.
|
||||||
@xref{Autoprobing}.
|
@xref{autoprobing,,Autoprobing}.
|
||||||
@item @code{-ignore-version}
|
@item @code{-ignore-version}
|
||||||
@*Specify this to ignore the JTAG version field in the @code{-expected-id}
|
@*Specify this to ignore the JTAG version field in the @code{-expected-id}
|
||||||
option. When vendors put out multiple versions of a chip, or use the same
|
option. When vendors put out multiple versions of a chip, or use the same
|
||||||
|
@ -3711,7 +3717,6 @@ a TCL string which is evaluated when the event is triggered.
|
||||||
The @code{cget} subcommand returns that handler.
|
The @code{cget} subcommand returns that handler.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{TAP Events}
|
|
||||||
@section TAP Events
|
@section TAP Events
|
||||||
@cindex events
|
@cindex events
|
||||||
@cindex TAP events
|
@cindex TAP events
|
||||||
|
@ -3760,7 +3765,7 @@ jtag configure CHIP.jrc -event post-reset @{
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
|
|
||||||
@anchor{Enabling and Disabling TAPs}
|
@anchor{enablinganddisablingtaps}
|
||||||
@section Enabling and Disabling TAPs
|
@section Enabling and Disabling TAPs
|
||||||
@cindex JTAG Route Controller
|
@cindex JTAG Route Controller
|
||||||
@cindex jrc
|
@cindex jrc
|
||||||
|
@ -3848,7 +3853,7 @@ for querying the state of the JTAG taps.
|
||||||
@end quotation
|
@end quotation
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Autoprobing}
|
@anchor{autoprobing}
|
||||||
@section Autoprobing
|
@section Autoprobing
|
||||||
@cindex autoprobe
|
@cindex autoprobe
|
||||||
@cindex JTAG autoprobe
|
@cindex JTAG autoprobe
|
||||||
|
@ -3924,7 +3929,7 @@ and so forth.
|
||||||
This chapter discusses how to set up GDB debug targets for CPUs.
|
This chapter discusses how to set up GDB debug targets for CPUs.
|
||||||
You can also access these targets without GDB
|
You can also access these targets without GDB
|
||||||
(@pxref{Architecture and Core Commands},
|
(@pxref{Architecture and Core Commands},
|
||||||
and @ref{Target State handling}) and
|
and @ref{targetstatehandling,,Target State handling}) and
|
||||||
through various kinds of NAND and NOR flash commands.
|
through various kinds of NAND and NOR flash commands.
|
||||||
If you have multiple CPUs you can have multiple such targets.
|
If you have multiple CPUs you can have multiple such targets.
|
||||||
|
|
||||||
|
@ -4042,7 +4047,7 @@ since there's a command to list them.
|
||||||
However, there is currently no way to list what target variants
|
However, there is currently no way to list what target variants
|
||||||
are supported (other than by reading the OpenOCD source code).
|
are supported (other than by reading the OpenOCD source code).
|
||||||
|
|
||||||
@anchor{target types}
|
@anchor{targettypes}
|
||||||
@deffn Command {target types}
|
@deffn Command {target types}
|
||||||
Lists all supported target types.
|
Lists all supported target types.
|
||||||
At this writing, the supported CPU types and variants are:
|
At this writing, the supported CPU types and variants are:
|
||||||
|
@ -4089,7 +4094,7 @@ reflect design generations;
|
||||||
while names like ARMv4, ARMv5, ARMv6, and ARMv7
|
while names like ARMv4, ARMv5, ARMv6, and ARMv7
|
||||||
reflect an architecture version implemented by a CPU design.
|
reflect an architecture version implemented by a CPU design.
|
||||||
|
|
||||||
@anchor{Target Configuration}
|
@anchor{targetconfiguration}
|
||||||
@section Target Configuration
|
@section Target Configuration
|
||||||
|
|
||||||
Before creating a ``target'', you must have added its TAP to the scan chain.
|
Before creating a ``target'', you must have added its TAP to the scan chain.
|
||||||
|
@ -4107,7 +4112,7 @@ command, created as part of target creation.
|
||||||
The two main things to configure after target creation are
|
The two main things to configure after target creation are
|
||||||
a work area, which usually has target-specific defaults even
|
a work area, which usually has target-specific defaults even
|
||||||
if the board setup code overrides them later;
|
if the board setup code overrides them later;
|
||||||
and event handlers (@pxref{Target Events}), which tend
|
and event handlers (@pxref{targetevents,,Target Events}), which tend
|
||||||
to be much more board-specific.
|
to be much more board-specific.
|
||||||
The key steps you use might look something like this
|
The key steps you use might look something like this
|
||||||
|
|
||||||
|
@ -4160,7 +4165,7 @@ using the @code{-chain-position @var{dotted.name}} configparam.
|
||||||
This name is also used to create the target object command,
|
This name is also used to create the target object command,
|
||||||
referred to here as @command{$target_name},
|
referred to here as @command{$target_name},
|
||||||
and in other places the target needs to be identified.
|
and in other places the target needs to be identified.
|
||||||
@item @var{type} ... specifies the target type. @xref{target types}.
|
@item @var{type} ... specifies the target type. @xref{targettypes,,target types}.
|
||||||
@item @var{configparams} ... all parameters accepted by
|
@item @var{configparams} ... all parameters accepted by
|
||||||
@command{$target_name configure} are permitted.
|
@command{$target_name configure} are permitted.
|
||||||
If the target is big-endian, set it here with @code{-endian big}.
|
If the target is big-endian, set it here with @code{-endian big}.
|
||||||
|
@ -4189,7 +4194,7 @@ used to access this target.
|
||||||
whether the CPU uses big or little endian conventions
|
whether the CPU uses big or little endian conventions
|
||||||
|
|
||||||
@item @code{-event} @var{event_name} @var{event_body} --
|
@item @code{-event} @var{event_name} @var{event_body} --
|
||||||
@xref{Target Events}.
|
@xref{targetevents,,Target Events}.
|
||||||
Note that this updates a list of named event handlers.
|
Note that this updates a list of named event handlers.
|
||||||
Calling this twice with two different event names assigns
|
Calling this twice with two different event names assigns
|
||||||
two different handlers, but calling it twice with the
|
two different handlers, but calling it twice with the
|
||||||
|
@ -4324,20 +4329,20 @@ foreach name [target names] @{
|
||||||
@end example
|
@end example
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{target curstate}
|
@anchor{targetcurstate}
|
||||||
@deffn Command {$target_name curstate}
|
@deffn Command {$target_name curstate}
|
||||||
Displays the current target state:
|
Displays the current target state:
|
||||||
@code{debug-running},
|
@code{debug-running},
|
||||||
@code{halted},
|
@code{halted},
|
||||||
@code{reset},
|
@code{reset},
|
||||||
@code{running}, or @code{unknown}.
|
@code{running}, or @code{unknown}.
|
||||||
(Also, @pxref{Event Polling}.)
|
(Also, @pxref{eventpolling,,Event Polling}.)
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@deffn Command {$target_name eventlist}
|
@deffn Command {$target_name eventlist}
|
||||||
Displays a table listing all event handlers
|
Displays a table listing all event handlers
|
||||||
currently associated with this target.
|
currently associated with this target.
|
||||||
@xref{Target Events}.
|
@xref{targetevents,,Target Events}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@deffn Command {$target_name invoke-event} event_name
|
@deffn Command {$target_name invoke-event} event_name
|
||||||
|
@ -4365,7 +4370,7 @@ Writes the specified @var{word} (32 bits),
|
||||||
at the specified address @var{addr}.
|
at the specified address @var{addr}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Target Events}
|
@anchor{targetevents}
|
||||||
@section Target Events
|
@section Target Events
|
||||||
@cindex target events
|
@cindex target events
|
||||||
@cindex events
|
@cindex events
|
||||||
|
@ -4528,7 +4533,7 @@ boot loader, operating system, or other data.
|
||||||
@item GDB Flashing
|
@item GDB Flashing
|
||||||
@* Flashing via GDB requires the flash be configured via ``flash
|
@* Flashing via GDB requires the flash be configured via ``flash
|
||||||
bank'', and the GDB flash features be enabled.
|
bank'', and the GDB flash features be enabled.
|
||||||
@xref{GDB Configuration}.
|
@xref{gdbconfiguration,,GDB Configuration}.
|
||||||
@end enumerate
|
@end enumerate
|
||||||
|
|
||||||
Many CPUs have the ablity to ``boot'' from the first flash bank.
|
Many CPUs have the ablity to ``boot'' from the first flash bank.
|
||||||
|
@ -4537,7 +4542,7 @@ so that it can't boot.
|
||||||
JTAG tools, like OpenOCD, are often then used to ``de-brick'' the
|
JTAG tools, like OpenOCD, are often then used to ``de-brick'' the
|
||||||
board by (re)installing working boot firmware.
|
board by (re)installing working boot firmware.
|
||||||
|
|
||||||
@anchor{NOR Configuration}
|
@anchor{norconfiguration}
|
||||||
@section Flash Configuration Commands
|
@section Flash Configuration Commands
|
||||||
@cindex flash configuration
|
@cindex flash configuration
|
||||||
|
|
||||||
|
@ -4555,7 +4560,7 @@ in other flash commands. A number is also available.
|
||||||
associated with the flash bank being declared.
|
associated with the flash bank being declared.
|
||||||
This is usually @code{cfi} for external flash, or else
|
This is usually @code{cfi} for external flash, or else
|
||||||
the name of a microcontroller with embedded flash memory.
|
the name of a microcontroller with embedded flash memory.
|
||||||
@xref{Flash Driver List}.
|
@xref{flashdriverlist,,Flash Driver List}.
|
||||||
@item @var{base} ... Base address of the flash chip.
|
@item @var{base} ... Base address of the flash chip.
|
||||||
@item @var{size} ... Size of the chip, in bytes.
|
@item @var{size} ... Size of the chip, in bytes.
|
||||||
For some drivers, this value is detected from the hardware.
|
For some drivers, this value is detected from the hardware.
|
||||||
|
@ -4605,13 +4610,13 @@ but most don't bother.
|
||||||
@cindex flash reading
|
@cindex flash reading
|
||||||
@cindex flash writing
|
@cindex flash writing
|
||||||
@cindex flash programming
|
@cindex flash programming
|
||||||
@anchor{Flash Programming Commands}
|
@anchor{flashprogrammingcommands}
|
||||||
|
|
||||||
One feature distinguishing NOR flash from NAND or serial flash technologies
|
One feature distinguishing NOR flash from NAND or serial flash technologies
|
||||||
is that for read access, it acts exactly like any other addressible memory.
|
is that for read access, it acts exactly like any other addressible memory.
|
||||||
This means you can use normal memory read commands like @command{mdw} or
|
This means you can use normal memory read commands like @command{mdw} or
|
||||||
@command{dump_image} with it, with no special @command{flash} subcommands.
|
@command{dump_image} with it, with no special @command{flash} subcommands.
|
||||||
@xref{Memory access}, and @ref{Image access}.
|
@xref{memoryaccess,,Memory access}, and @ref{imageaccess,,Image access}.
|
||||||
|
|
||||||
Write access works differently. Flash memory normally needs to be erased
|
Write access works differently. Flash memory normally needs to be erased
|
||||||
before it's written. Erasing a sector turns all of its bits to ones, and
|
before it's written. Erasing a sector turns all of its bits to ones, and
|
||||||
|
@ -4637,9 +4642,8 @@ For such systems, erasing and writing may require sector protection to be
|
||||||
disabled first.
|
disabled first.
|
||||||
Examples include CFI flash such as ``Intel Advanced Bootblock flash'',
|
Examples include CFI flash such as ``Intel Advanced Bootblock flash'',
|
||||||
and AT91SAM7 on-chip flash.
|
and AT91SAM7 on-chip flash.
|
||||||
@xref{flash protect}.
|
@xref{flashprotect,,flash protect}.
|
||||||
|
|
||||||
@anchor{flash erase_sector}
|
|
||||||
@deffn Command {flash erase_sector} num first last
|
@deffn Command {flash erase_sector} num first last
|
||||||
Erase sectors in bank @var{num}, starting at sector @var{first}
|
Erase sectors in bank @var{num}, starting at sector @var{first}
|
||||||
up to and including @var{last}.
|
up to and including @var{last}.
|
||||||
|
@ -4679,14 +4683,12 @@ each block, and the specified length must stay within that bank.
|
||||||
@end deffn
|
@end deffn
|
||||||
@comment no current checks for errors if fill blocks touch multiple banks!
|
@comment no current checks for errors if fill blocks touch multiple banks!
|
||||||
|
|
||||||
@anchor{flash write_bank}
|
|
||||||
@deffn Command {flash write_bank} num filename offset
|
@deffn Command {flash write_bank} num filename offset
|
||||||
Write the binary @file{filename} to flash bank @var{num},
|
Write the binary @file{filename} to flash bank @var{num},
|
||||||
starting at @var{offset} bytes from the beginning of the bank.
|
starting at @var{offset} bytes from the beginning of the bank.
|
||||||
The @var{num} parameter is a value shown by @command{flash banks}.
|
The @var{num} parameter is a value shown by @command{flash banks}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{flash write_image}
|
|
||||||
@deffn Command {flash write_image} [erase] [unlock] filename [offset] [type]
|
@deffn Command {flash write_image} [erase] [unlock] filename [offset] [type]
|
||||||
Write the image @file{filename} to the current target's flash bank(s).
|
Write the image @file{filename} to the current target's flash bank(s).
|
||||||
A relocation @var{offset} may be specified, in which case it is added
|
A relocation @var{offset} may be specified, in which case it is added
|
||||||
|
@ -4739,7 +4741,7 @@ This command will first query the hardware, it does not print cached
|
||||||
and possibly stale information.
|
and possibly stale information.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{flash protect}
|
@anchor{flashprotect}
|
||||||
@deffn Command {flash protect} num first last (@option{on}|@option{off})
|
@deffn Command {flash protect} num first last (@option{on}|@option{off})
|
||||||
Enable (@option{on}) or disable (@option{off}) protection of flash sectors
|
Enable (@option{on}) or disable (@option{off}) protection of flash sectors
|
||||||
in flash bank @var{num}, starting at sector @var{first}
|
in flash bank @var{num}, starting at sector @var{first}
|
||||||
|
@ -4756,7 +4758,7 @@ programmer. The only required parameter is @option{filename}, the others are opt
|
||||||
@xref{Flash Programming}.
|
@xref{Flash Programming}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Flash Driver List}
|
@anchor{flashdriverlist}
|
||||||
@section Flash Driver List
|
@section Flash Driver List
|
||||||
As noted above, the @command{flash bank} command requires a driver name,
|
As noted above, the @command{flash bank} command requires a driver name,
|
||||||
and allows driver-specific options and behaviors.
|
and allows driver-specific options and behaviors.
|
||||||
|
@ -5601,7 +5603,8 @@ Write the binary file @var{filename} to mflash bank @var{num}, starting at
|
||||||
@chapter Flash Programming
|
@chapter Flash Programming
|
||||||
|
|
||||||
OpenOCD implements numerous ways to program the target flash, whether internal or external.
|
OpenOCD implements numerous ways to program the target flash, whether internal or external.
|
||||||
Programming can be acheived by either using GDB @ref{Programming using GDB}, or using the cmds given in @ref{Flash Programming Commands}.
|
Programming can be acheived by either using GDB @ref{programmingusinggdb,,Programming using GDB},
|
||||||
|
or using the cmds given in @ref{flashprogrammingcommands,,Flash Programming Commands}.
|
||||||
|
|
||||||
@*To simplify using the flash cmds directly a jimtcl script is available that handles the programming and verify stage.
|
@*To simplify using the flash cmds directly a jimtcl script is available that handles the programming and verify stage.
|
||||||
OpenOCD will program/verify/reset the target and shutdown.
|
OpenOCD will program/verify/reset the target and shutdown.
|
||||||
|
@ -5693,7 +5696,7 @@ is larger than 0xffffffff, the largest 32-bit unsigned integer.)
|
||||||
Some larger devices will work, since they are actually multi-chip
|
Some larger devices will work, since they are actually multi-chip
|
||||||
modules with two smaller chips and individual chipselect lines.
|
modules with two smaller chips and individual chipselect lines.
|
||||||
|
|
||||||
@anchor{NAND Configuration}
|
@anchor{nandconfiguration}
|
||||||
@section NAND Configuration Commands
|
@section NAND Configuration Commands
|
||||||
@cindex NAND configuration
|
@cindex NAND configuration
|
||||||
|
|
||||||
|
@ -5719,7 +5722,7 @@ configuration files, not interactively.
|
||||||
in most other NAND commands. A number is also available.
|
in most other NAND commands. A number is also available.
|
||||||
@item @var{driver} ... identifies the NAND controller driver
|
@item @var{driver} ... identifies the NAND controller driver
|
||||||
associated with the NAND device being declared.
|
associated with the NAND device being declared.
|
||||||
@xref{NAND Driver List}.
|
@xref{nanddriverlist,,NAND Driver List}.
|
||||||
@item @var{target} ... names the target used when issuing
|
@item @var{target} ... names the target used when issuing
|
||||||
commands to the NAND controller.
|
commands to the NAND controller.
|
||||||
@comment Actually, it's currently a controller-specific parameter...
|
@comment Actually, it's currently a controller-specific parameter...
|
||||||
|
@ -5936,7 +5939,7 @@ bypassing hardware ECC logic.
|
||||||
with the wrong ECC data can cause them to be marked as bad.
|
with the wrong ECC data can cause them to be marked as bad.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{NAND Driver List}
|
@anchor{nanddriverlist}
|
||||||
@section NAND Driver List
|
@section NAND Driver List
|
||||||
As noted above, the @command{nand device} command allows
|
As noted above, the @command{nand device} command allows
|
||||||
driver-specific options and behaviors.
|
driver-specific options and behaviors.
|
||||||
|
@ -6171,7 +6174,7 @@ Useful in connection with script files
|
||||||
Close the OpenOCD daemon, disconnecting all clients (GDB, telnet, other).
|
Close the OpenOCD daemon, disconnecting all clients (GDB, telnet, other).
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{debug_level}
|
@anchor{debuglevel}
|
||||||
@deffn Command debug_level [n]
|
@deffn Command debug_level [n]
|
||||||
@cindex message level
|
@cindex message level
|
||||||
Display debug level.
|
Display debug level.
|
||||||
|
@ -6205,7 +6208,7 @@ the initial log output channel is stderr.
|
||||||
Add @var{directory} to the file/script search path.
|
Add @var{directory} to the file/script search path.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Target State handling}
|
@anchor{targetstatehandling}
|
||||||
@section Target State handling
|
@section Target State handling
|
||||||
@cindex reset
|
@cindex reset
|
||||||
@cindex halt
|
@cindex halt
|
||||||
|
@ -6302,7 +6305,7 @@ Single-step the target at its current code position,
|
||||||
or the optional @var{address} if it is provided.
|
or the optional @var{address} if it is provided.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Reset Command}
|
@anchor{resetcommand}
|
||||||
@deffn Command reset
|
@deffn Command reset
|
||||||
@deffnx Command {reset run}
|
@deffnx Command {reset run}
|
||||||
@deffnx Command {reset halt}
|
@deffnx Command {reset halt}
|
||||||
|
@ -6393,7 +6396,7 @@ Unlinks the file @file{filename}.
|
||||||
Removes all data in the file @file{filename}.
|
Removes all data in the file @file{filename}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Memory access}
|
@anchor{memoryaccess}
|
||||||
@section Memory access commands
|
@section Memory access commands
|
||||||
@cindex memory access
|
@cindex memory access
|
||||||
|
|
||||||
|
@ -6437,13 +6440,11 @@ Otherwise, or if the optional @var{phys} flag is specified,
|
||||||
@var{addr} is interpreted as a physical address.
|
@var{addr} is interpreted as a physical address.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
|
@anchor{imageaccess}
|
||||||
@anchor{Image access}
|
|
||||||
@section Image loading commands
|
@section Image loading commands
|
||||||
@cindex image loading
|
@cindex image loading
|
||||||
@cindex image dumping
|
@cindex image dumping
|
||||||
|
|
||||||
@anchor{dump_image}
|
|
||||||
@deffn Command {dump_image} filename address size
|
@deffn Command {dump_image} filename address size
|
||||||
Dump @var{size} bytes of target memory starting at @var{address} to the
|
Dump @var{size} bytes of target memory starting at @var{address} to the
|
||||||
binary file named @var{filename}.
|
binary file named @var{filename}.
|
||||||
|
@ -6465,7 +6466,6 @@ target programming performance as I/O and target programming can easily be profi
|
||||||
separately.
|
separately.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{load_image}
|
|
||||||
@deffn Command {load_image} filename address [[@option{bin}|@option{ihex}|@option{elf}|@option{s19}] @option{min_addr} @option{max_length}]
|
@deffn Command {load_image} filename address [[@option{bin}|@option{ihex}|@option{elf}|@option{s19}] @option{min_addr} @option{max_length}]
|
||||||
Load image from file @var{filename} to target memory offset by @var{address} from its load address.
|
Load image from file @var{filename} to target memory offset by @var{address} from its load address.
|
||||||
The file format may optionally be specified
|
The file format may optionally be specified
|
||||||
|
@ -6514,7 +6514,7 @@ at @var{address} for @var{length} bytes.
|
||||||
This is a software breakpoint, unless @option{hw} is specified
|
This is a software breakpoint, unless @option{hw} is specified
|
||||||
in which case it will be a hardware breakpoint.
|
in which case it will be a hardware breakpoint.
|
||||||
|
|
||||||
(@xref{arm9 vector_catch}, or @pxref{xscale vector_catch},
|
(@xref{arm9vectorcatch,,arm9 vector_catch}, or @pxref{xscalevectorcatch,,xscale vector_catch},
|
||||||
for similar mechanisms that do not consume hardware breakpoints.)
|
for similar mechanisms that do not consume hardware breakpoints.)
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
|
@ -6565,7 +6565,7 @@ OpenOCD packages most such operations in its standard command framework.
|
||||||
Some of those operations don't fit well in that framework, so they are
|
Some of those operations don't fit well in that framework, so they are
|
||||||
exposed here as architecture or implementation (core) specific commands.
|
exposed here as architecture or implementation (core) specific commands.
|
||||||
|
|
||||||
@anchor{ARM Hardware Tracing}
|
@anchor{armhardwaretracing}
|
||||||
@section ARM Hardware Tracing
|
@section ARM Hardware Tracing
|
||||||
@cindex tracing
|
@cindex tracing
|
||||||
@cindex ETM
|
@cindex ETM
|
||||||
|
@ -6628,7 +6628,7 @@ ETM setup is coupled with the trace port driver configuration.
|
||||||
|
|
||||||
@deffn {Config Command} {etm config} target width mode clocking driver
|
@deffn {Config Command} {etm config} target width mode clocking driver
|
||||||
Declares the ETM associated with @var{target}, and associates it
|
Declares the ETM associated with @var{target}, and associates it
|
||||||
with a given trace port @var{driver}. @xref{Trace Port Drivers}.
|
with a given trace port @var{driver}. @xref{traceportdrivers,,Trace Port Drivers}.
|
||||||
|
|
||||||
Several of the parameters must reflect the trace port capabilities,
|
Several of the parameters must reflect the trace port capabilities,
|
||||||
which are a function of silicon capabilties (exposed later
|
which are a function of silicon capabilties (exposed later
|
||||||
|
@ -6769,7 +6769,7 @@ Starts trace data collection.
|
||||||
Stops trace data collection.
|
Stops trace data collection.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Trace Port Drivers}
|
@anchor{traceportdrivers}
|
||||||
@subsection Trace Port Drivers
|
@subsection Trace Port Drivers
|
||||||
|
|
||||||
To use an ETM trace port it must be associated with a driver.
|
To use an ETM trace port it must be associated with a driver.
|
||||||
|
@ -6948,7 +6948,6 @@ unsafe, especially with targets running at very low speeds. This command was int
|
||||||
with OpenOCD rev. 60, and requires a few bytes of working area.
|
with OpenOCD rev. 60, and requires a few bytes of working area.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{arm7_9 fast_memory_access}
|
|
||||||
@deffn Command {arm7_9 fast_memory_access} [@option{enable}|@option{disable}]
|
@deffn Command {arm7_9 fast_memory_access} [@option{enable}|@option{disable}]
|
||||||
Displays the value of the flag controlling use of memory writes and reads
|
Displays the value of the flag controlling use of memory writes and reads
|
||||||
that don't check completion of the operation.
|
that don't check completion of the operation.
|
||||||
|
@ -6988,7 +6987,7 @@ Such cores include the ARM920T, ARM926EJ-S, and ARM966.
|
||||||
@c 23-oct-2009: doesn't work _consistently_ ... as if the ICE
|
@c 23-oct-2009: doesn't work _consistently_ ... as if the ICE
|
||||||
@c versions have different rules about when they commit writes.
|
@c versions have different rules about when they commit writes.
|
||||||
|
|
||||||
@anchor{arm9 vector_catch}
|
@anchor{arm9vectorcatch}
|
||||||
@deffn Command {arm9 vector_catch} [@option{all}|@option{none}|list]
|
@deffn Command {arm9 vector_catch} [@option{all}|@option{none}|list]
|
||||||
@cindex vector_catch
|
@cindex vector_catch
|
||||||
Vector Catch hardware provides a sort of dedicated breakpoint
|
Vector Catch hardware provides a sort of dedicated breakpoint
|
||||||
|
@ -7213,7 +7212,7 @@ The image @var{type} may be one of
|
||||||
@option{mem}, or @option{builder}.
|
@option{mem}, or @option{builder}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{xscale vector_catch}
|
@anchor{xscalevectorcatch}
|
||||||
@deffn Command {xscale vector_catch} [mask]
|
@deffn Command {xscale vector_catch} [mask]
|
||||||
@cindex vector_catch
|
@cindex vector_catch
|
||||||
Display a bitmask showing the hardware vectors to catch.
|
Display a bitmask showing the hardware vectors to catch.
|
||||||
|
@ -7232,7 +7231,6 @@ The mask bits correspond with bit 16..23 in the DCSR:
|
||||||
@end example
|
@end example
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{xscale vector_table}
|
|
||||||
@deffn Command {xscale vector_table} [(@option{low}|@option{high}) index value]
|
@deffn Command {xscale vector_table} [(@option{low}|@option{high}) index value]
|
||||||
@cindex vector_table
|
@cindex vector_table
|
||||||
|
|
||||||
|
@ -7384,10 +7382,10 @@ Using @option{vectreset} is a safe option for all current Cortex-M3 cores.
|
||||||
This however has the disadvantage of only resetting the core, all peripherals
|
This however has the disadvantage of only resetting the core, all peripherals
|
||||||
are uneffected. A solution would be to use a @code{reset-init} event handler to manually reset
|
are uneffected. A solution would be to use a @code{reset-init} event handler to manually reset
|
||||||
the peripherals.
|
the peripherals.
|
||||||
@xref{Target Events}.
|
@xref{targetevents,,Target Events}.
|
||||||
@end deffn
|
@end deffn
|
||||||
|
|
||||||
@anchor{Software Debug Messages and Tracing}
|
@anchor{softwaredebugmessagesandtracing}
|
||||||
@section Software Debug Messages and Tracing
|
@section Software Debug Messages and Tracing
|
||||||
@cindex Linux-ARM DCC support
|
@cindex Linux-ARM DCC support
|
||||||
@cindex tracing
|
@cindex tracing
|
||||||
|
@ -7403,7 +7401,7 @@ is supported only for @option{arm7_9} and @option{cortex_m3} cores.
|
||||||
These messages are received as part of target polling, so
|
These messages are received as part of target polling, so
|
||||||
you need to have @command{poll on} active to receive them.
|
you need to have @command{poll on} active to receive them.
|
||||||
They are intrusive in that they will affect program execution
|
They are intrusive in that they will affect program execution
|
||||||
times. If that is a problem, @pxref{ARM Hardware Tracing}.
|
times. If that is a problem, @pxref{armhardwaretracing,,ARM Hardware Tracing}.
|
||||||
|
|
||||||
See @file{libdcc} in the contrib dir for more details.
|
See @file{libdcc} in the contrib dir for more details.
|
||||||
In addition to sending strings, characters, and
|
In addition to sending strings, characters, and
|
||||||
|
@ -7477,7 +7475,7 @@ or after @command{trace point clear}) and count up from there.
|
||||||
@chapter JTAG Commands
|
@chapter JTAG Commands
|
||||||
@cindex JTAG Commands
|
@cindex JTAG Commands
|
||||||
Most general purpose JTAG commands have been presented earlier.
|
Most general purpose JTAG commands have been presented earlier.
|
||||||
(@xref{JTAG Speed}, @ref{Reset Configuration}, and @ref{TAP Declaration}.)
|
(@xref{jtagspeed,,JTAG Speed}, @ref{Reset Configuration}, and @ref{TAP Declaration}.)
|
||||||
Lower level JTAG commands, as presented here,
|
Lower level JTAG commands, as presented here,
|
||||||
may be needed to work with targets which require special
|
may be needed to work with targets which require special
|
||||||
attention during operations such as reset or initialization.
|
attention during operations such as reset or initialization.
|
||||||
|
@ -7789,7 +7787,7 @@ Setting up GDB to work with OpenOCD can involve several components:
|
||||||
|
|
||||||
@itemize
|
@itemize
|
||||||
@item The OpenOCD server support for GDB may need to be configured.
|
@item The OpenOCD server support for GDB may need to be configured.
|
||||||
@xref{GDB Configuration}.
|
@xref{gdbconfiguration,,GDB Configuration}.
|
||||||
@item GDB's support for OpenOCD may need configuration,
|
@item GDB's support for OpenOCD may need configuration,
|
||||||
as shown in this chapter.
|
as shown in this chapter.
|
||||||
@item If you have a GUI environment like Eclipse,
|
@item If you have a GUI environment like Eclipse,
|
||||||
|
@ -7803,7 +7801,6 @@ cross-development for ARM on an x86 PC, instead of using the native
|
||||||
x86 @command{gdb} command you might use @command{arm-none-eabi-gdb}
|
x86 @command{gdb} command you might use @command{arm-none-eabi-gdb}
|
||||||
if that's the tool chain used to compile your code.
|
if that's the tool chain used to compile your code.
|
||||||
|
|
||||||
@anchor{Connecting to GDB}
|
|
||||||
@section Connecting to GDB
|
@section Connecting to GDB
|
||||||
@cindex Connecting to GDB
|
@cindex Connecting to GDB
|
||||||
Use GDB 6.7 or newer with OpenOCD if you run into trouble. For
|
Use GDB 6.7 or newer with OpenOCD if you run into trouble. For
|
||||||
|
@ -7920,7 +7917,7 @@ using @command{gdb -x filename}.
|
||||||
|
|
||||||
@section Programming using GDB
|
@section Programming using GDB
|
||||||
@cindex Programming using GDB
|
@cindex Programming using GDB
|
||||||
@anchor{Programming using GDB}
|
@anchor{programmingusinggdb}
|
||||||
|
|
||||||
By default the target memory map is sent to GDB. This can be disabled by
|
By default the target memory map is sent to GDB. This can be disabled by
|
||||||
the following OpenOCD configuration option:
|
the following OpenOCD configuration option:
|
||||||
|
@ -7934,7 +7931,7 @@ working area.
|
||||||
Informing GDB of the memory map of the target will enable GDB to protect any
|
Informing GDB of the memory map of the target will enable GDB to protect any
|
||||||
flash areas of the target and use hardware breakpoints by default. This means
|
flash areas of the target and use hardware breakpoints by default. This means
|
||||||
that the OpenOCD option @command{gdb_breakpoint_override} is not required when
|
that the OpenOCD option @command{gdb_breakpoint_override} is not required when
|
||||||
using a memory map. @xref{gdb_breakpoint_override}.
|
using a memory map. @xref{gdbbreakpointoverride,,gdb_breakpoint_override}.
|
||||||
|
|
||||||
To view the configured memory map in GDB, use the GDB command @option{info mem}
|
To view the configured memory map in GDB, use the GDB command @option{info mem}
|
||||||
All other unassigned addresses within GDB are treated as RAM.
|
All other unassigned addresses within GDB are treated as RAM.
|
||||||
|
@ -7960,8 +7957,8 @@ $_TARGETNAME configure -event EVENTNAME BODY
|
||||||
|
|
||||||
To verify any flash programming the GDB command @option{compare-sections}
|
To verify any flash programming the GDB command @option{compare-sections}
|
||||||
can be used.
|
can be used.
|
||||||
@anchor{Using openocd SMP with GDB}
|
@anchor{usingopenocdsmpwithgdb}
|
||||||
@section Using openocd SMP with GDB
|
@section Using OpenOCD SMP with GDB
|
||||||
@cindex SMP
|
@cindex SMP
|
||||||
For SMP support following GDB serial protocol packet have been defined :
|
For SMP support following GDB serial protocol packet have been defined :
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
|
@ -7990,8 +7987,8 @@ print $_core
|
||||||
#jc packet is sent and result is affected in $
|
#jc packet is sent and result is affected in $
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
@item by the usage of GDB maintenance command as described in following example (2
|
@item by the usage of GDB maintenance command as described in following example (2 cpus in SMP with
|
||||||
cpus in SMP with core id 0 and 1 @pxref{Define CPU targets working in SMP}).
|
core id 0 and 1 @pxref{definecputargetsworkinginsmp,,Define CPU targets working in SMP}).
|
||||||
|
|
||||||
@example
|
@example
|
||||||
# toggle0 : force display of coreid 0
|
# toggle0 : force display of coreid 0
|
||||||
|
@ -8104,7 +8101,7 @@ is jim, not real tcl).
|
||||||
@chapter FAQ
|
@chapter FAQ
|
||||||
@cindex faq
|
@cindex faq
|
||||||
@enumerate
|
@enumerate
|
||||||
@anchor{FAQ RTCK}
|
@anchor{faqrtck}
|
||||||
@item @b{RTCK, also known as: Adaptive Clocking - What is it?}
|
@item @b{RTCK, also known as: Adaptive Clocking - What is it?}
|
||||||
@cindex RTCK
|
@cindex RTCK
|
||||||
@cindex adaptive clocking
|
@cindex adaptive clocking
|
||||||
|
@ -8357,7 +8354,7 @@ processed. Such commands include @command{nand probe} and everything
|
||||||
else that needs to write to controller registers, perhaps for setting
|
else that needs to write to controller registers, perhaps for setting
|
||||||
up DRAM and loading it with code.
|
up DRAM and loading it with code.
|
||||||
|
|
||||||
@anchor{FAQ TAP Order}
|
@anchor{faqtaporder}
|
||||||
@item @b{JTAG TAP Order} Do I have to declare the TAPS in some
|
@item @b{JTAG TAP Order} Do I have to declare the TAPS in some
|
||||||
particular order?
|
particular order?
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue