I checked out r2726 and applied the patch. It works great during 'reset halt/init/run/etc' but again does not do anything for initial JTAG scan.
I hooked up scope to the srst and trst to see how the jtag controller drives those signals. For the initial reset (before first JTAG scan) I get about 170ms pulse on srst and trst is pulled low (but not strongly enough to make it look like low signal, I think telo's pull-up is about as strong as olimex's pull-down on trst line). Now, during 'reset halt', the reset signals behave as expected (that is they both drive reset lines for the requested time). They *_assert_width is a great addition to the openocd. I can't figure out where in the code is the reset command invoked. This is clearly broken code (at least for ft2232 chip). If this is done outside of openocd (in libftd during driver setup for example) then openocd should apply the reset procedure as defined in config files before doing initial JTAG scan buf after this strange 'reset'. BTW I set the reset_config to: reset_config trst_and_srst separate But it does not matter for the 'initial reset' Anybody can point out where the first reset occurs? Does this also happen on the non-ft2232 controllers? On Fri, 2009-09-18 at 08:04 +0200, Øyvind Harboe wrote: > I've made a quick stab at implementing two new commands > (less documentation/help): > > jtag_nsrst_assert_width > jtag_tsrst_assert_width > > The implementation is a bit crude in that it assures a *minimum* > time that srst/trst are asserted. > > More sophisticated methods are of course possible, but perhaps > this is obscure enough that we shouldn't try anything more clever... > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
