I support what Rick is saying. I think we can work through it. With diligent usage of tap_set_state() when its full logging is enabled, this can be tracked down. There is currently not diligent usage of tap_set_state() in effect in any cable driver. But that is on my to do list when I get back to this.
My vision is that any state transition must be reported to tap_set_state(). This way problems like this become easier to diagnose. Dick > > On Feb 19, 2009, at 10:01 PM, Kees Jongenburger wrote: > >> >> Hello Rick, >> >> On Fri, Feb 20, 2009 at 12:47 AM, Rick Altherr <[email protected]> >> wrote: >>> >>> On Feb 19, 2009, at 3:38 PM, Kees Jongenburger wrote: >>> >>> Can you write up the problems you encountered with OpenOCD? There >>> are a few >>> people on the OpenOCD development list who are actively working on >>> fixing up >>> the JTAG layer. If we could get some data as to what isn't working >>> and what >>> is needed, we can start working on the necessary improvements. >> >> There are currently problems that possibly prevent the OpenOCD from >> adding >> the DAP. >> >> 1) When performing ir/dr scans the default end state is Run Test Idle. >> This does not match >> what the ICEPICK wants. I don't know it this is a problem or not >> > > I know that the JTAG internals in OpenOCD can support this. It may be > as simple as allowing an extra argument to the irscan and drscan > commands in the TCL layer. > >> 2) The tap_move that allows moving between "stable" tap states does >> not follow "shortest pad" >> but always takes 7 steps, possibly passing via test logic reset. I >> mailed about it >> https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html >> >> >> > > Yes. I remember seeing the query about this, but I didn't realize it > was a limiting issue for ICEPICK. > >> 3) There is no support for generating clock pulses in the IDLE state. >> but this is required >> > > The internals have support for this as it was needed for SVF support. > Again, it may just need to be exposed at the TCL layer. > >> 4) I had some trouble implementing the sequence because of the problems >> mentioned above. Those changes where not trivial for me to implement >> so I decided to focus >> on getting the sequence done by using urjtag. My plan is still to use >> OpenOCD for "stage 2" >> because of its good GDB support. But then at least I know what needs >> fixing in OpenOCD. >> >> Greetings >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google >> Groups "Beagle Board" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/beagleboard?hl=en >> -~----------~----~----~----~------~----~------~--~--- >> _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
