xscale documentation: vector table handling
[fw/openocd] / doc / openocd.texi
index da2782b133895b10aa28c7d567589e03b406942f..0e57c1afeea80b5e8abac71b9df99d17110671c5 100644 (file)
@@ -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: returns name of session's 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 Transport
+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 Transport
+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,
@@ -4180,8 +4221,8 @@ To configure two adjacent banks of 16 MBytes each, both sixteen bits (two bytes)
 wide on a sixteen bit bus:
 
 @example
-flash bank cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
-flash bank cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
 @end example
 
 To configure one bank of 32 MBytes
@@ -4189,7 +4230,7 @@ built from two sixteen bit (two byte) wide parts wired in parallel
 to create a thirty-two bit (four byte) bus with doubled throughput:
 
 @example
-flash bank cfi 0x00000000 0x02000000 2 4 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME
 @end example
 
 @c "cfi part_id" disabled
@@ -4205,7 +4246,7 @@ The setup command only requires the @var{target} argument
 since all devices in this family have the same memory layout.
 
 @example
-flash bank aduc702x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME aduc702x 0 0 0 0 $_TARGETNAME
 @end example
 @end deffn
 
@@ -4226,9 +4267,9 @@ the following fixed locations:
 
 @example
 # Flash bank 0 - all chips
-flash bank at91sam3 0x00080000 0 1 1 $_TARGETNAME
+flash bank $_FLASHNAME at91sam3 0x00080000 0 1 1 $_TARGETNAME
 # Flash bank 1 - only 256K chips
-flash bank at91sam3 0x00100000 0 1 1 $_TARGETNAME
+flash bank $_FLASHNAME at91sam3 0x00100000 0 1 1 $_TARGETNAME
 @end example
 
 Internally, the AT91SAM3 flash memory is organized as follows.
@@ -4280,7 +4321,7 @@ recognizes a number of these chips using the chip identification
 register, and autoconfigures itself.
 
 @example
-flash bank at91sam7 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME
 @end example
 
 For chips which are not recognized by the controller driver, you must
@@ -4367,7 +4408,7 @@ with most tool chains @command{verify_image} will fail.
 LPC flashes don't require the chip and bus width to be specified.
 
 @example
-flash bank lpc2000 0x0 0x7d000 0 0 $_TARGETNAME \
+flash bank $_FLASHNAME lpc2000 0x0 0x7d000 0 0 $_TARGETNAME \
       lpc2000_v2 14765 calc_checksum
 @end example
 
@@ -4385,7 +4426,7 @@ the programming clock rate in Hz.
 LPC flashes don't require the chip and bus width to be specified.
 
 @example
-flash bank lpc288x 0 0 0 0 $_TARGETNAME 12000000
+flash bank $_FLASHNAME lpc288x 0 0 0 0 $_TARGETNAME 12000000
 @end example
 @end deffn
 
@@ -4418,7 +4459,7 @@ and not by the standard @code{flash protect} command.
 
 Example for a 125 MHz clock frequency:
 @example
-flash bank lpc2900 0 0 0 0 $_TARGETNAME 125000
+flash bank $_FLASHNAME lpc2900 0 0 0 0 $_TARGETNAME 125000
 @end example
 
 Some @code{lpc2900}-specific commands are defined. In the following command list,
@@ -4516,7 +4557,7 @@ lpc2900 secure_jtag 0
 @emph{No idea what this is, other than using some arm7/arm9 core.}
 
 @example
-flash bank ocl 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME ocl 0 0 0 0 $_TARGETNAME
 @end example
 @end deffn
 
@@ -4525,8 +4566,8 @@ The PIC32MX microcontrollers are based on the MIPS 4K cores,
 and integrate flash memory.
 
 @example
-flash bank pix32mx 0x1fc00000 0 0 0 $_TARGETNAME
-flash bank pix32mx 0x1d000000 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME pix32mx 0x1fc00000 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME pix32mx 0x1d000000 0 0 0 $_TARGETNAME
 @end example
 
 @comment numerous *disabled* commands are defined:
@@ -4555,7 +4596,7 @@ That seems pointless since the same effect can be had using the
 standard @command{flash erase_address} command.}
 
 @example
-flash bank stellaris 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stellaris 0 0 0 0 $_TARGETNAME
 @end example
 @end deffn
 
@@ -4581,7 +4622,7 @@ The driver automatically recognizes a number of these chips using
 the chip identification register, and autoconfigures itself.
 
 @example
-flash bank stm32x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
 @end example
 
 Some stm32x-specific commands
@@ -4619,7 +4660,7 @@ The @var{str7x} driver defines one mandatory parameter, @var{variant},
 which is either @code{STR71x}, @code{STR73x} or @code{STR75x}.
 
 @example
-flash bank str7x 0x40000000 0x00040000 0 0 $_TARGETNAME STR71x
+flash bank $_FLASHNAME str7x 0x40000000 0x00040000 0 0 $_TARGETNAME STR71x
 @end example
 
 @deffn Command {str7x disable_jtag} bank
@@ -4635,7 +4676,7 @@ The str9 needs the flash controller to be configured using
 the @command{str9x flash_config} command prior to Flash programming.
 
 @example
-flash bank str9x 0x40000000 0x00040000 0 0 $_TARGETNAME
+flash bank $_FLASHNAME str9x 0x40000000 0x00040000 0 0 $_TARGETNAME
 str9x flash_config 0 4 2 0 0x80000
 @end example
 
@@ -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
 
@@ -4785,13 +4846,13 @@ Currently, the mflash driver supports s3c2440 and pxa270.
 Example for s3c2440 mflash where @var{RST pin} is GPIO B1:
 
 @example
-mflash bank s3c2440 0x10000000 1b 0
+mflash bank $_FLASHNAME s3c2440 0x10000000 1b 0
 @end example
 
 Example for pxa270 mflash where @var{RST pin} is GPIO 43:
 
 @example
-mflash bank pxa270 0x08000000 43 0
+mflash bank $_FLASHNAME pxa270 0x08000000 43 0
 @end example
 @end deffn
 
@@ -5099,7 +5160,7 @@ be removed in a future release.
 @section Other NAND commands
 @cindex NAND other commands
 
-@deffn Command {nand check_bad_blocks} [offset length]
+@deffn Command {nand check_bad_blocks} num [offset length]
 Checks for manufacturer bad block markers on the specified NAND
 device.  If no parameters are provided, checks the whole
 device; otherwise, starts at the specified @var{offset} and
@@ -5369,25 +5430,6 @@ file (which is normally the server's standard output).
 @xref{Running}.
 @end deffn
 
-@deffn Command fast (@option{enable}|@option{disable})
-Default disabled.
-Set default behaviour of OpenOCD to be "fast and dangerous".
-
-At this writing, this only affects the defaults for two ARM7/ARM9 parameters:
-fast memory access, and DCC downloads.  Those parameters may still be
-individually overridden.
-
-The target specific "dangerous" optimisation tweaking options may come and go
-as more robust and user friendly ways are found to ensure maximum throughput
-and robustness with a minimum of configuration.
-
-Typically the "fast enable" is specified first on the command line:
-
-@example
-openocd -c "fast enable" -c "interface dummy" -f target/str710.cfg
-@end example
-@end deffn
-
 @deffn Command echo message
 Logs a message at "user" priority.
 Output @var{message} to stdout.
@@ -5666,10 +5708,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}]]
@@ -6285,10 +6337,10 @@ handler. However, this means that the complete first cacheline in the
 mini-IC is marked valid, which makes the CPU fetch all exception
 handlers from the mini-IC, ignoring the code in RAM.
 
-OpenOCD currently does not sync the mini-IC entries with the RAM
-contents (which would fail anyway while the target is running), so
-the user must provide appropriate values using the @code{xscale
-vector_table} command.
+To address this situation, OpenOCD provides the @code{xscale
+vector_table} command, which allows the user to explicity write
+individual entries to either the high or low vector table stored in
+the mini-IC.
 
 It is recommended to place a pc-relative indirect branch in the vector
 table, and put the branch destination somewhere in memory. Doing so
@@ -6315,6 +6367,24 @@ _vectors:
         .long real_fiq_handler
 @end example
 
+Alternatively, you may choose to keep some or all of the mini-IC
+vector table entries synced with those written to memory by your
+system software.  The mini-IC can not be modified while the processor
+is executing, but for each vector table entry not previously defined
+using the @code{xscale vector_table} command, OpenOCD will copy the
+value from memory to the mini-IC every time execution resumes from a
+halt.  This is done for both high and low vector tables (although the
+table not in use may not be mapped to valid memory, and in this case
+that copy operation will silently fail).  This means that you will
+need to briefly halt execution at some strategic point during system
+start-up; e.g., after the software has initialized the vector table,
+but before exceptions are enabled.  A breakpoint can be used to
+accomplish this once the appropriate location in the start-up code has
+been identified.  A watchpoint over the vector table region is helpful
+in finding the location if you're not sure.  Note that the same
+situation exists any time the vector table is modified by the system
+software.
+
 The debug handler must be placed somewhere in the address space using
 the @code{xscale debug_handler} command.  The allowed locations for the
 debug handler are either (0x800 - 0x1fef800) or (0xfe000800 -
@@ -7406,8 +7476,8 @@ has closed the connection to OpenOCD. This might be a GDB issue.
 
 @item @b{LPC2000 Flash} In the configuration file in the section where flash device configurations
 are described, there is a parameter for specifying the clock frequency
-for LPC2000 internal flash devices (e.g.  @option{flash bank lpc2000
-0x0 0x40000 0 0 0 lpc2000_v1 14746 calc_checksum}), which must be
+for LPC2000 internal flash devices (e.g.  @option{flash bank $_FLASHNAME lpc2000
+0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14746 calc_checksum}), which must be
 specified in kilohertz. However, I do have a quartz crystal of a
 frequency that contains fractions of kilohertz (e.g. 14,745,600 Hz,
 i.e. 14,745.600 kHz).  Is it possible to specify real numbers for the