Reported by thesourcerer on IRC.
Change-Id: I36d4d95de176a19fdd0bf80d8b419be6ca637e98
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/3893
Tested-by: jenkins
When both SRST and TRST asserted, 'u' is sent to remote bitbang.
Fix for correct handling of such a case
Change-Id: I2a93ff71f5bbae658e6c0c3649a9fbcca2c5a14b
Signed-off-by: Aleksey Shargalin <myokaski@gmail.com>
Reviewed-on: http://openocd.zylin.com/4283
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
We can now use the generic stlink.cfg which allows for both ST-LINK/V2
and V2-1 debuggers.
Change-Id: I229c6fe5f6a6a4f2d3c787a49939846f102f9e24
Signed-off-by: Pushpal Sidhu <psidhu.devel@gmail.com>
Reviewed-on: http://openocd.zylin.com/4313
Tested-by: jenkins
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Leaving mode before closing added
Resolved a collision with JTAG API v1 error/status
checking overwriting SWIM status bytes
Change-Id: I35444ec0e6caace3e072c60085059602f4cdf0a4
Signed-off-by: Ake Rehnman <ake.rehnman@gmail.com>
Reviewed-on: http://openocd.zylin.com/4265
Tested-by: jenkins
Reviewed-by: Philipp Klaus Krause
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Fixed a bug in stlink_usb_read_mem/write_mem preventing large data transfers
The SWIM support in stlink_usb was basically non existent so I have
implemented the missing parts. The bCBWCBLength and dCBWDataTransferLength
for STLINK-V1 protocol was not correct so that was fixed. The reason for
adding SWIM support is to add STM8 support for OpenOCD.
I have tested the driver on:
STM8 discovery board with the built-in STLINK-V1
STM8 discovery board with STLINK-V2 dongle
STM32 vldiscovery board with the built-in STLINK-V1
STM32F1xxx processor with STLINK-V2 dongle
Change-Id: I4aa80a92fb0226174356adaf2f8ff949920a621f
Signed-off-by: Ake Rehnman <ake.rehnman@gmail.com>
Reviewed-on: http://openocd.zylin.com/3952
Tested-by: jenkins
Reviewed-by: Philipp Klaus Krause
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Functions mem_ap_read() and mem_ap_write() incremented address even
if addrinc=false. I overlooked this fact and moved mem_ap_setup_tar()
set wrong addresses in no-incr mode.
Fixed by preventing address increment in no-incr mode.
Change-Id: I512e12a6a64e30cf6bc5bf77e3d57d35cc33e058
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Suggested-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-on: http://openocd.zylin.com/4326
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
MEM-AP access through banked data registers MEM_AP_REG_BD0..3
does not increment TAR regardless of the current autoincrement mode.
mem_ap_read_u32() and mem_ap_write_u32() can keep the current
autoincrement mode instead of switching autoincrement off.
Change-Id: Ib7ec688d3e04f1da678363cd2819ce90e8910e58
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4163
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Problem: If the same memory location is accessed alternatively
by MEM-AP banked data registers without autoincrement and by standard
autoincremented read/write, TAR register is not updated correctly.
How to replicate: On a Cortex-M issue
mdw 0xe000edf0
multiple times. When poll is on (poll reads the same memory location)
only the first read is correct.
0xe000edf0: 01000000
0xe000edf0: 00000000
0xe000edf0: 20002640
0xe000edf0: 01000000
0xe000edf0: 00000000
0xe000edf0: 00000000
No problems with poll off.
0xe000edf0: 01000000
0xe000edf0: 01000000
0xe000edf0: 01000000
mem_ap_setup_tar() writes to MEM_AP_REG_TAR if requested TAR value
changed or CSW_ADDRINC_... is currently active.
However if an autoincremented access has been issued and autoinc
switched off in CSW afterwards, TAR does not get updated.
The change introduces mem_ap_update_tar_cache() which is called
after queuing of any access to MEM_AP_REG_DRW. It simulates
TAR increment to keep tar_value in sync with MEM_AP.
Crossing tar autoincrement block boundary invalidates cached value.
mem_ap_write() and mem_ap_read() do not check tar autoincrement
block boundary, mem_ap_setup_tar() is called before each transfer instead.
dap_invalidate_cache() is introduced to ensure invalidation
of all cached values during dap_dp_init() and swd_connect()
Change-Id: I815c2283d2989cffd6ea9a4100ce2f29dc3fb7b4
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4162
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
The existing code only used Memory Access mode to read memory,
which uses 32 bit operations only.
Rework the code to check the alignment/size of the read/write operation,
and use the Memory Access mode to read aligned 32 bit memory.
When using unaligned access, or 8 or 16 bit reads, use LDR{BHW} and STR{BHW}
instead.
The exception handling is still the same as it was before (meaning it breaks
when things go wrong), but I can now read an 8 bit register correctly.
Change-Id: I739a5ee825c0226ed4a89c32895cc2a047b8dc15
Signed-off-by: Bas Vermeulen <bas@daedalean.ai>
Reviewed-on: http://openocd.zylin.com/4301
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Commit ef02b69b14 included
a call to cmsis_dap_cmd_DAP_Connect() before calling
cmsis_dap_cmd_DAP_SWJ_Sequence(). According to comment
it is necessary for at least Keil ULINK-ME.
Commit 72c3464be4 added
a cmsis_dap_cmd_DAP_Disconnect() before connect call to pair
connection/disconnection. It solves some problems on Atmel EDBG.
Unfortunately calling either of cmsis_dap_cmd_DAP_Connect()
or cmsis_dap_cmd_DAP_Disconnect() deasserts reset signal.
So these workarounds break ability to connect under reset.
Use cmsis_dap_cmd_DAP_Disconnect() and cmsis_dap_cmd_DAP_Connect()
pair only if both SRST and TRST are deasserted.
Change-Id: I0914dae0a1360b8c7fe48231ff3867caedfb2dbe
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reported-by: Leonardo Sabino dos Santos <leonardo.sabino@gmail.com>
Reviewed-on: http://openocd.zylin.com/4100
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Events reset-halt-pre, reset-halt-post, reset-wait-pre and
reset-wait-post are not used anywhere.
Change-Id: I9a0f94875b102d9b08f6c2fd9d73a9f05f8e8e79
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4285
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Theese devices do not have a gap in sector numbering.
The driver translates sectors numbers 12 13... to 16 17... as used on dual
bank flash devices. Therefore erase of sector 12 and above fails with error
'stm32x device protected'
on F413/423.
Drop sector number translation for devices without has_large_mem flag.
Change-Id: I65531c0dfe02e2fd0f3d68f0615e0926e9901391
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4299
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
A protection block comprises two adjacent sectors in dual bank mode.
As there are 64 and 128kB sectors joined in blocks 2 and 8, block size
should be computed as a sum of sector sizes.
Change-Id: Ie915df8cf7ca232c4565d7e0c514c8933e71fdfe
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4271
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
also remove legacy footnote as it adds no value.
Change-Id: I3892acf244bd8fba6f844a5d82a66004e193a395
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/4309
Tested-by: jenkins
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Extend HLA interface to allow multiple VID/PID pairs and use it to
autodetect the connected stlink version.
Change-Id: I35cd895b2260e23cf0e8fcb1fc11a78c2b99c69b
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/3961
Tested-by: jenkins
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
New low-end chips have only 2k of RAM, workarea size adjusted
Change-Id: Ibfccd73fef9e6dabffc87d901736c5626ce411fe
Signed-off-by: Ilia Motornyi <elijah.mot@gmail.com>
Reviewed-on: http://openocd.zylin.com/4308
Tested-by: jenkins
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
New STM8 target based mostly on mips4k. Target communication
through STLINK/SWIM. No flash driver yet but it is still possible
to program flash through load_image command. The usual target debug
methods are implemented.
Change-Id: I7216f231d3ac7c70cae20f1cd8463c2ed864a329
Signed-off-by: Ake Rehnman <ake.rehnman@gmail.com>
Reviewed-on: http://openocd.zylin.com/3953
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
The CMSIS-DAP used by NXP's LS1012ARDB board only supports JTAG,
and not SWD. Calling cmsis_dap_cmd_DAP_SWD_Configure returns with an
error (and doesn't actually do anything in the debugger).
Wrap the call to cmsis_dap_cmd_DAP_SWD_Configure in a check for
swd_mode, to make sure initialisation doesn't fail needlessly.
Change-Id: Id7e568cb6e36886bd7c5b3699d198a77a51c28c9
Signed-off-by: Bas Vermeulen <bas@daedalean.ai>
Reviewed-on: http://openocd.zylin.com/4294
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Change-Id: Ieea1b0dec88818e9e8d5c8c5d54aa8959556d77b
Signed-off-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-on: http://openocd.zylin.com/4275
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
The SWDIO buffer has to be enabled, by setting SWDIO_OE, for data on
SWDIO to reach the target. Explicitly do this before sending the
switch sequences for JTAG-to-SWD, etc.
This makes the code insensitive to the state of SWDIO_OE specified in
ftdi_layout_init. It used to work only on adapters with a non-inverted
SWDIO_OE inited to 1, or inverted SWDIO_OE inited to 0.
Change-Id: I4b9e520ac1c7ce2a437251a05fc036bc68de718e
Signed-off-by: Jonas Norling <jonas.norling@cyanconnode.com>
Reviewed-on: http://openocd.zylin.com/4270
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Similar to the Sheevaplug fix inf95f8b70fbd0f7e9c91a2d9006b1abb2dd07ebf2
the OpenRD device has its JTAG interface on the first channel of the
ft2232, which is 0 for the new driver but was 1 for the old one. Correct
the config file appropriately. Also the device description was missing
the trailing " B" and thus not picking up the device correctly. Finally
add an adapter_khz setting in the OpenRD board configuration file - set
to 2MHz to match the Sheeva variant.
Confirmed as working thanks to Phil Hands providing me access to his
hardware to test on.
See also Debian Bug#793214; https://bugs.debian.org/793214
Change-Id: Ifacf53124eaa330bbbdf36dfa79e3256bf2a5201
Signed-off-by: Jonathan McDowell <noodles@earth.li>
Reviewed-on: http://openocd.zylin.com/4254
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The dhcsr_save variable was used to save the value of
cortex_m->dcb_dhcsr so it could be restored later. However, all writes
in between the save and the restore use mem_ap_write_atomic_u32, not
cortex_m_write_debug_halt_mask, which means cortex_m->dcb_dhcsr isn’t
changed anyway. Delete the unnecessary local.
Change-Id: I064a3134e21398e1ecfc9f1fa7efd7b020b52341
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/4240
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
In cortex_m_assert_reset, in two locations, DHCSR is written directly
using mem_ap_write_u32. This means that the cached version,
target_to_cm(target)->dcb_dhcsr, is not updated when these writes are
performed, so subsequent writes to DHCSR that use
cortex_m_write_debug_halt_mask will change those bits back to their old
values which, unless modified in that particular invocation, come from
the cache. This causes an actual, observable bug on an STM32F7 in which
running “reset run” immediately after “program” can in some cases result
in execution proceeding with C_MASKINTS set (it is cleared on line 1021
but is then set immediately afterward in cortex_m_clear_halt), causing
failure of the application. Replace these mem_ap_write_u32 calls with
cortex_m_write_debug_halt_mask calls to do the same jobs.
Change-Id: Id35ca7f6057c2df2ba9cd67c53a73b50816d0b71
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/4239
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
GCC7 with -Wall warns about possible string truncation with
snprint()-type functions with "directive output may be truncated writing
1 byte into a region of size between 0 and 9
[-Werror=format-truncation=]" + "note: ‘snprintf’ output between 5 and
14 bytes into a destination of size 12" (or similar). Fix this by
increasing sizes of buffers.
See https://gcc.gnu.org/gcc-7/changes.html
Change-Id: Ib848f2a56dd658783534158947ae1be7c0e99d45
Signed-off-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-on: http://openocd.zylin.com/4175
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
GCC7 with -Wextra warns about switch-case blocks which fallthrough with
"this statement may fall through [-Werror=implicit-fallthrough=]". This
can be fixed by adding "special" comments: "/* fallthrough */".
See https://gcc.gnu.org/gcc-7/changes.html
Change-Id: Iba0be791dbdd86984489b2d9a0592bb59828da1e
Signed-off-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-on: http://openocd.zylin.com/4174
Tested-by: jenkins
Add "arm semihosting_cmdline [argv0 argv1 ...]" for setting the
command line arguments for the debuggee.
[andreas.fritiofson@gmail.com]: Dynamic allocation, empty default
Change-Id: I831ddd161d602f251940e29608a154e9590fdee1
Signed-off-by: Christian Groessler <chris@groessler.org>
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/3106
Tested-by: jenkins
This config covers the 4x Cortex A53 CPUs. A custom connector
is required from J14 to standard ARM JTAG on v1 boards. However
v2 hardware should have a standard FTSH-105-01-L-DV connector.
Pinmuxing code to enable JTAG pins is included in l-loader-poplar
repository, so board is flashed with open source code, JTAG
is available at very early boot. Alternatively the following
pokes can be issued from U-Boot to enable JTAG (e.g. to debug
hisilicon SDK).
mw 0xf8a210ec 0x130;
mw 0xf8a210f0 0x130;
mw 0xf8a210f4 0x130;
mw 0xf8a210f8 0x130;
mw 0xf8a210fc 0x130;
mw 0xf8a21100 0x130;
Change-Id: I2b83dfcb3dc5461c1620f94dd99aa7b31fdda59b
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-on: http://openocd.zylin.com/4161
Tested-by: jenkins
Reviewed-by: Jiri Kastner <cz172638@gmail.com>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Renaming of all nrf51 NOR flash code to nrf5, as to prepare the
code for being able to flash nrf51 and nrf52 chips.
The nrf51 command is retained for backwards compatability.
"nRF5" is also the name Nordic Semiconductor uses to describe
both the nrf51 and nrf52 chips.
Change-Id: I5f4e3f1ec780184b28ad44f735a746e68908c502
Signed-off-by: Slowcoder <slowcoder@gmail.com>
Reviewed-on: http://openocd.zylin.com/4209
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This cleans up the list of supported nrf51 chips considerably.
Change-Id: Ic74685657bb72a8703c0a49df4c48c54604ec2a7
Signed-off-by: Slowcoder <slowcoder@gmail.com>
Reviewed-on: http://openocd.zylin.com/4208
Tested-by: jenkins
Reviewed-by: Fredrik Hederstierna <fredrik@hederstierna.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Trying to read the L0 idcode at the L1 idcode address 0xE0042000 often
resulted in an uncatched error. Reading at the right L0 address 0x40015800
afterwards results in reading 0. So access to the device is denied..
Change-Id: I6de92cf99a5d5d46c72f9ba055613cbc5753a951
Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Reviewed-on: http://openocd.zylin.com/3883
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>