X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=9feee03348f192392d34e20f92d9f0cbc0e432ae;hp=83a6369cf8f30e4d892d0d7b4933f0f8ecd7cc66;hb=db8b99aed6b4e6c046bf51853dacd8d511607984;hpb=d37ed9094a62ec144b9d9fdc214d8c7723caadec diff --git a/doc/openocd.texi b/doc/openocd.texi index 83a6369cf8..9feee03348 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -21,7 +21,7 @@ of the Open On-Chip Debugger (OpenOCD). @itemize @bullet @item Copyright @copyright{} 2008 The OpenOCD Project @item Copyright @copyright{} 2007-2008 Spencer Oliver @email{spen@@spen-soft.co.uk} -@item Copyright @copyright{} 2008 Oyvind Harboe @email{oyvind.harboe@@zylin.com} +@item Copyright @copyright{} 2008-2010 Oyvind Harboe @email{oyvind.harboe@@zylin.com} @item Copyright @copyright{} 2008 Duane Ellis @email{openocd@@duaneellis.com} @item Copyright @copyright{} 2009-2010 David Brownell @end itemize @@ -332,7 +332,7 @@ and one can be used for a UART adapter at the same time the other one is used to provide a debug adapter. Also, some development boards integrate an FT2232 chip to serve as -a built-in low coast debug adapter and usb-to-serial solution. +a built-in low cost debug adapter and usb-to-serial solution. @itemize @bullet @item @b{usbjtag} @@ -537,7 +537,7 @@ command interpreter today is a mixture of (newer) JIM-Tcl commands, and (older) the orginal command interpreter. @item @b{Commands} -@* At the OpenOCD telnet command line (or via the GDB mon command) one +@* At the OpenOCD telnet command line (or via the GDB monitor command) one can type a Tcl for() loop, set variables, etc. Some of the commands documented in this guide are implemented as Tcl scripts, from a @file{startup.tcl} file internal to the server. @@ -2093,12 +2093,20 @@ target. @end deffn @deffn Command {interface_list} -List the interface drivers that have been built into +List the debug adapter drivers that have been built into the running copy of OpenOCD. @end deffn +@deffn Command {interface transports} transport_name+ +Specifies the transports supported by this debug adapter. +The adapter driver builds-in similar knowledge; use this only +when external configuration (such as jumpering) changes what +the hardware can support. +@end deffn + + -@deffn Command {jtag interface} -Returns the name of the interface driver being used. +@deffn Command {adapter_name} +Returns the name of the debug adapter driver being used. @end deffn @section Interface Drivers @@ -2417,6 +2425,7 @@ which are not currently documented here. @deffn {Interface Driver} {ZY1000} This is the Zylin ZY1000 JTAG debugger. +@end deffn @quotation Note This defines some driver-specific commands, @@ -2428,7 +2437,41 @@ Turn power switch to target on/off. No arguments: print status. @end deffn -@end deffn +@section Transport Configuration +As noted earlier, depending on the version of OpenOCD you use, +and the debug adapter you are using, +several transports may be available to +communicate with debug targets (or perhaps to program flash memory). +@deffn Command {transport list} +displays the names of the transports supported by this +version of OpenOCD. +@end deffn + +@deffn Command {transport select} transport_name +Select which of the supported transports to use in this OpenOCD session. +The transport must be supported by the debug adapter hardware and by the +version of OPenOCD you are using (including the adapter's driver). +No arguments: print selected transport.. +@end deffn + +@subsection JTAG Transport +JTAG is the original transport supported by OpenOCD, and most +of the OpenOCD commands support it. +JTAG transports expose a chain of one or more Test Access Points (TAPs), +each of which must be explicitly declared. +JTAG supports both debugging and boundary scan testing. +Flash programming support is built on top of debug support. +@subsection SWD ransport +SWD (Serial Wire Debug) is an ARM-specific transport which exposes one +Debug Access Point (DAP, which must be explicitly declared. +(SWD uses fewer signal wires than JTAG.) +SWD is debug-oriented, and does not support boundary scan testing. +Flash programming support is built on top of debug support. +(Some processors support both JTAG and SWD.) +@subsection SPI ransport +The Serial Peripheral Interface (SPI) is a general purpose transport +which uses four wire signaling. Some processors use it as part of a +solution for flash programming. @anchor{JTAG Speed} @section JTAG Speed @@ -3432,7 +3475,7 @@ At this writing, the supported CPU types and variants are: @item @code{arm11} -- this is a generation of ARMv6 cores @item @code{arm720t} -- this is an ARMv4 core with an MMU @item @code{arm7tdmi} -- this is an ARMv4 core -@item @code{arm920t} -- this is an ARMv5 core with an MMU +@item @code{arm920t} -- this is an ARMv4 core with an MMU @item @code{arm926ejs} -- this is an ARMv5 core with an MMU @item @code{arm966e} -- this is an ARMv5 core @item @code{arm9tdmi} -- this is an ARMv4 core @@ -3784,7 +3827,8 @@ proc my_attach_proc @{ @} @{ mychip.cpu configure -event gdb-attach my_attach_proc mychip.cpu configure -event gdb-attach @{ echo "Reset..." - reset halt + # To make flash probe and gdb load to flash work we need a reset init. + reset init @} @end example @@ -3804,7 +3848,11 @@ The following target events are defined: @* Currently not used (goal: when JTAG examine starts) @end ignore @item @b{gdb-attach} -@* When GDB connects +@* When GDB connects. This is before any communication with the target, so this +can be used to set up the target so it is possible to probe flash. Probing flash +is necessary during gdb connect if gdb load is to write the image to flash. Another +use of the flash memory map is for GDB to automatically hardware/software breakpoints +depending on whether the breakpoint is in RAM or read only memory. @item @b{gdb-detach} @* When GDB disconnects @item @b{gdb-end} @@ -4038,7 +4086,7 @@ specifies "to the end of the flash bank". The @var{num} parameter is a value shown by @command{flash banks}. @end deffn -@deffn Command {flash erase_address} [@option{pad}] address length +@deffn Command {flash erase_address} [@option{pad}] [@option{unlock}] address length Erase sectors starting at @var{address} for @var{length} bytes. Unless @option{pad} is specified, @math{address} must begin a flash sector, and @math{address + length - 1} must end a sector. @@ -4048,6 +4096,8 @@ The flash bank to use is inferred from the @var{address}, and the specified length must stay within that bank. As a special case, when @var{length} is zero and @var{address} is the start of the bank, the whole flash is erased. +If @option{unlock} is specified, then the flash is unprotected +before erase starts. @end deffn @deffn Command {flash fillw} address word length @@ -4122,9 +4172,8 @@ The @var{num} parameter is a value shown by @command{flash banks}. @deffn Command {flash info} num Print info about flash bank @var{num} The @var{num} parameter is a value shown by @command{flash banks}. -The information includes per-sector protect status, which may be -incorrect (outdated) unless you first issue a -@command{flash protect_check num} command. +This command will first query the hardware, it does not print cached +and possibly stale information. @end deffn @anchor{flash protect} @@ -4137,14 +4186,6 @@ specifies "to the end of the flash bank". The @var{num} parameter is a value shown by @command{flash banks}. @end deffn -@deffn Command {flash protect_check} num -Check protection state of sectors in flash bank @var{num}. -The @var{num} parameter is a value shown by @command{flash banks}. -@comment @option{flash erase_sector} using the same syntax. -This updates the protection information displayed by @option{flash info}. -(Code execution may have invalidated any state records kept by OpenOCD.) -@end deffn - @anchor{Flash Driver List} @section Flash Driver List As noted above, the @command{flash bank} command requires a driver name, @@ -4674,6 +4715,26 @@ the flash clock. @end deffn @end deffn +@deffn {Flash Driver} virtual +This is a special driver that maps a previously defined bank to another +address. All bank settings will be copied from the master physical bank. + +The @var{virtual} driver defines one mandatory parameters, + +@itemize +@item @var{master_bank} The bank that this virtual address refers to. +@end itemize + +So in the following example addresses 0xbfc00000 and 0x9fc00000 refer to +the flash bank defined at address 0x1fc00000. Any cmds executed on +the virtual banks are actually performed on the physical banks. +@example +flash bank $_FLASHNAME pic32mx 0x1fc00000 0 0 0 $_TARGETNAME +flash bank vbank0 virtual 0xbfc00000 0 0 0 $_TARGETNAME $_FLASHNAME +flash bank vbank1 virtual 0x9fc00000 0 0 0 $_TARGETNAME $_FLASHNAME +@end example +@end deffn + @subsection str9xpec driver @cindex str9xpec @@ -5666,10 +5727,20 @@ separately. @end deffn @anchor{load_image} -@deffn Command {load_image} filename address [@option{bin}|@option{ihex}|@option{elf}] -Load image from file @var{filename} to target memory at @var{address}. +@deffn Command {load_image} filename address [[@option{bin}|@option{ihex}|@option{elf}] @option{min_addr} @option{max_length}] +Load image from file @var{filename} to target memory offset by @var{address} from its load address. The file format may optionally be specified -(@option{bin}, @option{ihex}, or @option{elf}) +(@option{bin}, @option{ihex}, or @option{elf}). +In addition the following arguments may be specifed: +@var{min_addr} - ignore data below @var{min_addr} (this is w.r.t. to the target's load address + @var{address}) +@var{max_length} - maximum number of bytes to load. +@example +proc load_image_bin @{fname foffset address length @} @{ + # Load data from fname filename at foffset offset to + # target at address. Load at most length bytes. + load_image $fname [expr $address - $foffset] bin $address $length +@} +@end example @end deffn @deffn Command {test_image} filename [address [@option{bin}|@option{ihex}|@option{elf}]]