Currently all Atmel CMSIS-DAP interfaces are assumed to have 512 byte
reports except for the mEDBG (found on Xplained Mini boards) and the nEDBG
(found on Curiosity Nano boards). This check is far from exaustive and it
results in some Microchip programmers (like the MPLAB Snap and PICkit 4)
not working correctly with OpenOCD.
Instead of assuming that Atmel programmers have 512 byte reports unless we
know otherwise, this commit flips the logic around. Only the older "third
generation" EDBG based programmers have 512 byte report sizes, and that 64
bytes will be more common in Microchip tools going forward.
The list of PIDs for 3rd generation Microchip programmers comes from
toolinfo.py from Microchip's pyedbglib.
This commit adds a more generic "quirks" list that will allow programmers
with unusual report sizes to be added easily in the future.
Change-Id: Ic39a4bdcd67c4c93d5707657c6ee5d216bc4437a
Signed-off-by: Samuel Dewan <samdewan@me.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8033
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Introduce 'cmsis-dap quirk' command to enable and
disable quirk mode.
If enabled, disconnect and connect before a switch
sequence and do not use multiple packets pipelining.
Change-Id: I6576f7de9f6c98a25c3cf9eec9a456a23610d00d
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7966
Tested-by: jenkins
Use it whenever an out-of-sync response is detected to clean
USB bulk transfer state.
USB hidapi does not offer any means to cancel a pending request,
therefore cmsis_dap_hid_cancel_all() does nothing.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ie36fa760c1643ae10be0e87fc633068965a72242
Reviewed-on: https://review.openocd.org/c/openocd/+/7366
Tested-by: jenkins
Reviewed-by: zapb <dev@zapb.de>
The synchronous libusb_bulk_transfer() always waits
for the transfer to complete. Therefore it does not allow issuing
multiple USB requests as used on HID backend.
Switch to asynchrounous libusb_submit_transfer().
With this patch a good USB FS based CMSIS-DAPv2 adapter
almost doubles the throughput:
adapter speed: 20000 kHz
poll off
> load_image /run/user/1000/ram256k.bin 0x20000000
262144 bytes written at address 0x20000000
downloaded 262144 bytes in 0.428576s (597.327 KiB/s)
> dump_image /dev/null 0x20000000 0x40000
dumped 262144 bytes in 0.572875s (446.869 KiB/s)
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ic6168ea4eca4f6bd1d8ad541a07a8d70427cc509
Reviewed-on: https://review.openocd.org/c/openocd/+/7365
Reviewed-by: zapb <dev@zapb.de>
Tested-by: jenkins
This adds new command characters to make SWD work with the new split
jtag and swd operations of bitbang.
The command characters are as follows:
O - SWDIO drive 1
o - SWDIO drive 0
c - SWDIO read request
d - SWD write 0 0
e - SWD write 0 1
f - SWD write 1 0
g - SWD write 1 1
Documentation has been updated accordingly. The new commands will be
used by an adapted version of the jtag-openocd applet of the "Glasgow
Debug Tool" (https://github.com/glasgowEmbedded/Glasgow). It has been
tested against an stm32f103 and an at91samd21 target.
contrib/remote/bitbang/remote_bitbang_sysfsgpio.c has also been adapted
to support SWD via the new command set. Some limited testing has been
done using a Raspberry Pi 2 with an stm32f103 and an at91samd21 target
attached.
Change-Id: I8e998a2cb36905142cb16e534483094cd99e8fa7
Signed-off-by: Manuel Wick <manuel@matronix.de>
Signed-off-by: David Ryskalczyk <david.rysk@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6044
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
While at it, remove the syntax error messages as the correct
syntax is already suggested due to the return value used.
Change-Id: I9310ba96ed3f8a85c37cee9193e481ad3df02e77
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/7969
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Use a command group 'kitprog' with subcommands instead of individual
commands with 'kitprog_' prefix.
The old command is still available to ensure backwards compatibility,
but is marked as deprecated.
Change-Id: I7f0d447939819ffc488a3d7a8de672b58887127f
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/7967
Reviewed-by: Bohdan Tymkiv <bohdan200@gmail.com>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Use a command group 'cmsis-dap' with subcommands instead of individual
commands with 'cmsis_dap_' prefix.
The old commands are still available to ensure backwards compatibility,
but are marked as deprecated.
Change-Id: I75facb7572a86354c2ce6144aa7fadf3b5a6db4e
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/7963
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Bohdan Tymkiv <bohdan200@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Previously, the bcm2835_peri_base value would be printed as a decimal
value despite having a "0x" prefix, implying it should be a hex value.
BCM2835 GPIO: peripheral_base = 0x1056964608
Now, the value is correctly converted to hexidecimal.
BCM2835 GPIO: peripheral_base = 0x3F000000
Change-Id: Id59185423917e6350f99ef68320e2102a3192291
Fixes: b41b368255 ("jtag/drivers/bcm2835gpio: extend peripheral_base to off_t")
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7888
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Previously, if a pin was configured as ADAPTER_GPIO_INIT_STATE_INPUT and
its drive value was ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL, initialize_gpio
would configure the pin as an output.
The set_gpio_value function is optimized to not set the direction for
pins configured as ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL as it only needs to
be set once. When initialize_gpio performs this setup, it checked only
that the drive value was ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL to set the
output direction but did not exclude input pins which have already had
their direction set.
Now, input pins are ignored when initialize_gpio checks for
ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL to set the mode to output.
Fixes: ace028262b ("drivers/am335xgpio: Migrate to adapter gpio commands")
Change-Id: I9ea502c400ea4ffae37080b9cee891ca9176a47d
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7877
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Steve Marple <stevemarple@googlemail.com>
Previously, if a pin was configured as ADAPTER_GPIO_INIT_STATE_INPUT and
its drive value was ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL, initialize_gpio
would configure the pin as an output.
The set_gpio_value function is optimized to not set the direction for
pins configured as ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL as it only needs to
be set once. When initialize_gpio performs this setup, it checked only
that the drive value was ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL to set the
output direction but did not exclude input pins which have already had
their direction set.
Now, input pins are ignored when initialize_gpio checks for
ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL to set the mode to output.
Change-Id: I4fc7a8132a6b00c7f213ec9fd05c7bbb37ee5f20
Fixes: 0dd969d83b ("drivers/bcm2835gpio: Migrate to adapter gpio commands")
Signed-off-by: Brandon Pupp <bpupp@xes-inc.com>
[vfazio: update commit message]
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7862
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
add new i2c bit-banging feature, we can now connect in JTAG with the SoC
target and in i2c with the main board components at the same time.
Change-Id: I8e4516fe1ad5238e0373444f1c3c9bc0814d0f52
Signed-off-by: Ahmed BOUDJELIDA <aboudjelida@nanoxplore.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7796
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
add a line that checks the returned value of set signals function
add two VIDs of other original boards (have onboard angie architecture)
so angie driver can connect to them and change their VID after
renumeration.
Change-Id: Ide4f1f6f38168a410191bf3ff75bcd59dcf7ef50
Signed-off-by: Ahmed BOUDJELIDA <aboudjelida@nanoxplore.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7795
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
stlink v2 on Nucleo-64 board (e.g. NUCLEO-L476RG) has target SWO signal
connected to STM32F103CB'S PA10, which is UART1_RX. UART1 within this
MCU in theory can be configured to 4.5 Mbps baudrate, which means this
is the upper limit supported by HW. As a confirmation BMP (Black Magic
Probe) project also states in documentation that UART1 can be used with
up to 4.5 Mbps baudrate.
Tests have shown that configuring 4.5 Mbps baudrate on stlink v2
available on NUCLEO-L476RG board results in receiving corrupted data.
Using 2.25 Mbps however allows to successfully receive all data from
SWO. This makes sense in terms of STM32F103CB capabilities, since 2.25
Mbps is the next supported baudrate due to division by 2.
Increase supported stlink v2 SWO speed from 2 to 2.25 Mbps.
Tested with NUCLEO-L476RG:
$ stm32l4x.tpiu configure -protocol uart \
-traceclk 80000000 -pin-freq 2250000 \
-output /dev/stdout
$ stm32l4x.tpiu enable
2.25 Mbps speed confirmed with logic analyzer.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Change-Id: Icbec04585664aba8b217e8f9a75458e577f7617f
Reviewed-on: https://review.openocd.org/c/openocd/+/7848
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This emulation mode supports software translation of an AP request
into an address mapped transaction that does not rely on physical AP
hardware. This is necessary in some hardware such as K3 SoCs since the
hardware architecture anticipates a potential race condition between
AP doing direct memory access generating transactions back to system
bus and firewalls that data path out.
This emulation mode allows direct memory driver to emulate CoreSight
Access Port (AP) and reuse the SoC configuration meant for JTAG
debuggers.
Since the address ranges are flat in nature, the requisite memory base
and size will need to be provided a-priori to the driver for mapping.
The other design alternative would be to map requested memory map for
every register operation, but, that would defeat our intent of getting
max debug performance.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jason Peck <jpeck@ti.com>
Change-Id: I2d3c5f7833f1973e90b4f6b247827f62fc2905d0
Reviewed-on: https://review.openocd.org/c/openocd/+/7089
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Direct memory driver support for CoreSight Access Port(AP).
Even though we emulate SWD (serial wire debug), we aren't actually
using swd. Instead, we are using a direct memory access to get to the
register set. This is similar in approach to other fast access native
drivers such as am335xgpio drivers.
Example operation on Texas Instrument's AM62x K3 SoC:
+-----------+
| OpenOCD | SoC mem map
| on |--------------+
| Cortex-A53| |
+-----------+ |
|
+-----------+ +-----v-----+
|Cortex-M4F |<───────| |
+-----------+ | |
| DebugSS |
+-----------+ | |
|Cortex-M4F |<───────| |
+-----------+ +-----------+
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jason Peck <jpeck@ti.com>
Change-Id: I8470cb15348863dd844b2c0e3f63a9063cb032c6
Reviewed-on: https://review.openocd.org/c/openocd/+/7088
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This is the driver code for NanoXplore's ANGIE USB-JTAG Adapter.
The driver is based on the openULINK project.
This driver communicate with ANGIE's firmware in order to establish
JTAG protocol to debug the target chip.
Since the ANGIE Adapter has a Spartan-6 FPGA in addition to the
FX2 microcontroller, the driver adds two functions, one to download
the firmware (embedded C) to the FX2, and the second to program
the FPGA with its bitstream.
Add ANGIE's configuration file to tcl/interface/
Add the device VID/PID to 60-openocd.rules file.
Add ANGIE to OpenOCD's documentation
Change-Id: Id17111c74073da01450d43d466e11b0cc086691f
Signed-off-by: Ahmed BOUDJELIDA <aboudjelida@nanoxplore.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7702
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The USB control transfer can be executed without any data.
The libusb API libusb_control_transfer() can thus be called with
zero 'size', thus returning zero byte transferred when succeed.
The OpenOCD API jtag_libusb_control_transfer() returns zero either
in case of transfer error and in case of libusb_control_transfer()
returning zero, making impossible discriminating the two cases.
Extend jtag_libusb_control_transfer() with separate return value
for error code and explicit parameter's pointer for transferred
bytes.
Make the transferred pointer optional, as many callers do not
properly handle the returned value.
Use 'int' type pointer for transferred, instead of the 'uint16_t'
that would have matched the type of 'size'. This can simplify the
caller's code by using a single 'int transferred' variable shared
with other jtag_libusb_bulk_read|write, while keeping possible the
comparison int vs uint16_t without cast.
This change is inspired from commit d612baacaa
("jtag_libusb_bulk_read|write: return error code instead of size")
Change-Id: I14d9bff3e845675be03465c307a136e69eebc317
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7756
Tested-by: jenkins
Reviewed-by: ahmed BOUDJELIDA <aboudjelida@nanoxplore.com>
Compiler would complain that `written` was used without being
initialized.
Simplify the code a little. The number of bytes written is already
checked in usb_write().
Signed-off-by: Tim Newsome <tim@sifive.com>
Change-Id: Ibada85dcccfca6f1269c584cdbc4f2e3b93bb8f3
Reviewed-on: https://review.openocd.org/c/openocd/+/7813
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Jan Matyas <jan.matyas@codasip.com>
The bcm2835gpio driver preferred /dev/gpiomem for access to
memory mapped GPIO control and used /dev/mem as a fallback
only if it couldn't open /dev/gpiomem.
/dev/mem usually requires elevated rights or specific capabilities
of the opening process, so the fallback failed anyway.
Although /dev/gpiomem is the strongly preferred option with respect
to security, there could be also use cases which require /dev/mem
even if /dev/gpiomem is available (e.g. changing the GPIO pad
settings is necessary or testing/debugging OpenOCD).
It was difficult to handle such cases because they required
to block globally the system device /dev/gpiomem
(remove, rename or chmod).
Drop the fallback feature and select the memory device
by 'bcm2835gpio peripheral_mem_dev' configuration command.
Use /dev/gpiomem as a default.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I60e427bda795d7a13d55d61443590dd31d694832
Reviewed-on: https://review.openocd.org/c/openocd/+/7350
Tested-by: jenkins
Reviewed-by: Jonathan Bell <jonathan@raspberrypi.com>
The pads were configured at a wrong memory address
if /dev/gpiomem was mapped.
The pad setting registers are not accessible in mapped /dev/gpiomem,
disable the pads setting if the driver doesn't open /dev/mem.
While on it, do not fail the driver initialization if pad mapping fails
- just emit a warning and work with unchanged pad setting.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I0bce76cade8f7efd75efd9087a7d9ba6511a6239
Reviewed-on: https://review.openocd.org/c/openocd/+/7684
Tested-by: jenkins
Reviewed-by: Jonathan Bell <jonathan@raspberrypi.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
For some trivial case only, replace calls to jim-nvp with calls
to the new OpenOCD nvp.
Change-Id: Ifd9aff32b67748af8ab808e6a6b6e64f5271b888
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7553
Tested-by: jenkins
Commit 07e1ebcc12 ("jtag: drivers: with pointers, use NULL
instead of 0") incorrectly inverts the check, making the driver's
pathmove operation not functional and triggering two clang errors.
Fix the check on malloc() returned pointer.
Change-Id: If1f220aca67452adbcd3a1c9cf691fc984b16b27
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: 07e1ebcc12 ("jtag: drivers: with pointers, use NULL instead of 0")
Reviewed-on: https://review.openocd.org/c/openocd/+/7656
Tested-by: jenkins
Don't compare pointers with 0, use NULL when needed.
Don't assign pointer to 0, use NULL.
Don't pass 0 ad pointer argument, pass NULL.
While there, check for return value from malloc(), replace an
assert() with a LOG_ERROR(), drop a useless cast.
Detected through 'sparse' tool.
Change-Id: Ia7cf52221b12198aba1a07ebdfaf57ce341d5699
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7592
Tested-by: jenkins
Add static type to symbols that are not used elsewhere.
Detected through 'sparse' tool.
Change-Id: I00e151d2466868a5dce028444d326defb80d4826
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7591
Tested-by: jenkins
The driver tries to open mpsse engine for each vid pid
pair in sequence. If more vid/pid pairs are configured and
the USB device does not correspond to the first pair,
the driver shows 'unable to open ftdi device ...' error.
Match vid pid with the whole list as used in jtag_libusb_open()
instead of multiple mpsse_open() in for loop over vid/pid pairs.
Change-Id: I8ef55205be221c727607fe25b81ae21de0d96f02
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7529
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
We currently fail the transfer when issuing more than 255 transactions
at once, e.g.
> read_memory 0x10000000 32 256
CMSIS-DAP transfer count mismatch: expected 257, got 1
This is because the protocol only supports 255 transactions per packet
(65535 for block transactions), and as a result we truncate the
transaction count when assembling the packet. Fix it by running the
queue when we hit the limit.
Change-Id: Ia9e01e3af5ad035f2cf2a32292c9d66e57eafae9
Signed-off-by: Peter Collingbourne <pcc@google.com>
Fixes: 40bac8e8c4 ("jtag/drivers/cmsis_dap: improve USB packets filling")
Reviewed-on: https://review.openocd.org/c/openocd/+/7483
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
SW-DPv2 and SWJ-DPv2 devices do not reply to DP_TARGETSEL write cmd.
Ignore the received ACK after TARGETSEL write.
While on it, use swd_ack_to_error_code() for unified error code
translation of the received ACK value for all other commands.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: If978c88c8496e31581175385e59c32faebfd20aa
Reviewed-on: https://review.openocd.org/c/openocd/+/7383
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: zapb <dev@zapb.de>
After setting adapter speed to some values, the driver
shows the real speed little bit higher.
Although it does not impose a problem from technical point
of view because the difference is smaller than usual speed error,
it looks at least strange to the user. The documentation reads
that real frequency should be same or lower than requested.
Use proper rounding in speed -> delay and delay -> speed
conversions.
Change-Id: I1831112cc58681875548d2aeb688391fb79fa37f
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7261
Tested-by: jenkins
Reviewed-by: Jonathan Bell <jonathan@raspberrypi.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
bitbang_swd_exchange(rnw=true,...) calls bitbang_interface->swd_write()
with swdio clamped to 0.
bitbang_swd_write_reg() reads 1 turnaround bit, 3 ack bits
and 1 turnaround by one call to bitbang_swd_exchange()
and then switches SWDIO to output.
AFAIK all bitbang interfaces switch SWDIO GPIO direction immediately
in bitbang_interface->swdio_drive().
The GPIO now drives SWDIO line to the value stored in the output register
which is always zero from previous bitbang_swd_exchange(rnw=true,...).
In case the following data bit (bit 0) is 1 we can observe a glitch
on SWDIO:
_____ out 1 ____
HiZ/pull-up ----\ /
\ /
\______ out 0 ______/
swdio_drive(true) swd_write(0,1)
The glitch fortunately takes place far enough from SWCLK rising edge
where SWDIO is sampled by the target, so I believe it is harmless
except some corner cases where the reflected wave is delayed on long
line.
Anyway keeping electrical signals glitch free is a good practice.
To keep performance penalty minimal, pre-write the first data
bit to SWDIO GPIO output buffer while clocking the turnaround bit.
Following swdio_drive(true) outputs the pre-written value
and the same value is rewritten by the next swd_write()
instead of glitching SWDIO.
Change-Id: I72ea9c0b2fae57e8ff5aa616859182c67abc924f
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7260
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The OpenJTAG driver logs "num_cycles > 16 on run test" warning
whenever the JTAG_RUNTEST operation cycle count is larger than 16.
Instead of logging the warning and only running the first 16 TCLK
cycles, remove the warning and queue up multiple operations of up
to 16 cycles each.
Signed-off-by: N S <nlshipp@yahoo.com>
Change-Id: Id405fa802ff1cf3db7a21e76bd6df0c2d3a0fe61
Reviewed-on: https://review.openocd.org/c/openocd/+/7420
Tested-by: jenkins
Reviewed-by: Jonathan McDowell <noodles-openocd@earth.li>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The line reset SWD sequence is used quite often in SWD multidrop mode.
Prevent the ugly connect/disconnect adapter firmware bug workaround
to be called before each line reset.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Id85bff075dba9077e4e501e2cdcfd64d5d9d0531
Reviewed-on: https://review.openocd.org/c/openocd/+/7381
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
DAP_TransferBlock command saves n - 3 bytes in comparison to DAP_Transfer,
where n is number of transfers.
Use DAP_TransferBlock optionaly to save some USB bandwidth.
The change increases the speed of the write transfer
from 40 KiB/s to 42 KiB/s @ USB FS, adapter speed 1000.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ifde0159cfd44481d2b81b90daa088e731c03e26d
Reviewed-on: https://review.openocd.org/c/openocd/+/7372
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
DAP write transaction occupies 5 bytes of a command packet.
DAP read transaction needs just one byte in a command packet
and expect 4 bytes in a response.
The fixed maximal number of transactions in a packet caused
packet filling less than optimal.
Compute both command and expected response sizes based on
read or write direction of each transaction.
Run the queue if one of sizes does not fit into a packet.
The change increases the speed of the mostly read transfer
from 36 KiB/s to almost 40 KiB/s @ USB FS, adapter speed 1000
due to reduction of adapter inserted RDBUFF reads.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ib70812600eaae0403b8ee8673b6f897348496569
Reviewed-on: https://review.openocd.org/c/openocd/+/7364
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
USB bulk backend needs to avoid zero sized USB packets
sent after each full sized packed for performance reasons.
HID backend uses fixed size HID reports so the full size
of the report can be utilized.
Introduce packet_usable_size to reflect it.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I34094c9edac5730624480711cbd6aa65883c47c7
Reviewed-on: https://review.openocd.org/c/openocd/+/7363
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
