Hello!
I'm trying to embed a FT2232D based programmer into my board with a
STM32 (Cortex-M3 MCU).
I want the programmer to be compatible with jtagkey, so I looked at
schematics of compaible designs.
I noticed that while the JTAG signals (TCK, TDI, TDO, TMS) are only
buffered when translation is necessary, the SRST and TRST signals are
always tri-state buffered, with OE going into the FTDI chip.
Is there a reason for that? Can I omit the buffers?
On the JTAGkey http://www.amontec.com/jtagkey.shtml , the output buffers have 3
basic functions:
- remove any pull-down or pull-up from the internal of JTAGkey (The pull-up and
pull-down value must be controlled by the target board and not by the emultator)
- pass from 8mA output to 32mA output driver (JTAGkey and JTAGkey-2 are tested
to support more than 12 daisy-chain devices on the same JTAG Chain)
- possibility to tristate the JTAG port at any time
- provide an ultra large IO voltage tolerance from 1.5V to 5V ;-)
The Amontec JTAGkey was designed to be the most generic USB JTAG adapter as possible.
Also, the Amontec JTAGkey has the advantage to provide a full control of the TRST and SRST line. In fact, the TRST and SRST of the Amontec JTAGkey can be configured as push-pull buffer and as open-drain buffer.
Note, SRST can be monitored from the JTAGkey Layout.
Also, I heard it's possible to omit the TRST signal and only keep the
SRST signal, because system reset will also reset the TAP controller. Is
that true? Are there problems with that?
TRST and SRST are optional, and their usage will depend on what is the target
need.
So you can try to customize the Amontec JTAGkey Layout for your need, or you
can use it as it is.
The advantage of using the original Amontec JTAGkey Layout is you make to sure
have a full compatibility with software supporting JTAGkey !
Regards,
Laurent
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 High-speed USB JTAG Adapter with RTCK feature.
Many thanks!
Matthew
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development