On Wed, Nov 13, 2013 at 7:46 PM, Paul Fertser <[email protected]> wrote:
> 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.
>
Wow! Are they even labeling this feature "JTAG"?
This popular part is used in numerous devices
I know, we still ship a lot of them at work, but not chained with other
ICs. And we buy them pre-programmed with our firmware and the JTAG fuse
blown so I only ever use their JTAG for development. With proprietary tools
unfortunately. I didn't even know they had these issues.
> 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?
>
Better in what sense, and for whom? I'm not opposed to having a hackish
procedure for this purpose in OpenOCD as long as it doesn't negatively
affect other users. I do oppose to the way this hack was implemented.
> > 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?
>
Looking at the stock configs is not enough.
Consider anyone using
proc my_special_reset {
jtag_ntrst_assert width 500 (or whatever the syntax is)
jtag_reset 1 0
jtag_reset 0 0
}
and having a sufficiently fast adapter (synchronous, for example). The 1550
patch would make the procedure fail because the assert width would no
longer have any effect.
The solution to this issue is simple: Instead of mutilating jtag_reset,
create a separate command handler (not necessarily placed in jtag/tcl.c) to
provide some generic base functionality that can be used to code the
sequence in Tcl. Or just code the MSP430 specific sequence directly in a
dedicated command handler. Also document in the function that:
> 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.
>
>
As long as the adapter driver hasn't queued up just enough data to do a
flush on its own in the middle of the sequence. So to be (more) sure, the
queue should be flushed both before and after the sequence.
/Andreas
------------------------------------------------------------------------------
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
