Serial Wire Debug (SWD) Interface--PSOC5

PSoC 5 supports programming through the serial Wire debug (SWD) interface.

There is signals in SWD interface:data signal (swdio) and a clock for data signal (SWDCK).

The host programmer always drives the clock line, whereas either the programmer or the PSoC 5 device drives the data line.

The timing diagram for the SWD protocol are given in programming specifications chapter on page 29.

Host Programmer and PSoC 5 device communicate in packet format through the SWD interface.

Write packet refers to the SWD packet transaction in which the host writes data to PSoC 5.

Read packet refers to the SWD packet transaction in which the host reads data from PSoC 5.

The format of the write packet and read packet is illustrated in Figure 2-4 and figure 2-5,

respectively Figure 2-4. SWD "Write Packet" Timing Diagram

A.) Host Write Operation:

Host sends data on the Swdio line on falling edge of SWDCK and

PSoC 5 reads that data on the next Swdck rising edge
(for example, 8-bit header data, Write data (wdata[31:0]), Dummy phase (3 ' b000))

B.) Host Read Operation:

PSoC 5 sends data on the Swdio line on the rising edge of SWDCK

And the host should read that data on the next swdck falling Edge
(Ex:ack data (ack[2:0]) Z Z

C.) The host should not drive the Swdio line during TrN phase.

During First TrN phase (½cycle duration) of SWD packet,

PSoC 5 starts driving the ACK data on the Swdio line on the rising edge of SWDCK.

The host should read the data on the subsequent falling edge of SWDCK.

The second TrN phase is 1.5 swdck clock cycles.

Both PSoC 5 and the Host won't drive the line during the entire second TrN phase (indicated as ' Z ').

Host should start sending the Write data (Wdata) on the next falling edge of swdck after second TrN phase.

D.) "DUMMY" phase is three SWD clock cycles with Swdio line low.

This DUMMY phase isn't part of the SWD protocol.

The three extra clocks with Swdio low is required for the Test Controller in PSoC 5
The read/write operation when the SWDCK clock was not free-running.

For a reliable implementation, the include three IDLE clock cycles with the Swdio low for each packet.
According to the SWD protocol, the host can generate any number of SWD clock cycles between and packets with Swdio low .

A.) Host Write Operation:

Host sends data on the Swdio line on falling edge of SWDCK
and PSoC 5 reads that data on the next SWDCK rising edge
(for example, 8-bit header data, dummy phase (3 ' b000))

B.) Host Read Operation:

PSoC 5 sends data on the Swdio line on rising edge of SWDCK
And the host should read that data on the next Swdck falling edge
(for example, ACK data (ack[2:0], Read data (rdata[31:0]))

C.) The host should not drive the Swdio line during TrN phase.

During First TrN phase (½cycle duration) of SWD packet,
PSoC 5 starts driving the ACK data on the Swdio line on the rising edge of SWDCK.
The host should read the data on the subsequent falling edge of SWDCK.

The second TrN phase is 1.5 swdck clock cycles. jlink use 0.5 swdck clock cycles and then enter DUMMY phase.  
Both PSoC 5 and the host won't drive the line during the entire second TrN phase (indicated as ' Z ').

Host should start sending the Dummy phase (3 ' b000) on the next falling edge of swdck after second TrN phase.

D.) "DUMMY" phase is three SWD clock cycles with Swdio line low.

This phase isn't part of the SWD protocol.
The three extra clocks with Swdio low is required for the Test Controller in PSoC 5
The read/write operation when the SWDCK clock was not free-running.

For a reliable implementation, the include three IDLE clock cycles with the Swdio low for each packet.
According to the SWD protocol, the host can generate any number of SWD clock cycles between and packets with Swdio low .

A Complete data transfer requires-clocks (not including, optional three dummy clock cycles in Figure 2-4 and figure 2-5).

Each data transfer consists of three phases:

? Packet request–external host programmer issues a request to the PSoC 5 device.

? Acknowledge Response–psoc 5 sends a acknowledgement to the host.

? Data–data is valid if a packet request is followed by a valid (OK) acknowledge response.

The data transfer is either:

? PSoC 5 to host, following a read request–rdata

? Host to PSoC 5, following a write Request–wdata

In Figure 2-4 and figure 2-5, the following sequence occurs:

1. The start bit initiates a transfer; It's always logic ' 1 '.

2. The APNDP bit determines whether the transfer is an AP access, ' 1 ', or a DP access, ' 0 '.

3. The next bit is RnW, which are ' 1 ' for a read from the PSoC 5 device or ' 0 ' for a write to the PSoC 5 device.

4. The ADDR bits (A[3:2]) is register select bits for the access port or debug port.
See Table 2-2 for address bit definitions.

5. The parity bit has the parity of APNDP, RnW, and ADDR. This was an even parity bit.
If the number of logical 1s in these bits was odd, then parity must was ' 1 ', otherwise it is ' 0 '.
If the parity bit is not correct, the header was ignored by the target device; There is no ACK response.
For the host implementation, the programming operation should is stopped and tried again by doing a device reset.

6. The stop bit is always logic ' 0 '.

7. The park bit is always logic ' 1 ' and should are driven high by the host.

8. The ACK bits is the device-to-host response. Possible values is shown in Table 2-1.
Note that the ACK in the current SWD transfer reflects the status of the previous transfer.
OK ACK means the previous packet is successful.
WAIT response indicates that the previous packet transaction are not yet complete.
For a Fault operation, the programming operation should is aborted immediately.

• A. For a WAIT-response, if it is a read transaction,The host should ignore the data read in the data phase.
  PSoC 5 does not drive the line and the host must not check the parity bit.
  
  B. For a WAIT response, if it was a write transaction, the data phase is ignored by the PSoC 5 device.
  But the host must still send the data to is written from an implementation standpoint.
  The parity data corresponding to the data should also is sent by the host.
  
  C. For a WAIT response, it means the PSoC 5 device is processing the previous transaction.
  The host can try for a maximum of four continuous WAIT responsesTo see if a OK response is received,
  Failing which, it can abort the programming operation and try again.
  
  d. For a FAULT response, the programming operation should is aborted and retried by doing a device reset.

9. The data phase includes a parity bit (even parity, similar to the packet request phase).

• A. For a read data packet, if the host detects a parity error,
  Then it must abort the programming operation and restart.
  
  
• B. For a write data packet, if the PSoC 5 detects a parity error in the data packet sent by the host,
  It generates a FAULT ACK response in the next packet.

Turnaround (TrN) phase:

According to the SWD protocol, the TrN phase are used both by the host and the PSoC 5 device
To change the drive modes on their respective Swdio line.
There is TrN phases in each SWD packet.

During the first TrN phase after packet request, PSoC 5 drives the ACK data in the Swdio line on the rising edge of SWDCK In TrN phase.
This ensures, the host can read the ACK data on the next falling edge.
Thus, the first TrN cycle is a-half cycle duration, as shown in figure 2-4 and Figure 2-5.

The location of the second TrN phase are different for read and write packets.
The second TrN phase of the SWD packet is one-and-a-half cycle long.
Neither the host nor PSoC 5 should drive Swdio line during both the TrN phases as indicated by ' Z ' on Figure 2-4 and Figur E 2-5.

The address, ACK, and read and write data is always transmitted least significant bit (LSB) first.

At the end of each SWD packet in Figure 2-4 and figure 2-5, there is a "DUMMY" phase,
Which is three SWD clock cycles with Swdio line held low.
This DUMMY phase isn't part of the SWD protocol.

The three extra clocks with Swdio low is required for the Test Controller in PSoC 5
The read/write operation when the SWDCK clock was not free-running.

For a reliable implementation, the include three IDLE clock cycles with the Swdio low for each packet.

According to the SWD protocol, the host can generate any number of SWD clock cycles
Between packets with Swdio low.

Note the SWD interface can be reset anytime during programming by clocking Wuyi or more cycles with Swdio high.
To return to the idle state, Swdio must is clocked low for three or more cycles. < ADIV5 said, at least 8 cycles >

The host programmer can begin a new SWD packet transaction from the idle state.

Register Access Using SWD Interface

To access the registers using the SWD interface, in the 8-bit transfer request packet,

Set the APNDP bit and select the corresponding ADDR bits, as shown in Table 2-2.

Table 2-3 shows the 8-bit transfer request packet to access the DP and AP registers for read or write operation.

The 8-bit transfer request data in Table 2-3 is transmitted least significant bit first.

The ' Start ' bit is the least significant bit (LSb) and the ' Park ' bit are the most significant bit (MSb) in Table 2-3.

Use Table 2-3 and vectors given in SWD vectors for programming chapter on page implement PSoC 5 programming.

Table 2-3. SWD Transfer Request Data Packet for Test Controller Dpacc and Apacc Register Access

Switching to SWD Interface

PSoC 5 supports programming only through the SWD interface.

IT does not support programming through the Joint Test Action Group (JTAG) interface.

But it's necessary to send a jtag-to-swd switching sequence on Swdio, SWDCK lines to program through the SWD interface.

This switching was required in "Step 2:configure Target Device" on page 21.

The PSoC 5 architecture warrants the switching sequence to SWD interface due to the following reason.

After acquiring the PSoC 5 device, access to the Debug and Access Port (DAP) must is done

By setting, the ' D_TST_ACC ' bit in the Test Controller register ' TC. TST_CR4 '.

The Test Controller automatically switches from SWD to JTAG the first time ' D_TST_ACC ' bit

is set, because the DAP always resets to JTAG the first time.

JTAG to SWD switching must is done once during programming as a result of this condition.

But the switching from SWD to JTAG does not happen for subsequent setting of the ' D_TST_ACC ' bit while programming.

This is because the DAP remembers it last configuration from the (until, the device is reset by Xres).

JTAG to SWD switching

To switch DAP from JTAG to SWD operation, the sequence is as follows:

1. Send Wuyi or more swdck cycles with Swdio high.

This ensures, the current interface are in the IT reset state.

The JTAG interface only detects the 16-bit jtagto-swd sequence starting from the Test-logic-reset state.

2. Send the 16-bit jtag-to-swd select sequence on Swdio.

The 16-bit jtag-to-swd Select sequence is 0b0111_1001_1110_0111, most-significant bit (MSB) first.

This can is represented as either:

A. 0x79e7 transmitted most-significant bit (MSB) first

B. 0xe79e transmitted least-significant bit (LSB) first.

3. Send Wuyi or more swdck cycles with Swdio high.

This ensures, if DAP are already in SWD operation before sending the select sequence,

The SWD interface enters line reset state.

4. Send three or more swdck cycles with Swdio low.

This ensures, the SWD line was in the idle state before starting a new SWD packet transaction.

5. Send the DPACC idcode read SWD read packet as given in Table 2-3.

There is no need to process the device ID returned by the PSoC 5 device for this read packet.

Ignore the Device ID returned by PSoC 5 in this step.

Serial Wire Debug (SWD) Interface--PSOC5