Short version is this: You *MUST* be able to change the JTAG clock frequency - *at*least* by hand.... to any value - at any time using a command.
The Long version - with explanation follows Pieter> The AT91SAM9260's JTAG speed must always be 6 times lower than its clock speed. The true problem is - many jtag controllers do not support RTCK - or the chip implementor choose not to hook the F-ing pin up. the pin is *REQUIRED* on many "S" type cores from ARM - but ... well not always there. Chip companies sometimes skimp. Board makers do not understand and skimp. It is called "adaptive clocking" see this: http://www.arm.com/support/faqdev/4170.html Example - ARM7TDMI-S - found in a number of chips. See: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdf Page 5-10 & 5-11, Section 5.3.5 FYI - there are two types of arm7tdmi - "hard macro cell" - or "synthesize-able aka: S core". The S type, has 2 rules: 6x slower - or use RTCK. The hard macro cell - I think is 6x slower. Example: ARM966 - (aka: STR9 parts) http://infocenter.arm.com/help/topic/com.arm.doc.ddi0213e/ARM966E-S_TRM.pdf Pages 7-1 - section 7.1.2 Example: ARM946 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/DDI0201D_arm946es_r1p1_trm.pdf Pages 9-3, section 9.1.3 I am surprised to find the 926ej-s TRM does not state anything about the RTCK signal. Nor does the ARM968. However - reading that part of the TRMs signal description I suspect they require it - but perhaps did not document it as clearly as they should have (they probably do - in 'nda' type documents) While Pieter says 6x slower - ST says 10x slower - (STR9 data sheet section 3.15, 3rd paragraph Perhaps ST does something more we do not know about. http://www.st.com/stonline/products/literature/ds/13495.pdf There are others - like XILINX who want 12x slower, 32/12 => 1.x khz - I can probably only program even multiples so it is 1khz clock YUCK! PIETER> Let's say one was busy with a debugging session where the AT91SAM9260's clock speed was 100 MHz and the JTAG Speed set to 6 MHz. I'll give you a worse situation - battery powered system, CPU runs @ 100 mhz, update the LCD, set LCD & SDRAM to self refresh, turn off all clocks and run on the 32khz clock. and wait for the user to press a button. Or maybe "hibernate" or "off" mode - So - the CPU dynamically switches between 32khz - and 100mhz - lighting fast. So for normal debugging I am going to run at 5khz Jtag? Oh please!!!!!! SHOOT ME NOW! This is very true if you are debugging ultra low power and "wakeup after sleep" or "hibernate" problems. I have done that before - what a pain in the ass!. You *MUST* be able to change the JTAG clock frequency - *at*least* by hand.... to any value - at any time. Or - the JTAG interface *MUST* support RTCK - in a reasonable way. (I know a commercial JTAG box - that had mental issues - with ultra slow jtag clocks) I sure wish FTDI - would have supported RTCK... what a loss. I suspect - (because the Cortex debug TRM debug manual states: "Arm Limited recommends that RTCK is not implemented on an arm debug interface") it will never happen on cortex. Perhaps - there is something new - about cortex - I do not know. -Duane. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
