OpenOCD初探:如何配置调试适配器
调试适配器配置
正确安装OpenOCD包括使您的操作系统允许OpenOCD访问调试适配器。一旦完成,Tcl命令将被用来选择使用哪个命令,并配置如何使用它。
注意:因为OpenOCD一开始只关注JTAG,所以您可能会发现它错误地认为JTAG是唯一正在使用的传输协议。请注意,最近版本的OpenOCD正在消除这一限制。JTAG仍然比大多数其他传输工具更有功能。其他传输不支持边界扫描操作,或者可能是特定于给定的芯片供应商的。有些可能只用于编程闪存,而不适用于调试。
调试适配器/接口/加密狗通常通过由openocd.cfg文件提供的接口配置文件中的命令进行配置,或通过命令行-f interface/…cfg选项进行配置。
source [find interface/olimex-jtag-tiny.cfg]
这些命令告诉OpenOCD您有什么类型的JTAG适配器,以及如何与它对话。一些情况是如此简单,你只需要说使用什么驱动程序:
# jlink interface adapter driver jlink
大多数适配器需要比更多的配置。
1适配器配置
适配器驱动程序命令告诉OpenOCD您正在使用什么类型的调试适配器。根据适配器的类型,您可能需要使用一个或多个附加命令来进一步识别或配置适配器。
- Config Command: adapter driver name
使用适配器驱动程序名称连接到目标。
- Command: adapter list
列出已内置到OpenOCD运行副本中的调试适配器驱动程序。
- Config Command: adapter transports transport_name+
指定此调试适配器支持的传输。适配器驱动程序构建在类似的知识中;只有当外部配置(如跳线)改变了硬件可以支持的内容时,才使用此选项。
- Config Command: adapter gpio [ tdo | tdi | tms | tck | trst | swdio | swdio_dir | swclk | srst | led [ gpio_number | -chip chip_number | -active-high | -active-low | -push-pull | -open-drain | -open-source | -pull-none | -pull-up | -pull-down | -init-inactive | -init-active | -init-input ] ]定义适配器将使用的GPIO映射。可以定义以下信号:
- tdo, tdi, tms, tck, trst: JTAG transport signals
- swdio, swclk: SWD transport signals
- swdio_dir: optional swdio buffer control signal
- srst: system reset signal
- led: optional activity led
有些适配器要求除了GPIO编号之外,还设置GPIO芯片编号。配置选项使信号能够被定义为有效高电平或有效低电平。输出驱动模式可以设置为推挽、开漏或开源。
大多数适配器将不得不通过在输入和输出之间切换来模拟开漏或开源驱动模式。输入和输出信号可以被指示使用上拉或下拉电阻器,假设它得到适配器驱动器和硬件的支持。
输出的初始状态也可以设置,“活动”状态表示高活动输出为1,低活动输出为0。双向信号也可以被初始化为输入。如果swdio信号被缓冲,则可以利用swdio_dir信号来控制缓冲方向;活动状态意味着应该将缓冲区设置为适配器的输出。命令选项是累积的,以后的命令可以覆盖以前的命令定义的设置。
顺序发送的两个命令gpio led 7-active high和gpio led-chip 1-active low相当于发出一个命令gpio-led 7-chip 1-active low。不允许为作为输入的信号设置驱动模式或初始状态。srst和trst信号的驱动模式必须使用adapter reset_config命令设置。不允许设置swdio_dir的初始状态,因为它是从swdio的初始状态导出的。
命令适配器gpio打印所有gpio的当前配置,而命令适配器gpiogpio_name打印gpio_name的当前配置。并非所有适配器都支持这种通用GPIO映射,有些适配器需要自己的命令来定义所使用的GPIO。支持通用映射的适配器可能不支持所有列出的选项。
- Command: adapter name
返回正在使用的调试适配器驱动程序的名称。 - Config Command: adapter usb location [-[.]…]
显示或指定要使用的适配器的物理USB端口。路径从总线开始,沿着物理端口走,每个端口选项都指定总线拓扑中的更深层次,最后一个端口表示目标适配器实际插入的位置。可以使用命令lsusb-t或dmesg查询USB总线拓扑。
只有当您的libusb1版本至少为1.0.16时,此命令才可用。 - Config Command: adapter serial serial_string
指定要使用的适配器的serial_string。如果未指定此命令,则不会检查串行字符串。只有以下适配器驱动程序使用此命令中的串行字符串:arm jtag ew、cmsis_dap、esp_usb_jtag、ft232r、ftdi、hla(stlink、ti icdi)、jlink、kitprog、opendus、openjtag、osbdm、presto、rlink、st link、usb_blaster(ublast2)、usbprog、vsllink、xds10。
2接口驱动程序
在配置OpenOCD时,必须显式启用此处列出的每个接口驱动程序,以便在运行时可用。
Interface Driver: amt_jtagaccel
Amontec Chameleon in its JTAG Accelerator configuration, connected to a PC’s EPP mode parallel port. This defines some driver-specific commands:
Config Command: parport port number
Specifies either the address of the I/O port (default: 0x378 for LPT1) or the number of the /dev/parport device.
Config Command: rtck [enable|disable]
Displays status of RTCK option. Optionally sets that option first.
Interface Driver: arm-jtag-ew
Olimex ARM-JTAG-EW USB adapter This has one driver-specific command:
Command: armjtagew_info
Logs some status
Interface Driver: at91rm9200
Supports bitbanged JTAG from the local system, presuming that system is an Atmel AT91rm9200 and a specific set of GPIOs is used.
Interface Driver: cmsis-dap
ARM CMSIS-DAP compliant based adapter v1 (USB HID based) or v2 (USB bulk).
Config Command: cmsis_dap_vid_pid [vid pid]+
The vendor ID and product ID of the CMSIS-DAP device. If not specified the driver will attempt to auto detect the CMSIS-DAP device. Currently, up to eight [vid, pid] pairs may be given, e.g.
cmsis_dap_vid_pid 0xc251 0xf001 0x0d28 0x0204
Config Command: cmsis_dap_backend [auto|usb_bulk|hid]
Specifies how to communicate with the adapter:
- hid Use HID generic reports - CMSIS-DAP v1
- usb_bulk Use USB bulk - CMSIS-DAP v2
- auto First try USB bulk CMSIS-DAP v2, if not found try HID CMSIS-DAP v1. This is the default if cmsis_dap_backend is not specified.
Config Command: cmsis_dap_usb interface [number]
Specifies the number of the USB interface to use in v2 mode (USB bulk). In most cases need not to be specified and interfaces are searched by interface string or for user class interface.
Command: cmsis-dap info
Display various device information, like hardware version, firmware version, current bus status.
Command: cmsis-dap cmd number number …
Execute an arbitrary CMSIS-DAP command. Use for adapter testing or for handling of an adapter vendor specific command from a Tcl script.
Take given numbers as bytes, assemble a CMSIS-DAP protocol command packet from them and send it to the adapter. The first 4 bytes of the adapter response are logged. See https://arm-software.github.io/CMSIS_5/DAP/html/group__DAP__Commands__gr.html
Interface Driver: dummy
A dummy software-only driver for debugging.
Interface Driver: ep93xx
Cirrus Logic EP93xx based single-board computer bit-banging (in development)
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.
The driver is using libusb-1.0 in asynchronous mode to talk to the FTDI device, bypassing intermediate libraries like libftdi.
Support for new FTDI based adapters can be added completely 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 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. Inputs can be read using the ftdi get_signal command.
To support SWD, a signal named SWD_EN must be defined. It is set to 1 when the SWD protocol is selected. When set, the adapter should route the SWDIO pin to the data input. An SWDIO_OE signal, if defined, will be set to 1 or 0 as required by the protocol, to tell the adapter to drive the data output onto the SWDIO pin or keep the SWDIO pin Hi-Z, respectively.
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:
- Push-pull with one FTDI output as (non-)inverted data line
- Open drain with one FTDI output as (non-)inverted output-enable
- Tristate with one FTDI output as (non-)inverted data line and another FTDI output as (non-)inverted output-enable
- Unbuffered, using the FTDI GPIO as a tristate output directly by switching data and direction as necessary
These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain:
Config Command: ftdi vid_pid [vid pid]+
The vendor ID and product ID of the adapter. Up to eight [vid, pid] pairs may be given, e.g.
ftdi vid_pid 0x0403 0xcff8 0x15ba 0x0003
Config Command: ftdi device_desc description
Provides the USB device description (the iProduct string) of the adapter. If not specified, the device description is ignored during device selection.
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.
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.
Command: ftdi layout_signal name [-data|-ndata data_mask] [-input|-ninput input_mask] [-oe|-noe oe_mask] [-alias|-nalias name]
Creates a signal with the specified 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. data_mask is the bitmask for the pin(s) connected to the data input of the output buffer. -ndata is used with inverting data inputs and -data with non-inverting inputs. The -oe (or -noe) option tells where the output-enable (or not-output-enable) input to the output buffer is connected. The options -input and -ninput specify the bitmask for pins to be read with the method ftdi get_signal.
Both data_mask and oe_mask need not be specified. For example, a simple open-collector transistor driver would be specified with -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, reset_config must be specified as srst_open_drain, not srst_push_pull.
A special case is provided when -data and -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.
If -alias or -nalias is used, the signal is created identical (or with data inverted) to an already specified signal name.
Command: ftdi set_signal name 0|1|z
Set a previously defined signal to the specified level.
- 0, drive low
- 1, drive high
- z, set to high-impedance
Command: ftdi get_signal name
Get the value of a previously defined signal.
Command: ftdi tdo_sample_edge rising|falling
Configure TCK edge at which the adapter samples the value of the TDO signal
Due to signal propagation delays, sampling TDO on rising TCK can become quite peculiar at high JTAG clock speeds. However, FTDI chips offer a possibility to sample TDO on falling edge of TCK. With some board/adapter configurations, this may increase stability at higher JTAG clocks.
- rising, sample TDO on rising edge of TCK - this is the default
- falling, sample TDO on falling edge of TCK
For example adapter definitions, see the configuration files shipped in the interface/ftdi directory.
Interface Driver: ft232r
This driver is implementing synchronous bitbang mode of an FTDI FT232R, FT230X, FT231X and similar USB UART bridge ICs by reusing RS232 signals as GPIO. It currently doesn’t support using CBUS pins as GPIO.
List of connections (default physical pin numbers for FT232R in 28-pin SSOP package):
- RXD(5) - TDI
- TXD(1) - TCK
- RTS(3) - TDO
- CTS(11) - TMS
- DTR(2) - TRST
- DCD(10) - SRST
User can change default pinout by supplying configuration commands with GPIO numbers or RS232 signal names. GPIO numbers correspond to bit numbers in FTDI GPIO register. They differ from physical pin numbers. For details see actual FTDI chip datasheets. Every JTAG line must be configured to unique GPIO number different than any other JTAG line, even those lines that are sometimes not used like TRST or SRST.
FT232R
- bit 7 - RI
- bit 6 - DCD
- bit 5 - DSR
- bit 4 - DTR
- bit 3 - CTS
- bit 2 - RTS
- bit 1 - RXD
- bit 0 - TXD
These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain:
Config Command: ft232r vid_pid vid pid
The vendor ID and product ID of the adapter. If not specified, default 0x0403:0x6001 is used.
Config Command: ft232r jtag_nums tck tms tdi tdo
Set four JTAG GPIO numbers at once. If not specified, default 0 3 1 2 or TXD CTS RXD RTS is used.
Config Command: ft232r tck_num tck
Set TCK GPIO number. If not specified, default 0 or TXD is used.
Config Command: ft232r tms_num tms
Set TMS GPIO number. If not specified, default 3 or CTS is used.
Config Command: ft232r tdi_num tdi
Set TDI GPIO number. If not specified, default 1 or RXD is used.
Config Command: ft232r tdo_num tdo
Set TDO GPIO number. If not specified, default 2 or RTS is used.
Config Command: ft232r trst_num trst
Set TRST GPIO number. If not specified, default 4 or DTR is used.
Config Command: ft232r srst_num srst
Set SRST GPIO number. If not specified, default 6 or DCD is used.
Config Command: ft232r restore_serial word
Restore serial port after JTAG. This USB bitmode control word (16-bit) will be sent before quit. Lower byte should set GPIO direction register to a “sane” state: 0x15 for TXD RTS DTR as outputs (1), others as inputs (0). Higher byte is usually 0 to disable bitbang mode. When kernel driver reattaches, serial port should continue to work. Value 0xFFFF disables sending control word and serial port, then kernel driver will not reattach. If not specified, default 0xFFFF is used.
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 instead of directly driving JTAG.
The remote_bitbang driver is useful for debugging software running on processors which are being simulated.
Config Command: remote_bitbang port number
Specifies the TCP port of the remote process to connect to or 0 to use UNIX sockets instead of TCP.
Config Command: remote_bitbang host hostname
Specifies the hostname of the remote process to connect to using TCP, or the name of the UNIX socket to use if remote_bitbang port is 0.
For example, to connect remotely via TCP to the host foobar you might have something like:
adapter driver remote_bitbang
remote_bitbang port 3335
remote_bitbang host foobar
To connect to another process running locally via UNIX sockets with socket named mysocket:
adapter driver remote_bitbang
remote_bitbang port 0
remote_bitbang host mysocket
Interface Driver: usb_blaster
USB JTAG/USB-Blaster compatibles over one of the userspace libraries for FTDI chips. These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain:
Config Command: usb_blaster vid_pid vid pid
The vendor ID and product ID of the FTDI FT245 device. If not specified, default values are used. Currently, only one vid, pid pair may be given, e.g. for Altera USB-Blaster (default):
usb_blaster vid_pid 0x09FB 0x6001
The following VID/PID is for Kolja Waschk’s USB JTAG:
usb_blaster vid_pid 0x16C0 0x06AD
Command: usb_blaster pin (pin6|pin8) (0|1|s|t)
Sets the state or function of the unused GPIO pins on USB-Blasters (pins 6 and 8 on the female JTAG header). These pins can be used as SRST and/or TRST provided the appropriate connections are made on the target board.
For example, to use pin 6 as SRST:
usb_blaster pin pin6 s
reset_config srst_only
Config Command: usb_blaster lowlevel_driver (ftdi|ublast2)
Chooses the low level access method for the adapter. If not specified, ftdi is selected unless it wasn’t enabled during the configure stage. USB-Blaster II needs ublast2.
Config Command: usb_blaster firmware path
This command specifies path to access USB-Blaster II firmware image. To be used with USB-Blaster II only.
Interface Driver: gw16012
Gateworks GW16012 JTAG programmer. This has one driver-specific command:
Config Command: parport port [port_number]
Display either the address of the I/O port (default: 0x378 for LPT1) or the number of the /dev/parport device. If a parameter is provided, first switch to use that port. This is a write-once setting.
Interface Driver: jlink
SEGGER J-Link family of USB adapters. It currently supports JTAG and SWD transports.
Compatibility Note: SEGGER released many firmware versions for the many hardware versions they produced. OpenOCD was extensively tested and intended to run on all of them, but some combinations were reported as incompatible. As a general recommendation, it is advisable to use the latest firmware version available for each hardware version. However the current V8 is a moving target, and SEGGER firmware versions released after the OpenOCD was released may not be compatible. In such cases it is recommended to revert to the last known functional version. For 0.5.0, this is from “Feb 8 2012 14:30:39”, packed with 4.42c. For 0.6.0, the last known version is from “May 3 2012 18:36:22”, packed with 4.46f.
Command: jlink hwstatus
Display various hardware related information, for example target voltage and pin states.
Command: jlink freemem
Display free device internal memory.
Command: jlink jtag [2|3]
Set the JTAG command version to be used. Without argument, show the actual JTAG command version.
Command: jlink config
Display the device configuration.
Command: jlink config targetpower [on|off]
Set the target power state on JTAG-pin 19. Without argument, show the target power state.
Command: jlink config mac [ff:ff:ff:ff:ff:ff]
Set the MAC address of the device. Without argument, show the MAC address.
Command: jlink config ip [A.B.C.D(/E|F.G.H.I)]
Set the IP configuration of the device, where A.B.C.D is the IP address, E the bit of the subnet mask and F.G.H.I the subnet mask. Without arguments, show the IP configuration.
Command: jlink config usb [0 to 3]
Set the USB address of the device. This will also change the USB Product ID (PID) of the device. Without argument, show the USB address.
Command: jlink config reset
Reset the current configuration.
Command: jlink config write
Write the current configuration to the internal persistent storage.
Command: jlink emucom write
Write data to an EMUCOM channel. The data needs to be encoded as hexadecimal pairs.
The following example shows how to write the three bytes 0xaa, 0x0b and 0x23 to the EMUCOM channel 0x10:
jlink emucom write 0x10 aa0b23
Command: jlink emucom read
Read data from an EMUCOM channel. The read data is encoded as hexadecimal pairs.
The following example shows how to read 4 bytes from the EMUCOM channel 0x0:
jlink emucom read 0x0 4
77a90000
Config Command: jlink usb <0 to 3>
Set the USB address of the interface, in case more than one adapter is connected to the host. If not specified, USB addresses are not considered. Device selection via USB address is not always unambiguous. It is recommended to use the serial number instead, if possible.
As a configuration command, it can be used only before ’init’.
Interface Driver: kitprog
This driver is for Cypress Semiconductor’s KitProg adapters. The KitProg is an SWD-only adapter that is designed to be used with Cypress’s PSoC and PRoC device families, but it is possible to use it with some other devices. If you are using this adapter with a PSoC or a PRoC, you may need to add kitprog_init_acquire_psoc or kitprog acquire_psoc to your configuration script.
Note that this driver is for the proprietary KitProg protocol, not the CMSIS-DAP mode introduced in firmware 2.14. If the KitProg is in CMSIS-DAP mode, it cannot be used with this driver, and must either be used with the cmsis-dap driver or switched back to KitProg mode. See the Cypress KitProg User Guide for instructions on how to switch KitProg modes.
Known limitations:
The frequency of SWCLK cannot be configured, and varies between 1.6 MHz and 2.7 MHz.
For firmware versions below 2.14, “JTAG to SWD” sequences are replaced by “SWD line reset” in the driver. This is for two reasons. First, the KitProg does not support sending arbitrary SWD sequences, and only firmware 2.14 and later implement both “JTAG to SWD” and “SWD line reset” in firmware. Earlier firmware versions only implement “SWD line reset”. Second, due to a firmware quirk, an SWD sequence must be sent after every target reset in order to re-establish communications with the target.
Due in part to the limitation above, KitProg devices with firmware below version 2.14 will need to use kitprog_init_acquire_psoc in order to communicate with PSoC 5LP devices. This is because, assuming debug is not disabled on the PSoC, the PSoC 5LP needs its JTAG interface switched to SWD mode before communication can begin, but prior to firmware 2.14, “JTAG to SWD” could only be sent with an acquisition sequence.
Config Command: kitprog_init_acquire_psoc
Indicate that a PSoC acquisition sequence needs to be run during adapter init. Please be aware that the acquisition sequence hard-resets the target.
Command: kitprog acquire_psoc
Run a PSoC acquisition sequence immediately. Typically, this should not be used outside of the target-specific configuration scripts since it hard-resets the target as a side-effect. This is necessary for “reset halt” on some PSoC 4 series devices.
Command: kitprog info
Display various adapter information, such as the hardware version, firmware version, and target voltage.
Interface Driver: parport
Supports PC parallel port bit-banging cables: Wigglers, PLD download cable, and more. These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain:
Config Command: parport cable name
Set the layout of the parallel port cable used to connect to the target. This is a write-once setting. Currently valid cable name values include:
- altium Altium Universal JTAG cable.
- arm-jtag Same as original wiggler except SRST and TRST connections reversed and TRST is also inverted.
- chameleon The Amontec Chameleon’s CPLD when operated in configuration mode. This is only used to program the Chameleon itself, not a connected target.
- dlc5 The Xilinx Parallel cable III.
- flashlink The ST Parallel cable.
- lattice Lattice ispDOWNLOAD Cable
- old_amt_wiggler The Wiggler configuration that comes with some versions of Amontec’s Chameleon Programmer. The new version available from the website uses the original Wiggler layout (’wiggler’)
- triton The parallel port adapter found on the “Karo Triton 1 Development Board”. This is also the layout used by the HollyGates design (see http://www.lartmaker.nl/projects/jtag/).
- wiggler The original Wiggler layout, also supported by several clones, such as the Olimex ARM-JTAG
- wiggler2 Same as original wiggler except an led is fitted on D5.
- wiggler_ntrst_inverted Same as original wiggler except TRST is inverted.
Config Command: parport port [port_number]
Display either the address of the I/O port (default: 0x378 for LPT1) or the number of the /dev/parport device. If a parameter is provided, first switch to use that port. This is a write-once setting.
When using PPDEV to access the parallel port, use the number of the parallel port: parport port 0 (the default). If parport port 0x378 is specified you may encounter a problem.
Config Command: parport toggling_time [nanoseconds]
Displays how many nanoseconds the hardware needs to toggle TCK; the parport driver uses this value to obey the adapter speed configuration. When the optional nanoseconds parameter is given, that setting is changed before displaying the current value.
The default setting should work reasonably well on commodity PC hardware. However, you may want to calibrate for your specific hardware.
Tip: To measure the toggling time with a logic analyzer or a digital storage oscilloscope, follow the procedure below:
parport toggling_time 1000
adapter speed 500
This sets the maximum JTAG clock speed of the hardware, but the actual speed probably deviates from the requested 500 kHz. Now, measure the time between the two closest spaced TCK transitions. You can use runtest 1000 or something similar to generate a large set of samples. Update the setting to match your measurement:
parport toggling_time
Now the clock speed will be a better match for adapter speed command given in OpenOCD scripts and event handlers.
You can do something similar with many digital multimeters, but note that you’ll probably need to run the clock continuously for several seconds before it decides what clock rate to show. Adjust the toggling time up or down until the measured clock rate is a good match with the rate you specified in the adapter speed command; be conservative.
Config Command: parport write_on_exit (on|off)
This will configure the parallel driver to write a known cable-specific value to the parallel interface on exiting OpenOCD.
For example, the interface configuration file for a classic “Wiggler” cable on LPT2 might look something like this:
adapter driver parport
parport port 0x278
parport cable wiggler
Interface Driver: presto
ASIX PRESTO USB JTAG programmer.
Interface Driver: rlink
Raisonance RLink USB adapter
Interface Driver: usbprog
usbprog is a freely programmable USB adapter.
Interface Driver: vsllink
vsllink is part of Versaloon which is a versatile USB programmer.
Note: This defines quite a few driver-specific commands, which are not currently documented here.
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 STMicroelectronics ST-LINK, TI ICDI and Nuvoton Nu-Link. ST-LINK firmware version >= V2.J21.S4 recommended due to issues with earlier versions of firmware where serial number is reset after first use. Suggest using ST firmware update utility to upgrade ST-LINK firmware even if current version reported is V2.J21.S4.
Config Command: hla_device_desc description
Currently Not Supported.
Config Command: hla_layout (stlink|icdi|nulink)
Specifies the adapter layout to use.
Config Command: hla_vid_pid [vid pid]+
Pairs of vendor IDs and product IDs of the device.
Config Command: hla_stlink_backend (usb | tcp [port])
ST-Link only: Choose between ’exclusive’ USB communication (the default backend) or ’shared’ mode using ST-Link TCP server (the default port is 7184).
Note: ST-Link TCP server is a binary application provided by ST available from ST-LINK server software module.
Command: hla_command command
Execute a custom adapter-specific command. The command string is passed as is to the underlying adapter layout handler.
Interface Driver: st-link
This is a driver that supports STMicroelectronics adapters ST-LINK/V2 (from firmware V2J24), STLINK-V3 and STLINK-V3PWR, thanks to a new API that provides directly access the arm ADIv5 DAP.
The new API provide access to multiple AP on the same DAP, but the maximum number of the AP port is limited by the specific firmware version (e.g. firmware V2J29 has 3 as maximum AP number, while V2J32 has 8). An error is returned for any AP number above the maximum allowed value.
Note: Either these same adapters and their older versions are also supported by the hla interface driver.
Config Command: st-link backend (usb | tcp [port])
Choose between ’exclusive’ USB communication (the default backend) or ’shared’ mode using ST-Link TCP server (the default port is 7184).
Note: ST-Link TCP server is a binary application provided by ST available from ST-LINK server software module.
Note: ST-Link TCP server does not support the SWIM transport.
Config Command: st-link vid_pid [vid pid]+
Pairs of vendor IDs and product IDs of the device.
Command: st-link cmd rx_n (tx_byte)+
Sends an arbitrary command composed by the sequence of bytes tx_byte and receives rx_n bytes.
For example, the command to read the target’s supply voltage is one byte 0xf7 followed by 15 bytes zero. It returns 8 bytes, where the first 4 bytes represent the ADC sampling of the reference voltage 1.2V and the last 4 bytes represent the ADC sampling of half the target’s supply voltage.
> st-link cmd 8 0xf7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0xf1 0x05 0x00 0x00 0x0b 0x08 0x00 0x00
The result can be converted to Volts (ignoring the most significant bytes, always zero)
> set a [st-link cmd 8 0xf7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] > set n [expr {[lindex $a 4] + 256 * [lindex $a 5]}] > set d [expr {[lindex $a 0] + 256 * [lindex $a 1]}] > echo [expr {2 * 1.2 * $n / $d}] 3.24891518738
Interface Driver: opendous
opendous-jtag is a freely programmable USB adapter.
Interface Driver: ulink
This is the Keil ULINK v1 JTAG debugger.
Interface Driver: xds110
The XDS110 is included as the embedded debug probe on many Texas Instruments LaunchPad evaluation boards. The XDS110 is also available as a stand-alone USB debug probe with the added capability to supply power to the target board. The following commands are supported by the XDS110 driver:
Config Command: xds110 supply voltage_in_millivolts
Available only on the XDS110 stand-alone probe. Sets the voltage level of the XDS110 power supply. A value of 0 leaves the supply off. Otherwise, the supply can be set to any value in the range 1800 to 3600 millivolts.
Command: xds110 info
Displays information about the connected XDS110 debug probe (e.g. firmware version).
Interface Driver: xlnx_pcie_xvc
This driver supports the Xilinx Virtual Cable (XVC) over PCI Express. It is commonly found in Xilinx based PCI Express designs. It allows debugging fabric based JTAG/SWD devices such as Cortex-M1/M3 microcontrollers. Access to this is exposed via extended capability registers in the PCI Express configuration space.
For more information see Xilinx PG245 (Section on From_PCIE_to_JTAG mode).
Config Command: xlnx_pcie_xvc config device
Specifies the PCI Express device via parameter device to use.
The correct value for device can be obtained by looking at the output of lscpi -D (first column) for the corresponding device.
The string will be of the format “DDDD:BB:SS.F” such as “0000:65:00.1”.
Interface Driver: bcm2835gpio
This SoC is present in Raspberry Pi which is a cheap single-board computer exposing some GPIOs on its expansion header.
The driver accesses memory-mapped GPIO peripheral registers directly for maximum performance, but the only possible race condition is for the pins’ modes/muxing (which is highly unlikely), so it should be able to coexist nicely with both sysfs bitbanging and various peripherals’ kernel drivers. The driver restores the previous configuration on exit.
GPIO numbers >= 32 can’t be used for performance reasons. GPIO configuration is handled by the generic command adapter gpio.
See interface/raspberrypi-native.cfg for a sample config and interface/raspberrypi-gpio-connector.cfg for pinout.
Config Command: bcm2835gpio speed_coeffs speed_coeff speed_offset
Set SPEED_COEFF and SPEED_OFFSET for delay calculations. If unspecified, speed_coeff defaults to 113714, and speed_offset defaults to 28.
Config Command: bcm2835gpio peripheral_mem_dev device
Set the device path for access to the memory mapped GPIO control registers. Uses /dev/gpiomem by default, this is also the preferred option with respect to system security. If overridden to /dev/mem:
- OpenOCD needs cap_sys_rawio or run as root to open /dev/mem. Please be aware of security issues imposed by running OpenOCD with elevated user rights and by /dev/mem itself.
- correct peripheral_base must be configured.
- GPIO 0-27 pads are set to the limited slew rate and drive strength is reduced to 4 mA (2 mA on RPi 4).
Config Command: bcm2835gpio peripheral_base base
Set the peripheral base register address to access GPIOs. Ignored if /dev/gpiomem is used. For the RPi1, use 0x20000000. For RPi2 and RPi3, use 0x3F000000. For RPi4, use 0xFE000000. A full list can be found in the official guide.
Interface Driver: imx_gpio
i.MX SoC is present in many community boards. Wandboard is an example of the one which is most popular.
This driver is mostly the same as bcm2835gpio.
See interface/imx-native.cfg for a sample config and pinout.
Interface Driver: am335xgpio The AM335x SoC is present in BeagleBone
Black and BeagleBone Green single-board computers which expose some of the GPIOs on the two expansion headers.
For maximum performance the driver accesses memory-mapped GPIO peripheral registers directly. The memory mapping requires read and write permission to kernel memory; if /dev/gpiomem exists it will be used, otherwise /dev/mem will be used. The driver restores the GPIO state on exit.
All four GPIO ports are available. GPIO configuration is handled by the generic command adapter gpio.
Config Command: am335xgpio speed_coeffs speed_coeff speed_offset
Set SPEED_COEFF and SPEED_OFFSET for delay calculations. If unspecified speed_coeff defaults to 600000 and speed_offset defaults to 575.
See interface/beaglebone-swd-native.cfg for a sample configuration file.
Interface Driver: linuxgpiod
Linux provides userspace access to GPIO through libgpiod since Linux kernel version v4.6. The driver emulates either JTAG or SWD transport through bitbanging. There are no driver-specific commands, all GPIO configuration is handled by the generic command adapter gpio. This driver supports the resistor pull options provided by the adapter gpio command but the underlying hardware may not be able to support them.
See interface/dln-2-gpiod.cfg for a sample configuration file.
Interface Driver: sysfsgpio
Linux legacy userspace access to GPIO through sysfs is deprecated from Linux kernel version v5.3. Prefer using linuxgpiod, instead.
See interface/sysfsgpio-raspberrypi.cfg for a sample config.
Interface Driver: openjtag
OpenJTAG compatible USB adapter. This defines some driver-specific commands:
Config Command: openjtag variant variant
Specifies the variant of the OpenJTAG adapter (see http://www.openjtag.org/). Currently valid variant values include:
- standard Standard variant (default).
- cy7c65215 Cypress CY7C65215 Dual Channel USB-Serial Bridge Controller (see http://www.cypress.com/?rID=82870).
Config Command: openjtag device_desc string
The USB device description string of the adapter. This value is only used with the standard variant.
Interface Driver: vdebug
Cadence Virtual Debug Interface driver.
Config Command: vdebug server host:port
Specifies the host and TCP port number where the vdebug server runs.
Config Command: vdebug batching value
Specifies the batching method for the vdebug request. Possible values are 0 for no batching 1 or wr to batch write transactions together (default) 2 or rw to batch both read and write transactions
Config Command: vdebug polling min max
Takes two values, representing the polling interval in ms. Lower values mean faster debugger responsiveness, but lower emulation performance. The minimum should be around 10, maximum should not exceed 1000, which is the default gdb and keepalive timeout value.
Config Command: vdebug bfm_path path clk_period
Specifies the hierarchical path and input clk period of the vdebug BFM in the design. The hierarchical path uses Verilog notation top.inst.inst The clock period must include the unit, for instance 40ns.
Config Command: vdebug mem_path path base size
Specifies the hierarchical path to the design memory instance for backdoor access. Up to 4 memories can be specified. The hierarchical path uses Verilog notation. The base specifies start address in the design address space, size its size in bytes. Both values can use hexadecimal notation with prefix 0x.
Interface Driver: jtag_dpi
SystemVerilog Direct Programming Interface (DPI) compatible driver for JTAG devices in emulation. The driver acts as a client for the SystemVerilog DPI server interface.
Config Command: jtag_dpi set_port port
Specifies the TCP/IP port number of the SystemVerilog DPI server interface.
Config Command: jtag_dpi set_address address
Specifies the TCP/IP address of the SystemVerilog DPI server interface.
Interface Driver: buspirate
This driver is for the Bus Pirate (see http://dangerousprototypes.com/docs/Bus_Pirate) and compatible devices. It uses a simple data protocol over a serial port connection.
Most hardware development boards have a UART, a real serial port, or a virtual USB serial device, so this driver allows you to start building your own JTAG adapter without the complexity of a custom USB connection.
Config Command: buspirate port serial_port
Specify the serial port’s filename. For example:
buspirate port /dev/ttyUSB0
Config Command: buspirate speed (normal|fast)
Set the communication speed to 115k (normal) or 1M (fast). For example:
buspirate speed normal
Config Command: buspirate mode (normal|open-drain)
Set the Bus Pirate output mode.
- In normal mode (push/pull), do not enable the pull-ups, and do not connect I/O header pin VPU to JTAG VREF.
- In open drain mode, you will then need to enable the pull-ups.
For example:
buspirate mode normal
Config Command: buspirate pullup (0|1)
Whether to connect (1) or not (0) the I/O header pin VPU (JTAG VREF) to the pull
推荐阅读
-
OpenOCD初探:如何配置调试适配器
-
如何在VS Code中轻松完成常用设置:快捷键配置、C/C++调试与代码路径管理指南
-
如何在Windows上使用VScode轻松设置C/C++编译、运行与调试(详解json配置文件)
-
如何在 VS Code 中设置调试参数:理解 launch.json 配置详情、利用 task.json 替换变量、开启自动保存与代码格式化、处理空格与制表符、探索函数调用链、掌握文件查找与全站搜索技巧
-
如何在远程服务器上利用Tomcat内置的jpda进行调试 - 第一步:配置远程Tomcat以启用debug功能
-
如何在Eclipse中使用Java JPDA进行远程应用程序调试 - 配置Java应用的步骤指南
-
如何在JDPA IDEA中配置并解决连接拒绝的远程调试问题
-
在VS Code中调试:如何针对特定的conda环境修改launch.json配置
-
SSM三大框架基础面试题-一、Spring篇 什么是Spring框架? Spring是一种轻量级框架,提高开发人员的开发效率以及系统的可维护性。 我们一般说的Spring框架就是Spring Framework,它是很多模块的集合,使用这些模块可以很方便地协助我们进行开发。这些模块是核心容器、数据访问/集成、Web、AOP(面向切面编程)、工具、消息和测试模块。比如Core Container中的Core组件是Spring所有组件的核心,Beans组件和Context组件是实现IOC和DI的基础,AOP组件用来实现面向切面编程。 Spring的6个特征: 核心技术:依赖注入(DI),AOP,事件(Events),资源,i18n,验证,数据绑定,类型转换,SpEL。 测试:模拟对象,TestContext框架,Spring MVC测试,WebTestClient。 数据访问:事务,DAO支持,JDBC,ORM,编组XML。 Web支持:Spring MVC和Spring WebFlux Web框架。 集成:远程处理,JMS,JCA,JMX,电子邮件,任务,调度,缓存。 语言:Kotlin,Groovy,动态语言。 列举一些重要的Spring模块? Spring Core:核心,可以说Spring其他所有的功能都依赖于该类库。主要提供IOC和DI功能。 Spring Aspects:该模块为与AspectJ的集成提供支持。 Spring AOP:提供面向切面的编程实现。 Spring JDBC:Java数据库连接。 Spring JMS:Java消息服务。 Spring ORM:用于支持Hibernate等ORM工具。 Spring Web:为创建Web应用程序提供支持。 Spring Test:提供了对JUnit和TestNG测试的支持。 谈谈自己对于Spring IOC和AOP的理解 IOC(Inversion Of Controll,控制反转)是一种设计思想: 在程序中手动创建对象的控制权,交由给Spring框架来管理。IOC在其他语言中也有应用,并非Spring特有。IOC容器实际上就是一个Map(key, value),Map中存放的是各种对象。 将对象之间的相互依赖关系交给IOC容器来管理,并由IOC容器完成对象的注入。这样可以很大程度上简化应用的开发,把应用从复杂的依赖关系中解放出来。IOC容器就像是一个工厂一样,当我们需要创建一个对象的时候,只需要配置好配置文件/注解即可,完全不用考虑对象是如何被创建出来的。在实际项目中一个Service类可能由几百甚至上千个类作为它的底层,假如我们需要实例化这个Service,可能要每次都搞清楚这个Service所有底层类的构造函数,这可能会把人逼疯。如果利用IOC的话,你只需要配置好,然后在需要的地方引用就行了,大大增加了项目的可维护性且降低了开发难度。 Spring中的bean的作用域有哪些? 1.singleton:该bean实例为单例 2.prototype:每次请求都会创建一个新的bean实例(多例)。 3.request:每一次HTTP请求都会产生一个新的bean,该bean仅在当前HTTP request内有效。 4.session:每一次HTTP请求都会产生一个新的bean,该bean仅在当前HTTP session内有效。 5.global-session:全局session作用域,仅仅在基于Portlet的Web应用中才有意义,Spring5中已经没有了。Portlet是能够生成语义代码(例如HTML)片段的小型Java Web插件。它们基于Portlet容器,可以像Servlet一样处理HTTP请求。但是与Servlet不同,每个Portlet都有不同的会话。 Spring中的单例bean的线程安全问题了解吗? 概念用于理解:大部分时候我们并没有在系统中使用多线程,所以很少有人会关注这个问题。单例bean存在线程问题,主要是因为当多个线程操作同一个对象的时候,对这个对象的非静态成员变量的写操作会存在线程安全问题。 有两种常见的解决方案(用于回答的点): 1.在bean对象中尽量避免定义可变的成员变量(不太现实)。 2.在类中定义一个ThreadLocal成员变量,将需要的可变成员变量保存在ThreadLocal(线程本地化对象)中(推荐的一种方式)。 ThreadLocal解决多线程变量共享问题(参考博客):https://segmentfault.com/a/1190000009236777 Spring中Bean的生命周期: 1.Bean容器找到配置文件中Spring Bean的定义。 2.Bean容器利用Java Reflection API创建一个Bean的实例。 3.如果涉及到一些属性值,利用set方法设置一些属性值。 4.如果Bean实现了BeanNameAware接口,调用setBeanName方法,传入Bean的名字。 5.如果Bean实现了BeanClassLoaderAware接口,调用setBeanClassLoader方法,传入ClassLoader对象的实例。 6.如果Bean实现了BeanFactoryAware接口,调用setBeanClassFacotory方法,传入ClassLoader对象的实例。 7.与上面的类似,如果实现了其他*Aware接口,就调用相应的方法。 8.如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象,执postProcessBeforeInitialization方法。 9.如果Bean实现了InitializingBean接口,执行afeterPropertiesSet方法。 10.如果Bean在配置文件中的定义包含init-method属性,执行指定的方法。 11.如果有和加载这个Bean的Spring容器相关的BeanPostProcess对象,执行postProcessAfterInitialization方法。 12.当要销毁Bean的时候,如果Bean实现了DisposableBean接口,执行destroy方法。 13.当要销毁Bean的时候,如果Bean在配置文件中的定义包含destroy-method属性,执行指定的方法。 Spring框架中用到了哪些设计模式? 1.工厂设计模式:Spring使用工厂模式通过BeanFactory和ApplicationContext创建bean对象。 2.代理设计模式:Spring AOP功能的实现。 3.单例设计模式:Spring中的bean默认都是单例的。 4.模板方法模式:Spring中的jdbcTemplate、hibernateTemplate等以Template结尾的对数据库操作的类,它们就使用到了模板模式。 5.包装器设计模式:我们的项目需要连接多个数据库,而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。 6.观察者模式:Spring事件驱动模型就是观察者模式很经典的一个应用。 7.适配器模式:Spring AOP的增强或通知(Advice)使用到了适配器模式、Spring MVC中也是用到了适配器模式适配Controller。 还有很多。。。。。。。 @Component和@Bean的区别是什么 1.作用对象不同。@Component注解作用于类,而@Bean注解作用于方法。 2.@Component注解通常是通过类路径扫描来自动侦测以及自动装配到Spring容器中(我们可以使用@ComponentScan注解定义要扫描的路径)。@Bean注解通常是在标有该注解的方法中定义产生这个bean,告诉Spring这是某个类的实例,当我需要用它的时候还给我。 3.@Bean注解比@Component注解的自定义性更强,而且很多地方只能通过@Bean注解来注册bean。比如当引用第三方库的类需要装配到Spring容器的时候,就只能通过@Bean注解来实现。 @Configuration public class AppConfig { @Bean public TransferService transferService { return new TransferServiceImpl; } } <beans> <bean id="transferService" class="com.kk.TransferServiceImpl"/> </beans> @Bean public OneService getService(status) { case (status) { when 1: return new serviceImpl1; when 2: return new serviceImpl2; when 3: return new serviceImpl3; } } 将一个类声明为Spring的bean的注解有哪些? 声明bean的注解: @Component 组件,没有明确的角色 @Service 在业务逻辑层使用(service层) @Repository 在数据访问层使用(dao层) @Controller 在展现层使用,控制器的声明 注入bean的注解: @Autowired:由Spring提供 @Inject:由JSR-330提供 @Resource:由JSR-250提供 *扩:JSR 是 java 规范标准 Spring事务管理的方式有几种? 1.编程式事务:在代码中硬编码(不推荐使用)。 2.声明式事务:在配置文件中配置(推荐使用),分为基于XML的声明式事务和基于注解的声明式事务。 Spring事务中的隔离级别有哪几种? 在TransactionDefinition接口中定义了五个表示隔离级别的常量:ISOLATION_DEFAULT:使用后端数据库默认的隔离级别,Mysql默认采用的REPEATABLE_READ隔离级别;Oracle默认采用的READ_COMMITTED隔离级别。ISOLATION_READ_UNCOMMITTED:最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。ISOLATION_READ_COMMITTED:允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生ISOLATION_REPEATABLE_READ:对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。ISOLATION_SERIALIZABLE:最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。 Spring事务中有哪几种事务传播行为? 在TransactionDefinition接口中定义了八个表示事务传播行为的常量。 支持当前事务的情况:PROPAGATION_REQUIRED:如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。PROPAGATION_SUPPORTS: 如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。PROPAGATION_MANDATORY: 如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。(mandatory:强制性)。 不支持当前事务的情况:PROPAGATION_REQUIRES_NEW: 创建一个新的事务,如果当前存在事务,则把当前事务挂起。PROPAGATION_NOT_SUPPORTED: 以非事务方式运行,如果当前存在事务,则把当前事务挂起。PROPAGATION_NEVER: 以非事务方式运行,如果当前存在事务,则抛出异常。 其他情况:PROPAGATION_NESTED: 如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价于PROPAGATION_REQUIRED。 二、SpringMVC篇 什么是Spring MVC ?简单介绍下你对springMVC的理解? Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架,通过把Model,View,Controller分离,将web层进行职责解耦,把复杂的web应用分成逻辑清晰的几部分,简化开发,减少出错,方便组内开发人员之间的配合。 Spring MVC的工作原理了解嘛? image.png Springmvc的优点: (1)可以支持各种视图技术,而不仅仅局限于JSP; (2)与Spring框架集成(如IoC容器、AOP等); (3)清晰的角色分配:前端控制器(dispatcherServlet) , 请求到处理器映射(handlerMapping), 处理器适配器(HandlerAdapter), 视图解析器(ViewResolver)。 (4) 支持各种请求资源的映射策略。 Spring MVC的主要组件? (1)前端控制器 DispatcherServlet(不需要程序员开发) 作用:接收请求、响应结果,相当于转发器,有了DispatcherServlet 就减少了其它组件之间的耦合度。 (2)处理器映射器HandlerMapping(不需要程序员开发) 作用:根据请求的URL来查找Handler (3)处理器适配器HandlerAdapter 注意:在编写Handler的时候要按照HandlerAdapter要求的规则去编写,这样适配器HandlerAdapter才可以正确的去执行Handler。 (4)处理器Handler(需要程序员开发) (5)视图解析器 ViewResolver(不需要程序员开发) 作用:进行视图的解析,根据视图逻辑名解析成真正的视图(view) (6)视图View(需要程序员开发jsp) View是一个接口, 它的实现类支持不同的视图类型(jsp,freemarker,pdf等等) springMVC和struts2的区别有哪些? (1)springmvc的入口是一个servlet即前端控制器(DispatchServlet),而struts2入口是一个filter过虑器(StrutsPrepareAndExecuteFilter)。 (2)springmvc是基于方法开发(一个url对应一个方法),请求参数传递到方法的形参,可以设计为单例或多例(建议单例),struts2是基于类开发,传递参数是通过类的属性,只能设计为多例。 (3)Struts采用值栈存储请求和响应的数据,通过OGNL存取数据,springmvc通过参数解析器是将request请求内容解析,并给方法形参赋值,将数据和视图封装成ModelAndView对象,最后又将ModelAndView中的模型数据通过reques域传输到页面。Jsp视图解析器默认使用jstl。 SpringMVC怎么样设定重定向和转发的? (1)转发:在返回值前面加"forward:",譬如"forward:user.do?name=method4" (2)重定向:在返回值前面加"redirect:",譬如"redirect:http://www.baidu.com" SpringMvc怎么和AJAX相互调用的? 通过Jackson框架就可以把Java里面的对象直接转化成Js可以识别的Json对象。具体步骤如下 : (1)加入Jackson.jar (2)在配置文件中配置json的映射 (3)在接受Ajax方法里面可以直接返回Object,List等,但方法前面要加上@ResponseBody注解。 如何解决POST请求中文乱码问题,GET的又如何处理呢? (1)解决post请求乱码问题: 在web.xml中配置一个CharacterEncodingFilter过滤器,设置成utf-8; <filter> <filter-name>CharacterEncodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>utf-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>CharacterEncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> (2)get请求中文参数出现乱码解决方法有两个: ①修改tomcat配置文件添加编码与工程编码一致,如下: <ConnectorURIEncoding="utf-8" connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/> ②另外一种方法对参数进行重新编码: String userName = new String(request.getParamter("userName").getBytes("ISO8859-1"),"utf-8") ISO8859-1是tomcat默认编码,需要将tomcat编码后的内容按utf-8编码。 Spring MVC的异常处理 ? 统一异常处理: Spring MVC处理异常有3种方式: (1)使用Spring MVC提供的简单异常处理器SimpleMappingExceptionResolver; (2)实现Spring的异常处理接口HandlerExceptionResolver 自定义自己的异常处理器; (3)使用@ExceptionHandler注解实现异常处理; 统一异常处理的博客:https://blog.csdn.net/ctwy291314/article/details/81983103 SpringMVC的控制器是不是单例模式,如果是,有什么问题,怎么解决? 是单例模式,所以在多线程访问的时候有线程安全问题,不要用同步,会影响性能的,解决方案是在控制器里面不能写成员变量。(此题目类似于上面Spring 中 第5题 有两种解决方案) SpringMVC常用的注解有哪些? @RequestMapping:用于处理请求 url 映射的注解,可用于类或方法上。用于类上,则表示类中的所有响应请求的方法都是以该地址作为父路径。 @RequestBody:注解实现接收http请求的json数据,将json转换为java对象。 @ResponseBody:注解实现将conreoller方法返回对象转化为json对象响应给客户。 SpingMvc中的控制器的注解一般用那个,有没有别的注解可以替代? 一般用@Controller注解,也可以使用@RestController,@RestController注解相当于@ResponseBody + @Controller,表示是表现层,除此之外,一般不用别的注解代替。 如果在拦截请求中,我想拦截get方式提交的方法,怎么配置? 可以在@RequestMapping注解里面加上method=RequestMethod.GET。 怎样在方法里面得到Request,或者Session? 直接在方法的形参中声明request,SpringMVC就自动把request对象传入。 如果想在拦截的方法里面得到从前台传入的参数,怎么得到? 直接在形参里面声明这个参数就可以,但必须名字和传过来的参数一样。 如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象? 直接在方法中声明这个对象,SpringMVC就自动会把属性赋值到这个对象里面。 SpringMVC中函数的返回值是什么? 返回值可以有很多类型,有String, ModelAndView。ModelAndView类把视图和数据都合并的一起的。 SpringMVC用什么对象从后台向前台传递数据的? 通过ModelMap对象,可以在这个对象里面调用put方法,把对象加到里面,前台就可以拿到数据。 怎么样把ModelMap里面的数据放入Session里面? 可以在类上面加上@SessionAttributes注解,里面包含的字符串就是要放入session里面的key。 SpringMvc里面拦截器是怎么写的: 有两种写法,一种是实现HandlerInterceptor接口,另外一种是继承适配器类,接着在接口方法当中,实现处理逻辑;然后在SpringMvc的配置文件中配置拦截器即可: <!-- 配置SpringMvc的拦截器 --> <mvc:interceptors> <!-- 配置一个拦截器的Bean就可以了 默认是对所有请求都拦截 --> <bean id="myInterceptor" class="com.zwp.action.MyHandlerInterceptor"></bean> <!-- 只针对部分请求拦截 --> <mvc:interceptor> <mvc:mapping path="/modelMap.do" /> <bean class="com.zwp.action.MyHandlerInterceptorAdapter" /> </mvc:interceptor> </mvc:interceptors> 注解原理: 注解本质是一个继承了Annotation的特殊接口,其具体实现类是Java运行时生成的动态代理类。我们通过反射获取注解时,返回的是Java运行时生成的动态代理对象。通过代理对象调用自定义注解的方法,会最终调用AnnotationInvocationHandler的invoke方法。该方法会从memberValues这个Map中索引出对应的值。而memberValues的来源是Java常量池 三、Mybatis篇 什么是MyBatis? MyBatis是一个可以自定义SQL、存储过程和高级映射的持久层框架。 讲下MyBatis的缓存 MyBatis的缓存分为一级缓存和二级缓存,一级缓存放在session里面,默认就有, 二级缓存放在它的命名空间里,默认是不打开的,使用二级缓存属性类需要实现Serializable序列化接口, 可在它的映射文件中配置<cache/> Mybatis是如何进行分页的?分页插件的原理是什么? 1)Mybatis使用RowBounds对象进行分页,也可以直接编写sql实现分页,也可以使用Mybatis的分页插件。 2)分页插件的原理:实现Mybatis提供的接口,实现自定义插件,在插件的拦截方法内拦截待执行的sql,然后重写sql。 举例:select * from student,拦截sql后重写为:select t.* from (select * from student)t limit 0,10 简述Mybatis的插件运行原理,以及如何编写一个插件? 1)Mybatis仅可以编写针对ParameterHandler、ResultSetHandler、StatementHandler、 Executor这4种接口的插件,Mybatis通过动态代理, 为需要拦截的接口生成代理对象以实现接口方法拦截功能, 每当执行这4种接口对象的方法时,就会进入拦截方法, 具体就是InvocationHandler的invoke方法,当然, 只会拦截那些你指定需要拦截的方法。 2)实现Mybatis的Interceptor接口并复写intercept方法, 然后在给插件编写注解,指定要拦截哪一个接口的哪些方法即可, 记住,别忘了在配置文件中配置你编写的插件。 Mybatis动态sql是做什么的?都有哪些动态sql?能简述一下动态sql的执行原理不? 1)Mybatis动态sql可以让我们在Xml映射文件内, 以标签的形式编写动态sql,完成逻辑判断和动态拼接sql的功能。 2)Mybatis提供了9种动态sql标签:trim|where|set|foreach|if|choose|when|otherwise|bind。 3)其执行原理为,使用OGNL从sql参数对象中计算表达式的值, 根据表达式的值动态拼接sql,以此来完成动态sql的功能。 #{}和${}的区别是什么? 1)#{}是预编译处理,${}是字符串替换。 2)Mybatis在处理#{}时,会将sql中的#{}替换为?号,调用PreparedStatement的set方法来赋值(有效的防止SQL注入); 3)Mybatis在处理${}时,就是把${}替换成变量的值。 为什么说Mybatis是半自动ORM映射工具?它与全自动的区别在哪里? Hibernate属于全自动ORM映射工具, 使用Hibernate查询关联对象或者关联集合对象时, 可以根据对象关系模型直接获取,所以它是全自动的。 而Mybatis在查询关联对象或关联集合对象时, 需要手动编写sql来完成,所以,称之为半自动ORM映射工具。 Mybatis是否支持延迟加载?如果支持,它的实现原理是什么? 1)Mybatis仅支持association关联对象和collection关联集合对象的延迟加载, association指的就是一对一,collection指的就是一对多查询。 在Mybatis配置文件中, 可以配置是否启用延迟加载lazyLoadingEnabled=true|false。 2)它的原理是,使用CGLIB创建目标对象的代理对象, 当调用目标方法时,进入拦截器方法, 比如调用a.getB.getName, 拦截器invoke方法发现a.getB是null值, 那么就会单独发送事先保存好的查询关联B对象的sql, 把B查询上来,然后调用a.setB(b), 于是a的对象b属性就有值了, 接着完成a.getB.getName方法的调用。 这就是延迟加载的基本原理。 MyBatis与Hibernate有哪些不同? 1)Mybatis和hibernate不同,它不完全是一个ORM框架, 因为MyBatis需要程序员自己编写Sql语句, 不过mybatis可以通过XML或注解方式灵活配置要运行的sql语句, 并将java对象和sql语句映射生成最终执行的sql, 最后将sql执行的结果再映射生成java对象。 2)Mybatis学习门槛低,简单易学,程序员直接编写原生态sql, 可严格控制sql执行性能,灵活度高,非常适合对关系数据模型要求不高的软件开发, 例如互联网软件、企业运营类软件等,因为这类软件需求变化频繁, 一但需求变化要求成果输出迅速。但是灵活的前提是mybatis无法做到数据库无关性, 如果需要实现支持多种数据库的软件则需要自定义多套sql映射文件,工作量大。 3)Hibernate对象/关系映射能力强,数据库无关性好, 对于关系模型要求高的软件(例如需求固定的定制化软件) 如果用hibernate开发可以节省很多代码,提高效率。 但是Hibernate的缺点是学习门槛高,要精通门槛更高, 而且怎么设计O/R映射,在性能和对象模型之间如何权衡, 以及怎样用好Hibernate需要具有很强的经验和能力才行。 总之,按照用户的需求在有限的资源环境下只要能做出维护性、 扩展性良好的软件架构都是好架构,所以框架只有适合才是最好。 MyBatis的好处是什么? 1)MyBatis把sql语句从Java源程序中独立出来,放在单独的XML文件中编写, 给程序的维护带来了很大便利。 2)MyBatis封装了底层JDBC API的调用细节,并能自动将结果集转换成Java Bean对象, 大大简化了Java数据库编程的重复工作。 3)因为MyBatis需要程序员自己去编写sql语句, 程序员可以结合数据库自身的特点灵活控制sql语句, 因此能够实现比Hibernate等全自动orm框架更高的查询效率,能够完成复杂查询。 简述Mybatis的Xml映射文件和Mybatis内部数据结构之间的映射关系? Mybatis将所有Xml配置信息都封装到All-In-One重量级对象Configuration内部。 在Xml映射文件中,<parameterMap>标签会被解析为ParameterMap对象, 其每个子元素会被解析为ParameterMapping对象。 <resultMap>标签会被解析为ResultMap对象, 其每个子元素会被解析为ResultMapping对象。 每一个<select>、<insert>、<update>、<delete> 标签均会被解析为MappedStatement对象, 标签内的sql会被解析为BoundSql对象。 什么是MyBatis的接口绑定,有什么好处? 接口映射就是在MyBatis中任意定义接口,然后把接口里面的方法和SQL语句绑定, 我们直接调用接口方法就可以,这样比起原来了SqlSession提供的方法我们可以有更加灵活的选择和设置. 接口绑定有几种实现方式,分别是怎么实现的? 接口绑定有两种实现方式,一种是通过注解绑定,就是在接口的方法上面加 上@Select@Update等注解里面包含Sql语句来绑定, 另外一种就是通过xml里面写SQL来绑定,在这种情况下, 要指定xml映射文件里面的namespace必须为接口的全路径名. 什么情况下用注解绑定,什么情况下用xml绑定? 当Sql语句比较简单时候,用注解绑定;当SQL语句比较复杂时候,用xml绑定,一般用xml绑定的比较多 MyBatis实现一对一有几种方式?具体怎么操作的? 有联合查询和嵌套查询,联合查询是几个表联合查询,只查询一次, 通过在resultMap里面配置association节点配置一对一的类就可以完成; 嵌套查询是先查一个表,根据这个表里面的结果的外键id, 去再另外一个表里面查询数据,也是通过association配置, 但另外一个表的查询通过select属性配置。 Mybatis能执行一对一、一对多的关联查询吗?都有哪些实现方式,以及它们之间的区别? 能,Mybatis不仅可以执行一对一、一对多的关联查询, 还可以执行多对一,多对多的关联查询,多对一查询, 其实就是一对一查询,只需要把selectOne修改为selectList即可; 多对多查询,其实就是一对多查询,只需要把selectOne修改为selectList即可。 关联对象查询,有两种实现方式,一种是单独发送一个sql去查询关联对象, 赋给主对象,然后返回主对象。另一种是使用嵌套查询,嵌套查询的含义为使用join查询, 一部分列是A对象的属性值,另外一部分列是关联对象B的属性值, 好处是只发一个sql查询,就可以把主对象和其关联对象查出来。 MyBatis里面的动态Sql是怎么设定的?用什么语法? MyBatis里面的动态Sql一般是通过if节点来实现,通过OGNL语法来实现, 但是如果要写的完整,必须配合where,trim节点,where节点是判断包含节点有 内容就插入where,否则不插入,trim节点是用来判断如果动态语句是以and 或or 开始,那么会自动把这个and或者or取掉。 Mybatis是如何将sql执行结果封装为目标对象并返回的?都有哪些映射形式? 第一种是使用<resultMap>标签,逐一定义列名和对象属性名之间的映射关系。 第二种是使用sql列的别名功能,将列别名书写为对象属性名, 比如T_NAME AS NAME,对象属性名一般是name,小写, 但是列名不区分大小写,Mybatis会忽略列名大小写,
-
如何配置 VS Code 使用 clang++ 编译并使用 cppvsdbg 或 lldb 调试 - VS Code 需要安装的插件: