In digital circuit design it is often refered to as “clock synchronisation” the JTAG interface uses one clock (TCK or TCLK) operating at some speed, your target is operating at another. The two clocks are not synchronised, they are “asynchronous”
In order for the two to work together they must be synchronised. Otherwise the two systems will get out of sync with each other and nothing will work. There are 2 basic options:
Does this really matter? For some chips and some situations, this is a non-issue (i.e.: A 500MHz ARM926) but for others - for example some Atmel SAM7 and SAM9 chips start operation from reset at 32kHz - program/enable the oscillators and eventually the main clock. It is in those critical times you must slow the JTAG clock to sometimes 1 to 4kHz.
Imagine debugging a 500MHz ARM926 hand held battery powered device that “deep sleeps” at 32kHz between every keystroke. It can be painful.
Solution #1 - A special circuit
In order to make use of this, your JTAG dongle must support the RTCK feature. Not all dongles support this - keep reading!
The RTCK signal often found in some ARM chips is used to help with this problem. ARM has a good description of the problem described at this link: http://www.arm.com/support/faqdev/4170.html [checked 28/nov/2008]. Link title: “How does the JTAG synchronisation logic work? / how does adaptive clocking work?”.
The nice thing about adaptive clocking is that “battery powered hand held device example” - the adaptiveness works perfectly all the time. One can set a break point or halt the system in the deep power down code, slow step out until the system speeds up.
Note that adaptive clocking may also need to work at the board level, when a board-level scan chain has multiple chips. Parallel clock voting schemes are good way to implement this, both within and between chips, and can easily be implemented with a CPLD. It's not difficult to have logic fan a module's input TCK signal out to each TAP in the scan chain, and then wait until each TAP's RTCK comes back with the right polarity before changing the output RTCK signal. Texas Instruments makes some clock voting logic available for free (with no support) in VHDL form; see http://tiexpressdsp.com/index.php/Adaptive_Clocking
Solution #2 - Always works - but may be slower
Often this is a perfectly acceptable solution.
In most simple terms: Often the JTAG clock 3 class="section">21.2 Internal low-level Commands
By low-level, the intent is a human would not directly use these commands.
Low-level commands are (should be) prefixed with "ocd_", e.g. ocd_flash_banks is the low level API upon which flash banks is implemented.
Read memory and return as a Tcl array for script processing
Convert a Tcl array to memory locations and write the values
Return information about the flash banks
OpenOCD commands can consist of two words, e.g. "flash banks". The startup.tcl "unknown" proc will translate this into a Tcl proc called "flash_banks".
Real Tcl has ::tcl_platform(), and platform::identify, and many other variables. JimTCL, as implemented in OpenOCD creates $HostOS which holds one of the following values:
Note: 'winxx' was choosen because today (March-2009) no distinction is made between Win32 and Win64.
Note: We should add support for a variable like Tcl variabletcl_platform(platform), it should be calledjim_platform(because it is jim, not real tcl).