blob: 7951a58a7c409f8af3da7206e5c77a799524d537 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
-------------------------------------------------------------------------------
SWD
-------------------------------------------------------------------------------
This is a set of example captures of the ARM SWD (version 1) protocol.
Details:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0031c/index.html
(registration required)
Logic analyzer setup
--------------------
Probe SWD
---------------
0 swclk
1 swdio
Data
----
Different SWD sessions showing different types of behaviour:
* ftdi_openocd/
Using an FTDI-based adapter via "openocd ftdi resistor hack". OpenOCD
0.9.0 development version. Device under test is a Nordic nRF51822.
Command line:
$ openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg \
-f interface/ftdi/swd-resistor-hack.cfg \
-f target/nrf51.cfg
** ftdi_openocd/init.sr
Initialising device, IDCODE read, etc.
OpenOCD args: -c "init; exit"
** ftdi_openocd/init_noreply.sr
Initialising when no device is connected (i.e. all responses are 1s.)
OpenOCD args: -c "init; exit"
** ftdi_openocd/init_write_0xabbabeeb.sr
Initialise, write 20 bytes of 0xabbabeeb at start of RAM.
OpenOCD args: -c "init; halt; mww 0x20000000 0xabbabeeb 20; exit"
** ftdi_openocd/init_wait_fault.sr
Initialise, attempt to write flash fill of 0xabbabeeb via async loader.
This causes SWD WAIT states in "overrun" mode, so the first WAIT causes all
subsequent responses to be FAULT until OpenOCD clears the sticky error bit.
For this capture OpenOCD was patched with this change (known to induce
SWD WAITs): http://openocd.zylin.com/#/c/2204/
OpenOCD args: -c "init; reset halt; flash fillw 0 0xabbabeeb 2048; exit"
|
