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.
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 8:1 division. Xilinx rule of thumb is 1/12 the clock speed.
Note: Many FTDI2232C based JTAG dongles are limited to 6MHz.
You can still debug the 'low power' situations - you just need to manually adjust the clock speed at every step. While painful and tedious, it 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.
To set the JTAG frequency use the command:
# Example: 1.234MHz jtag_khz 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 - artifically 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 intrest 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 jtag_reset 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...
First of all, the reason might be the USB power supply. Try using a self-powered hub instead of a direct connection to your computer. Secondly, the error code 4 corresponds to an FT_IO_ERROR, which means that the driver for the FTDI USB chip ran into some sort of error - this points us to a USB problem.
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: ST Microsystems 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.