xscale documentation: vector table handling

[fw/openocd] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 89c9f6684bc83b16a74294dbb945ab7d9372c623..0e57c1afeea80b5e8abac71b9df99d17110671c5 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2451,7 +2451,7 @@ version of OpenOCD.
 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..
+No arguments: returns name of session's selected transport.
 @end deffn
 
 @subsection JTAG Transport
@@ -6337,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
@@ -6367,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 -