天鹅的故事Serial Wire Debug and the CoreSight TM Debug and Trace Architecture Eddie Ashfield, Ian Field, Peter Harrod*, Sean Houlihane, William Orme and
Sheldon Woodhou
火碱清洗油烟机ARM Ltd
110 Fulbourn Road, Cambridge, CB1 9NJ, UK
*peter.
Abstract
This paper describes a reduced pin-count debug interface, known as the Serial Wire Debug Interface, which has been developed as a 2-pin alternative to a traditional IEEE1149.1 compliant interface (JTAG). It provides the interface to debug and trace functionality on processor cores and System on Chip (SoC) devices, especially tho that conform to the CoreSight debug and trace architecture1. This 2-pin interface has benefits for devices in verely pin-limited packages (e.g. microcontrollers, such as the ARM Cortex-M3) or in designs where few package pins are available for the debug interface. It is also suitable as a debug and trace interface on cost-nsitive packaged products (e.g. m抑扬顿挫什么意思
obile phones), where the width of any external connectors must be kept to a minimum, while still providing performance as good as or better than traditional JTAG debug. The additional benefits that Serial Wire Debug provides, for all systems whether pin-limited or not, will be described in this paper: the apply not only for traditional software debug and trace but also for the debug and diagnosis of first silicon and complex hardware/software interactions.
Serial Wire Debug
When developing this alternative to JTAG as the interface for debug and trace, the opportunity was taken to analy where the requirements for debug and trace differed from tho for test and to design the protocol appropriately. In order to exploit the full power of this new interface standard, a packet-bad protocol has been developed; this is in contrast to the scan in, scan out protocol of JTAG.
The packet protocol is split into Header, Respon and Data, with the data being skipped if the interface is not ready.
Although the Serial Wire Debug protocol is not compatible directly with JTAG, it can be ud to connect to legacy JTAG devices, giving additional benefits (e.g. clock and power isolation) over a dir
ect, daisy-chained JTAG architecture. Furthermore, it is possible to connect a debug tool to both JTAG and Serial Wire Debug (SWD) devices over the same connector, by overlaying the SWD pins over existing JTAG pins and using a switching protocol to switch between JTAG and SWD.
SWD Benefits
In addition to the reduction in pin count on the interface, SWD has the following benefits:
•Performance: SWD is able to make u of the full clock cycle for data
transfer, from rising edge to rising edge of the Serial Wire clock. This is in
contrast to JTAG where data is driven on the falling edge and sampled on
the next rising edge, giving only one pha for the data to propagate. This
has the effect of enabling SWD to be run at up to twice the frequency of
JTAG in the same technology. Some efficiency is lost due to the packet-
bad nature of the SWD protocol but this is minimal. In addition, SWD
supports pushed operations – e below. Pushed operations can improve
performance, for instance in situations where writes might be faster than
reads.
•Error detection: SWD provides some protection against errors. It现在分词作状语
implements simple parity checking and can also check for overrun,
enabling blocks of commands to be nt on a high latency, high throughput发难
connection. SWD also gives confirmation that the physical connection is
OK, independent of system level operation.
•Tools. It is possible to build low cost, lower performance tools very
simply.
•Migration. Overlaying SWD over JTAG provides a migration path that
刀削面
doesn’t force urs to upgrade their test hardware.
•Interface to debug and trace infrastructure: SWD provides full access
to the debug and trace functionality on an SoC. It provides the
communication channel, giving full access, via the internal debug bus (the
DAP bus), to a CoreSight compliant system.
Pushed Operations
The SWD protocol is designed to make the u of pushed operations easy. For a pushed operation, the value written as an access port transaction is ud at the debug port level to compare against a target read. As an example, in order to verify a memory image after transfer to the target, a block of data would normally be read by the debugger and compared with the original. The process of performing a read may involve veral layers of handshaking between the read request being issued by the debugger, and valid data being returned through the debug interface. In a pushed operation, the two-way data flow becomes uni-directional. The reference values are transmitted to the target, which takes care of the read and compare. Once a block has been procesd, the status (pass or th
e address of a failure) can be retrieved with a single read operation.
SWD in a Bus-bad Debug and Trace Environment In Figure 1, the combined Serial Wire and JTAG Debug Port (SWJ-DP) is shown as the debug interface to a SOC.
Figure 1 - Serial Wire Debug as interface to a CoreSight Debug and Trace System Connecting through the DAP internal bus, SWJ-DP various slave devices:
• legacy JTAG-equipped cores via the JTAG Access Port (JTAG-AP)
• system memory via the AMBA High Performance Bus Access Port (AHB-AP) • bus-bad debug functionality on the debug APB bus via the AMBA Peripheral Bus Access Port (APB-AP).
• dedicated debug control devices (not shown in figure 1) An APB mux is provided so that the CPU in the system can also access debug components. SWD in a Bus-bad Debug and Trace Environment The move from using a JTAG scan interface to using a bus-bad approach for debug control and access is the most significant change introduced with SWD. This approach acknowledges that modern silicon designs frequently contain multiple IP blocks, sometimes pre-hardened, often using multiple clock and power domains. The debug infrastructure is more modular and has removed the requirement for a traditional JTAG scan chain on chip. Conquently the Serial Wire Debug interface no longer needs to support this style of debug architecture directly; instead it provides a narrow channel to a fully bus-bad debug and trace infrastructure. The bus bad approach enables register-bad access of debug configuration and status information: this provides a more consistent programmers’ model and eas
software development, as reflected in the ARM Debug Interface v5 for ARM Cortex cores. The same registers can also be accesd by the CPU itlf, giving additional flexibility. With the debug channel being less tightly coupled to the internal debug infrastructure, it becomes easier to optimi the physical protocol to match the external interface as has been done for SWD.
A bus-bad debug architecture can also provide efficient access to design for debug features, meaning that the same paradigm can be ud for both applications debug and silicon debug and diagnosis – and possibly also for repair in the future. As the debug infrastructure relies less on re-using the core functionality, difficult problems such as system lockup can be probed using the standard debug tools.
This style of debug architecture has additional benefits:
•It permits debug access while the CPU is running, possibly non-intrusively •Debug access is more abstract, less CPU-specific and more scalable
The DAP supports true power and clock isolation which is becoming esntial in most battery-powered applications, where it must be possible to power down individual blocks of logic or control the clocks independently, including when debugging.
Devices that are intended for curity applications might need special logic to enable unlocking of debug functionality, via the u of a Debug Authentication Module, which may be added to the DAP bus. Since the debug infrastructure is parated from the primary system function, it becomes simpler and less risky to mask debug access to individual parts of a system. Equally, it is now possible to access the debug infrastructure while all of the functional logic is powered down or held in ret. Making it easy to add vendor specific components such as a Debug Authentication Module helps vendors to protect their cure implementations.
DAP Access
浓溶液和稀溶液Before explaining the Serial Wire protocol, it is necessary to first cover the format of an access to the debug port. As can be en in Figure 1, the DAP bus has a single master (the DP – or Debug Port - which is the external facing part) and one or more slaves (the APs – or Access Ports) which are typically ud to interface to the various on-chip bus standards, or to provide dedicated debug features. Each transaction nt from the external debugger is addresd to a single one of the components (the DP or an AP).
AP Access
Each AP provides up to 64 registers of 32 bits, arranged in 16 banks of 4, including one register which identifies the particular AP type. In the ca of an AP which access a memory mapped part of the target system, a pair or registers are ud as address and data, each access to the Data Read/Write register resulting in an access to the target system being performed. The AP can be designed to optimi common functions (for example an address incrementor allows a write to n address using only n+1 writes to the AP), and can also provide detailed status and control of the system gment to which it is attached.
DP Access
Registers in the DP are ud to provide status and control of the external link (SWD), interface to power and ret controls and provide modifiers for access which are pasd to the APs. The DP also has registers to lect the current AP, and the register bank within that AP. The Control/Status register for SWJ-DP is shown in Figure 2 below.
Figure 2 – SW-DP CTL/STAT register The DP also provides functions which are designed to improve the performance of common debug operations. When the transfer count is t, the next AP access will be converted into a stream of access within the ASIC, independent of the clock frequency provided to the external interface. This can be ud in conjunction with the Transfer Mode and Bit Mask, which allow the DP to perform a ‘read and compare’ operation. The functions together can be ud for efficient block fill, memory verify, arch for match, arch for non-match – and at clo to system speed when the data value is constant.
Sticky Bits
Having described the structure of the DAP, it is now possible to introduce the sticky bits, which play an important part in the Serial Wire Debug protocol. Transfers from the debugger can fail – either due to data corruption, or a system being unable to perform a requested access – or a pushed comparison (using the comparator in the DP) may be triggered. When the conditions occur, it is necessary for the debugger to recogni the fact, and to be able to recover to the point where the event occurred. Rather than requiring the external debugger to check for success after every single access, the DP has a number of sticky bits which can be t, and once the bits are t, most new transfers will be accepted, but ignored. Although the debugger is not required to respond immediatel
y to the state of the sticky bits, the SWD protocol provides an indication of any of the ‘ERR’ or ‘STICKY’ bits from the status register in its handshake on every transfer. It is important to recogni that the status of the physical interface and the status of the debug port are isolated, if the link is broken then re-attached, the port will be found to have retained its state – even to the point of allowing a read which was in progress when the link was lost to be recovered without re-reading it from the system (since repeating that read is not always possible).
吃团圆饭作文
