If you've paid attention, you have seen this patch before (or a very
slightly earlier version).  I expect to commit it soonish on grounds
that it'll be needed, and seems innocuous/safe, and will move us just
a bit closer to working SWD ... :)

From: David Brownell <[email protected]>
Subject: swj-dp.tcl (SWD infrastructure #1)

Provide new helper proc that can set up either an SWD or JTAG DAP
based on the transport which is in use -- mostly for SWJ-DP.

 Also update some SWJ-DP based chips/targets to use it.  The goal
is making SWD-vs-JTAG transparent in most places.  SWJ-DP based chips
really need this flexible configuration to cope with debug adapters
that support different transports, without needing new target configs
for each transport or adapter.

For JTAG-DP, callers will use "jtag newtap" directly, as today; only
one chip-level transport option exists.

For SW-DP (e.g. LPC1[13]xx or EFM32, they'll use "swd newdap" directly
(part of an upcoming SWD transport patch).  Again, only one transport
option exists, so hard-wiring is appropriate there.


Signed-off-by: David Brownell <[email protected]>
---
 tcl/target/lpc1768.cfg   |    7 ++++++-
 tcl/target/stellaris.cfg |   17 ++++++++++++++++-
 tcl/target/swj-dp.tcl    |   25 +++++++++++++++++++++++++
 3 files changed, 47 insertions(+), 2 deletions(-)

--- /dev/null
+++ oocd/tcl/target/swj-dp.tcl
@@ -0,0 +1,25 @@
+# ARM Debug Interface V5 (ADI_V5) utility
+# ... Mostly for SWJ-DP (not SW-DP or JTAG-DP, since
+# SW-DP and JTAG-DP targets don't need to switch based
+# on which transport is active.
+#
+# declare a JTAG or SWD Debug Access Point (DAP)
+# based on the transport in use with this session.
+# You can't access JTAG ops when SWD is active, etc.
+
+# params are currently what "jtag newtap" uses
+# because OpenOCD internals are still strongly biased
+# to JTAG ....  but for SWD, "irlen" etc are ignored,
+# and the internals work differently
+
+# for now, ignore non-JTAG and non-SWD transports
+# (e.g. initial flash programming via SPI or UART)
+
+# split out "chip" and "tag" so we can someday handle
+# them more uniformly irlen too...)
+
+proc swj_newdap {chip tag args} {
+set tran [transport select]
+if [string equal $tran "jtag"] { eval jtag newtap $chip $tag $args}
+if [string equal $tran "swd"] { eval swd newdap $chip $tag $args }
+}
--- oocd.orig/tcl/target/stellaris.cfg
+++ oocd/tcl/target/stellaris.cfg
@@ -1,5 +1,12 @@
 # TI/Luminary Stellaris LM3S chip family
 
+# Luminary chips support both JTAG and SWD transports.
+# Adapt based on what transport is active.
+source [find target/swj-dp.tcl]
+
+# For now we ignore the SPI and UART options, which
+# are usable only for ISP style initial flash programming.
+
 if { [info exists CHIPNAME] } {
    set  _CHIPNAME $CHIPNAME
 } else {
@@ -18,6 +25,12 @@ if { [info exists CPUTAPID ] } {
    set _CPUTAPID 0x0ba00477
 }
 
+# SWD DAP, and JTAG TAP, take same params for now;
+# ... even though SWD ignores all except TAPID, and
+# JTAG shouldn't need anything more then irlen. (and TAPID).
+swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf \
+       -expected-id $_CPUTAPID -ignore-version
+
 if { [info exists WORKAREASIZE ] } {
    set _WORKAREASIZE $WORKAREASIZE
 } else {
--- oocd.orig/tcl/target/lpc1768.cfg
+++ oocd/tcl/target/lpc1768.cfg
@@ -1,5 +1,9 @@
 # NXP LPC1768 Cortex-M3 with 512kB Flash and 32kB+32kB Local On-Chip
SRAM,
 
+# LPC17xx chips support both JTAG and SWD transports.
+# Adapt based on what transport is active.
+source [find target/swj-dp.tcl]
+
 if { [info exists CHIPNAME] } {
        set  _CHIPNAME $CHIPNAME
 } else {
@@ -31,7 +35,8 @@ jtag_ntrst_delay 200
 # LPC2000 & LPC1700 -> SRST causes TRST
 reset_config srst_pulls_trst
 
-jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
+#jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
+swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
 
 set _TARGETNAME $_CHIPNAME.cpu
 target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME


_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to