ARM JTAG 信号 RTCK 应该如何处理？

用户在调试内嵌可综合内核的 CPU 如 ARM7TDMI-S 时，需要通过打开仿真器的自适应时钟功能。

此时，ARM仿真器根据 RTCK 时钟信号的频率，产生可用于 CPU 内核当前时钟主频的最快的 TCK 时钟。

即 ARM 内核的时钟主频变化，引起 RTCK 变化， 仿真器根据 RTCK 的变化，产生合适的最快的 TCK 时钟。      

如果没有有效的 RTCK 信号，用户不能使用自适应时钟功能。这种情况下，用户可以设置 TCK 为比较低的频率。

当用户确认 CPU 运行在比较高的频率的情况下，可以手工调整 TCK 到比较高的频率。

如果用户不使用自适应时钟功能时， JTAG 插座上的 RTCK 可以直接拉低。 

S3C2440中JTAG 20管脚调试接口中RTCK管脚功能

数据手册中表明：RTCK－返回的测试时钟输出。

JTAG 端口的额外信号。当处理器频率变化时帮助调试器保持同步。

带内部上拉的双向口。当RESET 为低时，RTCK 上的低电平会使

P1.26~P1.31 在复位后作为调试端口。但是RTCK管脚可以不接。

RTCK from target to adapter, Some chips are entirely controlled by a single clock,

where TDO changes are possibly asynchronous to TCK.

The re-synchronized RTCK can be used by the JTAG adapter to deal with asynchronous TDO signals.

The adapter will not change TCK until it gets back the RTCK edge from a previous TCK change.

This results in a second advantage, because the adapter can dynamically adapt the JTAG clock rate to the target's ability.

If, for example, the target is switched to sleep mode and running on a reduced main clock,

it may not be able to handle full speed JTAG clocking.

The CoreSight DAP (SWJ-DP or JTAG-DP) has no need for an RTCK.

RTCK is not a standard IEEE 1149 JTAG signal.

It was created to allow the use of synchronized TAP controllers in ARM9 and ARM11 class of cores,

where the JTAG inputs (TMS and TDI) have to cross an asynchronous boundary into the processor clock domain.

RTCK has the effect of controlling the TCK from the emulator box (RVI, Multi-ICE, etc)

to ensure correct JTAG-like behaviour across that clock domain boundary.

The CoreSight implementation of the DAP uses a fully asynchronous TAP controller

which does not require any local synchronization (hence no need for RTCK).

It manages the asynchronous relationship between JTAG (TCK) and the DAP bus (DAPCLK/PCLKDBG) internally to the JTAG-DP or SWJ-DP.

TCK can be run at any frequency up to the maximum operating frequency of

your ICE unit + interconnect (wires, connectors, board traces) + TAP logic in the TCK domain.

TCK frequency is not dependent upon the core clock frequency in a CoreSight system.

Adaptive Clocking

Description

The ARM Ltd. ARM 9 and ARM 11 implementation of JTAG is not compliant to the IEEE1149.1 specification.

This is because the user must make sure the next TCK edge to the device is not provided before the device generates a RTCK edge.

This function of the Emulator is called Adaptive Clocking.

Most ARM emulators support adaptive clocking which:

• Ensures that TCK is running at the highest possible frequency no matter what the ARM clock is.
• Automatically scales TCK as the ARM clock scales.
• Ensures that chip is not presented with another TCK edge until an edge is detected on RTCK.
• TCK clock generation is essentially a NOT gate on RTCK.
• TCK is not a free-running clock.
• TCK is nearly completely out of phase with RTCK.

Summary

• Lack of Adaptive Clocking Makes debuggers (ex: CCS) look unstable.
• The key problem is a violation in the specification.
  Attempts to fix in the chip have been attempted, but have not been consistently successful.

• Use of Adaptive clocking will result in:
  • Higher performance (downloads, etc.) than without Adaptive clocking.
  • Greater Stability

Solutions

• Adaptive clocking emulator
  • This solution is the most reliable and best performing.
  • XDS560 Revision D and later products have adaptive clocking capability. XDS560 Emulators
  • 3rd party emulators from vendors such as Lauterbach, Green Hills, etc. may have adaptive clocking.
    Please contact your vendor to check support for this capability.
    
    
• Reduced TCK speed
  • Most processors made after 2007 have some integrated support for adaptive clocking.
    Slowing TCK to the legacy 10.368 MHz speed is generally sufficient to use an older XDS510 emulator with these devices.
  • If the 10.368 MHz speed still does not allow for a stable connection you can further slow it down, perhaps as low as 1 MHz, for better stability.
    
    
• Adaptive clocking Adapter
  • This solution is only recommended for older devices that did not integrate any adaptive clocking support into the processor
    (e.g. OMAP5910/12, DM6446, etc.). It is not recommended to use this adapter with newer devices that already have integrated adaptive clocking support.
    For example, using one of these adapters with DM6467 will actually make the connection less stable.
  • Adaptive Clocking Adapters are available from TI: 
    Adaptive Clocking Adapters Note that you do not need an adaptive clocking adapter
    if your emulator supports adaptive clocking (ex: XDS560 Rev D).
    
    
• For multi-device Scan Chains, see below.
  
  
• For more details and configurations that include both devices that require adaptive clocking
  and devices that don't require adaptive clocking on a single scan chain see XDS Target Connection Guide.

Multi-Device Scan Chain Connections with Devices that require Adaptive Clocking

• For cards which have multiple devices (ex: multiple ARM9 devices) that require adaptive clocking on a single scan chain, attention must be paid to ensure that the connection is stable and able to operate at a reasonable speed.
• As these devices require a RTCK signal, there are two connection methods which can be used. They differ mainly in performance and complexity.

Series Topology Connection

• Connecting devices with RTCK in a serial cascade fashion means the RTCK
  from one device is synchronized with the TCK of the next device in the cascade,
  and so on until the last RTCK is returned to the emulator.

• Series Topology can only be used when:

1. a slow enough TCK freq to guarantee RTCK occurs before the next TCK edge, or
2. a debugger which supports adaptive clocking (see Solutions above) is used

Parallel Topology Connection

• In order to operate in parallel, external logic must be used to co-ordinate the TCK and RTCK between the devices. *This is shown below

• This external logic must be designed to allow multiple devices with