Pin mapping for JTAG-SMT2-NC?

[EdKeyes]

I'm trying to get a board using the JTAG-SMT2-NC working with OpenOCD. There's supposedly existing support for it, but at the moment I'm only getting a TCK signal and no others out, so I suspect that the existing pin mappings for the FTDI driver are incorrect.

Ideally I'd love to just get a copy of the SMT2 schematic to verify everything, but it doesn't seem to be publicly available. Short of that, would it be possible to know how the FTDI 232H signals are mapped onto the various outputs, i.e. ADBUS0 drives X, ACBUS5 tristates Y when high, etc.?

 

[jpeyron]

Hi @EdKeyes,

According to the OpenOCD website they already support the JTAG-SMT2.  You should select that configuration and it should work. 

cheers,

Jon

[EdKeyes]

Yep, that's what I tried first. The configuration built into OpenOCD only gives me TCK output, with no other JTAG signals. I've been able to get at least TMS to show up by randomly tweaking some of those bits, so it seems to be an error in the FTDI driver config rather than a hardware problem with my board. The SMT2 support in OpenOCD apparently was written on the basis of a single post in a Russian forum, so it's not exactly authoritative.

I'm hoping that Digilent can provide some definitive info for how things should be set up.

 

[jpeyron]

Hi @EdKeyes,

Sorry for the confusion. Here is how the signals are mapped onto the various outputs

TCK = ADBUS0

TDI = ADBUS1

TDO = ADBUS2

TMS = ADBUS3

OETMS = ADBUS5

OETDI = ADBUS6

OETCK = ADBUS7

 

All other pins should be configured as tri-state in order to avoid causing any issues.

 

cheers,

 

Jon

[EdKeyes]

Great, thanks! That indeed works just fine... the default config didn't turn on some of the needed OE signals.

For anyone running across this problem in the future, the OpenOCD config corresponding to the above information is:

ftdi_layout_init 0x00e0 0x00eb

@jpeyron, would you happen to also know how the GPIO pins are mapped on ACBUS, particularly GPIO2 which usually controls the processor reset line?

 

[jpeyron]

Hi @EdKeyes,

The GPIO pins are mapped on ACBUS as follows: 

GPIO0 = ACBUS0

GPIO1 = ACBUS1

GPIO2 = ACBUS5

OE0 = ACBUS2

OE1 = ACBUS3

OE2 = ACBUS4

The pins default to inputs and only become outputs when the application OEn pin is driven to a ‘1’. All other pins should be configured as tri-state in order to avoid causing any issues.

cheers,

Jon

[EdKeyes]

Thanks, @jpeyron! I'm getting some confusing results when trying to apply these settings to drive the reset signal on GPIO2, though.

Is there any chance that the OEn signals for this bank are actually active low (0 = output, 1 = input)? The ADBUS ones seem to be active high, but the GPIO lines aren't acting the same for some reason.

 

[jpeyron]

Hi @EdKeyes,

The output enable signals for the GPIO’s are inverted and thus are active low to enable output.

sorry about the confusion,

Jon

[EdKeyes]

Thanks again, @jpeyron! Everything makes sense now versus my logic probe.

Again, for anyone running across this thread in the future, the appropriate OpenOCD configuration for the above info is:

ftdi_layout_init 0x20e0 0x3feb

This assumes an nSRST signal on GPIO2 which is initialized to inactive high, same as the existing default.

[Sarah]

Hi

I do not understand the GPIO2 how to working!!!!!

can you describe this pin and that how to act when this pin connect to PS_SRST_B pin in zynq series,?

actually i need the timing for pin.

thanks

[JColvin]

Hi @Sarah,

Based on the JTAG SMT2 Reference Manual, the GPIO can be used for a number of applications, though the usual application for the GPIO2 would be to connect to the PS_SRST_B pin in Zynq based devices as you have noted. We (Digilent) do not have the timing information about when the Xilinx tools use this pin to reset the Zynq's processor core at various times during debugging operations, though it looks like Xilinx does have a little bit more information about it in their Zynq-7000 Technical Reference Manual here as well as some additional documentation for Zynq devices here.

Thanks,
JColvin

[mjdbishop]

Hi Digilent

Read and digested the forgoing.  But, can't get the GPIO012 pins to wiggle on an SMT2.  Whether my understanding is correct and how to diagnose the issue are the questions.

JTAG on AD0..3, JTAG OEs on AD5..7 work fine and the software stack does lots of solid JTAG through the user friendly D2XX dll.  Current requirement is to use the three GPIO lines for "USB" resets, e.g. GPIO2 => PS_Rst_n for Xilinx tools.  Understand that the mapping from AD0..7 to the GPIO pins is Gpio0/Gpio1/OE0_n/OE1_n/OE2_n/Gpio2/X/X.

Test results.  SMT2 module on the bench powered from a bench supply, 3v3 @ 60mA.  No discernable output from the GPIO pins however I poke it; e.g. 110001zz which should output 111, or 000000zz which should output 000.  An FT232H module wiggles its AC0..7 pins as directed.  The high byte wiggling is commanded by MPSSE 82x commands

Ordinarily the schematics would be consulted for places to probe and the FT2232H outputs probed.  That is inhibited by the compound effect of the abscence of schematics / layout and the 2232s QFN package - basically I need to know where to trace the signals.  Or, perhaps it's user error ...

Both further information and diagnostic suggestions would be most welcome

Best Regards  Martin

[malexander]

There are directional buffers between the FT232 and the actual GPIO pads on the module. The direction of these buffers is controlled by the logic level that's applied on the OE0, OE1, and OE2 nets. Placing a '0' on the OEn net will configure the applicable buffer as an output and allow the signal to be driven out of the applicable GPIO pad. Placing a '1' on the OEn net will configure the associated buffer as an input and allow the FT232H to read the state of the applicable GPIO pad.

[mjdbishop]

Hi Digilent

Thank you for the reply.  I had not appreciated, from the documentation, that the GPIO pins were bi-directional with unified direction/OE control.  However, I have been driving the GPIO OEs with 0's, consequently the data pattern presented should have been output.  So, what you have intimated leaves me where I started - drive the AC0..7 bits appropriately e.g. 110001zz [0..7] and the outputs don't obey.  Hence the original question, how do I trace the (output) signals, which on the components involved will come down to probing resistor pads and suchlike.

The test setup is USB cable for control and power, and  3v3 strapped to Vref.  All sitting on the bench.

Further information and diagnostic suggestions would be most welcome

Best Regards  Martin

[malexander]

If you want to probe the OEx signals as they appear coming out of the USB controller then R25, R24, and R5 are the easiest locations to access. If you want to probe the GPIO signals as they appear coming out of the chip then R29, R28, and R34 are the easiest locations. Those are in order of 0, 1, 2.

Just to confirm, you are asking about the the JTAG-SMT2 or JTAG-SMT2-NC and are trying to use the GPIO's in OpenOCD?