alvieboy

Indirect JTAG programming using Papilio

Recommended Posts

Hi,

I was kinda bored this morning, so I decided to think and implement a indirect JTAG programmer for Papilio One.

The objective is to present regular JTAG signals (TDI/TDO/TCK/TMS) at some preconfigured wing, and allow "butterfly loader" or any other FTDI-based JTAG programmer to address this device. Primary reason for this is to resume my work on C/WING and other JTAG devices without having to use my old S3E eval board (which allows, using the hirose connector, to connect other devices to JTAG chain).

The principle here is quite simple, and operates at a very high speed.

We use the BSCAN component on S3E, which exports 2 user chains. The first chain is used to select one of these three modes: CONFIG, TMS and TXRX. To access these modes one must shift the appropriate mode number into USER1 chain. After selecting the mode, USER2 chain behaves as follows:

if mode is CONFIG, a 33-bit register/sub-chain can be accessed. This register uses 32-bits for TXRX size, plus one bit to signal end of shift (TMS up)

if mode is TXRX, the TDI is mapped into device TDO, while holding TMS low - however, after we shift N bits, and N matches the 32-bit TXRX size we set on CONFIG, TMS will be set according to the 1 bit end-of-shift signal. This mimics the operation of the JTAG/IO interface in butterfly loader code.

if mode is TMS, the TDI is mapped into device TMS, which allows us to change TAP state.

In TXRX/TMS modes the TCK input clock is mapped also as output clock.

Right now I'm updating the software to use this "indirect jtag" approach, but looking at waveforms in simulation it's quite clear that this must work (and up to high frequencies - the design can withstand 200MHz according to synthesis).

You think this might be useful ? Want me to publish this ?

Best,

Álvaro

Share this post


Link to post
Share on other sites

For another approach, you can have a look at what I have done using an soft AVR8 and a C client to push the data through UART.

http://www.gadgetfactory.net/gadgetforum/index.php?topic=277

It certainly won't work with butterflyloader or any JTAG-based program, but XSVF is easy to generate, and the client app is really simple -- especially since all the config options are hard-coded in this beta version...

Can't say which of the two approaches would give best results. I should have thought that generating the TDI/TMS/TCK signals insisde the papilio would be faster than sending them through USB, but XSVF is really verbose (although it's nothing compared to SVF) and the AVR program is not optimized, so yours might be faster.

A though for Jack: why not add a jumper on the papilio board to switch between a closed JTAG chain (normal conf) and an open chain with TDI/TDO pads to allow the plugging of other devices ? then, we could use papilio-prog directly to program the device, without even uploading a bit file to the papilio fpga.

Share this post


Link to post
Share on other sites

Well this is great to have these options! I like the XSVF player because you can script commands like a reset and such.

But I do really like the idea of being able to use the existing papilio-prog approach to program the C/RAM Wing and other devices. It's also nice to program a bit file directly without having to generate xsvf with impact. So I'd say this will be great to publish.

Thanks,

Jack.

Share this post


Link to post
Share on other sites
Guest AtomSoft

hows this coming along? Im about to order some parts to build that parallel cable PC3 i think its called from Xilinx... i need it to program some CPLDs i want to order also. I was thinking this should be able to replace the PC3 and i wouldnt have to build it at all !

SO if this is actually working already it would be nice to know so i can take the parts out of my list and just order more CPLDs.

If you think i should build the parallel programmer cable anyway then ill leave the parts in the list. Its only like $8 but thats like 2-4 cplds

Share this post


Link to post
Share on other sites

Hi,

Yes, the JTAG interface seems to be working, but I don't have a means to replay XSVF into the CPLD. Perhaps ben can help me on this :)

This was actually trickier than I first thought. There's a lot of resynchronization going inside the BSCAN component which prevented proper TDI/TDO interaction. Right now it's working OK it seems, I can shift in/out in proper order.

So expect a JTAG debugger for ZPUino soon.

Ben: if you read this - I saw a lot of "progalgxcf" implementations for the current papilio loader (xs3cprog), but none seems to work. All I have is a mean to change TAP state (shift out TMS) and shift out+in the TDI/TDO thing in bursts. Your XSVF replayer looks very nice, but I cannot use the serial port because I want reprogramming with live systems - otherwise your tool (which is a very useful one) would suffice for me. Think debugging an internal processor with an already implemented TAP+CHAINS.

I am not sure who maintains xs2cprog. Jack: do you have any idea ?

Álvaro

Share this post


Link to post
Share on other sites

Ben: if you read this - I saw a lot of "progalgxcf" implementations for the current papilio loader (xs3cprog), but none seems to work. All I have is a mean to change TAP state (shift out TMS) and shift out+in the TDI/TDO thing in bursts. Your XSVF replayer looks very nice, but I cannot use the serial port because I want reprogramming with live systems - otherwise your tool (which is a very useful one) would suffice for me. Think debugging an internal processor with an already implemented TAP+CHAINS.

the 'firmware' part of my XSVF player, which actually translates the XSVF commands into TAP commands, is a AVR C program. I'm pretty sure you can have it to compile on a PC and use your BSCAN interface. That is actually how I made a prototype, using a AVR firmware that updated a port according to bytes received on a UART -- a poor man's bscan interface, really. I switched to a smarter firmware because UART was way to slow for that, unlike the FTDI 2232 bitbang mode, obviously.

Share this post


Link to post
Share on other sites

The xc3sprog code is maintained on sourceforge:

http://sourceforge.net/projects/xc3sprog/

I took a look at it recently to see about using the latest version instead of papilio_prog but it has diverged quite a bit. Looks like it will be some effort to switch to it and get it to do what we need.

Jack.

Share this post


Link to post
Share on other sites
the 'firmware' part of my XSVF player, which actually translates the  XSVF commands into TAP commands, is a AVR C program. I'm pretty sure  you can have it to compile on a PC and use your BSCAN interface. That  is actually how I made a prototype, using a AVR firmware that updated a  port according to bytes received on a UART -- a poor man's bscan  interface, really. I switched to a smarter firmware because UART was  way to slow for that, unlike the FTDI 2232 bitbang mode, obviously

ben: I'm still trying to do that. After a few byte order struggling I think I managed most of it, but I'm still having some troubles to program the thing.

Do you happen to have a successful debug log for XC9527 (aka C/RAM CPLD) ? I'm wondering if my part is somehow broken... or I might miss something.

Alvaro

Share this post


Link to post
Share on other sites

Yes, I did program successfully a c/ram cpld. Actually, the only difficult step (but quite a step...) was to get a correct answer for the 'id' command (the first real command of the xsvf) Then, you know you've got the xir/xdr commands working, and it's a matter of.correcting silly mistakes (you rely on my code there, I did make and correct more than my share)

The cpld seemed to work fine on the first successful program cycle (ie without tdo mismatch) if you are not too lazy (I am), you can have impact generate a verify xsvf and run it.

Share this post


Link to post
Share on other sites
The cpld seemed to work fine on the first successful program cycle (ie  without tdo mismatch) if you are not too lazy (I am), you can have  impact generate a verify xsvf and run it.

Everything kinda looks ok, but (note tihs is my own debug code, not yours) if fails on erase (if I don't erase it, programming seems to actually be done, but fails somewhere at the end). Note that binary values in TDI/TDO debug are depicted L->R (first bits on left, either for TDO and for TDI):

JTAG chainpos: 0 Device IDCODE = 0x29504093     Desc: XC9572
XREPEAT
TX TMS: 11111
TX TMS: 0
XRUNTEST
XSIR 0xfe
TX TMS: 1100
TX TDI: 01111111 (+TMS1)
XSDRSIZE 32
XTDOMASK ff ff ff ff
XSDRTDO 00 00 00 00 expect 29 50 40 93
TX TMS: 10100
TX TDI: 00000000000000000000000000000000 (+TMS1)
RX TDO: 11001001000000100000101010010100
HEX: 93 40 50 29
0 : 29 29 [actual 29 expected 29 mask ff]
1 : 50 50 [actual 50 expected 50 mask ff]
2 : 40 40 [actual 40 expected 40 mask ff]
3 : 93 93 [actual 93 expected 93 mask ff]
Read:  ff
XSIR 0xff
TX TMS: 101100
TX TDI: 11111111 (+TMS1)
XSIR 0xe8
TX TMS: 101100
TX TDI: 00010111 (+TMS1)
XSIR 0xec
TX TMS: 101100
TX TDI: 00110111 (+TMS1)
XRUNTEST
XSDRSIZE 27
XTDOMASK 00 00 00 00
XSDRTDO 06 a9 57 fe expect 00 00 00 00
TX TMS: 10100
TX TDI: 011111111110101010010101011 (+TMS1)
RX TDO: 001111111111111111111111111
HEX: fc ff ff 07
0 : 00 00 [actual 07 expected 00 mask 00]
1 : 00 00 [actual ff expected 00 mask 00]
2 : 00 00 [actual ff expected 00 mask 00]
3 : 00 00 [actual fc expected 00 mask 00]
XRUNTEST
XSIR 0xed
TX TMS: 101100
TX TDI: 10110111 (+TMS1)
XRUNTEST
XSDRTDO 00 3f ff fe expect 00 00 00 00
TX TMS: 10100
TX TDI: 011111111111111111111100000 (+TMS1)
RX TDO: 101111111110101010010101011
HEX: fd 57 a9 06
0 : 00 00 [actual 06 expected 00 mask 00]
1 : 00 00 [actual a9 expected 00 mask 00]
2 : 00 00 [actual 57 expected 00 mask 00]
3 : 00 00 [actual fd expected 00 mask 00]
XTDOMASK 00 00 00 03
XSDRTDO 00 3f ff fe expect 00 00 00 03
TX TMS: 10100
TX TDI: 011111111111111111111100000 (+TMS1)
RX TDO: 101111111111111111111100000
HEX: fd ff 3f 00
0 : 00 00 [actual 00 expected 00 mask 00]
1 : 00 00 [actual 3f expected 00 mask 00]
2 : 00 00 [actual ff expected 00 mask 00]
3 : 03 01 [actual fd expected 03 mask 03]
SDR failed -- trying again (31 left)

And it stays here, fails this last SDR always with same value (0x1 instead of 0x3)

That's why I'd like so see a debug dump from yours. This is the ISC_ERASE phase.

Share this post


Link to post
Share on other sites

ben: sorry to be such a PITA, but I wonder if you could try yours C/RAM wing with your player, but change it to print the IR shift out at least on the beginning. I suspect something is wrong (read/write protection on my device).

If I generate a plain SVF file, I can see this there:

//Check for Read/Write Protect.
SIR 8 TDI (ff) TDO (01) MASK (e3) ;

This is not in the XSVF file (not sure why, but appears in both SVF and STAPL). Anyway, I am getting "0x81" and not "0x01" when I shift any IR. The "write protect override" only comes after this check, which is also weird.

I have no Xilinx cable, so it's not easy for me to use this part with Impact.

Álvaro

Share this post


Link to post
Share on other sites

And it stays here, fails this last SDR always with same value (0x1 instead of 0x3)

That's why I'd like so see a debug dump from yours. This is the ISC_ERASE phase.

This part gave me headaches as well -- re-reading my earlier post, I realized I have a selective memory...

Did you implement the runtest delay *with the clock cycles* ? the  spec says you should wait for at least x us, and run at least x clock cycles, x being the runtest value -- I run x TCK cycles at a low clock (<1MHz). I'd recommend trying with values way beyond  the spec to make sure that this isn't the issue.

I'll try to find some time to dump the values some time, but I cannot promess when -- my schedule is unpredictable at these times.

And, finally, I don't know about the read/write protect.

Share this post


Link to post
Share on other sites

Thanks for your tips, you were right. The timings were not correct, however they are per XSVF spec. I had to add additional delays. XC9500 programming datasheet says RUNTEST "n" should wait "n" milissecconds (no actual need to pulse TCK). However if I do follow these timings I have errors. Something like 3 times that value seems to work (I wonder if this is due to FTDI latencies also).

So it's working right now, but it's not very fast either. Erasing + programming + verifying takes 1m15s, mostly due to those delays on erase, plus having to check all transactions (and additional delays):

$ time ./xc9500prog file.xsvf
JTAG chainpos: 0 Device IDCODE = 0x11c1a093    Desc: XC3S250E
JTAG chainpos: 0 Device IDCODE = 0x29504093    Desc: XC9572

real    1m15.331s

Can you program it faster ?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now