X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=55fbf4ff386897af3580165900e6818660f0953b;hp=3519222b5cd68bf8ea155a5fc3e81a0845f5869e;hb=57dce9560a2885782860b127fd1629798d659440;hpb=394dcc8e34dd4aa8864cce1d42e29d99d0640740 diff --git a/doc/openocd.texi b/doc/openocd.texi index 3519222b5c..55fbf4ff38 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -374,6 +374,8 @@ Stellaris eval boards, they can be used to debug other target boards. @* Link @url{http://www.hitex.com/index.php?id=cortino} @item @b{dlp-usb1232h} @* 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} @end itemize @section USB-JTAG / Altera USB-Blaster compatibles @@ -1339,7 +1341,7 @@ have only been used by the developer who created it. A separate chapter gives information about how to set these up. @xref{Debug Adapter Configuration}. -Read the OpenOCD source code (and Developer's GUide) +Read the OpenOCD source code (and Developer's Guide) if you have a new kind of hardware interface and need to provide a driver for it. @@ -1549,6 +1551,47 @@ also supports it. Otherwise use @command{adapter_khz}. Set the slow rate at the beginning of the reset sequence, and the faster rate as soon as the clocks are at full speed. +@anchor{The init_board procedure} +@subsection The init_board procedure +@cindex init_board procedure + +The concept of @code{init_board} procedure is very similar to @code{init_targets} (@xref{The init_targets procedure}.) +- it's a replacement of ``linear'' configuration scripts. This procedure is meant to be executed when OpenOCD enters run +stage (@xref{Entering the Run Stage},) after @code{init_targets}. The idea to have spearate @code{init_targets} and +@code{init_board} procedures is to allow the first one to configure everything target specific (internal flash, +internal RAM, etc.) and the second one to configure everything board specific (reset signals, chip frequency, +reset-init event handler, external memory, etc.). Additionally ``linear'' board config file will most likely fail when +target config file uses @code{init_targets} scheme (``linear'' script is executed before @code{init} and +@code{init_targets} - after), so separating these two configuration stages is very convenient, as the easiest way to +overcome this problem is to convert board config file to use @code{init_board} procedure. Board config scripts don't +need to override @code{init_targets} defined in target config files when they only need to to add some specifics. + +Just as @code{init_targets}, the @code{init_board} procedure can be overriden by ``next level'' script (which sources +the original), allowing greater code reuse. + +@example +### board_file.cfg ### + +# source target file that does most of the config in init_targets +source [find target/target.cfg] + +proc enable_fast_clock @{@} @{ + # enables fast on-board clock source + # configures the chip to use it +@} + +# initialize only board specifics - reset, clock, adapter frequency +proc init_board @{@} @{ + reset_config trst_and_srst trst_pulls_srst + + $_TARGETNAME configure -event reset-init @{ + adapter_khz 1 + enable_fast_clock + adapter_khz 10000 + @} +@} +@end example + @section Target Config Files @cindex config file, target @cindex target config file @@ -1815,8 +1858,8 @@ look at how you are setting up JTAG clocking. @cindex init_targets procedure Target config files can either be ``linear'' (script executed line-by-line when parsed in configuration stage, -@xref{Configuration Stage}) or they can contain a special procedure called @code{init_targets}, which will be executed -when entering run stage (after parsing all config files or after @code{init} command, @xref{Entering the Run Stage}). +@xref{Configuration Stage},) or they can contain a special procedure called @code{init_targets}, which will be executed +when entering run stage (after parsing all config files or after @code{init} command, @xref{Entering the Run Stage}.) Such procedure can be overriden by ``next level'' script (which sources the original). This concept faciliates code reuse when basic target config files provide generic configuration procedures and @code{init_targets} procedure, which can then be sourced and enchanced or changed in a ``more specific'' target config file. This is not possible with @@ -1849,6 +1892,8 @@ The easiest way to convert ``linear'' config files to @code{init_targets} versio For an example of this scheme see LPC2000 target config files. +The @code{init_boards} procedure is a similar concept concerning board config files (@xref{The init_board procedure}.) + @subsection ARM Core Specific Hacks If the chip has a DCC, enable it. If the chip is an ARM9 with some @@ -3326,7 +3371,7 @@ hardware to find these values. option. When vendors put out multiple versions of a chip, or use the same JTAG-level ID for several largely-compatible chips, it may be more practical to ignore the version field than to update config files to handle all of -the various chip IDs. +the various chip IDs. The version field is defined as bit 28-31 of the IDCODE. @item @code{-ircapture} @var{NUMBER} @*The bit pattern loaded by the TAP into the JTAG shift register on entry to the @sc{ircapture} state, such as 0x01. @@ -4611,13 +4656,6 @@ The AVR 8-bit microcontrollers from Atmel integrate flash memory. @comment - defines mass_erase ... pointless given flash_erase_address @end deffn -@deffn {Flash Driver} ecosflash -@emph{No idea what this is...} -The @var{ecosflash} driver defines one mandatory parameter, -the name of a modules of target code which is downloaded -and executed. -@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. @@ -4869,6 +4907,12 @@ the chip identification register, and autoconfigures itself. flash bank $_FLASHNAME stm32f1x 0 0 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 +flash bank $_FLASHNAME stm32f1x 0x08080000 0 0 0 $_TARGETNAME +@end example + Some stm32f1x-specific commands @footnote{Currently there is a @command{stm32f1x mass_erase} command. That seems pointless since the same effect can be had using the