Hi, Andreas, I know you have very fine justification for what you say, but let me try to express what I meant more clearly.
On Tue, Oct 15, 2013 at 11:57:53PM +0200, Andreas Fritiofson wrote: > Well, the obvious solution would be to *not* put non-JTAG devices in the JTAG > chain. If someone is determined to do so anyway, they could use a suitable > instrument such as a waveform generator to toggle the required pins before > connecting the JTAG debug tool. It's kind of out of scope for > OpenOCD. MSP430 is quirky, no doubt. And even after it's put in JTAG mode via the magic pin dance it's still quirky, e.g. only the very first device in the chain can be flashed because it uses TCK pulses during the process, and so if the chip is not the first in the chain it will receive them before the data reaches its TDI, so flashing can't work. However, if it's the first on the chain it behaves just fine in every possible regard after it's switched in JTAG mode. This popular part is used in numerous devices and Gateworks's boards are not something special. Moreover, Gateworks is a fine company actively supporting upstream OpenOCD development, talking to the community in the open etc. Here they tried to make OpenOCD usable out of the box with their boards and spent considerable time on that, so I deduce this usecase is important. The needed waveform is neither complex nor demanding, it can be played back with about any reasonable speed, but calling jtag_reset directly in Tcl config was way too slow. I'm sure with some small changes OpenOCD would be able to play it back fast enough on the wide range of adapters, and if one particular device can't do that, well, Gateworks would just warn the users it's not supported. It would still be better and easier than writing an external application (should it be tought to parse OpenOCD ftdi tcl configs? what else?). To sum up: are you sure implementing it externally is better than having a hackish implementation in OpenOCD which would work nicely provided one of the adapters that can toggle reset fast enough is used? > The 1550 change does it wrong in at least two ways: > 1. It changes the semantics of the jtag_reset command (it skips all the extra > stuff that jtag_add_reset does, wrong as it may be). It does, right. But is it really an issue here? I've taken a look at the existing config files that are using jtag_reset and I can't see how this might break them. So if it doesn't break anything, what's problematic about it? > 2. It gives no guarantee as to what the actual toggle rate will be. The JTAG > API > provides no such guarantee so neither can this nor any similar > patch. I have discussed that with Pushpal on IRC and I think his tests showed that flushing the queue after every bitbanging operation was too slow for the msp430, unfortunately. So it doesn't give any guarantees but otoh it's known to work fine with the existing FTDI adapters. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
