A JTAG TAP for boundary scan should be added in the scan chain
through the command "jtag newtap".
In some TCL target script the boundary scan TAP is added through
the command "swj_newdap", command that is inappropriate in this
context because specific for arm adi-v5 SWJ-DP.
This situation was probably created to bypass the error with HLA
framework, caused by missing command "jtag newtap".
Add the command "jtag newtap" in HLA, by reusing the existing
code for command "hla newtap".
Fix the TCL target scripts to use the command "jtag newtap" for
the boundary scan TAPs.
The TCL script target/psoc6.cfg has no evident reference to HLA,
so the reason for using "swj_newdap" is less clear. Nevertheless
it uses the wrong command and, once HLA is fixed, there is no
reason to avoid fixing it too.
Change-Id: Ia92f8221430cf6f3d2c34294e22e5e18963bb88c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4873
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
- add 'dap create' command to create dap instances
- move all dap subcmmand into the dap instance commands
- keep 'dap info' for convenience
- change all armv7 and armv8 targets to take a dap
instance instead of a jtag chain position
- restructure tap/dap/target relations, jtag tap no
longer references the dap, daps are now independently
created and initialized.
- clean up swd connect
- re-initialize DAP also on JTAG errors (e.g. after reset,
power cycle)
- update documentation
- update target files
Change-Id: I322cf3969b5407c25d1d3962f9d9b9bc1df067d9
Signed-off-by: Matthias Welwarsky <matthias.welwarsky@sysgo.com>
Reviewed-on: http://openocd.zylin.com/4468
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
It's Cortex-Xn, not Cortex Xn or cortex xn or cortex-xn or CORTEX-Xn
or CortexXn. Further it's Cortex-M0+, not M0plus.
Cf. http://www.arm.com/products/processors/index.php
Consistently write it the official way, so that it stops propagating.
Originally spotted in the documentation, it mainly affects code comments
but also Atmel SAM3/SAM4/SAMV, NiietCM4 and SiM3x flash driver output.
Found via:
git grep -i "Cortex "
git grep -i "Cortex-" | grep -v "Cortex-" | grep -v ".cpu"
git grep -i "CortexM"
Change-Id: Ic7b6ca85253e027f6f0f751c628d1a2a391fe914
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3483
Tested-by: jenkins
Reviewed-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
It depends on the particular target whether it can work with SRST
asserted or not, so this belongs to the target config rather than the
board config.
Also, this allows for simple
openocd -f myboard.cfg -c "reset_config connect_assert_srst"
command to be used whenever a user feels a need to connect to an
unresponsive target.
Change-Id: I3d8da9ae47088fc0c75a20bfdd20074be1014de0
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2459
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
So remove it from all the configs, it's misleading, and leads to cargo
culting of config files.
Change-Id: I2b77e60d5e96f9759c7c9fc91b20e73be2e95d9a
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2446
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This should allow to share common configs for both regular access and
high-level adapters.
Use the newly-added functionality in stlink and icdi drivers, amend
the configs accordingly.
Runtime-tested with a TI tm4c123g board.
Change-Id: Ibb88266a4ca25f06f6c073e916c963f017447bad
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
[gus@projectgus.com: context-specific deprecation warnings]
Signed-off-by: Angus Gratton <gus@projectgus.com>
[andrew.smirnov@gmail.com: additional nrf51.cfg mods]
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reviewed-on: http://openocd.zylin.com/1664
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>