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>
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
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>
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>
in some cases we need something to test if uart is actually
properly connected.
Change-Id: I5a16b053164b34bb30ae8370753be12887a85c51
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Reviewed-on: http://openocd.zylin.com/4194
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
