> In contrast, a hardware based jtag (cpld, or fpga) could - > theoretically run at lighting speed - and dynamically adjust > to *ANY* target clock, and implement a small hardware timer > to detect/error-on "stuck" signals. >
even with the fastest tool possible you will always have inbuilt sync delays with adaptive clocking. For most this is not a issue. Especially when debugging variable clock designs. > Just what is the correct TCK vrs CPU-CLK ratio? I believe a > simple statement of: 1/8 the CPU clock frequency is correct > for ARM parts. generally 1/6th is the norm for (synthesised) -S silicon, but like you say some differ. Hard macrocells, such as arm7tdmi - do not have the limitation of the -S parts. They can be clocked upto the cpu speed. > > Why? I have no idea - I think it is dumb because this means > debugging a device with an adaptive clock (ie: a battery > device that switches to 32khz between key strokes) is > painfully slow to debug. > The idea with the new v5 debug interface is that it features overrun checking. This is not as effective when using the jtag connection but works well when using the SWD interface. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
