Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2009-09-10 12:55:53

d18c7db
Contributor
Registered: 2008-08-19
Posts: 292

FPGA JTAG woes

Can someone please help me out here, on my PM3 board, I'm trying to connect to the JTAG port of the FPGA but no matter what I try, I keep getting the wrong IDCODE. I've tried OpenOCD with "jtag newtap xilinx tap -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 0x0060C093" and it keeps returning:

Info : JTAG tap: xilinx.tap tap/device found: 0xf8041003 (mfg: 0x001, part: 0x8041, ver: 0xf)
Error: JTAG tap: xilinx.tap              got: 0xf8041003 (mfg: 0x001, part: 0x8041, ver: 0xf)
Error: JTAG tap: xilinx.tap  expected 1 of 1: 0x0060c093 (mfg: 0x049, part: 0x060c, ver: 0x0)

Whereas if I move the JTAG connector to the ARM port and using "jtag newtap sam7x256 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3f0f0f0f" I get the correct ID:

Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : JTAG Tap/device matched

I've quadruple checked the cable pinout both visually and with a meter, I've verified that power is applied to the board and with a scope I have checked that the correct waveforms are present (ie the clock ends up on TCK, the mode select on TMS, etc) and I have no doubt whatsoever that there is no problem with the JTAG interface cable. The signal levels also match the 3.3V levels so they're not too high or too low.

I then moved to a homebrew piece of code I wrote, to bitbang the JTAG over the parallel port so I have complete control and I get similar results as OpenOCD. My homebrew software clocks the TCK real slow, about 2000 pulses per second, so it's not a matter of driving the TAP too fast either. With my homebrew, the ARM returns IDCODE 0x3F0F0F0F as expected but the FPGA always returns 0x00041003. Note that this is slightly different from the value that OpenOCD got, but OpenOCD clocks TCK at 250KHz. I verified this with a scope and they're both correct, it seems the data line goes high earlier at the faster TCK speed so OpenOCD reads that as a F8 (data is shifted lbs first).

I was using this document as reference and it clearly states on page 6 and I quote "The IDCODE is the default instruction at power-up and Test-Logic-Reset state." then in the table below it gives a IDCODE of 0xX060C093 for a XC2S30.

In both cases (the ARM that works and the FPGA which doesn't) I follow the same process, clock the TAP with TMS high for ten TCK cycles to end up in "Test logic reset", then four more TCK clocks with TMS low high low low to move to "shift DR" state, then holding TMS low I clock TCK 32 times to shift out the IDCODE data. This is a no brainer, and in fact looking at the scope trace this is exactly what OpenOCD does, only faster. This works on the ARM but not the FPGA!

I checked that my FPGA is functional and I can do all the usual operations, reading LF and HF tags and get the expected results. As a last resort I hooked up to another board with a XC3S250E FPGA and it behaves the same (I get IDCODE 0x00041003 as well), even though it's a different FPGA chip family.

I'm really stuck on this, if anyone who has dealt with JTAG in depth has any ideas, please let me know.

Offline

Board footer

Powered by FluxBB