Adaptive Clocking

From Texas Instruments Wiki
Jump to: navigation, search

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

Series.jpg

  • 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

Parallel.jpg

  • This external logic must be designed to allow multiple devices with RTCK to be operated in parallel, rather than a serial fashion. This method of operation provides higher performance than the series topology connection. In order to operate in parallel, logic provides a TCK edge to each device simultaneously. It then waits until every device has responded with an RTCK signal of the same polarity. Once this has occurred, the opposite edge of TCK can be applied to the devices. This repeats indefinitely.
  • Click here for Board level Clocking Voting Logic. Note that this Boad level clocking voting logic is offered as-is, without support.

FAQ

Q: How to enable adaptive clocking on CCS?

You need to access the Advanced options tab on the target configuration editor. Check this topic on how to access it.

Also, the short video clip below it shows how to access this tab and also experiment with the JTAG clock speeds.

Q: What header should I use?

Q: What about ARM Cortex M3, R4, or A8 devices? Do these have RTCK?

  • A: The ARM Cortex M4, R4, or A8 cores do not have RTCK, so are not affected. However, some devices which feature these cores may also have an ARM9 which does require RTCK. In those cases, if the ARM9/11 core is debugged, then RTCK must be taken into account. For example, if you have 2 devices, each with a Cortex A8/ARM9, and you do not plan to debug the ARM9, you could hook the emulator TCK to TCK input of both devices and pick the RTCK from either one to emulator RTCK.

Q: I have two TMS320DM355 that I want to put on a card.

  • A: What is the recommended method? Please see the above section "Multi-Device Scan Chain Connections with Devices that require Adaptive Clocking".

Q: How can I turn on adaptive clocking on the XDS560?

Q: How can I turn on adaptive clocking on the XDS100?

Q: My OMAPL-138 / ARM926 based device is not reliably connecting...

  • A: Turn on adaptive clocking mode and select falling-edge JTAG timing. These are settings for the emulator in the target configuration dialog.

Q: How can I test just the ARM926 scan path?

  • A: Use "dbgjtag -f <CCS Path>\ccboard0.dat -S pathlength -R routelist,devices=<arm9_0>" where <CCS Path> is your CCS installation path and directory for the CCBoard0.dat file and <arm9_0> is the name of the ICEpick scan path for the ARM926. This will have ICEpick add just the ARM9 to the path and test it. It should return "JTAG IR instruction path length is 28 bits", "JTAG DR bypass path-length is 5 bits". Take note of any errors reported by the tool that conflicts with that message.

Related