Home

As SourceForce switched away from TRAC and did not convert project resources were lost. In case you are still interested in Open-Source development of Embedded systems you may like my iCeDeROM project or LibSWD that was somehow outcome and goal of STM32Primer2SWD project...

iCeDeROM (In-Circuit Evaluate Debug and Edit for Research on Microelectronics) http://www.icederom.com

LibSWD (Serial Wire Debug Open Framework) http://libswd.sf.net

Below are unformatted ascii remainings of Stm32Primer2SWD project - read at your own risk =)

---

Introduction

This project was started by Tomek Cedro to create and document Free and Open-Source SWD (S=
erial Wire Debug) access to new ARM-Cortex cores. SWD is an alternative =
to JTAG method for accessing the TAP (Test Access Port) that allows low-=
level access to system resources such as system bus, memory, IO, even si=
ngle stepping the code execution - a must-have for an embedded systems d=
eveloper. Because Stm32Pr=
imer Development Kits designed by Raisonance are relatively cheap and freely accessible, th=
ey became my target hardware for this project. Please note that SWD will=
also work on more advanced devices from the ARM Cortex family. Some par=
ts of this research are conducted as a cooperation between Orange Labs W=
arsaw and Orange Labs Paris, and some additionally by Cybernetic Researc=
h Student Group from Warsaw Univeristy of Technology in Poland that I am=
founder and member.

By default Cortex-design CPU or FPGA'a IP Core is both JTAG and S=
WD capable, so the common name for this access is SWJ (Serial Wire and J=
TAG). It is the application requirement and designer choice if a final p=
roduct supports JTAG, SWD, or both (SWJ). Here<=
/a> you can read short and interesting article on how SWD overcomes JTAG=
limitations.

Software

Target software that allows JTAG access is OpenOCD (memory access + debug) and UrJTAG (low level operations). When this project started t=
here was no SWD support in neither of these nice utilities, so it had to=
be created from scratch. =

Work in progress... meanwhile you can take a look at:

OpenOCD GIT Repository Summary
UrJTAG GIT Respository Summary

First things first

Because UrJTAG is a bit simpler (no debug) I will start from this pro=
gram to test low level operations on SWD, then move to OpenOCD and try t=
he debug functionality.

<=
/a>
KT-LINK driver for UrJTAG

A driver for KT-LINK interface working in JTAG mode had to be first c=
reated to test JTAG functionality on target Stm32Primer and Stm32Primer2=
. Because it is FT2232H based device not embedded into Primer, it also g=
ives access to other targets. Driver code is ready and available on SVN =
since trunk #1683.

The next step is to get SWD running...

Hardware

Both Stm32Primer and Stm32Primer2, except some fancy user interface d=
evices onboard, consist of the CPU and RLink interface - both have their=
own USB connectors. RLink allows code memory access and program executi=
on trace with no additional hardware, but it is a proprietary device wit=
h proprietary protocol, so using Stm32Primer development kits with non-R=
aisonance software is made difficult.

Stm32Primer use JTAG mode for programming and is already supporte=
d by OpenOCD and UrJTAG, Stm32Primer2 use SWD and need some additional =
work documented in this project. I want to make JTAG+SWD modes work on b=
oth RLink interfaces, but also make SWD working with more generic FT2232=
H based device - KT-LINK seem=
s just perfect for this purpose.

Also it is important to remember not to use both RLink and oth=
er interface simultaneously as this may damage both interfaces and t=
he CPU. When device is going to be used with an external inerface, inter=
nal one must be disconnected by desoltering the resistors or simply cutt=
ing the wires on the PCB. It is also necessary to connect ground and ref=
erence voltage pins for the logic buffers to work properly on the extern=
al interface.

Strm32Primer

3D""
3D""
Device: Stm32Primer
CPU: STM32F103RBT6 <br=> Programming: Onboard USB RLink JTAG</br=>

To access the SWJ pins on the Stm32Primer you need to connect externa=
l interface to signal points shown on the pictures below. I have made a =
simple socket connector for easier connect/disconnect. Here you can get a high quality =
pdf file.

3D"" <i= mg="" alt="3D" ""="" src="3D" apps="" mediawiki="" stm32primer2swd="" nfs="" project="" s="" st="" stm3=" 2primer2swd=" "="" thumb="" 7="" 7c="" stm32primer-jtag-bottom.jpg="" 200px-stm32primer-jta="g-bottom.jpg" width="3D" 200""="" height="3D" 173""="" border="3D" 0""=""> 3D""</i=>

Stm32Primer2

3D""
<di= v="" class="" magnify""=""><im= g="" src="3D" apps="" mediawiki="" stm32primer2swd="" skins="" common="" images="" magnify-cli=" p.png" =""="" width="3D" 15""="" height="3D" 11""="" alt="3D" ""="">
Device: Stm32Prim=
er2
CPU: STM32F103VET6
Programming: Onboard USB RLink SWD<=
/div></im=></di=>

To access the SWJ pins on the Stm32Primer2 you need to connect extern=
al interface to signal points shown on the pictures below. Here yo=
u can get a high quality pdf file.

3D"" 3D""

To have ability to test JTAG and SWD on the same device, also the=
ability to switch to and from one of the modes, full JTAG connector mus=
t be first created. There are some problems however with a brand new Pri=
mer2 taken out of the box - it is only SWD aware so no JTAG connection =
is available between the CPU and builtin RLink, also the remaining JTAG =
pins are set as outputs driving the audio codec chip onboard (I have phy=
sically cut off this connection). Because TRST signal behavior can be al=
so obtained with toggling the TCK/TMS and this signal should reset the T=
AP, in most cases this is enough to reset device and zero the port regis=
ters setting their function to default - but not this time. A separate S=
RST signal needs to hold device after power up and before the program st=
arts and lock out the pins. In case of KT-LINK SRST signal has to high i=
mpedance to reset target at command (urjtag command "pod reset=3D0"), so=
I had to apply low state on reset line and then power on the device - b=
elow is the result:

%./jtag =

UrJTAG 0.10 #1862
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors
UrJTAG is free software, covered by the GNU General Public License, and =
you are
welcome to change it and/or distribute copies of it under certain condit=
ions.
There is absolutely no warranty for UrJTAG.
jtag.c:518 main() Warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.
jtag> cable kt-link
Connected to libftdi driver.
SRST pin state is high...
KT-LINK JTAG Mode Initialization OK!
jtag> pod reset=3D0
jtag> detect
Error: parse.c:208 urj_parse_file() no error: Cannot open file '~/.jtag/=
rc' to parse
jtag> detect
IR length: 9
Chain length: 2
Device Id: 00111011101000000000010001110111 (0x3BA00477)
Unknown manufacturer! (01000111011) (/mnt/stuff/tmp/swd/target/share/ur=
jtag/MANUFACTURERS)
Device Id: 00000110010000010100000001000001 (0x06414041)
Unknown manufacturer! (00000100000) (/mnt/stuff/tmp/swd/target/share/ur=
jtag/MANUFACTURERS)

KT-LI=
NK (FT2232H based, SWD ready)

3D""

3D""
Device: KT-LINK
Chipset: FT2232H <b= r=""> JTAG+SWD Capable Programmer Interface</b=>

Because SWD is a bidirectional bus, more advanced buffering is requir=
ed than in case of JTAG where one pin was used for input and another for=
output signal. Therefore not all dongles supporting JTAG will support S=
WD, or at least in their default configuration, please keep that in mind=
. Here you can get the KT-LINK specification. Also note that diffe=
rent interfaces might have slightly different pinout (especially the VCC=
pin).

There is an Open-Source libftdi library that all=
ows multiplatform communication with FT2232 devices. There is also a fre=
e but proprietary libftd2xx library released by the Future Technology Devices International (F=
T2232 manufacturer), however audience is limited I will not use this one=
in this project.

Older JTAG interfaces use FT2232D silicon, t=
hat is Full-Speed USB version (12MBit/s max. throughput). Newer devices,=
such as KT-LINK, use already Hi-Speed FT2232H vers=
ion (480MBit/s max. throughput), that became supported by l=
ibftdi release 0.16 - if you have this chip remember to use up-to-da=
te library!

The UrJTAG's driver for KT-LINK working in JTAG mode is now ready=
and available in the SVN trunk since #1863.

<img= alt="3D" buffers"="" organization"="" src="3D" apps="" mediawiki="" stm32primer2swd="" nfs=" project=" "="" s="" st="" thumb="" 6="" 6a="" ktlink-buffers.png="" 200px-ktlink="-buffers.png" width="3D" 200""="" height="3D" 232""="" border="3D" 0""=""> 3D"Buffers</img=>

RLi=
nk

RLink interface can be found as OEM standalone or embedded programmin=
g interface. Stm32Primer device family has this interface embedded on on=
e board with the CPU, so I will concentrate only on this version. In thi=
s section I will place any information usable to make it work with Open-=
Source utilities.

<span= class="" mw-headline""=""> Debug Access Port (DAP) Model / Design / Theory =</span=>

Introduction

In this section I will provide essential information on the component=
s that are used to access ARM Cortex system bus and debug unit with SWJ =
and will be helpful for developers and testers. All information presente=
d here can be found on the ARM Website,=
specifically in their ARM Info Center. If you prefer PDF documentation search for "C=
ortex-M1 Technical Reference Manual". ARM holds copyright to this materi=
als according to their policy specified on the website and within the do=
cuments. If you have any comments, questions or find a bug - please let =
me know :-)

Before we start with the general DAP description lets take a look=
at the STM32F103VE microcontroller block diagram (picture copyrighted b=
y the STM Microelectronics) - this will=
give a good perspective on how the components are interconnected and de=
pendent on each other, making it easier to understand the specific block=
registers, their function and meaning in terms of being a part of bigge=
r system:

3D""

As we can see the SW/JTAG (so called SWJ-DP) in the left top corner o=
f the block diagram is placed right next to the ARM-Cortex-M3 CPU. The b=
us connections are important to know how it can interact with the rest o=
f the system. There is no need to remember the names exactly, but this d=
iagram will be helpful when reading the further chapters. Let's start wi=
th the Debus Access Port then and focus only on the SWJ-DP (transport la=
yer access port) and the AHB-AP (memory and peripherial access).

3D""

Debug Access Port (DAP) includes some internal logic, Serial Wire JTA= G Debug Port (SWJ-DP) as an interface to the debugger and Advanced High-= performance Bus Access Port (AHB-AP) interface to enable the SWJ-DP to a= ccess the system over an AHB interface. The SWJ-DP is a debug port that = combines the JTAG-DP and Serial Wire Debug Port (SW-DP). By default, aft= er power up JTAG-DP is active, however special sequences can switch betw= een JTAG and SWD DP. It is recommended that after power up selection is = performed before and during the debug session with no further switchover= - reselecting the DP when debug is already active requires hard reset, = or unpredictable result may occur. The switching sequences are as follow= s:

JTAG-to-SWD:
    Send more than 50 SWCLKTCK cycles with SWDIOTMS=3D1. This ensure= s that both SWD and JTAG are in their reset states.
    Send the 16-bit JTAG-to-SWD select sequence on SWDIOTMS.
    Send more than 50 SWCLKTCK cycles with SWDIOTMS=3D1. This ensur= es that if SWJ-DP was already in SWD mode, before sending the select seq= uence, the SWD goes to line reset.
    Perform a READID to validate that SWJ-DP has switched to SWD op= eration.
    The 16-bit JTAG-to-SWD select sequence is defined to be 0111100= 111100111, MSB first. This can be represented as 16'h79E7 transmitted MS= B first or 16'hE79E when transmitted LSB first. 
SWD-to-JTAG:
    Send more than 50 SWCLKTCK cycles with SWDIOTMS=3D1. This ensure= s that both SWD and JTAG are in their reset states.
    Send the 16-bit SWD-to-JTAG select sequence on SWDIOTMS.
    Send at least 5 SWCLKTCK cycles with SWDIOTMS=3D1. This ensures= that if SWJ-DP was already in JTAG mode before sending the select seque= nce, that JTAG goes into the TLR state.
    Set the JTAG-DP IR to READID and shift out the DR to read the I= D. =
    The 16-bit SWD-to-JTAG select sequence is defined to be 0011110= 011100111, MSB first. This can be represented as 16'h3CE7 transmitted MS= B first or 16'hE73C when transmitted LSB first.

=
JTAG-DP

Description

JTAG-DP contains a debug port state machine (JTAG) that controls the =
JTAG-DP operation, including controlling the scan chain interface that p=
rovides the external physical interface to the JTAG-DP. It is based clos=
ely on the JTAG TAP State Machine, see IEEE Std 1149.1 (2001).

3D""

nTRST asynchronously takes the JTAG state machine logic to the Debug-=
Logic-Reset state. Debug-Logic-Reset state can also always be entered sy=
nchronously from any state by a sequence of five TCK cycles with TMS hig=
h, however depending on the initial state of the JTAG this might take th=
e state machine through one of the Update states, with the resulting sid=
e effects. When the JTAG goes through the Capture-IR state, a value is t=
ransferred onto the Instruction Register (IR) scan chain. The IR scan ch=
ain is connected between TDI and TDO. While the JTAG is in the Shift-IR =
state, and for the transition from Capture-IR to Shift-IR, the IR scan c=
hain advances one bit for each tick of TCK. This means that on the first=
tick, the LSB of the IR is output on TDO, bit [1] of the IR is transfer=
red to bit [0], bit [2] is transferred to bit [1], for example. The MSB =
of the IR is replaced with the value on TDI. When the JTAG goes through =
the Update-IR state, the value scanned into the scan chain is transferre=
d into the Instruction Register. When the JTAG goes through the Capture-=
DR state, a value is transferred from one of a number of Data Registers =
(DRs) onto one of a number of Data Register scan chains, connected betwe=
en TDI and TDO. This data is then shifted while the JTAG is in the Shift=
-DR state, in the same manner as the IR shift in the Shift-IR state. Whe=
n the JTAG goes through the Update-DR state, the value scanned into the =
scan chain is transferred into the Data Register. When the JTAG is in th=
e Run-Test/Idle state, no special actions occur. Debuggers can use this =
as a true resting state.

JTAG-DP Registers

The JTAG-DP registers are only accessed when the Instruction Register=
(IR) for the DAP access contains the IDCODE, DPACC, or ABORT instructio=
n. The JTAG-DP register accessed depends on both Instruction Register (I=
R) value for the DAP access and the address field of the DAP access.

JTAG Instruction =
Register (IR)

JTAG IR is a 4-bit register that holds the current DAP Controller ins=
truction. On debug logic reset, IDCODE becomes the current instruction. =
If the IR register is set to IR instruction value out of scope (that is =
not implemented, or reserved), then the Bypass Register is selected.

Standard IR instructions are:

b1000: ABORT (DR: 1bit) - JTAG-DP Abort Register (ABORT) - Acces=
s the DP Abort Register, to force a DAP abort.
b1010: DPACC (DR: 35bits) - JTAG DP Access Registers (DPACC) - =
Initiate a Debug Port (DP) or Access Port (AP) access, to access a debug=
port or access port register. The DPACC and APACC are used for read and=
write accesses to registers - DPACC to access the CTRL/STAT, SELECT and=
RDBUFF registers, while APACC is used to access all of the access port =
registers.
b1011: APACC (DR: 35bits) - JTAG AP Access Registers (APACC) - =
The DPACC and APACC scan chains have the same format. See DPACC (above).=

b1110: IDCODE (DR: 32bits) - JTAG Device ID Code Register (IDCO=
DE) - Device identification. The Device ID Code value enables a debugger=
to identify the debug port to which it is connected. Different debug po=
rts have different Device ID Codes, so that a debugger can make this dis=
tinction.
b1111 BYPASS (DR: 1bit) - JTAG Bypass Register (BYPASS) - Bypas=
ses the device, by providing a direct path between TDI and TDO.

JTAG Data Register (DR) =

There are five physical DR registers: BYPASS, IDCODE, DPACC, APACC, A=
BORT. There is a scan chain associated with each of these registers - th=
e IR register determines which of these scan chains is connected to the =
TDI and TDO signals.

ABORT (IR: b1111, D=
R: 1bit)

Access the DP Abort Register, to force a DAP abort. The debugger must=
scan the value 0x0000008 into this scan chain. This value writes the Rn=
W bit as 0, A[3:2] field as b00, 1 into bit 0, the DAPABORT bit, of the =
Abort Register.

IDCODE (IR:b1110,=
DR: 32bit)

Version, bit [31:28], is set to 3
Part number, bit [27:12], is set to 0xBA00
Manufacturer ID, bit [11:1], is set to 0x23B
Reserved, bit [0], is set to 1.

DPACC / APACC (DPAC_IR:b101=
0, APAC_IR:b1011, DR: 35bit)

Initiate a debug port or access port access, to access a debug port o=
r access port register. =

In the Capture-DR state, the result of the previous transaction, =
if any, is returned, together with a 3-bit ACK response. Only two ACK re=
sponses are implemented (all others reserved): =

b010 OK/FAULT response to a DPACC or APACC access: If the respon=
se indicated by ACK[2:0] is OK/FAULT, the previous transaction has compl=
eted. The response code does not show whether the transaction completed =
successfully or was faulted. You must read the CTRL/STAT register to fin=
d whether the transaction was successful:
    If the previous transaction was a read that completed successful=
    ly, then the captured ReadResult[31:0] is the requested register value. =
    This result is shifted out as Data[34:3].
    If the previous transaction was a write, or a read that did not=
    complete successfully, the captured ReadResult[31:0] is Unpredictable. =
    If Data[34:3] is shifted out it must be discarded.

b001 WAIT response to a DPACC or APACC access: A WAIT response =
indicates that the previous transaction has not completed. The host shou=
ld retry the DPACC or APACC access. Normally, if software detects a WAIT=
response, it retries the same transfer. This enables the protocol to pr=
ocess data as quickly as possible. However, if the software has retried =
a transfer a number of times, permitting enough time for a slow intercon=
nect and memory system to respond, it might write to the ABORT register,=
to cancel the operation. This signals to the active access port that it=
can terminate the transfer it is currently attempting and permits acces=
s to other parts of the debug system. An access port might not be able t=
o terminate a transfer on its ASIC interface. However, on receiving an A=
BORT, the access port must free its JTAG interface.

Operation in the Update-DR depends on whether the ACK[2:0] response w=
as OK/FAULT or WAIT. The two cases are described in:

Update-DR operation following an OK/FAULT response.
Update-DR operation following a WAIT response: No request is ge=
nerated at the Update-DR state and the shifted-in data is discarded. The=
captured value of ReadResult[31:0] is Unpredictable. You can detect a W=
AIT response without shifting through the entire DP or AP Access Registe=
r

If IR=3DDPACC then read/write to DP, IR=3DAPACC then read/write to AP=
register. RnW=3D0 write into DATAIN[31:0], RnW=3D1 read from addressed =
register in next read cycle: DPACC selects A[3:2], APACC selected by A[3=]
:2 and the SELECT DP register. Register accesses can be pipelined, beca=
use a single DPACC or APACC scan can return the result of the previous r=
ead operation at the same time as requesting another register access. At=
the end of a sequence of pipelined register reads, you can read the DP =
RDBUFF Register to return the result of the final register read.

If the current IR instruction is APACC, causing an APACC access:

If any sticky flag is set in the DP CTRL/STAT Register, the tran=
saction is discarded. The next scan returns an OK/FAULT response immedia=
tely.
If pushed compare or pushed verify operations are enabled then =
the scanned-in value of RnW must be 0, otherwise behavior is Unpredictab=
le. On Update-DR, a read request is issued and the returned value compa=
red against DATAIN[31:0]. The STICKYCMP flag in the DP CTRL/STAT regist=
er is updated based on this comparison.
The AP access does not complete until the access port signals i=
t as completed.

Sticky overrun behavior on DPACC and APACC accesses: At the Capture-D=
R state, if the previous transaction has not completed a WAIT response i=
s generated. When this happens, if the Overrun Detect flag is set, the S=
ticky Overrun flag, STICKYORUN, is set. While the previous transaction r=
emains not completed, subsequent scans also receive a WAIT response. Whe=
n the previous transaction has completed, any more APACC transactions ar=
e abandoned and scans respond immediately with an OK/FAULT response. How=
ever, debug port registers can be accessed. In particular the CTRL/STAT =
register can be accessed, to confirm that the Sticky Overrun flag is set=
and to clear the flag after gathering any required information about th=
e overrun condition. See Overrun detection on page 9-48 for more informa=
tion.

Most common situations handling:

Read Operation returns OK/FAULT - Capture read data.
Write Operation returns OK/FAULT - No more action required.
Read or Write Operation returns WAIT - Repeat the same access =
until either an OK/FAULT ACK is received or the wait timeout is reached.=
If necessary, use the DAP ABORT register to enable access to the AP.
Read or Write Operation returns Invalid ACK - Assume a target =
or line error has occurred and treat as a fatal error.

SW-=
DP

Description

The SW-DP operates with a synchronous serial interface. This uses a s=
ingle bidirectional data signal and a clock signal. =

Each sequence of operations on the wire consists of two or three =
phases:

Packet request - The external host debugger issues a request to =
the debug port. The debug port is the target of the request.
Acknowledge response - The target sends an acknowledge response=
to the host.
Data transfer phase - This phase is only present when either:
    Data Read or Data Write request is followed by a valid (OK) - a=
    cknowledge response.
    ORUNDETECT flag is set to 1 in the CTRL/STAT Register (if CTRL=
    /STAT=3D1 then data transfer is required on all responses).

The data transfer is one of:

target to host, following a read request (RDATA)
host to target, following a write request (WDATA).

The SW-DP uses a serial wire for both host and target sourced signals=
. The host emulator drives the protocol timing. Only the host emulator g=
enerates packet headers. Both the target and host are capable of driving=
the bus HIGH and LOW, or tristating it. Time required to switch from tr=
ansmission into receiving mode is called Turnaround time.

The SW-DP clock, SWCLKTCK, can be asynchronous to the device/syst=
em CLK. SWCLKTCK can be stopped when the debug port is idle, but host mu=
st continue to clock the interface for a number of cycles after the data=
phase of any data transfer - this ensures that the transfer can be cloc=
ked through the SW-DP. 100k high-pullup resistor is recommended at targe=
t on SWTMSIO line, therefore this line should be driven high before ente=
ring low power mode.

Interface Reset=
and Synchronization

Interface reset or resynchronization occurs at 50 clocks with data li=
ne set high and then IDCODE read ended with OK response. Device will sig=
nal request for reset by not driving the data line at response stage, af=
ter two bad data sequences in a row target locks out and requests reset =
sequence described before. Additionally host should give target some tim=
e for command processing to return a payload, host can request IDCODE re=
ad and when it fails it should reset Target.

<=
h4> SWD Packet Construction

Start - single start bit, with value 1.
APnDP - single bit, indicating whether the DP or the AP Access =
Register is to be accessed. This bit is 0 for a DPACC access, or 1 for a=
n APACC access.
RnW - single bit, indicating whether the access is a read or a =
write. This bit is 0 for an write access, or 1 for a read access.
A[2:3] - two bits, giving the A[3:2] address field for the DP o=
r AP Register Address (shifted out LSB first):
    APACC access, the register being addressed depends on the A[3:2]=
    value and the value held in the SELECT register. =

    DPACC access, the A[3:2] value determines the address of the re=
    gister in the SW-DP register map.

Parity - single parity bit for the preceding packet.
Stop - single stop bit. In the synchronous SWD protocol this is=
always 0.
Park - single bit. The host must drive the line high before tri=
stating the line. The target reads this bit as 1.
Trn (Turnaround) - this is a period when the line is not driven=
and the state of the line is Undefined. The length of the turnaround pe=
riod is controlled by the TURNROUND field in the Wire Control Register. =
The default setting is a turnaround period of one clock cycle. By defaul=
t turnaround time is one cycle.
ACK - 3-bit target-to-host response. Transmitted LSB first on t=
he wire.
WDATA[0:31] - 32 bits of write data, from host to target.
RDATA[0:31] - 32 bits of read data, from target to host.

In the SWD protocol, a simple parity check is applied to all packet r=
equest and data transfer phases. Parity bit appears on the wire immediat=
ely after the A[2:3] bits (ACK[0:2] bits are never included in the parit=
y calculation). Even parity is used: =

Packet requests - parity check is made over the APnDP, RnW and A=
[2:3] bits (when the number of bits set to 1 is odd then the parity bit =
is set to 1, when the number of bits set to 1 is even then the parity bi=
t is set to 0).
Data transfers (WDATA and RDATA) - parity check is made over th=
e 32 data bits, WDATA[0:31] or RDATA[0:31]. If, of these 32 bits (if the=
number of bits set to 1 is odd then the parity bit is set to 1, if the =
number of bits set to 1 is even then the parity bit is set to 0).

<a name=3D"Successful_Write_Operation" id=3D"Successful_Write_Operation"=

Successful Write Operation </span=>

A successful write operation consists of three phases:

    8-bit write packet request, from the host to the target
    3-bit OK acknowledge response, from the target to the host
    33-bit data write phase, from the host to the target


3D""
</di=>

By default, there are single-cycle turnaround periods between each of=
these phases. The OK response only indicates that the debug port is rea=
dy to accept the write data. The debug port writes this data after the w=
rite phase has completed. The response to the debug port write itself is=
given on the next operation. There is no turnaround phase after the dat=
a phase. The host is driving the line and can start the next operation i=
mmediately. SW-DP can buffer writes to the APBUS.

The SW-DP implements a write buffer that enables it to accept wri=
te operations even when other transactions are still outstanding. The de=
bug port issues an OK response to a write request if it can accept the w=
rite into its write buffer. This means that an OK response to a write re=
quest, other than a write to the DP ABORT Register, indicates only that =
the write has been accepted by the debug port. It does not indicate that=
all previous transactions have completed.

If a write is accepted into the write buffer but later abandoned,=
the WDATAERR flag is set in the CTRL/STAT Register, see Control/Status =
Register, CTRL/STAT. A buffered write is abandoned if:

    A sticky flag is set by a previous transaction.
    A debug port read of the IDCODE or CTRL/STAT Register is made.=
    Because the debug port is not permitted to stall reads of these registe=
    rs, it must:
        perform the IDCODE or CTRL/STAT Register access immediately
        discard any buffered writes, because otherwise they would be pe=
        rformed out-of-order.

    A debug port write of the ABORT Register is made. This is beca=
    use the debug port cannot stall an ABORT Register access.


This means that if you make a series of access port write transaction=
s, it might not be possible to determine which transaction failed from e=
xamining the ACK responses. However, it might be possible to use other e=
nquiries to find which write failed. For example, if you are using the a=
uto-address increment (AddrInc) feature of a Memory Access Port (AHB-AP)=
, then you can read the Transfer Address Register to find which was the =
final successful write transaction. See AHB-AP Transfer Address Register=
, TAR, 0x04 and AHB-AP register summary for more information. =

The write buffer must be emptied before the following operations =
can be performed:

any access port read operation
any debug port operation other than a read of the IDCODE or CT=
RL/STAT Register, or a write of the ABORT Register.

Attempting these operations causes WAIT responses from the debug port=
until the write buffer is empty. If you have to perform a SW-DP read of=
the IDCODE or CTRL/STAT Register, or a SW-DP write to the ABORT Registe=
r immediately after a sequence of access port writes, you must first per=
form an access that the SW-DP is able to stall. In this way you can chec=
k that the write buffer is cleared before performing the SW-DP register =
access. If this is not done, WDATAERR might be set and the buffered writ=
es lost.

<=
/a>
Successful Read Operation

A successful read operation consists of three phases:

8-bit read packet request, from the host to the target
3-bit OK acknowledge response, from the target to the host
33-bit data read phase, where data is transferred from the tar=
get to the host.

3D""

By default, there are single-cycle turnaround periods between the fir= st and second of these phases and after the third phase. However, there = is no turnaround period between the second and third phases.

The SW-DP CTRL/STAT register includes a READOK flag, bit [6]. Thi= s register is described in Control/Status Register, CTRL/STAT. The READO= K flag is updated on every access port read access and on every RDBUFF r= ead request. When the SW-DP initiates the access port access it clears t= he READOK flag to 0 and, when the SW-DP target gives an OK response to t= he read request, it sets the READOK flag to 1. This means that if a host= receives a corrupted ACK response to an access port or RDBUFF read requ= est it can check whether the read actually completed correctly. The host= can read the DP CTRL/STAT Register to find the value of the READOK flag= :

If the flag is set to 1 then the read was performed correctly. = The host can use a RESEND request to obtain the read result, see Read Re= send Register, RESEND (SW-DP only).
If the flag is set to 0 then the read was not successful. The = host must retry the original access port or RDBUFF read request.

Read accesses to the access port are posted. This means that the resu= lt of the access is returned on the next transfer. If the next access yo= u have to make is not another access port read then you must insert a re= ad of the DP RDBUFF Register to obtain the posted result. When you must = make a series of access port reads, you only have to insert one read of = the RDBUFF Register:

On the first access port read access, the read data returned is= Undefined. You must discard this result.
If you immediately make another access port read access this r= eturns the result of the previous access port read.
You can repeat this for any number of access port reads.
Issuing the last access port read packet request returns the l= ast-but-one access port read result.
You must then read the DP RDBUFF Register to obtain the last a= ccess port read result.

WAIT response to Read or Write operation request

A WAIT response to a read or write packet request consists of two pha= ses:

8-bit read or write packet request, from the host to the target=
3-bit WAIT acknowledge response, from the target to the host.

3D""

By default, there are single-cycle turnaround periods between these t= wo phases and after the second phase. If Overrun Detection is enabled th= en a data phase is required on a WAIT response. Writing to the ABORT reg= ister after receiving a WAIT response enables the debugger to access oth= er parts of the debug system.

A WAIT response is issued by the SW-DP if it is not able to immed= iately process the request from the debugger. However, a WAIT response m= ust not be issued to the following requests. SW-DP must always be able t= o process these three requests immediately: IDCODE, CTRL/STAT, ABORT. Wi= th any request other than those listed, the SW-DP issues a WAIT response= , with no data phase, if it cannot process the request. This happens if = a previous access port or debug port access is outstanding, or if the n= ew request is an access port read request and the result of the previous= AP read is not yet available.

Normally, when a debugger receives a WAIT response it retries the= same operation. This enables it to process data as quickly as possible.= However, if several retries have been attempted, and time permitted for= a slow interconnection and memory system to respond, if appropriate, th= e debugger might write to the ABORT register. This signals to the active= access port that it must terminate the transfer that it is currently at= tempting. An access port implementation might be unable to terminate a t= ransfer on its ASIC interface. However, on receiving an ABORT request th= e access port must free up the SWD interface.

FAULT response to Read or Write operation request

A FAULT response to a read or write packet request consists of two ph=
ases:

8-bit read or write packet request, from the host to the target=

3-bit FAULT acknowledge response, from the target to the host.=

3D""

By default, there are single-cycle turnaround periods between these t=
wo phases and after the second phase. If Overrun Detection is enabled th=
en a data phase is required on a FAULT response. =

SW-DP does not issue a FAULT response to an access to the IDCODE,=
CTRL/STAT or ABORT registers. For any other access, the SW-DP issues a =
FAULT response if any sticky flag is set in the CTRL/STAT Register. Use =
of the FAULT response enables the protocol to remain synchronized. A deb=
ugger might stream a block of data and then check the CTRL/STAT register=
at the end of the block. The sticky error flags are cleared by writing =
bits in the ABORT register, see Abort Register, ABORT.

<=
h4> Protocol Error Sequence
=3D""

A protocol error occurs when a host issues a packet request but the t=
arget fails to return any acknowledge response. If the SW-DP detects a p=
arity error in the packet request it does not reply to the request.

When the host receives no reply to its request, it must back off,=
in case the SW-DP has lost frame synchronization for some reason. After=
this, it can issue a new transfer request. In this situation it must re=
ad the IDCODE register - this is mandated by this specification because =
a successful read of the IDCODE register confirms that the target is ope=
rational. If there is no response at the second attempt, the debugger mu=
st force a line reset to ensure frame synchronization and valid operatio=
n. This is necessary because the SW-DP is in a state where it only respo=
nds to a line reset. After the line reset the debugger must read the IDC=
ODE register before it attempts any other operations.

If the transfer that resulted in the original protocol error resp=
onse was a write, you can assume that no write occurred. If the original=
transfer was a read, it is possible that the read was issued to an acce=
ss port. Although this is unlikely, you must consider this possibility b=
ecause reads are pipelined and the debug port might implement a write bu=
ffer.

SW-DP Registers

address b00:
    R, APnDP=3Db1: Identification Code Register, IDCODE
    W, APnDP=3Db1: Abort Register, ABORT

address b01
    CTRLSEL=3Db0: R/W: Control/Status Register, CTRL/STAT
    CTRLSEL=3Db1: R/W: Wire Control Register, WCR (SW-DP only)

address b10:
    R: Read Resend Register, RESEND (SW-DP only)
    W: AP Select Register, SELECT

addrsss b11:
    R: Read Buffer, RDBUFF

ABO=
RT

The Abort Register is always present on all debug port implementation=
s. Its main purpose is to force a DAP abort. On a SW-DP, it is also used=
to clear error and sticky flag conditions. A write-only register. Alway=
s accessible and returns an OK response if a valid transaction is receiv=
ed. Abort Register accesses always complete on the first attempt.

3D""

Bit description:

[31:5] - Reserved, SBZ.
[4] ORUNERRCLR - Write b1 to this bit to clear the STICKYORUN =
overrun error flagb (SW-DP only).
[3] WDERRCLR - Write b1 to this bit to clear the WDATAERR writ=
e data error flagb (SW-DP only).
[2] STKERRCLR - Write b1 to this bit to clear the STICKYERR st=
icky error flagb (SW-DP only).
[1] STKCMPCLR - Write b1 to this bit to clear the STICKYCMP st=
icky compare flagb (SW-DP only).
[0] DAPABORT - Write b1 to this bit to generate a DAP abort. T=
his aborts the current access port transaction. This must only be done i=
f the debugger has received WAIT responses over an extended period.

DP Aborts - Writing b1 to bit [0] of the Abort Register generates a d=
ebug port abort, causing the current AP transaction to abort. This also =
terminates the Transaction Counter, if it was active. From a software pe=
rspective, this is a fatal operation. It discards any outstanding and pe=
nding transactions and leaves the access port in an unknown state. Howev=
er, on a SW-DP, the sticky error bits are not cleared. You use this func=
tion only in extreme cases, where debug host software has observed stall=
ed target hardware for an extended period. Stalled target hardware is in=
dicated by WAIT responses.

After a debug port abort is requested, new transactions can be ac=
cepted by the debug port. However, an access port access to the access p=
ort that was aborted can result in more WAIT responses. Other access por=
ts can be accessed, however, the state of the system might make it impos=
sible to continue with debug.

Clearing error and sticky compare flags - When a debugger, connec=
ted to a SW-DP, checks the Control/Status Register and finds that an err=
or flag is set, or that the sticky compare flag is set, it must write to=
the Abort register to clear the error or sticky compare flag. Table 9-1=
4 on page 9-56 lists the flags
that might be set in the Control/Status Register and shows which bit of =
the Abort register is used to clear each of the flags. You can use a sin=
gle write of the Abort Register to clear multiple flags, if this is nece=
ssary. After clearing the flag, you might have to access the debug port =
and access port registers
to find what caused the flag to be set. Typically:

For the STICKYCMP or STICKYERR flag, you must find which locati=
on was accessed to cause the flag to be set.
For the WDATAERR flag, after clearing the flag you must resend=
the data that was corrupted.
For the STICKYORUN flag, you must find which debug port or ac=
cess port transaction caused the overflow. You then have to repeat your =
transactions from that point.

IDCODE, I=
dentification Code Register

The Identification Code Register is always present on all debug port =
implementations. It provides identification information about the ARM De=
bug Interface. It is at address 0b00 on read operations when the APnDP b=
it=3D1. It is a read-only register and always accessible.

3D""=

Bits description:

[31:28] Version code: JTAG-DP=3D0x3, SW-DP=3D0x2
[27:12] PARTNO - Part Number for the debug port. Current ARM-d=
esigned debug ports have the following PARTNO values: JTAG-DP=3D0xBA00, =
SW-DP=3D0xBA10
[11:1] MANUFACTURER - JEDEC Manufacturer ID, an 11-bit JEDEC c=
ode that identifies the manufacturer of the device. The ARM default valu=
e for this field is 0x23B.
[0] - Always 0b1.

JEDEC Manufacturer ID codes are assigned by the JEDEC Solid State Tec=
hnology Association, see JEP106M, Standard Manufacture=E2=80=99s Identif=
ication Code. This code is also described as the JEP-106 manufacturer id=
entification code and can be subdivided into two fields:

Continuation code, 4 bits, [11:8]: b0100, 0x4
Identity code, 7 bits, [7:1]: b0111011, 0x3B

CTRL/=
STAT, Control/Status Register

The Control/Status Register is always present on all debug port imple=
mentations. It provides control of the debug port and status information=
about the debug port. It is located at address 0b01 on read and write o=
perations when the APnDP=3Db1 and the CTRLSEL=3Db0 in the Select Registe=
r. It is a read-write register, in which some bits have different access=
rights. It is implementation-defined whether some fields in the registe=
r are supported - below is an obligatory bit list and description.

3D""

Bits description:

[31], RO: CSYSPWRUPACK - System power-up acknowledge.
[30], R/W: CSYSPWRUPREQ - System power-up request. After a res=
et this bit is LOW (0).
[29], RO: CDBGPWRUPACK - Debug power-up acknowledge.
[28], R/W: CDBGPWRUPREQ - Debug power-up request. After a rese=
t this bit is LOW (0).
[27], RO: CDBGRSTACK - Debug reset acknowledge.
[26], R/W: CDBGRSTREQ - Debug reset request. After a reset thi=
s bit is LOW (0).
[25:24] - Reserved, RAZ/SBZP.
[21:12], R/W: TRNCNT - Transaction counter. After a reset the =
value of this field is Unpredictable.
[11:8], R/W: MASKLANE - Indicates the bytes to be masked in pu=
shed compare and pushed verify operations. After a reset the value of th=
is field is Unpredictable. The MASKLANE field, bits [11:8] of the CTRL/S=
TAT Register, is only relevant if the Transfer Mode is set to pushed ver=
ify or pushed compare operation. In the pushed operations, the word supp=
lied in an access port write transaction is compared with the current va=
lue of the target access port address. The MASKLANE field lets you speci=
fy that the comparison is made using only certain bytes of the values. E=
ach bit of the MASKLANE field corresponds to one byte of the access port=
values. Therefore, each bit is said to control one byte lane of the com=
pare operation:
    b1XXX: Include byte lane 3 in comparisons (0xFF------)
    bX1XX: Include byte lane 2 in comparisons (0x--FF----)
    bXX1X: Include byte lane 1 in comparisons (0x----FF--)
    bXXX1: Include byte lane 0 in comparisons (0x------FF)

[7], RO[1]: WDATAERR[1] - This bit is set to 1 if a Write Data=
Error occurs. This bit can only be cleared by writing b1 to the WDERRCL=
R field of the Abort Register, see Abort Register, ABORT. After a power-=
on reset this bit is LOW (0). It is set if:
    there is a a parity or framing error on the data phase of a writ=
    e
    a write that has been accepted by the debug port is then discar=
    ded without being submitted to the access port.

[6], RO[1]: READOK[1] - This bit is set to 1 if the response t=
o a previous access port or RDBUFF was OK. It is cleared to 0 if the res=
ponse was not OK. This flag always indicates the response to the last ac=
cess port read access. After a power-on reset this bit is LOW (0).
[5], RO[2]: STICKYERR - This bit is set to 1 when the processo=
r receives a bus error on the system AHB-Lite bus. When STICKYERR is set=
, no transaction is passed from the JTAG or SW interfaces to the debug A=
HB system bus. Any read that is performed when STICKYERR is set results =
in data that is Unpredictable. To clear this bit write b1 to the STKERRC=
LR field of the Abort Register, see Abort Register, ABORT. After a power=
-on reset this bit is LOW (0).
[4], RO[2]: STICKYCMP - This bit is set to 1 when a match occ=
urs on a pushed compare or a pushed verify operation. To clear this bit =
write b1 to the STKCMPCLR field of the Abort Register, see Abort Registe=
r, ABORT. After a power-on reset this bit is LOW (0).
[3:2], R/W: TRNMODE - This field sets the transfer mode for ac=
cess port operations. After a power-on reset the value of this field is =
Unpredictable. In normal operation, access port transactions are passed =
to the access port for processing. In pushed verify and pushed compare o=
perations, the debug port compares the value supplied in the access port=
transaction with the value held in the target access port address. Belo=
w is a list of the permitted values of this field and their meaning:
    b00: Normal operation
    b01: Pushed verify operation
    b10: Pushed compare operation
    b11: Reserved

[1], RO[2]: STICKYORUN - If overrun detection is enabled (see =
bit [0] of this register), this bit is set to 1 when an overrun occurs. =
To clear this bit write b1 to the ORUNERRCLR field of the Abort Register=
, see Abort Register, ABORT. After a power-on reset this bit is LOW (0).=

[0], R/W: ORUNDETECT - This bit is set to b1 to enable overrun=
detection. After a reset this bit is Low (0).

SELECT, AP Select Register

The AP Select Register is always present on all debug port implementa=
tions. Its main purpose is to select the current Access Port (AP) and th=
e active four-word register window in that access port. On a SW-DP, it a=
lso selects the Debug Port address bank. It is at address 0b10 on write =
operations when the APnDP=3Db1 and is a write-only register. Access to t=
he AP Select Register is not affected by the value of the CTRLSEL bit.

3D""</a=

Bits description:

[31:24], APSEL: Selects current access port. Note: Because the =
processor has only one access port, APSEL must be 8'b00000000. The reset=
value of this field is Unpredictable.
[23:8], - Reserved. SBZ/RAZ[1].
[7:4], APBANKSEL - Selects the active 4-word register window o=
n the current access port. The reset value of this field is Unpredictabl=
e.
[3:1], - Reserved. SBZ/RAZ[1].
[0], CTRLSEL: SW-DP Debug Port address bank select, SW-DP only=
. After a reset this field is b0. However the register is WO so you cann=
ot read this value. The CTRLSEL field, bit [0], controls which debug por=
t register is selected at address b01 on a SW-DP. Meaning of the differe=
nt values of CTRLSEL is as follows:
    0: CTRL/STAT, see Control/Status Register, CTRL/STAT
    1: WCR, see Wire Control Register, WCR (SW-DP only)

=
RDBUFF, Read Buffer

The 32-bit Read Buffer is always present on all debug port implementa=
tions. However, there are significant differences in its implementation =
on JTAG and SW Debug Ports. On SW-DP it is at address 0xC on read operat=
ions when the APnDP=3Db1 and is a read-only register. Access to the Read=
Buffer is not affected by the value of the CTRLSEL bit in the SELECT Re=
gister.

On a SW-DP, performing a read of the Read Buffer captures data fr=
om the access port, presented as the result of a previous read, without =
initiating a new access port transaction. This means that reading the Re=
ad Buffer returns the result of the last access port read access, withou=
t generating a new AP access. After you have read the Read Buffer, its c=
ontents are no longer valid. The result of a second read of the Read Buf=
fer is Unpredictable.

If you require the value from an access port register read, that =
read must be followed by one of:

A second access port register read. You can read the Control/St=
atus Register (CSW) if you want to ensure that this second read has no s=
ide effects.
A read of the DP Read Buffer. This access, to the access port =
or the debug port depending on which option you used, stalls until the r=
esult of the original access port read is available.

WCR, Wire Control Register

The Wire Control Register is always present on any SW-DP implementati=
on. Its purpose is to select the operating mode of the physical serial p=
ort connection to the SW-DP. It is a read/write register at address 0b01=
on read and write operations when the CTRLSEL=3Db1 in the Select Regist=
er. For information about the CTRLSEL bit see AP Select Register, SELECT=
. Note: When the CTRLSEL=3Db1, to enable access to the WCR, the DP Contr=
ol/Status Register is not accessible. Many features of the Wire Control =
Register are implementation-defined!

3D""=

Bits description:

[31:10], - Reserved. SBZ/RAZ.
[9:8], TURNROUND: Turnaround tristate period. After a reset th=
is field is b00. This field defines the turnaround tristate period. This=
turnaround period allows for pad delays when using a high sample clock =
frequency. The possible values of this field and their meanings is prese=
nted below:
    b00: 1 sample period
    b01: 2 sample periods
    b10: 3 sample periods
    b11: 4 sample periods

[7:6], WIREMODE: Identifies the operating mode for the wire co=
nnection to the debug port. After a reset this field is b01. This field =
identifies SW-DP as operating in Synchronous mode only. This field is re=
quired. The possible values of the field and their meanings is presented=
below:
    b00: Reserved
    b01: Synchronous (no oversampling)
    b1X: Reserved

[5:3], - Reserved. SBZ/RAZ.
[2:0], PRESCALER: Reserved. SBZ/RAZ.

RESEND, Read Resend Regis=
ter

The Read Resend Register is always present on any SW-DP implementatio=
n. Its purpose is to enable the read data to be recovered from a corrupt=
ed debugger transfer, without repeating the original AP transfer. It is =
a 32-bit read-only register at address 0b10 on read operations. Access t=
o the Read Resend Register is not affected by the value of the CTRLSEL b=
it in the SELECT Register.

Performing a read to the RESEND register does not capture new dat=
a from the access port. It returns the value that was returned by the la=
st AP read or DP RDBUFF read. Reading the RESEND register enables the re=
ad data to be recovered from a corrupted transfer without having to re-i=
ssue the original read request or generate a new DAP or system level acc=
ess. The RESEND register can be accessed multiple times. It always retur=
ns the same value until a new access is made to the DP RDBUFF register o=
r to an access port register.

A=
HB-AP

This section describes the AHB Access Port (AHB-AP), for access to a =
system AHB bus through an AHB-Lite master. It acts as a slave to the DAP=
internal bus, driven by only a single debug port, SWJ-DP, at any one ti=
me.

3D""

The AHB-AP has two interfaces:

An internal DAP bus interface that connects to the SWJ-DP
An AHB master port for connection through the matrix to the ex=
ternal AHB-Lite interface and the PPB.

=
AHB-Lite master ports

The AHB-Lite master port supports AHB in AMBA v2.0. The AHB-Lite mast=
er port does not support: BURST and SEQ, Exclusive accesses, Unaligned t=
ransfers. The other AHB-AP ports are included:

DBGEN, Input[1]: Enables AHB-AP transfers if HIGH
SPIDEN, Input[2]: Permits secure transfers to take place on th=
e AHB-AP
nCDBGPWRDN, Input[1]: Indicates that the debug infrastructure =
is powered down
nCSOCPWRDN, Input[1]: Indicates that the system AHB interface =
is powered down

AHB-AP registers

The following AHB-AP registers are available:

0x00, R/W, 32bit: Control/Status Word, CSW (reset value: 0x4380=
0042)
0x04, R/W, 32bit: Transfer Address, TAR (reset value: 0x000000=
00)
0x08, Reserved SBZ
0x0C, R/W, 32bit: Data Read/Write, DRW
0x10, R/W, 32bit: Banked Data 0, BD0
0x14, R/W, 32bit: Banked Data 1, BD1
0x18, R/W, 32bit: Banked Data 2, BD2
0x1C, R/W, 32bit: Banked Data 3, BD3
0x20-0xF7, Reserved SBZ
0xF8, RO, 32bit: Debug ROM table (reset value: 0xE00FF000)
0xFC, RO, 32bit: Identification Register, IDR (reset value: 0x=
24770001)

CSW, 0x00, AHB-AP Control/Status Word Register

This is the control word used to configure and control transfers thro=
ugh the AHB interface.

3D""

Bits description:

[31], Reserved SBZ.
[30], Reserved SB0.
[29:28], Reserved SBZ.
[27:24], R/W, Prot: Specifies the protection signal encoding t=
o be output on HPROT[3:0]. Reset value is noncacheable, non-bufferable, =
data access, privileged =3D b0011.
[23], RO, SPIStatus: Indicates the status of the SPIDEN port. =
Always reads as b1.
[22:12], Reserved SBZ.
[11:8], R/W, Mode (reset value: b0000): Specifies the mode of =
operation:
    b0000 =3D Normal download/upload model
    b0001-b1111 =3D Reserved SBZ.

[7], RO, TrInProg: Transfer in progress. This field indicates =
if a transfer is currently in progress on the AHB master port.
[6], RO, DbgStatus: Indicates the status of the DBGEN port. Al=
ways reads as b1 =3D AHB transfers permitted.
[5:4], R/W, AddrInc (reset value: b00): Auto address increment=
and packing mode on Read or Write data access. Only increments if the c=
urrent transaction completes without an Error Response. Does not increme=
nt if the transaction completes with an Error Response or the transactio=
n is aborted. Auto address incrementing and packed transfers are not per=
formed on access to Banked Data registers 0x10-0x1C. The status of these=
bits is ignored in these cases. Increments and wraps within a 1KB addre=
ss boundary, for example, for word incrementing from 0x1400-0x17FC. If t=
he start is at 0x14A0, then the counter increments to 0x17FC, wraps to 0=
x1400, then continues incrementing to 0x149C. Size of address increment =
is defined by the Size field, bits [2:0].
    b00 =3D auto increment off
    b01 =3D increment, single. Single transfer from corresponding =
    byte lane.
    b10 =3D increment, packed. Word =3D same effect as single incr=
    ement. Byte/Halfword. Packs four 8-bit transfers or two 16-bit transfers=
    into a 32-bit DAP transfer. Multiple transactions are carried out on th=
    e AHB interface.
    b11 =3D Reserved SBZ, no transfer.

[3], Reserved SBZ, R/W =3D b0 =

[2:0], R/W, Size (reset value: b010): Size of the data access =
to perform:
    b000 =3D 8 bits
    b001 =3D 16 bits
    b010 =3D 32 bits
    b011-b111 =3D Reserved SBZ.

TAR, 0x04, AHB-AP Transfer Address Register

Bits description:

[31:0], R/W, Address (reset value: 0x00000000): Address of the =
current transfer. Unaligned address values with respect to the Size fiel=
d of the Control/Status Word Register are unsupported.

DRW, 0x0C, AHB-AP Data Read/Write Register

Bits description:

[31:0], R/W, Data:
    Write mode: Data value to write for the current transfer.
    Read mode: Data value read from the current transfer.

BD0-BD03, 0x10-Ox1C, AHB-AP Banked Data Registers <=
/span>

BD0-BD3 provide a mechanism for directly mapping through DAP accesses=
to AHB transfers without having to rewrite the Transfer Address Registe=
r (TAR) within a four-location boundary. BD0 reads/writes from TA. BD1 r=
eads/writes from TA+4. Below is the AHB-AP Banked Data Register bit assi=
gnments:

[31:0], R/W, Data: If DAPADDR[7:4] =3D 0x0001, so accessing AHB=
-AP registers in the range 0x10-0x1C, the derived HADDR[31:0] is:
    Write mode: Data value to write for the current transfer to ext=
    ernal address TAR[31:4] + DAPADDR[3:2] + 2'b00.
    Read mode: Data value read from the current transfer from exte=
    rnal address TAR[31:4] + DAPADDR[3:2] + 2'b00.

Auto address incrementing is not performed on DAP accesses to BD0-BD3=
. Banked transfers are only supported for word transfers. Non-word banke=
d transfers are reserved and Unpredictable. Transfer size is currently i=
gnored for banked transfers.

ROM, 0xF8, ROM =
Address Register

Bits description:

[31:0], RO, Debug AHB ROM Address: Base address of a ROM table.=
The ROM provides a look-up table for system components. Set to 0xE00FF0=
00 in the AHB-AP in the initial release.

IDR, 0xFC, AHB-AP Identification Register

3D""

The register reset value is 0x247700001. Bits description:

[31:28], RO, Revision: Reset value is 0x2 for AHB-AP.
[27:24], RO, JEDEC bank: Reset value is 0x4 (Using JEDEC bank =
0x0 with a JEDEC code of 0x00 is reserved for use by ARM.)
[23:17], RO, JEDEC code: Reset value is 0x3B.
[16], RO, ARM AP: Reset value is b1.
[15:8], Reserved SBZ.
[7:0], RO, Identity value: Reset value is 0x01 for AHB-AP.

</a=

AHB-AP clocks and resets
=

The AHB-AP has two clock domains that are connected together. HCLK dr= ives both of them:

DAPCLK - Drives the DAP bus interface and access control for re= gister read and writes. DAPCLK must be driven by a constant clock. When = started, it must not be stopped or altered while the DAP is in use.
HCLK - AHB clock domain driving AHB interface.
DBGRESETn - Initializes the state of all registers in the AHB-= AP.

Supported AHB protocol =
features

The AHB-Lite master port supports AHB in AMBA v2.0:

HPROT encodings

HPROT[3:0] is provided as an external port (see AHB-AP Control/=
Status Word Register, CSW, 0x00 for values of the Prot field) and is pro=
grammed from the Prot field in the CSW register with the following condi=
tions:
    HPROT[3:0] programming is supported.
    Exclusive access is not supported, so HRESP[2] is not supported=
    .

HRE=
SP

HRESP[0] is the only RESPONSE signal required by the AHB-AP: =

    AHB-Lite devices do not support SPLIT and RETRY and so HRESP[1]= is not required.
    HRESP[2] is not supported in the AHB-AP.

AHB-AP transfer types=
and bursts

The AHB-AP cannot initiate a new AHB transfer every clock cycle (unpa=
cked) because of the additional cycles required to serial scan in the ne=
w address or data value through a debug port. The AHB-AP supports two HT=
RANS transfer types, IDLE and NONSEQ. When a transfer is in progress, it=
is of type NONSEQ. When no transfer is in progress and the AHB-AP is st=
ill granted the bus then the transfer is of type IDLE. The only unpacked=
HBURST encoding supported is SINGLE. Packed 8-bit transfers or 16-bit t=
ransfers are treated as individual NONSEQ, SINGLE transfers at the AHB-L=
ite interface. This ensures that there are no issues with boundary wrapp=
ing, to avoid additional AHB-AP complexity.

Packed transfers

The DAP internal interface is a 32-bit data bus. 8-bit or 16-bit tran=
sfers can be formed on AHB according to the Size field in the Control/St=
atus Word Register at 0x00. The AddrInc field in the Control/Status Word=
Register enables optimized use of the DAP internal bus to reduce the nu=
mber of accesses from the tools to the DAP. It indicates if the entire d=
ata word is to be used to pack more than one transfer. Address increment=
ing is automatically enabled if packet transfers are initiated so that m=
ultiple transfers are carried out at the sequential addresses. The size =
of the address increment is based on the size of the transfer. See AHB-A=
P Control/Status Word Register, CSW, 0x00 for values of the AddrInc fiel=
d and AHB-AP Data Read/Write Register, DRW, 0x0C for Data Read/Write Reg=
ister bit values.

Examples of the transactions are:

For an unpacked 16-bit write to an address base of 0x2 (CSW[2:0=]
=3Db001, CSW[5:4]=3Db01), HWDATA[31:16] is written from bits [31:16] in=
the Data Read/Write Register.
For an unpacked 8-bit read to an address base of 0x1, (CSW[2:0=]
=3Db000, CSW[5:4]=3Db01), HRDATA[31:16] and HRDATA[7:0] are zeroed and =
HRDATA[15:8] contains read data.
For a packed byte write at a base address 0x2, (CSW[2:0]=3Db00=
0, CSW[5:4]=3Db10), four write transfers are initiated, the order of dat=
a being sent is:
    HWDATA[23:16], from DRW[23:16], to HADDR[31:0]=3D0x2 =

    HWDATA[31:24], from DRW[31:24], to HADDR[31:0]=3D0x3
    HWDATA[7:0], from DRW[7:0], to HADDR[31:0]=3D0x4
    HWDATA[15:8], from DRW[15:8], to HADDR[31:0]=3D0x5 =


For a packed halfword reading at a base address of 0x2, (CSW[2=]
:0=3Db001, CSW[5:4]=3Db10), two read transfers are initiated:
    HRDATA[31:16] is stored into DRW[31:16] from HADDR[31:0]=3D0x2
    HRDATA[15:0] is stored into DRW[15:0] from HADDR[31:0]=3D0x4

If the current transfer is aborted or the current transfer receives a=
n ERROR response, the AHB-AP does not complete the following packed tran=
sfers.

External and Memory Inter=
faces

I will place this chapter here because it is AHB-AP related and it ca=
n give good overview on the memory and peropherial access. The processor=
contains two bus interfaces:

external interface
memory interfaces

Note: The processor contains an internal PPB for accesses to the Nest=
ed Vectored Interrupt Controller (NVIC), Data Watchpoint (DW) unit, and =
BreakPoint Unit (BPU).

External interface

This is an AHB-Lite bus interface. Processor accesses and debug acces=
ses to external AHB peripherals are implemented over this bus. Because p=
rocessor AHB access to zero wait state slaves typically take two cycles =
longer than TCM accesses, instructions and data must be contained in TCM=
where possible. If on-chip FPGA memory is used for the processor, highe=
st performance is possible if this is TCM memory, rather than SRAM mappe=
d onto the AHB interface. =

Processor accesses and debug accesses share the external interfac=
e. Debug accesses take priority over processor accesses. Timing of proce=
ssor accesses might be changed by the presence of debug accesses. Giving=
highest priority to debug means that debug cannot be locked-out by a co=
ntinuously executing stream of core instructions. Because debug accesses=
tend to be infrequent, debug accesses do not have a major impact on pro=
cessor accesses.

Any vendor specific components can populate this bus. If an exter=
nal AHB peripheral incorrectly deadlocks the AHB bus, the debugger might=
not be able to halt or access the core registers. Contact your implemen=
tation team for FPGA probing tools to debug the system external to the c=
ore. Unaligned accesses to this bus are not supported. =

Write buffer

To prevent bus wait cycles from stalling the processor during data st=
ores, stores to the external interfaces go through a one-entry write buf=
fer. If the write buffer is full, subsequent accesses to the bus stall u=
ntil the write buffer has drained. DMB and DSB instructions wait for the=
write buffer to drain before completing.

Memory attributes

Below is the encoding for HPROT[3:0]:

HPROT[3]
HPROT[2]
HPROT[1]
HPROT[0]
Description
0 0 0 0 Invalid
0 0 0 1 Invalid
0 0 1 0 Instruction fetch
0 0 1 1 Data fetch
0 1 X X Invalid
1 X X X Invalid

=
Memory interfaces =3D

The processor has two memory interfaces:

ITCM
DTCM

See Memory interfaces in the ARM documentation for descriptions of th=
e ITCM and DTCM interface signals. The processor does not support wait s=
tates for the memory interfaces. Note: This section describes the ITCM i=
nterface. This description also applies to the DTCM interface. =

Byte-write sizeITCMBYTEWR value Size of write:

4'b1111: Word
4'b0011 or 4'b1100: Halfword
4'b0001, 4'b0010, 4'b0100 or 4'b1000: Byte

ITCM write signal timings:

<img alt=3D"" src=3D=
"/apps/mediawiki/stm32primer2swd/nfs/project/s/st/stm32primer2swd/6/69/I=
tcm_write_signal_timing.png" width=3D"262" height=3D"163" border=3D"0" /=

For writes, the write address, write data, and control signals are dr=
iven on the same cycle. The write enable signals ensure individual bytes=
within a word are written without corrupting the other bytes in the sam=
e word. For example, if ITCMBYTEWR[1] is asserted, bits ITCMBYTEWR[15:8]=
are written in to byte 1 of the word at address ITCMADRR.

ITCM read signal timings:

3D""=

Instruction and Data TCM sizes:

CFGITCMSZE
or
CFGDTCMSZE
TCM size
4'h0 0KB
4'h1 1KB
4'h2 2KB
4'h3 4KB
4'h4 8KB
4'h5 16KB
4'h6 32KB
4'h7 64KB
4'h8 128KB
4'h9 256KB
4'hA 512KB
4'hB 1MB

If you use other values than those that Table 10.3 shows, the effects=
are Unpredictable.

<h3= <span="" class="" mw-headline""=""> Common SWJ-DP Features</span="">

These common features for both JTAG-DP and SWD-DP mainly affect the w=
ay that a debugger is able to perform transactions with the DAP. The pro=
grammer's model of accessing the DAP and AHB-AP is different for both of=
these AP's and DP dependent (ie. different for JTAG and SWD). The commo=
n part is luckily the Error Detection mechanisms implemented with Sticky=
Flags and Error Responses and they obey to the following areas of funct=
ionality: Read and write errors, Overrun detection, Protocol errors (SW-=
DP only), Pushed compare and pushed verify operations.

When set to 1, a sticky flag remains set until it is explicitly c=
leared to 0. Even if the condition that caused the flag to be set no lon=
ger applies, the flag remains set until the debugger clears it. The meth=
od for clearing sticky flags is different for the SW-DP and JTAG-DP howe=
ver (see Programmer's Model).

Errors can be returned by the DAP itself, or might come from a de=
bug resource, for example, from a memory access made by a MEM-AP to a de=
bug register file of a processor that is powered down. In the debug port=
, errors are flagged by sticky flags in the DP Control/Status Register (=
CTRL/STAT). When an error is flagged, the current transaction is complet=
ed. Any further APACC (AP Access) transactions are discarded until the s=
ticky flag is cleared.

The debug port response to an error condition might be:

To signal an error response immediately. This happens with the =
SW-DP.
To immediately discard all transactions as complete. This happ=
ens with the JTAG=E2=80=91DP.

This means that a debugger must check the Control/Status Register aft=
er performing a series of APACC transactions, to check if an error occur=
red. If a sticky flag is set to 1, the debugger clears the flag to 0 and=
then, if necessary, initiates more APACC transactions to find the cause=
of the sticky flag condition. Because the flags are sticky, the debugge=
r only has to check the Control/Status Register periodically and does no=
t have to check the flags after every transaction. This reduces the over=
head of checking for errors.

=
Read and write errors

A read or write error might occur in the debug port, or come from the=
system being debugged as the result of an AHB-AP access in response to =
an access port request. In either case, when the error is detected the S=
ticky Error flag, STICKYERR, in the Control/Status Register is set to b1=
. A read/write error is also generated if the debugger makes an access p=
ort transaction request while the debug power domain is powered down.

Overrun detection

Debug ports support an overrun detection mode. This mode enables an e=
mulator on a high latency, high throughput connection to be sent blocks =
of commands. These must be sent with sufficient in-line delays to make o=
verrun errors unlikely. However, if an overrun error occurs, the debug p=
ort detects and flags the overrun errors, by setting a flag in the Contr=
ol/Status Register. In overrun detection mode, the debugger must check f=
or overrun errors after each sequence of APACC transactions, by checking=
the Sticky Overrun flag in the Control/Status Register. It is not neces=
sary for the emulator to react immediately to the overrun condition.

Overrun detection mode is enabled by setting the Overrun Detect b=
it, ORUNDETECT, in the DP Control/Status Register. When this bit is set,=
the only permitted response to any transaction is OK/FAULT on the JTAG-=
DP and OK on the SW-DP. In overrun detection mode, any other response, a=
t any point, is treated as an error and causes the Sticky Overrun flag, =
STICKYORUN, in the DP Control/Status Register to be set to b1. The Stick=
y Error flag, STICKYERR, is not set. The debugger must clear STICKYORUN =
to 0 to enable transactions to resume. The method of clearing the STICKY=
ORUN flag to 0 is different for a JTAG-DP and a SW-DP:

On a SW-DP, this bit is cleared by writing b1 to the ORUNERRCLR=
bit of the ABORT register.
On a JTAG-DP, this bit can be read normally. Writing 1 to this=
bit clears the bit to 0.

If a new transaction is attempted and results in an overrun error, be=
fore an earlier transaction has completed, the first transaction still c=
ompletes normally. Other sticky flags might be set on completion of the =
first transaction. If the overrun detection mode is disabled, by clearin=
g the ORUNDETECT flag, while STICKYORUN is set, the subsequent value of =
STICKYORUN is Unpredictable. To leave overrun detection mode, a debugger=
must:

check the value of the STICKYORUN bit in the Control/Status reg=
ister
clear the STICKYORUN bit, if it is set
clear the ORUNDETECT bit, to stop overrun detection mode.

Protocol errors, SW-DP only=

Although these errors can only be detected with the SW-DP, they are d=
escribed here because they are part of the sticky flags error handling m=
echanism. On the SWD interface, protocol errors can occur, for example b=
ecause of wire-level errors. These errors might be detected by the parit=
y checks on the data. On receiving a FAULT response from the SW-DP a deb=
ugger must read the CTRL/STAT register and check the sticky flag values.=
The WDATAERR flag is cleared by writing b1 to the WDERRCLR field of the=
Abort Register.

If the SW-DP detects a parity error in a message header, the debu=
g port does not respond to the message. The debugger must be aware of th=
is possibility. If it does not receive a response to a message, the debu=
gger must back off. It must then request a read of the IDCODE register, =
to ensure the debug port is responsive, before retrying the original acc=
ess. If the SW-DP detects a parity error in the data phase of a write tr=
ansaction, it sets the Sticky Write Data Error flag, WDATAERR, in the Co=
ntrol/Status (CTRL/STAT) Register. Subsequent accesses from the debugger=
, other than IDCODE, CTRL/STAT or ABORT, result in a FAULT response.

=
Pushed compare and pushed verify operations

The SW-DP and JTAG-DP debug ports support pushed operations, where th=
e value written as an access port transaction is used at the debug port =
level to compare against a target read. Pushed operations improve perfor=
mance where writes might be faster than reads. They are used as part of =
in-line tests, for example Flash ROM programming and monitor communicati=
on. Pushed operations are carried out as follows:

The debugger writes a value as an access port transaction.
The debug port performs a read from the access port.
The debug port compares the two values and updates the Sticky =
Compare flag, STICKYCMP, in the DP Control/Status register, based on the=
result of the comparison:
    pushed compare sets STICKYCMP to b1 if the values match
    pushed verify sets STICKYCMP to b1 if the values do not match.=
    =


Whenever the STICKYCMP bit is set, on detection of a valid com=
parison, any outstanding transaction repeats are cancelled.

The debug port includes a byte lane mask, so that the compare can be =
restricted to particular bytes in the word. This mask is set using the M=
ASKLANE bits in the Control/Status register. Pushed operations are enabl=
ed using the Transaction Mode bits, TRNMODE, in the DP Control/Status Re=
gister, see Control/Status Register, CTRL/STAT. Whenever an access port =
write transaction is performed with pushed compare or pushed verify acti=
ve, the actual access port access that results is a read operation, not =
a write. Performing an access port read transaction with pushed compare =
or pushed verify active causes Unpredictable behavior. On a SW-DP, perfo=
rming an access port read transaction with pushed compare or pushed veri=
fy active returns a value. This means the wire-level protocol remains co=
herent. However, the value returned is Unpredictable and the read has Un=
predictable side-effects. =

Considering pushed operations on a specific access port makes it =
easier to understand how these operations are implemented. On an AHB-AP,=
if you perform an access port write transaction to the Data Read/Write =
(DRW) Register, or to one of the Banked Data (BD0 to BD3) Registers, wit=
h either pushed compare or pushed verify active:

The debug port holds the data value from the access port write =
transaction in the pushed compare logic, see Figure 9.20.
The access port reads from the address indicated by the AP Tra=
nsfer Address Register (TAR), see AHB-AP Transfer Address Register, TAR,=
0x04.
The value returned by this read is compared with the value hel=
d in the pushed compare logic and the STICKYCMP bit is set depending on =
the result. The comparison is masked as required by the MASKLANE bits. F=
or more information see Control/Status Register, CTRL/STAT.

Example use of pushed verify operation on a AHB-AP </span=

You can use pushed verify to verify the contents of system memory.

Make sure that the AHB-AP Control/Status Word (CSW) is set up t=
o increment the Transfer Address Register after each access. See Control=
/Status Register, CTRL/STAT.
Write to the Transfer Address Register to indicate the start a=
ddress of the Debug Register region that is to be verified, see AHB-AP T=
ransfer Address Register, TAR, 0x04.
Write a series of expected values as access port transactions.=
On each write transaction, the debug port issues an access port read ac=
cess, compares the result against the value supplied in the access port =
write transaction, and sets the STICKYCMP bit in the CTRL/STAT Register =
if the values do not match. See Control/Status Register, CTRL/STAT.
    The TAR is incremented on each transaction.

In this way, the series of values supplied is compared against the co=
ntents of the access port locations and STICKYCMP set if they do not mat=
ch.

Example use of pushed find operation on a AHB-AP

You can use pushed find to search system memory for a particular word= . If you use pushed find with byte lane masking you can search for one o= r more bytes.

Make sure that the AHB-AP Control/Status Word (CSW) is set up t= o increment the TAR (Transfer Address Register) after each access. See C= ontrol/Status Register, CTRL/STAT.
Write to the Transfer Address Register (TAR) to indicate the s= tart address of the Debug Register region that is to be searched. See AH= B-AP Transfer Address Register, TAR, 0x04.
Write the value to be searched for as an AP write transaction.= The debug port repeatedly reads the location indicated by the TAR. On e= ach debug port read:
The value returned is compared with the value supplied in the = access port write transaction. If they match, the STICKYCMP flag is set.=
The TAR is incremented.
This continues until STICKYCMP is set, or ABORT is used to ter= minate the search.

You could also use pushed find without address incrementing to poll a= single location, for example to test for a flag being set on completion= of an operation.

Resources

ARM Document on SWD - Low Pin-Coun=
t Debug Interfaces for Multi-device Systems - short but good introductio=
n, recommended lecure!
Stm32Circle=

- homepage of the Raisonance's Stm32Primer devices, full of resources a=
nd example projects.
http://www.st.com/mcu/modules.php?name=3Dmcuklzzwxh:2253file=3Ddevicedocsklzzwxh:2254D= EV=3DSTM32F103VE" rel=3D"nofollow">STM32F103VE - ST website dedicate=
d to the CPU used in Stm32Primer2, full documentation and examples.
Stm32Primer2 JTAG/SWD sig=
nals - a PDF file containing pictures of Stm32Primer2 with marked JT=
AG and SWD signals.
Stm32Prim=
er JTAG signals - a PDF file containting pictures of Stm32Primer wit=
h marked JTAG signals.
OpenOCD - Open-Source u=
tility to (re)program target's memory and code debug.
UrJTAG - Open-Source util=
ity to perform low-level TAP operations on various hardware targets.
KT-LINK - inexpensive=
Polish design USB-SWJ dongle.
Future Technology Dev=
ice International - designer and manufacturer of FT2232 chip used wi=
dely for USB-JTAG access.
<a href=3D"http://www.ftdichip.com/Support/Documents/DataSheet=
s/ICs/DS_FT2232H.pdf" class=3D"external text" title=3D"http://www.ftdich=
ip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf" rel=3D"nofollow"=

    FT2232H Datasheet - Documentation of the HiSpeed USB (480MBit/s) IC=
    , also the programming referance manual and memory map for use with libf=
    tdi.

libftdi - gives multiplatform access to FT223=
2 devices family.
ARM SWD Website -=
Official ARM website with SWD description.
STM32 SWD Website - Official STM32 with SWD description.
ARM Inf=
o Center - every information you need to get about ARM product is th=
ere (including CoreSight on-chip trace and debug)