X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=e38e619db59b483f89ff4ab0ccd7cf225f0ebb34;hp=1604e9c6c2b712875ce2cca7b689b047b9c10982;hb=69359b1c52233f222bced5784f9f2687e720a633;hpb=37f8f0bf9aec3d7b3ff8fb9f2785ae2b12c95910;ds=sidebyside

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 1604e9c6c2..e38e619db5 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -357,13 +357,13 @@ a built-in low cost debug adapter and usb-to-serial solution.
 @item @b{signalyzer}
 @* See: @url{http://www.signalyzer.com}
 @item @b{Stellaris Eval Boards}
-@* See: @url{http://www.luminarymicro.com} - The Stellaris eval boards
+@* See: @url{http://www.ti.com} - The Stellaris eval boards
 bundle FT2232-based JTAG and SWD support, which can be used to debug
 the Stellaris chips.  Using separate JTAG adapters is optional.
 These boards can also be used in a "pass through" mode as JTAG adapters
 to other target boards, disabling the Stellaris chip.
-@item @b{Luminary ICDI}
-@* See: @url{http://www.luminarymicro.com} - Luminary In-Circuit Debug
+@item @b{TI/Luminary ICDI}
+@* See: @url{http://www.ti.com} - TI/Luminary In-Circuit Debug
 Interface (ICDI) Boards are included in Stellaris LM3S9B9x
 Evaluation Kits.  Like the non-detachable FT2232 support on the other
 Stellaris eval boards, they can be used to debug other target boards.
@@ -456,6 +456,11 @@ The simplest solution is to get linux to ignore the ST-LINK using one of the fol
 @item add "options usb-storage quirks=483:3744:i" to /etc/modprobe.conf
 @end itemize
 
+@section USB TI/Stellaris ICDI based
+Texas Instruments has an adapter called @b{ICDI}.
+It is not to be confused with the FTDI based adapters that were originally fitted to their
+evaluation boards. This is the adapter fitted to the Stellaris LaunchPad.
+
 @section USB Other
 @itemize @bullet
 @item @b{USBprog}
@@ -2484,12 +2489,12 @@ Currently valid layout @var{name} values include:
 @item @b{axm0432_jtag} Axiom AXM-0432
 @item @b{comstick} Hitex STR9 comstick
 @item @b{cortino} Hitex Cortino JTAG interface
-@item @b{evb_lm3s811} Luminary Micro EVB_LM3S811 as a JTAG interface,
+@item @b{evb_lm3s811} TI/Luminary Micro EVB_LM3S811 as a JTAG interface,
 either for the local Cortex-M3 (SRST only)
 or in a passthrough mode (neither SRST nor TRST)
 This layout can not support the SWO trace mechanism, and should be
 used only for older boards (before rev C).
-@item @b{luminary_icdi} This layout should be used with most Luminary
+@item @b{luminary_icdi} This layout should be used with most TI/Luminary
 eval boards, including Rev C LM3S811 eval boards and the eponymous
 ICDI boards, to debug either the local Cortex-M3 or in passthrough mode
 to debug some other target.  It can support the SWO trace mechanism.
@@ -2804,27 +2809,31 @@ which are not currently documented here.
 @end quotation
 @end deffn
 
-@deffn {Interface Driver} {stlink}
-ST Micro ST-LINK adapter.
+@deffn {Interface Driver} {hla}
+This is a driver that supports multiple High Level Adapters.
+This type of adapter does not expose some of the lower level api's
+that OpenOCD would normally use to access the target.
+
+Currently supported adapters include the ST STLINK and TI ICDI.
 
-@deffn {Config Command} {stlink_device_desc} description
+@deffn {Config Command} {hla_device_desc} description
 Currently Not Supported.
 @end deffn
 
-@deffn {Config Command} {stlink_serial} serial
+@deffn {Config Command} {hla_serial} serial
 Currently Not Supported.
 @end deffn
 
-@deffn {Config Command} {stlink_layout} (@option{sg}|@option{usb})
-Specifies the stlink layout to use.
+@deffn {Config Command} {hla_layout} (@option{stlink}|@option{icdi})
+Specifies the adapter layout to use.
 @end deffn
 
-@deffn {Config Command} {stlink_vid_pid} vid pid
-The vendor ID and product ID of the STLINK device.
+@deffn {Config Command} {hla_vid_pid} vid pid
+The vendor ID and product ID of the device.
 @end deffn
 
 @deffn {Config Command} {stlink_api} api_level
-Manually sets the stlink api used, valid options are 1 or 2.
+Manually sets the stlink api used, valid options are 1 or 2. (@b{STLINK Only}).
 @end deffn
 @end deffn
 
@@ -3156,10 +3165,9 @@ from a particular combination of interface and board.
 with a board that only wires up SRST.)
 
 The @var{mode_flag} options can be specified in any order, but only one
-of each type -- @var{signals}, @var{combination},
-@var{gates},
-@var{trst_type},
-and @var{srst_type} -- may be specified at a time.
+of each type -- @var{signals}, @var{combination}, @var{gates},
+@var{trst_type}, @var{srst_type} and @var{connect_type}
+-- may be specified at a time.
 If you don't provide a new value for a given type, its previous
 value (perhaps the default) is unchanged.
 For example, this means that you don't need to say anything at all about
@@ -3201,6 +3209,18 @@ JTAG clock. This means that no communication can happen on JTAG
 while SRST is asserted.
 Its converse is @option{srst_nogate}, indicating that JTAG commands
 can safely be issued while SRST is active.
+
+@item
+The @var{connect_type} tokens control flags that describe some cases where
+SRST is asserted while connecting to the target. @option{srst_nogate}
+is required to use this option.
+@option{connect_deassert_srst} (default)
+indicates that SRST will not be asserted while connecting to the target.
+Its converse is @option{connect_assert_srst}, indicating that SRST will
+be asserted before any target connection.
+Only some targets support this feature, STM32 and STR9 are examples.
+This feature is useful if you are unable to connect to your target due
+to incorrect options byte config or illegal program execution.
 @end itemize
 
 The optional @var{trst_type} and @var{srst_type} parameters allow the
@@ -4075,7 +4095,7 @@ The value should normally correspond to a static mapping for the
 
 @item @code{-rtos} @var{rtos_type} -- enable rtos support for target,
 @var{rtos_type} can be one of @option{auto}|@option{eCos}|@option{ThreadX}|
-@option{FreeRTOS}|@option{linux}.
+@option{FreeRTOS}|@option{linux}|@option{ChibiOS}.
 
 @end itemize
 @end deffn
@@ -4652,6 +4672,30 @@ flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME
 @c "cfi part_id" disabled
 @end deffn
 
+@deffn {Flash Driver} lpcspifi
+@cindex NXP SPI Flash Interface
+@cindex SPIFI
+@cindex lpcspifi
+NXP's LPC43xx and LPC18xx families include a proprietary SPI
+Flash Interface (SPIFI) peripheral that can drive and provide
+memory mapped access to external SPI flash devices.
+
+The lpcspifi driver initializes this interface and provides
+program and erase functionality for these serial flash devices.
+Use of this driver @b{requires} a working area of at least 1kB
+to be configured on the target device; more than this will
+significantly reduce flash programming times.
+
+The setup command only requires the @var{base} parameter. All
+other parameters are ignored, and the flash size and layout
+are configured by the driver.
+
+@example
+flash bank $_FLASHNAME lpcspifi 0x14000000 0 0 0 $_TARGETNAME
+@end example
+
+@end deffn
+
 @deffn {Flash Driver} stmsmi
 @cindex STMicroelectronics Serial Memory Interface
 @cindex SMI
@@ -7555,6 +7599,11 @@ A socket (TCP/IP) connection is typically started as follows:
 target remote localhost:3333
 @end example
 This would cause GDB to connect to the gdbserver on the local pc using port 3333.
+
+It is also possible to use the GDB extended remote protocol as follows:
+@example
+target extended-remote localhost:3333
+@end example
 @item
 A pipe connection is typically started as follows:
 @example