From: ntfreak at B. <nt...@ma...> - 2009-01-08 12:46:59
|
Author: ntfreak Date: 2009-01-08 12:46:55 +0100 (Thu, 08 Jan 2009) New Revision: 1306 Modified: trunk/doc/openocd.texi Log: - a few more docs tweaks Modified: trunk/doc/openocd.texi =================================================================== --- trunk/doc/openocd.texi 2009-01-07 21:16:06 UTC (rev 1305) +++ trunk/doc/openocd.texi 2009-01-08 11:46:55 UTC (rev 1306) @@ -3184,24 +3184,29 @@ @* In digital circuit design it is often refered to as ``clock -syncronization'' the JTAG interface uses one clock (TCK or TCLK) +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 syncronized, they are ``asynchronous'' +clocks are not synchronised, they are ``asynchronous'' -In order for the two to work together they must syncronize. Otherwise +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. @b{1.} use a special circuit or -@b{2.} one clock must be some multile slower the the other. +work. There are 2 basic options. +@enumerate +@item +Use a special circuit. +@item +One clock must be some multiple slower the the other. +@end enumerate @b{Does this really matter?} For some chips and some situations, this -is a non-issue (ie: A 500mhz ARM926) but for others - for example some -ATMEL SAM7 and SAM9 chips start operation from reset at 32khz - +is a non-issue (ie: 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. +4kHz. -Imagine debugging that 500mhz arm926 hand held battery powered device -that ``deep sleeps'' at 32khz between every keystroke. It can be +Imagine debugging that 500MHz ARM926 hand held battery powered device +that ``deep sleeps'' at 32kHz between every keystroke. It can be painful. @b{Solution #1 - A special circuit} @@ -3213,14 +3218,14 @@ this problem. ARM has a good description of the problem described at this link: @url{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 working?''. +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. -@b{Solution #2 - Always works - but is slower} +@b{Solution #2 - Always works - but may be slower} Often this is a perfectly acceptable solution. @@ -3230,7 +3235,7 @@ based systems require an 8:1 division. @b{Xilinx Rule of thumb} is 1/12 the clock speed. -Note: Many FTDI2232C based JTAG dongles are limited to 6mhz. +Note: Many FTDI2232C based JTAG dongles are limited to 6MHz. You can still debug the 'lower power' situations - you just need to manually adjust the clock speed at every step. While painful and @@ -3244,7 +3249,7 @@ To set the JTAG frequency use the command: @example - # Example: 1.234mhz + # Example: 1.234MHz jtag_khz 1234 @end example @@ -3390,7 +3395,7 @@ Many newer devices have multiple JTAG taps. For example: ST Microsystems STM32 chips have two taps, a ``boundary scan tap'' and -``cortexM3'' tap. Example: The STM32 reference manual, Document ID: +``CortexM3'' tap. Example: The STM32 reference manual, Document ID: RM0008, Section 26.5, Figure 259, page 651/681, the ``TDI'' pin is connected to the Boundary Scan Tap, which then connects to the CortexM3 Tap, which then connects to the TDO pin. |