Re: [OpenOCD-devel] SRST is pulled twice, breaking assumptions and some targets; other reset issues

[Paul F. <fer...@gm...>]

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:fer...@gm...