X-Git-Url: https://review.openocd.org/gitweb?a=blobdiff_plain;f=doc%2Fopenocd.texi;h=721989817de82fcd49b2c5f99534ec0126fd8d70;hb=13288a44bee0aa26067cb51c262b82a12b61699f;hp=e38e619db59b483f89ff4ab0ccd7cf225f0ebb34;hpb=69359b1c52233f222bced5784f9f2687e720a633;p=openocd.git diff --git a/doc/openocd.texi b/doc/openocd.texi index e38e619db5..721989817d 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -72,6 +72,7 @@ Free Documentation License''. * TAP Declaration:: TAP Declaration * CPU Configuration:: CPU Configuration * Flash Commands:: Flash Commands +* Flash Programming:: Flash Programming * NAND Flash Commands:: NAND Flash Commands * PLD/FPGA Commands:: PLD/FPGA Commands * General Commands:: General Commands @@ -155,13 +156,13 @@ OpenOCD internally. @xref{Debug Adapter Hardware}. @b{GDB Debug:} It allows ARM7 (ARM7TDMI and ARM720t), ARM9 (ARM920T, ARM922T, ARM926EJ--S, ARM966E--S), XScale (PXA25x, IXP42x) and -Cortex-M3 (Stellaris LM3 and ST STM32) based cores to be +Cortex-M3 (Stellaris LM3, ST STM32 and Energy Micro EFM32) based cores to be debugged via the GDB protocol. @b{Flash Programing:} Flash writing is supported for external CFI compatible NOR flashes (Intel and AMD/Spansion command set) and several -internal flashes (LPC1700, LPC2000, AT91SAM7, AT91SAM3U, STR7x, STR9x, LM3, and -STM32x). Preliminary support for various NAND flash controllers +internal flashes (LPC1700, LPC2000, AT91SAM7, AT91SAM3U, STR7x, STR9x, LM3, +STM32x and EFM32). Preliminary support for various NAND flash controllers (LPC3180, Orion, S3C24xx, more) controller is included. @section OpenOCD Web Site @@ -388,6 +389,9 @@ to be available anymore as of April 2012. @* Link @url{http://www.dlpdesign.com/usb/usb1232h.shtml} @item @b{digilent-hs1} @* Link @url{http://www.digilentinc.com/Products/Detail.cfm?Prod=JTAG-HS1} +@item @b{opendous} +@* Link @url{http://code.google.com/p/opendous/wiki/JTAG} FT2232H-based +(OpenHardware). @end itemize @section USB-JTAG / Altera USB-Blaster compatibles @@ -479,7 +483,7 @@ evaluation boards. This is the adapter fitted to the Stellaris LaunchPad. @* Link: @url{http://dangerousprototypes.com/bus-pirate-manual/} @item @b{opendous} -@* Link: @url{http://code.google.com/p/opendous-jtag/} +@* Link: @url{http://code.google.com/p/opendous-jtag/} - which uses an AT90USB162 @item @b{estick} @* Link: @url{http://code.google.com/p/estick-jtag/} @@ -2462,6 +2466,10 @@ Cirrus Logic EP93xx based single-board computer bit-banging (in development) @deffn {Interface Driver} {ft2232} FTDI FT2232 (USB) based devices over one of the userspace libraries. + +Note that this driver has several flaws and the @command{ftdi} driver is +recommended as its replacement. + These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain: @@ -2534,6 +2542,11 @@ also reduces the risk of timeouts before receiving the expected number of bytes. The OpenOCD default value is 2 and for some systems a value of 10 has proved useful. @end deffn +@deffn {Config Command} {ft2232_channel} channel +Used to select the channel of the ft2232 chip to use (between 1 and 4). +The default value is 1. +@end deffn + For example, the interface config file for a Turtelizer JTAG Adapter looks something like this: @@ -2545,6 +2558,119 @@ ft2232_vid_pid 0x0403 0xbdc8 @end example @end deffn +@deffn {Interface Driver} {ftdi} +This driver is for adapters using the MPSSE (Multi-Protocol Synchronous Serial +Engine) mode built into many FTDI chips, such as the FT2232, FT4232 and FT232H. +It is a complete rewrite to address a large number of problems with the ft2232 +interface driver. + +The driver is using libusb-1.0 in asynchronous mode to talk to the FTDI device, +bypassing intermediate libraries like libftdi of D2XX. Performance-wise it is +consistently faster than the ft2232 driver, sometimes several times faster. + +A major improvement of this driver is that support for new FTDI based adapters +can be added competely through configuration files, without the need to patch +and rebuild OpenOCD. + +The driver uses a signal abstraction to enable Tcl configuration files to +define outputs for one or several FTDI GPIO. These outputs can then be +controlled using the @command{ftdi_set_signal} command. Special signal names +are reserved for nTRST, nSRST and LED (for blink) so that they, if defined, +will be used for their customary purpose. + +Depending on the type of buffer attached to the FTDI GPIO, the outputs have to +be controlled differently. In order to support tristateable signals such as +nSRST, both a data GPIO and an output-enable GPIO can be specified for each +signal. The following output buffer configurations are supported: + +@itemize @minus +@item Push-pull with one FTDI output as (non-)inverted data line +@item Open drain with one FTDI output as (non-)inverted output-enable +@item Tristate with one FTDI output as (non-)inverted data line and another + FTDI output as (non-)inverted output-enable +@item Unbuffered, using the FTDI GPIO as a tristate output directly by + switching data and direction as necessary +@end itemize + +These interfaces have several commands, used to configure the driver +before initializing the JTAG scan chain: + +@deffn {Config Command} {ftdi_vid_pid} [vid pid]+ +The vendor ID and product ID of the adapter. If not specified, the FTDI +default values are used. +Currently, up to eight [@var{vid}, @var{pid}] pairs may be given, e.g. +@example +ftdi_vid_pid 0x0403 0xcff8 0x15ba 0x0003 +@end example +@end deffn + +@deffn {Config Command} {ftdi_device_desc} description +Provides the USB device description (the @emph{iProduct string}) +of the adapter. If not specified, the device description is ignored +during device selection. +@end deffn + +@deffn {Config Command} {ftdi_serial} serial-number +Specifies the @var{serial-number} of the adapter to use, +in case the vendor provides unique IDs and more than one adapter +is connected to the host. +If not specified, serial numbers are not considered. +(Note that USB serial numbers can be arbitrary Unicode strings, +and are not restricted to containing only decimal digits.) +@end deffn + +@deffn {Config Command} {ftdi_channel} channel +Selects the channel of the FTDI device to use for MPSSE operations. Most +adapters use the default, channel 0, but there are exceptions. +@end deffn + +@deffn {Config Command} {ftdi_layout_init} data direction +Specifies the initial values of the FTDI GPIO data and direction registers. +Each value is a 16-bit number corresponding to the concatenation of the high +and low FTDI GPIO registers. The values should be selected based on the +schematics of the adapter, such that all signals are set to safe levels with +minimal impact on the target system. Avoid floating inputs, conflicting outputs +and initially asserted reset signals. +@end deffn + +@deffn {Config Command} {ftdi_layout_signal} name [@option{-data}|@option{-ndata} data_mask] [@option{-oe}|@option{-noe} oe_mask] +Creates a signal with the specified @var{name}, controlled by one or more FTDI +GPIO pins via a range of possible buffer connections. The masks are FTDI GPIO +register bitmasks to tell the driver the connection and type of the output +buffer driving the respective signal. @var{data_mask} is the bitmask for the +pin(s) connected to the data input of the output buffer. @option{-ndata} is +used with inverting data inputs and @option{-data} with non-inverting inputs. +The @option{-oe} (or @option{-noe}) option tells where the output-enable (or +not-output-enable) input to the output buffer is connected. + +Both @var{data_mask} and @var{oe_mask} need not be specified. For example, a +simple open-collector transistor driver would be specified with @option{-oe} +only. In that case the signal can only be set to drive low or to Hi-Z and the +driver will complain if the signal is set to drive high. Which means that if +it's a reset signal, @command{reset_config} must be specified as +@option{srst_open_drain}, not @option{srst_push_pull}. + +A special case is provided when @option{-data} and @option{-oe} is set to the +same bitmask. Then the FTDI pin is considered being connected straight to the +target without any buffer. The FTDI pin is then switched between output and +input as necessary to provide the full set of low, high and Hi-Z +characteristics. In all other cases, the pins specified in a signal definition +are always driven by the FTDI. +@end deffn + +@deffn {Command} {ftdi_set_signal} name @option{0}|@option{1}|@option{z} +Set a previously defined signal to the specified level. +@itemize @minus +@item @option{0}, drive low +@item @option{1}, drive high +@item @option{z}, set to high-impedance +@end itemize +@end deffn + +For example adapter definitions, see the configuration files shipped in the +@file{interface/ftdi} directory. +@end deffn + @deffn {Interface Driver} {remote_bitbang} Drive JTAG from a remote process. This sets up a UNIX or TCP socket connection with a remote process and sends ASCII encoded bitbang requests to that process @@ -4479,6 +4605,7 @@ but most don't bother. @cindex flash reading @cindex flash writing @cindex flash programming +@anchor{Flash Programming Commands} One feature distinguishing NOR flash from NAND or serial flash technologies is that for read access, it acts exactly like any other addressible memory. @@ -4622,6 +4749,13 @@ specifies "to the end of the flash bank". The @var{num} parameter is a value shown by @command{flash banks}. @end deffn +@anchor{program} +@deffn Command {program} filename [verify] [reset] [offset] +This is a helper script that simplifies using OpenOCD as a standalone +programmer. The only required parameter is @option{filename}, the others are optional. +@xref{Flash Programming}. +@end deffn + @anchor{Flash Driver List} @section Flash Driver List As noted above, the @command{flash bank} command requires a driver name, @@ -4863,6 +4997,18 @@ The AVR 8-bit microcontrollers from Atmel integrate flash memory. @comment - defines mass_erase ... pointless given flash_erase_address @end deffn +@deffn {Flash Driver} efm32 +All members of the EFM32 microcontroller family from Energy Micro include +internal flash and use ARM Cortex M3 cores. The driver automatically recognizes +a number of these chips using the chip identification register, and +autoconfigures itself. +@example +flash bank $_FLASHNAME efm32 0 0 0 0 $_TARGETNAME +@end example +@emph{The current implementation is incomplete. Unprotecting flash pages is not +supported.} +@end deffn + @deffn {Flash Driver} lpc2000 Most members of the LPC1700 and LPC2000 microcontroller families from NXP include internal flash and use Cortex-M3 (LPC1700) or ARM7TDMI (LPC2000) cores. @@ -5087,7 +5233,6 @@ standard @command{flash erase_address} command.} @example flash bank $_FLASHNAME stellaris 0 0 0 0 $_TARGETNAME @end example -@end deffn @deffn Command {stellaris recover bank_id} Performs the @emph{Recovering a "Locked" Device} procedure to @@ -5103,10 +5248,11 @@ if more than one Stellaris chip is connected, the procedure is applied to all of them. @end quotation @end deffn +@end deffn @deffn {Flash Driver} stm32f1x -All members of the STM32f1x microcontroller family from ST Microelectronics -include internal flash and use ARM Cortex M3 cores. +All members of the STM32F0, STM32F1 and STM32F3 microcontroller families +from ST Microelectronics include internal flash and use ARM Cortex-M0/M3/M4 cores. The driver automatically recognizes a number of these chips using the chip identification register, and autoconfigures itself. @@ -5114,6 +5260,14 @@ the chip identification register, and autoconfigures itself. flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME @end example +Note that some devices have been found that have a flash size register that contains +an invalid value, to workaround this issue you can override the probed value used by +the flash driver. + +@example +flash bank $_FLASHNAME stm32f1x 0 0x20000 0 0 $_TARGETNAME +@end example + If you have a target with dual flash banks then define the second bank as per the following example. @example @@ -5149,10 +5303,45 @@ The @var{num} parameter is a value shown by @command{flash banks}. @end deffn @deffn {Flash Driver} stm32f2x -All members of the STM32f2x microcontroller family from ST Microelectronics -include internal flash and use ARM Cortex M3 cores. +All members of the STM32F2 and STM32F4 microcontroller families from ST Microelectronics +include internal flash and use ARM Cortex-M3/M4 cores. The driver automatically recognizes a number of these chips using the chip identification register, and autoconfigures itself. + +Note that some devices have been found that have a flash size register that contains +an invalid value, to workaround this issue you can override the probed value used by +the flash driver. + +@example +flash bank $_FLASHNAME stm32f2x 0 0x20000 0 0 $_TARGETNAME +@end example + +Some stm32f2x-specific commands are defined: + +@deffn Command {stm32f2x lock} num +Locks the entire stm32 device. +The @var{num} parameter is a value shown by @command{flash banks}. +@end deffn + +@deffn Command {stm32f2x unlock} num +Unlocks the entire stm32 device. +The @var{num} parameter is a value shown by @command{flash banks}. +@end deffn +@end deffn + +@deffn {Flash Driver} stm32lx +All members of the STM32L microcontroller families from ST Microelectronics +include internal flash and use ARM Cortex-M3 cores. +The driver automatically recognizes a number of these chips using +the chip identification register, and autoconfigures itself. + +Note that some devices have been found that have a flash size register that contains +an invalid value, to workaround this issue you can override the probed value used by +the flash driver. + +@example +flash bank $_FLASHNAME stm32lx 0 0x20000 0 0 $_TARGETNAME +@end example @end deffn @deffn {Flash Driver} str7x @@ -5408,6 +5597,38 @@ Write the binary file @var{filename} to mflash bank @var{num}, starting at @var{offset} bytes from the beginning of the bank. @end deffn +@node Flash Programming +@chapter Flash Programming + +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}. + +@*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. + +The script is executed as follows and by default the following actions will be peformed. +@enumerate +@item 'init' is executed. +@item 'reset init' is called to reset and halt the target, any 'reset init' scripts are executed. +@item @code{flash write_image} is called to erase and write any flash using the filename given. +@item @code{verify_image} is called if @option{verify} parameter is given. +@item @code{reset run} is called if @option{reset} parameter is given. +@item OpenOCD is shutdown. +@end enumerate + +An example of usage is given below. @xref{program}. + +@example +# program and verify using elf/hex/s19. verify and reset +# are optional parameters +openocd -f board/stm32f3discovery.cfg \ + -c "program filename.elf verify reset" + +# binary files need the flash address passing +openocd -f board/stm32f3discovery.cfg \ + -c "program filename.bin 0x08000000" +@end example + @node NAND Flash Commands @chapter NAND Flash Commands @cindex NAND @@ -7699,6 +7920,7 @@ using @command{gdb -x filename}. @section Programming using GDB @cindex Programming using GDB +@anchor{Programming using GDB} By default the target memory map is sent to GDB. This can be disabled by the following OpenOCD configuration option: