Replying here so comments are more visible. I know there's a lack of
documentation on how to create a config file for the new ftdi driver.
As the layout specifications are visible to the user now, they really
should be documented. I'm making the reply a bit more verbose in order
to dump some knowledge here that may go into the users guide in some
form or another.

On Wed, Sep 26, 2012 at 3:16 PM, Spencer Oliver (Code Review)
<[email protected]> wrote:
> Spencer Oliver has posted comments on this change.
>
> Change subject: cfg: ftdi icdi enable srst open drain config
> ......................................................................
>
>
> Patch Set 2: (1 inline comment)
>
> ....................................................
> File tcl/interface/ftdi/luminary.cfg
> Line 31: ftdi_layout_init 0x0088 0x008b
> i was using http://www.ti.com/lit/ug/spmu029a/spmu029a.pdf however they 
> should behave the same however.
>
> I am not seeing what you describe, describing srst for the lm3 is not good 
> anyway as we do not use it anyway.
>
> so are you saying these should be equiv?
> ftdi_layout_signal nSRST -data 0x0020 -oe 0x0020
> or
> ftdi_layout_signal nSRST -noe 0x0020

No, I'm saying that having srst open-drain in reset_config and the
following in the interface config:

 ftdi_layout_signal nSRST -noe 0x0020

has the same effect on the FTDI chip as having srst push-pull with the
following:

 ftdi_layout_signal nSRST -data 0x0020

Both options drive pin 0x0020 low when srst is asserted and drive it
high when it's deasserted.

It is not equivalent to

 ftdi_layout_signal nSRST -data 0x0020 -oe 0x0020

which will drive pin 0x0020 low when srst is asserted, drive it high
when deasserted with reset_config as push-pull and hi-z it when
deasserted with reset_config open-drain. This is the only
configuration that will hi-z a ftdi pin and is only useful when
there's no buffer of any kind.

For example

 ftdi_layout_signal nSRST -data 0x0020 -oe 0x0040

will drive pin 0x20 low and 0x40 high when asserted, both high when
deasserted push-pull and 0x40 low (0x20 unspecified, probably high)
when deasserted open-drain. This is suitable for a 74'126 style
3-state buffer. -oe can be changed to -noe to suit a 74'125 buffer
that has active-low output enable. -ndata is useful for inverting
buffers.

When no -oe (or -noe) is specified, the only valid setting for
reset_config is push-pull, otherwise it will error out when releasing
reset. Similarly, without -data (or -ndata), only open-drain reset can
be used. I've been thinking to add a signal level specifier to select
hi-z OR drive high, whichever is available, and use that to deassert
reset, in order to be more forgiving for reset_config settings that
doesn't match actual adapter capabilities.

Another consideration is the ftdi_layout_init values. It's important
that they initialize the adapter to the most forgiving non-reset state
(hi-z if available, otherwise drive-high) for the actual reset outputs
(after all buffers and such) in order not to affect the target during
startup. Also all other FTDI pins the adapter uses internally must
have suitable configurations to avoid shorts or floating CMOS inputs,
even if the pins are ignored by OpenOCD.

For example, the Luminary adapter has signals to switch between JTAG
and SWD mode and an enable for the TDI/TMS/TCK buffers. Those
obviously have to be well defined, but if they're not things may still
work sometimes and fail othertimes. Some adapters have target Vcc
detection or SRST feedback as inputs and then the adapter may even
break if those pins are driven by the FTDI too.

>
> --
> To view, visit http://openocd.zylin.com/848
> To unsubscribe, visit http://openocd.zylin.com/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I21a115121f167dc88cd9bf2d1ca1ac9f3e1110d7
> Gerrit-PatchSet: 2
> Gerrit-Project: openocd
> Gerrit-Branch: master
> Gerrit-Owner: Spencer Oliver <[email protected]>
> Gerrit-Reviewer: Andreas Fritiofson <[email protected]>
> Gerrit-Reviewer: Spencer Oliver <[email protected]>
> Gerrit-Reviewer: jenkins

/Andreas

------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to