X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=4cc051ee440a2e9466fc6eb26c5fc9e310d1d6b4;hp=483b27b7f1c2145e1c3ef28aae5310724565dfc4;hb=6f700d2b1c57d40c6ce4e9972427334f89bbc96c;hpb=b3d29cb5441ee5d38e8f7b561a58f03eb269dbe4 diff --git a/doc/openocd.texi b/doc/openocd.texi index 483b27b7f1..4cc051ee44 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -1595,8 +1595,11 @@ proc enable_fast_clock @{@} @{ proc init_board @{@} @{ reset_config trst_and_srst trst_pulls_srst + $_TARGETNAME configure -event reset-start @{ + adapter_khz 100 + @} + $_TARGETNAME configure -event reset-init @{ - adapter_khz 1 enable_fast_clock adapter_khz 10000 @} @@ -2556,6 +2559,36 @@ For example adapter definitions, see the configuration files shipped in the @end deffn +@deffn {Interface Driver} {ft232r} +This driver is implementing synchronous bitbang mode of an FTDI FT232R +USB UART bridge IC. + +List of connections (pin numbers for SSOP): +@itemize @minus +@item RXD(5) - TDI +@item TXD(1) - TCK +@item RTS(3) - TDO +@item CTS(11) - TMS +@item DTR(2) - TRST +@item DCD(10) - SRST +@end itemize + +These interfaces have several commands, used to configure the driver +before initializing the JTAG scan chain: + +@deffn {Config Command} {ft232r_vid_pid} @var{vid} @var{pid} +The vendor ID and product ID of the adapter. If not specified, default +0x0403:0x6001 is used. +@end deffn + +@deffn {Config Command} {ft232r_serial_desc} @var{serial} +Specifies the @var{serial} 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. +@end deffn + +@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 @@ -4217,6 +4250,9 @@ Calling this twice with two different event names assigns two different handlers, but calling it twice with the same event name assigns only one handler. +Current target is temporarily overridden to the event issuing target +before handler code starts and switched back after handler is done. + @item @code{-work-area-backup} (@option{0}|@option{1}) -- says whether the work area gets backed up; by default, @emph{it is not backed up.} @@ -4427,16 +4463,14 @@ buttons and events. The two examples below act the same, but one creates and invokes a small procedure while the other inlines it. @example -proc my_attach_proc @{ @} @{ - echo "Reset..." - reset halt +proc my_init_proc @{ @} @{ + echo "Disabling watchdog..." + mww 0xfffffd44 0x00008000 @} -mychip.cpu configure -event gdb-attach my_attach_proc -mychip.cpu configure -event gdb-attach @{ - echo "Reset..." - # To make flash probe and gdb load to flash work - # we need a reset init. - reset init +mychip.cpu configure -event reset-init my_init_proc +mychip.cpu configure -event reset-init @{ + echo "Disabling watchdog..." + mww 0xfffffd44 0x00008000 @} @end example @@ -4446,7 +4480,7 @@ The following target events are defined: @item @b{debug-halted} @* The target has halted for debug reasons (i.e.: breakpoint) @item @b{debug-resumed} -@* The target has resumed (i.e.: gdb said run) +@* The target has resumed (i.e.: GDB said run) @item @b{early-halted} @* Occurs early in the halt process @item @b{examine-start} @@ -4454,11 +4488,17 @@ The following target events are defined: @item @b{examine-end} @* After target examine is called with no errors. @item @b{gdb-attach} -@* 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. +@* When GDB connects. Issued before any GDB communication with the target +starts. GDB expects the target is halted during attachment. +@xref{gdbmeminspect,,GDB as a non-intrusive memory inspector}, how to +connect GDB to running target. +The event can be also used to set up the target so it is possible to probe flash. +Probing flash is necessary during GDB connect if you want to use +@pxref{programmingusinggdb,,programming using GDB}. +Another use of the flash memory map is for GDB to automatically choose +hardware or software breakpoints depending on whether the breakpoint +is in RAM or read only memory. +Default is @code{halt} @item @b{gdb-detach} @* When GDB disconnects @item @b{gdb-end} @@ -4473,13 +4513,13 @@ depending on whether the breakpoint is in RAM or read only memory. @item @b{gdb-flash-write-end} @* After GDB writes to the flash (default is @code{reset halt}) @item @b{gdb-start} -@* Before the target steps, gdb is trying to start/resume the target +@* Before the target steps, GDB is trying to start/resume the target @item @b{halted} @* The target has halted @item @b{reset-assert-pre} @* Issued as part of @command{reset} processing -after @command{reset_init} was triggered -but before either SRST alone is re-asserted on the scan chain, +after @command{reset-start} was triggered +but before either SRST alone is asserted on the scan chain, or @code{reset-assert} is triggered. @item @b{reset-assert} @* Issued as part of @command{reset} processing @@ -4513,8 +4553,8 @@ multiplexing, and so on. (You may be able to switch to a fast JTAG clock rate here, after the target clocks are fully set up.) @item @b{reset-start} -@* Issued as part of @command{reset} processing -before @command{reset_init} is called. +@* Issued as the first step in @command{reset} processing +before @command{reset-assert-pre} is called. This is the most robust place to use @command{jtag_rclk} or @command{adapter_khz} to switch to a low JTAG clock rate, @@ -5341,6 +5381,30 @@ The AVR 8-bit microcontrollers from Atmel integrate flash memory. @comment - defines mass_erase ... pointless given flash_erase_address @end deffn +@deffn {Flash Driver} bluenrg-x +STMicroelectronics BlueNRG-1 and BlueNRG-2 Bluetooth low energy wireless system-on-chip. They include ARM Cortex-M0 core and internal flash memory. +The driver automatically recognizes these chips using +the chip identification registers, and autoconfigures itself. + +@example +flash bank $_FLASHNAME bluenrg-x 0 0 0 0 $_TARGETNAME +@end example + +Note that when users ask to erase all the sectors of the flash, a mass erase command is used which is faster than erasing +each single sector one by one. + +@example +flash erase_sector 0 0 79 # It will perform a mass erase on BlueNRG-1 +@end example + +@example +flash erase_sector 0 0 127 # It will perform a mass erase on BlueNRG-2 +@end example + +Triggering a mass erase is also useful when users want to disable readout protection. + +@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 @@ -5401,7 +5465,7 @@ from NXP (former Freescale) include internal flash and use ARM Cortex-M0+ or M4 cores. The driver automatically recognizes flash size and a number of flash banks (1-4) using the chip identification register, and autoconfigures itself. -Use kinetis_ke driver for KE0x devices. +Use kinetis_ke driver for KE0x and KEAx devices. The @var{kinetis} driver defines option: @itemize @@ -5494,7 +5558,7 @@ Command disables watchdog timer. @deffn {Flash Driver} kinetis_ke @cindex kinetis_ke -KE0x members of the Kinetis microcontroller family from Freescale include +KE0x and KEAx members of the Kinetis microcontroller family from NXP include internal flash and use ARM Cortex-M0+. The driver automatically recognizes the KE0x sub-family using the chip identification register, and autoconfigures itself. @@ -5891,6 +5955,62 @@ The @var{num} parameter is a value shown by @command{flash banks}. @end deffn @end deffn +@deffn {Flash Driver} psoc6 +Supports PSoC6 (CY8C6xxx) family of Cypress microcontrollers. +PSoC6 is a dual-core device with CM0+ and CM4 cores. Both cores share +the same Flash/RAM/MMIO address space. + +Flash in PSoC6 is split into three regions: +@itemize @bullet +@item Main Flash - this is the main storage for user application. +Total size varies among devices, sector size: 256 kBytes, row size: +512 bytes. Supports erase operation on individual rows. +@item Work Flash - intended to be used as storage for user data +(e.g. EEPROM emulation). Total size: 32 KBytes, sector size: 32 KBytes, +row size: 512 bytes. +@item Supervisory Flash - special region which contains device-specific +service data. This region does not support erase operation. Only few rows can +be programmed by the user, most of the rows are read only. Programming +operation will erase row automatically. +@end itemize + +All three flash regions are supported by the driver. Flash geometry is detected +automatically by parsing data in SPCIF_GEOMETRY register. + +PSoC6 is equipped with NOR Flash so erased Flash reads as 0x00. + +@example +flash bank main_flash_cm0 psoc6 0x10000000 0 0 0 $@{TARGET@}.cm0 +flash bank work_flash_cm0 psoc6 0x14000000 0 0 0 $@{TARGET@}.cm0 +flash bank super_flash_user_cm0 psoc6 0x16000800 0 0 0 $@{TARGET@}.cm0 +flash bank super_flash_nar_cm0 psoc6 0x16001A00 0 0 0 $@{TARGET@}.cm0 +flash bank super_flash_key_cm0 psoc6 0x16005A00 0 0 0 $@{TARGET@}.cm0 +flash bank super_flash_toc2_cm0 psoc6 0x16007C00 0 0 0 $@{TARGET@}.cm0 + +flash bank main_flash_cm4 psoc6 0x10000000 0 0 0 $@{TARGET@}.cm4 +flash bank work_flash_cm4 psoc6 0x14000000 0 0 0 $@{TARGET@}.cm4 +flash bank super_flash_user_cm4 psoc6 0x16000800 0 0 0 $@{TARGET@}.cm4 +flash bank super_flash_nar_cm4 psoc6 0x16001A00 0 0 0 $@{TARGET@}.cm4 +flash bank super_flash_key_cm4 psoc6 0x16005A00 0 0 0 $@{TARGET@}.cm4 +flash bank super_flash_toc2_cm4 psoc6 0x16007C00 0 0 0 $@{TARGET@}.cm4 +@end example + +psoc6-specific commands +@deffn Command {psoc6 reset_halt} +Command can be used to simulate broken Vector Catch from gdbinit or tcl scripts. +When invoked for CM0+ target, it will set break point at application entry point +and issue SYSRESETREQ. This will reset both cores and all peripherals. CM0+ will +reset CM4 during boot anyway so this is safe. On CM4 target, VECTRESET is used +instead of SYSRESETREQ to avoid unwanted reset of CM0+; +@end deffn + +@deffn Command {psoc6 mass_erase} num +Erases the contents given flash bank. The @var{num} parameter is a value shown +by @command{flash banks}. +Note: only Main and Work flash regions support Erase operation. +@end deffn +@end deffn + @deffn {Flash Driver} sim3x All members of the SiM3 microcontroller family from Silicon Laboratories include internal flash and use ARM Cortex-M3 cores. It supports both JTAG @@ -9095,19 +9215,6 @@ With that particular hardware (Cortex-M3) the hardware breakpoints only work for code running from flash memory. Most other ARM systems do not have such restrictions. -Another example of useful GDB configuration came from a user who -found that single stepping his Cortex-M3 didn't work well with IRQs -and an RTOS until he told GDB to disable the IRQs while stepping: - -@example -define hook-step -mon cortex_m maskisr on -end -define hookpost-step -mon cortex_m maskisr off -end -@end example - Rather than typing such commands interactively, you may prefer to save them in a file and have GDB execute them as it starts, perhaps using a @file{.gdbinit} in your project directory or starting GDB @@ -9147,14 +9254,60 @@ GDB will look at the target memory map when a load command is given, if any areas to be programmed lie within the target flash area the vFlash packets will be used. -If the target needs configuring before GDB programming, an event -script can be executed: +If the target needs configuring before GDB programming, set target +event gdb-flash-erase-start: @example -$_TARGETNAME configure -event EVENTNAME BODY +$_TARGETNAME configure -event gdb-flash-erase-start BODY @end example +@xref{targetevents,,Target Events} for other GDB programming related events. To verify any flash programming the GDB command @option{compare-sections} can be used. + +@section Using GDB as a non-intrusive memory inspector +@cindex Using GDB as a non-intrusive memory inspector +@anchor{gdbmeminspect} + +If your project controls more than a blinking LED, let's say a heavy industrial +robot or an experimental nuclear reactor, stopping the controlling process +just because you want to attach GDB is not a good option. + +OpenOCD does not support GDB non-stop mode (might be implemented in the future). +Though there is a possible setup where the target does not get stopped +and GDB treats it as it were running. +If the target supports background access to memory while it is running, +you can use GDB in this mode to inspect memory (mainly global variables) +without any intrusion of the target process. + +Remove default setting of gdb-attach event. @xref{targetevents,,Target Events}. +Place following command after target configuration: +@example +$_TARGETNAME configure -event gdb-attach @{@} +@end example + +If any of installed flash banks does not support probe on running target, +switch off gdb_memory_map: +@example +gdb_memory_map disable +@end example + +Ensure GDB is configured without interrupt-on-connect. +Some GDB versions set it by default, some does not. +@example +set remote interrupt-on-connect off +@end example + +If you switched gdb_memory_map off, you may want to setup GDB memory map +manually or issue @command{set mem inaccessible-by-default off} + +Now you can issue GDB command @command{target remote ...} and inspect memory +of a running target. Do not use GDB commands @command{continue}, +@command{step} or @command{next} as they synchronize GDB with your target +and GDB would require stopping the target to get the prompt back. + +Do not use this mode under an IDE like Eclipse as it caches values of +previously shown varibles. + @anchor{usingopenocdsmpwithgdb} @section Using OpenOCD SMP with GDB @cindex SMP