Next: Tcl Crash Course, Previous: Tcl Scripting API, Up: Top [Contents][Index]
In digital circuit design it is often referred to as “clock synchronisation” the JTAG interface uses one clock (TCK or TCLK) operating at some speed, your CPU 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 well enough to work; JTAG can’t go ten times faster than the CPU, for example. There are 2 basic options:
Does this really matter? For some chips and some situations, this is a non-issue, like a 500MHz ARM926 with a 5 MHz JTAG link; the CPU has no difficulty keeping up with JTAG. Startup sequences are often problematic though, as are other situations where the CPU clock rate changes (perhaps to save power).
For example, Atmel AT91SAM chips start operation from reset with a 32kHz system clock. Boot firmware may activate the main oscillator and PLL before switching to a faster clock (perhaps that 500 MHz ARM926 scenario). If you’re using JTAG to debug that startup sequence, you must slow the JTAG clock to sometimes 1 to 4kHz. After startup completes, JTAG can use a faster clock.
Consider also debugging a 500MHz ARM926 hand held battery powered device that enters a low power “deep sleep” mode, at 32kHz CPU clock, between keystrokes unless it has work to do. When would that 5 MHz JTAG clock be usable?
Solution #1 - A special circuit
In order to make use of this, your CPU, board, and JTAG adapter must all support the RTCK feature. Not all of them support this; keep reading!
The RTCK ("Return TCK") signal 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 must be 1/10 to 1/12 of the target clock speed. But what that “magic division” is varies depending on the chips on your board. ARM rule of thumb Most ARM based systems require an 6:1 division; ARM11 cores use an 8:1 division. Xilinx rule of thumb is 1/12 the clock speed.
Note: most full speed FT2232 based JTAG adapters are limited to a maximum of 6MHz. The ones using USB high speed chips (FT2232H) often support faster clock rates (and adaptive clocking).
You can still debug the ’low power’ situations - you just need to either use a fixed and very slow JTAG clock rate ... or else manually adjust the clock speed at every step. (Adjusting is painful and tedious, and is not always practical.)
It is however easy to “code your way around it” - i.e.: Cheat a little, have a special debug mode in your application that does a “high power sleep”. If you are careful - 98% of your problems can be debugged this way.
Note that on ARM you may need to avoid using the wait for interrupt
operation in your idle loops even if you don’t otherwise change the CPU
clock rate.
That operation gates the CPU clock, and thus the JTAG clock; which
prevents JTAG access. One consequence is not being able to halt
cores which are executing that wait for interrupt operation.
To set the JTAG frequency use the command:
# Example: 1.234MHz adapter speed 1234
OpenOCD uses Tcl and a backslash is an escape char. Use { and } around Windows filenames.
> echo \a
> echo {\a}
\a
> echo "\a"
>
Make sure you have Cygwin installed, or at least a version of OpenOCD that claims to come with all the necessary DLLs. When using Cygwin, try launching OpenOCD from the Cygwin shell.
GDB issues software breakpoints when a normal breakpoint is requested, or to implement source-line single-stepping. On ARMv4T systems, like ARM7TDMI, ARM720T or ARM920T, software breakpoints consume one of the two available hardware breakpoints.
Make sure the core frequency specified in the flash lpc2000 line matches the clock at the time you’re programming the flash. If you’ve specified the crystal’s frequency, make sure the PLL is disabled. If you’ve specified the full core speed (e.g. 60MHz), make sure the PLL is enabled.
Make sure your PC’s parallel port operates in EPP mode. You might have to try several settings in your PC BIOS (ECP, EPP, and different versions of those).
The errors are non-fatal, and are the result of GDB trying to trace stack frames beyond the last valid frame. It might be possible to prevent this by setting up a proper "initial" stack frame, if you happen to know what exactly has to be done, feel free to add this here.
Simple: In your startup code - push 8 registers of zeros onto the stack before calling main(). What GDB is doing is “climbing” the run time stack by reading various values on the stack using the standard call frame for the target. GDB keeps going - until one of 2 things happen #1 an invalid frame is found, or #2 some huge number of stackframes have been processed. By pushing zeros on the stack, GDB gracefully stops.
Debugging Interrupt Service Routines - In your ISR before you call your C code, do the same - artificially push some zeros onto the stack, remember to pop them off when the ISR is done.
Also note: If you have a multi-threaded operating system, they often do not in the interest of saving memory waste these few bytes. Painful...
This warning doesn’t indicate any serious problem, as long as you don’t want to debug your core right out of reset. Your .cfg file specified reset_config trst_and_srst srst_pulls_trst to tell OpenOCD that either your board, your debugger or your target uC (e.g. LPC2000) can’t assert the two reset signals independently. With this setup, it’s not possible to halt the core right out of reset, everything else should work fine.
No, this is not a stability issue concerning OpenOCD. Most users have solved this issue by simply using a self-powered USB hub, which they connect their Amontec JTAGkey to. Apparently, some computers do not provide a USB power supply stable enough for the Amontec JTAGkey to be operated.
Laptops running on battery have this problem too...
Error code 10054 corresponds to WSAECONNRESET, which means that the debugger (GDB) has closed the connection to OpenOCD. This might be a GDB issue.
No. The clock frequency specified here must be given as an integral number. However, this clock frequency is used by the In-Application-Programming (IAP) routines of the LPC2000 family only, which seems to be very tolerant concerning the given clock frequency, so a slight difference between the specified clock frequency and the actual clock frequency will not cause any trouble.
Well, yes and no. Commands can be given in arbitrary order, yet the devices listed for the JTAG scan chain must be given in the right order (jtag newdevice), with the device closest to the TDO-Pin being listed first. In general, whenever objects of the same type exist which require an index number, then these objects must be given in the right order (jtag newtap, targets and flash banks - a target references a jtag newtap and a flash bank references a target).
You can use the “scan_chain” command to verify and display the tap order.
Also, some commands can’t execute until after init has been
processed. Such commands include nand probe and everything
else that needs to write to controller registers, perhaps for setting
up DRAM and loading it with code.
Yes; whenever you have more than one, you must declare them in the same order used by the hardware.
Many newer devices have multiple JTAG TAPs. For example: STMicroelectronics STM32 chips have two TAPs, a “boundary scan TAP” and “Cortex-M3” 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 Cortex-M3 TAP, which then connects to the TDO pin.
Thus, the proper order for the STM32 chip is: (1) The Cortex-M3, then (2) The boundary scan TAP. If your board includes an additional JTAG chip in the scan chain (for example a Xilinx CPLD or FPGA) you could place it before or after the STM32 chip in the chain. For example:
The “jtag device” commands would thus be in the order shown below. Note:
TODO.
Next: Tcl Crash Course, Previous: Tcl Scripting API, Up: Top [Contents][Index]