JTAG: First of 4 Spartan-3E always UNKNOWN
in [FPGA]
|
From: Andrew Greensted on 31 Mar 2008 11:25 Hi All, I have custom board with 4 Spartan-3E (XC3S500E-PQ208). For configuration I have both JTAG and slave serial access. Slave serial works fine. However, when I try to identify the JTAG chain the first FPGA always comes back UNKNOWN. If I'm correct, impact's response to the identify command lists the devices in reverse order. So the when it reports this: '1': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 INFO:iMPACT:1777 - Reading /opt/xilinx-ProgTools-9.1i/spartan3e/data/xc3s500e.bsd... INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Version is 0000 '2': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Version is 0000 '3': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Version is 1110 INFO:iMPACT:1588 - '4':The part does not appear to be Xilinx Part. '4': : Manufacturer's ID =Unknown , Version : 14 INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- done. the unknown device is actually the first in the chain. Slave serial uses the same device order, so the problem FPGA is also the first in the slave serial chain. - I'm using a Platform Cable USB. - VCCAUX is 2.5V - All DONE pins are commoned with a 330R to 2.5V (VCCAUX) - All PROG_B pins are commoned with a 4.7K to 2.5V - All INIT_B pins are commoned with a 4.7K to 3.3V (VCCO) - ISE 9.1i under linux I've tried isolating the problem FPGA and it will not identify. I've also isolated the last three, these do identify (and configure). I'm quite sure it is not a faulty FPGA. I've 4 other boards that show the same behaviour. Here are the complete schematics: http://www.elec.york.ac.uk/intsys/users/ajg112/board.pdf Any suggestions as to what the problem might be would be a great help Thanks Andy
From: Antti on 31 Mar 2008 12:02 On 31 Mrz., 17:25, Andrew Greensted <ajg...(a)ohm.york.ac.uk> wrote: > Hi All, > > I have custom board with 4 Spartan-3E (XC3S500E-PQ208). For > configuration I have both JTAG and slave serial access. Slave serial > works fine. However, when I try to identify the JTAG chain the first > FPGA always comes back UNKNOWN. > > If I'm correct, impact's response to the identify command lists the > devices in reverse order. So the when it reports this: > > '1': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 > INFO:iMPACT:1777 - > Reading /opt/xilinx-ProgTools-9.1i/spartan3e/data/xc3s500e.bsd... > > INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > Version is 0000 > > '2': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 > INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > Version is 0000 > > '3': : Manufacturer's ID =Xilinx xc3s500e, Version : 0 > INFO:iMPACT:501 - '1': Added Device xc3s500e successfully. > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > Version is 1110 > INFO:iMPACT:1588 - '4':The part does not appear to be Xilinx Part. > '4': : Manufacturer's ID =Unknown , Version : 14 > > INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > done. > > the unknown device is actually the first in the chain. Slave serial uses > the same device order, so the problem FPGA is also the first in the > slave serial chain. > > - I'm using a Platform Cable USB. > - VCCAUX is 2.5V > - All DONE pins are commoned with a 330R to 2.5V (VCCAUX) > - All PROG_B pins are commoned with a 4.7K to 2.5V > - All INIT_B pins are commoned with a 4.7K to 3.3V (VCCO) > - ISE 9.1i under linux > > I've tried isolating the problem FPGA and it will not identify. I've > also isolated the last three, these do identify (and configure). > > I'm quite sure it is not a faulty FPGA. I've 4 other boards that show > the same behaviour. > > Here are the complete schematics:http://www.elec.york.ac.uk/intsys/users/ajg112/board.pdf > > Any suggestions as to what the problem might be would be a great help > > Thanks > Andy impact select chain debug issue TLR create a string of 128 '11111111111111111.. with some text editor, paste it into edit box for dr shift shift it out you should see JTAG ID of all 4 devices in chain scaned back in if there is 32 bit 1'1 at one end of the return string your chain is broken Antti
From: Antti on 31 Mar 2008 12:30 On 31 Mrz., 18:20, Andrew Greensted <ajg...(a)ohm.york.ac.uk> wrote: > Antti wrote: > > > impact select chain debug > > > issue TLR > > > create a string of 128 '11111111111111111.. with some text editor, > > paste it into edit box for dr shift > > shift it out > > you should see JTAG ID of all 4 devices in chain scaned back in > > > if there is 32 bit 1'1 at one end of the return string your chain is > > broken > > Here is the output (Cut and paste from the impact log) for this > operation done 4 times. You can see how the output is slightly different > each time, but the changes are only within the first 32 bits (i.e. the > first device) > > // *** BATCH CMD : bsdebug -scandr > 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 > > TDO Capture Data: > 11110000011000000010000010010011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 > > // *** BATCH CMD : bsdebug -scandr > 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 > > TDO Capture Data: > 11110000000110001001000001000011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 > > // *** BATCH CMD : bsdebug -scandr > 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 > > TDO Capture Data: > 11100000001110000100010000100001000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 > > // *** BATCH CMD : bsdebug -scandr > 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 > > TDO Capture Data: > 11000000011100001000100001001011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 hm chain aint completly broken, weird well i have seen wrong jtag id been returned, it was digged down to have excessive 100mhz noise on VCCINT Antti
From: Andrew Greensted on 31 Mar 2008 12:20 Antti wrote: > impact select chain debug > issue TLR > > create a string of 128 '11111111111111111.. with some text editor, > paste it into edit box for dr shift > shift it out > you should see JTAG ID of all 4 devices in chain scaned back in > > if there is 32 bit 1'1 at one end of the return string your chain is > broken Here is the output (Cut and paste from the impact log) for this operation done 4 times. You can see how the output is slightly different each time, but the changes are only within the first 32 bits (i.e. the first device) // *** BATCH CMD : bsdebug -scandr 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 TDO Capture Data: 11110000011000000010000010010011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 // *** BATCH CMD : bsdebug -scandr 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 TDO Capture Data: 11110000000110001001000001000011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 // *** BATCH CMD : bsdebug -scandr 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 TDO Capture Data: 11100000001110000100010000100001000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011 // *** BATCH CMD : bsdebug -scandr 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 TDO Capture Data: 11000000011100001000100001001011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011
From: Andrew Greensted on 1 Apr 2008 06:45
Antti wrote: > hm chain aint completly broken, weird > well i have seen wrong jtag id been returned, it was digged down to > have excessive 100mhz noise on VCCINT Looks like I've got a similar problem. After removing the oscillator module the JTAG identification works fine. Thanks for the pointer Andy |