## 22 FAQ ¶

2. RTCK, also known as: Adaptive Clocking - What is it?

   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:

   1. Use a special "adaptive clocking" circuit to change the JTAG clock rate to match what the CPU currently supports.
   2. The JTAG clock must be fixed at some speed that’s enough slower than the CPU clock that all TMS and TDI transitions can be detected.

   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

3. Win32 Pathnames Why don’t backslashes work in Windows paths?

   OpenOCD uses Tcl and a backslash is an escape char. Use { and } around Windows filenames.

       > echo \a

       > echo {\a}
       \a
       > echo "\a"

       >

4. Missing: cygwin1.dll OpenOCD complains about a missing cygwin1.dll.

   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.

5. Breakpoint Issue I’m trying to set a breakpoint using GDB (or a front-end like Insight or Eclipse), but OpenOCD complains that "Info: arm7_9_common.c:213 arm7_9_add_breakpoint(): sw breakpoint requested, but software breakpoints not enabled".

   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.

6. LPC2000 Flash When erasing or writing LPC2000 on-chip flash, the operation fails at random.

   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.

7. Amontec Chameleon When debugging using an Amontec Chameleon in its JTAG Accelerator configuration, I keep getting "Error: amt_jtagaccel.c:184 amt_wait_scan_busy(): amt_jtagaccel timed out while waiting for end of scan, rtck was disabled".

   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).

8. Data Aborts When debugging with OpenOCD and GDB (plain GDB, Insight, or Eclipse), I get lots of "Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read caused data abort".

   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...

9. JTAG Reset Config I get the following message in the OpenOCD console (or log file): "Warning: arm7_9_common.c:679 arm7_9_assert_reset(): srst resets test logic, too".

   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.

10. USB Power When using OpenOCD in conjunction with Amontec JTAGkey and the Yagarto toolchain (Eclipse, arm-elf-gcc, arm-elf-gdb), the debugging seems to be unstable. When single-stepping over large blocks of code, GDB and OpenOCD quit with an error message. Is there a stability issue with OpenOCD?

    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...

11. GDB Disconnects When using the Amontec JTAGkey, sometimes OpenOCD crashes with the following error message: "Error: gdb_server.c:101 gdb_get_char(): read: 10054". What does that mean and what might be the reason for this?

    Error code 10054 corresponds to WSAECONNRESET, which means that the debugger (GDB) has closed the connection to OpenOCD. This might be a GDB issue.

12. LPC2000 Flash In the configuration file in the section where flash device configurations are described, there is a parameter for specifying the clock frequency for LPC2000 internal flash devices (e.g. `flash bank $_FLASHNAME lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14746 calc_checksum`), which must be specified in kilohertz. However, I do have a quartz crystal of a frequency that contains fractions of kilohertz (e.g. 14,745,600 Hz, i.e. 14,745.600 kHz). Is it possible to specify real numbers for the clock frequency?

    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.

13. Command Order Do I have to keep a specific order for the commands in the configuration file?

    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.

14. JTAG TAP Order Do I have to declare the TAPS in some particular order?

    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:

    - OpenOCD_TDI(output) -> STM32 TDI Pin (BS Input)
    - STM32 BS TDO (output) -> STM32 Cortex-M3 TDI (input)
    - STM32 Cortex-M3 TDO (output) -> SM32 TDO Pin
    - STM32 TDO Pin (output) -> Xilinx TDI Pin (input)
    - Xilinx TDO Pin -> OpenOCD TDO (input)

    The “jtag device” commands would thus be in the order shown below. Note:

    - jtag newtap Xilinx tap -irlen ...
    - jtag newtap stm32 cpu -irlen ...
    - jtag newtap stm32 bs -irlen ...
    - # Create the debug target and say where it is
    - target create stm32.cpu -chain-position stm32.cpu ...
15. SYSCOMP Sometimes my debugging session terminates with an error. When I look into the log file, I can see these error messages: Error: arm7_9_common.c:561 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP

    TODO.