From c45984f93ede02b80dd6beb2bfa2132cdec5dfa0 Mon Sep 17 00:00:00 2001 From: oharboe Date: Mon, 26 May 2008 12:12:03 +0000 Subject: [PATCH] found out why str912 reset halt failed. git-svn-id: svn://svn.berlios.de/openocd/trunk@688 b42882b7-edfa-0310-969c-e2dbd0fdcd60 --- src/jtag/bitbang.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/jtag/bitbang.c b/src/jtag/bitbang.c index c4f9ce94..4c58e1d5 100644 --- a/src/jtag/bitbang.c +++ b/src/jtag/bitbang.c @@ -37,7 +37,24 @@ bitbang_interface_t *bitbang_interface; -/* should the clock be high or low in idle? */ +/* DANGER!!!! clock absolutely *MUST* be 0 in idle or reset won't work! + * + * Set this to 1 and str912 reset halt will fail. + * + * If someone can submit a patch with an explanation it will be greatly + * appreciated, but as far as I can tell (ØH) DCLK is generated upon + * clk=0 in TAP_RTI. Good luck deducing that from the ARM documentation! + * The ARM documentation uses the term "DCLK is asserted while in the TAP_RTI + * state". With hardware there is no such thing as *while* in a state. There + * are only edges. So clk => 0 is in fact a very subtle state transition that + * happens *while* in the TAP_RTI state. "#&¤"#¤&"#&"#& + * + * For "reset halt" the last thing that happens before srst is asserted + * is that the breakpoint is set up. If DCLK is not wiggled one last + * time before the reset, then the breakpoint is not set up and + * "reset halt" will fail to halt. + * + */ #define CLOCK_IDLE() 0 int bitbang_execute_queue(void); -- 2.39.5