simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL attempt to configure FPGA with Impact, done not high configuration status register = 0000 attempt to program PLD seems to stall forever clicking abort and waiting makes impact again responsive with failure to program changing the BSDL file makes the chain order to get messed, attempt to re order the device by mouse drag and drop causes impact to self terminate. are there any issues with non Xilinx device in JTAG chain with impact 8.1? any help really welcome, I do not have time to open a webcase as I must have the board up and running til early next week. (the new bugs are entered in bugtrackter http://bugs.xilant.com ) -- Antti Lukats
Impact 8.1 problems with non xilinx device in chain
Started by ●January 27, 2006
Reply by ●January 27, 20062006-01-27
"Antti Lukats" <antti@openchip.org> wrote in message news:drd04j$iu7$01$1@news.t-online.com...> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL > > attempt to configure FPGA with Impact, done not high configuration status > register = 0000 > attempt to program PLD seems to stall forever clicking abort and waiting > makes impact again responsive with failure to program > > changing the BSDL file makes the chain order to get messed, attempt to re > order the device by mouse drag and drop causes impact to self terminate. > > are there any issues with non Xilinx device in JTAG chain with impact 8.1? > > any help really welcome, I do not have time to open a webcase as I must > have the board up and running til early next week. > > (the new bugs are entered in bugtrackter http://bugs.xilant.com ) > > -- > Antti LukatsI don't know why I had problems but we worked around them. The Spartan-3 on my board was the first in the JTAG chain followed by 4 other non-Xilinx devices. On the new rev of board we connected the FPGA so it could be isolated from the other devices for Chipscope-like debug (Synplify's Identify product) by swapping a couple resistors. Without the isolation from the chain, when I tried to get the debugger to communicate the board would reset. There may have been troubles with 1) another chip resetting the system when toggled through the jtag sequence with or without TRST applied properly to that device or 2) unexpected voltages on the soft reset signal sourced by the FPGA causing a system reset. Bottom line: I couldn't get the JTAG port up & running for debug on the first generation of board. Thankfully the Identify tool allows a "custom" port that's a JTAG emulator that I ported out to 4 test points.
Reply by ●January 27, 20062006-01-27
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:88sCf.1959$wk5.1266@news02.roc.ny...> "Antti Lukats" <antti@openchip.org> wrote in message > news:drd04j$iu7$01$1@news.t-online.com... >> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL >> >> attempt to configure FPGA with Impact, done not high configuration status >> register = 0000 >> attempt to program PLD seems to stall forever clicking abort and waiting >> makes impact again responsive with failure to program >> >> changing the BSDL file makes the chain order to get messed, attempt to re >> order the device by mouse drag and drop causes impact to self terminate. >> >> are there any issues with non Xilinx device in JTAG chain with impact >> 8.1? >> >> any help really welcome, I do not have time to open a webcase as I must >> have the board up and running til early next week. >> >> (the new bugs are entered in bugtrackter http://bugs.xilant.com ) >> >> -- >> Antti Lukats > > > I don't know why I had problems but we worked around them. The Spartan-3 > on my board was the first in the JTAG chain followed by 4 other non-Xilinx > devices. On the new rev of board we connected the FPGA so it could be > isolated from the other devices for Chipscope-like debug (Synplify's > Identify product) by swapping a couple resistors. Without the isolation > from the chain, when I tried to get the debugger to communicate the board > would reset. There may have been troubles with 1) another chip resetting > the system when toggled through the jtag sequence with or without TRST > applied properly to that device or 2) unexpected voltages on the soft > reset signal sourced by the FPGA causing a system reset. Bottom line: I > couldn't get the JTAG port up & running for debug on the first generation > of board. Thankfully the Identify tool allows a "custom" port that's a > JTAG emulator that I ported out to 4 test points. >thanks John, well I have a workaround also, the chip that makes impact to freeze is Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at powerup) one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan) 3 bit IR length. So if the ARMice is chain all is OK. if the ARM boundary scan then impact freezes. So my guess is that Impact can not handle JTAG devices with IR register lenght less than 4 but I may be wrong of course. Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM SAM and those make the ARM IR register 4 bit long, then impact can work without problems -- Antti Lukats http://www.xilant.com
Reply by ●January 27, 20062006-01-27
"Antti Lukats" <antti@openchip.org> wrote in message news:drdk27$3o4$02$1@news.t-online.com... <snip>> thanks John, > > well I have a workaround also, the chip that makes impact to freeze is > Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at > powerup) > one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary > scan) 3 bit IR > length. So if the ARMice is chain all is OK. if the ARM boundary scan then > impact freezes. > > So my guess is that Impact can not handle JTAG devices with IR register > lenght less than 4 > but I may be wrong of course. > > Anyway the workaround for us was to remove the pullup on JTAGSEL of the > ARM SAM > and those make the ARM IR register 4 bit long, then impact can work > without problems > > > -- > Antti Lukats > http://www.xilant.comIt almost sounds like the BDSL file expected the ARM IR jtag chain rather than the boundary scan chain. That *is* where the length is specified, isn't it? I'm glad you've got a workaround.
Reply by ●January 27, 20062006-01-27
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:%GsCf.1962$wk5.137@news02.roc.ny...> "Antti Lukats" <antti@openchip.org> wrote in message > news:drdk27$3o4$02$1@news.t-online.com... > <snip> >> thanks John, >> >> well I have a workaround also, the chip that makes impact to freeze is >> Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at >> powerup) >> one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary >> scan) 3 bit IR >> length. So if the ARMice is chain all is OK. if the ARM boundary scan >> then impact freezes. >> >> So my guess is that Impact can not handle JTAG devices with IR register >> lenght less than 4 >> but I may be wrong of course. >> >> Anyway the workaround for us was to remove the pullup on JTAGSEL of the >> ARM SAM >> and those make the ARM IR register 4 bit long, then impact can work >> without problems >> >> >> -- >> Antti Lukats >> http://www.xilant.com > > It almost sounds like the BDSL file expected the ARM IR jtag chain rather > than the boundary scan chain. That *is* where the length is specified, > isn't it? > > I'm glad you've got a workaround. >I am using proper BSDL files in both cases to support the proper IR lenght impact still freezes, but with the workaround its no longer a showstopper. the thing is an small FPGA board that is going to displayed at embedded in Nurnberg so I am a little bit under pressure as the PCBs did delay. but a few minutes the board did boot uClinux from SD card OK I just love how easy it is to port uClinux to new platform, just change the UCF file and there you go :) -- Antti Lukats http://www.xilant.com
Reply by ●January 27, 20062006-01-27
I am unfamiliar with the Atmel part in question but am quite certain that iMPACT is OK with instruction register lengths down to 2 bits (which is the minimum allowed by the standard). My cursory examination of the Atmel data sheets indicates that the part has 2 pins that control the test modes - a TST (which seems to enable some manufacturing modes so it must always be low) and the JTAGSEL (which seems to be temperamental in that a reset is required between toggles). I'm wondering if the FPGA pins are connected to either of these pins and perhaps interfering with the boundary-scan chain during configuration? I'm suspicious of some interaction of that sort, if not between the FPGA and those pins, perhaps some other ones - or perhaps an interaction between the processor pins and PROG or the FPGA mode pins during configuration. Idle thoughts... Glad you have a work-around. Antti Lukats wrote:> "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > news:88sCf.1959$wk5.1266@news02.roc.ny... >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:drd04j$iu7$01$1@news.t-online.com... >>> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL >>> >>> attempt to configure FPGA with Impact, done not high configuration status >>> register = 0000 >>> attempt to program PLD seems to stall forever clicking abort and waiting >>> makes impact again responsive with failure to program >>> >>> changing the BSDL file makes the chain order to get messed, attempt to re >>> order the device by mouse drag and drop causes impact to self terminate. >>> >>> are there any issues with non Xilinx device in JTAG chain with impact >>> 8.1? >>> >>> any help really welcome, I do not have time to open a webcase as I must >>> have the board up and running til early next week. >>> >>> (the new bugs are entered in bugtrackter http://bugs.xilant.com ) >>> >>> -- >>> Antti Lukats >> >> I don't know why I had problems but we worked around them. The Spartan-3 >> on my board was the first in the JTAG chain followed by 4 other non-Xilinx >> devices. On the new rev of board we connected the FPGA so it could be >> isolated from the other devices for Chipscope-like debug (Synplify's >> Identify product) by swapping a couple resistors. Without the isolation >> from the chain, when I tried to get the debugger to communicate the board >> would reset. There may have been troubles with 1) another chip resetting >> the system when toggled through the jtag sequence with or without TRST >> applied properly to that device or 2) unexpected voltages on the soft >> reset signal sourced by the FPGA causing a system reset. Bottom line: I >> couldn't get the JTAG port up & running for debug on the first generation >> of board. Thankfully the Identify tool allows a "custom" port that's a >> JTAG emulator that I ported out to 4 test points. >> > thanks John, > > well I have a workaround also, the chip that makes impact to freeze is > Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at > powerup) > one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan) > 3 bit IR > length. So if the ARMice is chain all is OK. if the ARM boundary scan then > impact freezes. > > So my guess is that Impact can not handle JTAG devices with IR register > lenght less than 4 > but I may be wrong of course. > > Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM > SAM > and those make the ARM IR register 4 bit long, then impact can work without > problems > >
Reply by ●January 27, 20062006-01-27
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com...>I am unfamiliar with the Atmel part in question but am quite certain that >iMPACT is OK with instruction register lengths down to 2 bits (which is the >minimum allowed by the standard). My cursory examination of the Atmel data >sheets indicates that the part has 2 pins that control the test modes - a >TST (which seems to enable some manufacturing modes so it must always be >low) and the JTAGSEL (which seems to be temperamental in that a reset is >required between toggles). I'm wondering if the FPGA pins are connected to >either of these pins and perhaps interfering with the boundary-scan chain >during configuration? I'm suspicious of some interaction of that sort, if >not between the FPGA and those pins, perhaps some other ones - or perhaps >an interaction between the processor pins and PROG or the FPGA mode pins >during configuration. > > Idle thoughts... > > Glad you have a work-around. >yes I have a workaround that is ok so far, but for production test I need correct solution too. JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL value by reprogramming the PLD, afer that impact just frozed while trying to reporgram the PLD. so no matter the the reason for the fail, there is some sort of bug with impact as any kind of wrong behaviour of the JTAG chain during programming should not cause impact to freeze. my guess about the 3 IR bits not supported was based on fact that as soon as reverted the ARM into ICE mode with longer IR register everything started to work again. the ARM has been unprogrammed all the time, only change to revert the chain useable was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the connection to PLD can not change the scan chain config once powered. well FPGA PROG_B is also connected to the PLD, but it should not matter as the signal that made the difference was JTAGSEL on ARM, no matter the FPGA connections it should not prevent the PLD from being programmed - as long as ARM IR chain doesnt chain its length during runtime. I will investigate it a little more when the board is otherwise fully tested. Antti
Reply by ●January 27, 20062006-01-27
Antti Lukats wrote:> "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im > Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com... >> I am unfamiliar with the Atmel part in question but am quite certain that >> iMPACT is OK with instruction register lengths down to 2 bits (which is the >> minimum allowed by the standard). My cursory examination of the Atmel data >> sheets indicates that the part has 2 pins that control the test modes - a >> TST (which seems to enable some manufacturing modes so it must always be >> low) and the JTAGSEL (which seems to be temperamental in that a reset is >> required between toggles). I'm wondering if the FPGA pins are connected to >> either of these pins and perhaps interfering with the boundary-scan chain >> during configuration? I'm suspicious of some interaction of that sort, if >> not between the FPGA and those pins, perhaps some other ones - or perhaps >> an interaction between the processor pins and PROG or the FPGA mode pins >> during configuration. >> >> Idle thoughts... >> >> Glad you have a work-around. >> > yes I have a workaround that is ok so far, but for production test I need > correct solution too. > > JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL > value by reprogramming the PLD, afer that impact just frozed while trying to > reporgram the PLD. > > so no matter the the reason for the fail, there is some sort of bug with > impact as any kind of > wrong behaviour of the JTAG chain during programming should not cause impact > to freeze. > > my guess about the 3 IR bits not supported was based on fact that as soon > as reverted > the ARM into ICE mode with longer IR register everything started to work > again. the > ARM has been unprogrammed all the time, only change to revert the chain > useable > was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the > connection > to PLD can not change the scan chain config once powered. > > well FPGA PROG_B is also connected to the PLD, but it should not matter as > the > signal that made the difference was JTAGSEL on ARM, no matter the FPGA > connections it should not prevent the PLD from being programmed - as long > as ARM IR chain doesnt chain its length during runtime. I will investigate > it > a little more when the board is otherwise fully tested. > > Antti >Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not actually frozen but just taking a really long time to fail. If it is a 9500/XL/XV then these devices use polling to indicate when programming (or erasure) is complete. The device responds with a status to iMPACT to indicate success or failure. Some failure statuses mean keep trying - just wait longer. The wait time increase can quickly increase to minutes in certain failure situations. I am speculating that the PLD mucks with JTAGSEL doing something horrible to the boundary-scan chain, making the output look like the status that says "keep trying - just wait longer" and then you end up with this apparent "freeze". Bad behavior. Should fail more elegantly if that's what happening. That's my theory, anyway.> > > > > > > >
Reply by ●January 27, 20062006-01-27
Antti Lukats wrote:> my guess about the 3 IR bits not supported was based on fact that as soon > as reverted > the ARM into ICE mode with longer IR register everything started to work > again... perhaps the Atmel device itself has Bypass problems in the other mode ? -jg
Reply by ●January 27, 20062006-01-27
The PLD pins float during programming. Depending on the CPLD, it is typically pulled high, weakly, while the device is being programmed. You might want to install a strong pull-up on the JTAGSEL to hold it high during configuration and see if that helps things. If JTAGSEL floats low, you will be hosed - it appears. Again, not knowing which Atmel device you are using you may also find this instructive: http://www.atmel.com/dyn/products/faq_card.asp?faq_id=780 Neil Glenn Jacobson wrote:> Antti Lukats wrote: >> "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> >> schrieb im Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com... >>> I am unfamiliar with the Atmel part in question but am quite certain >>> that iMPACT is OK with instruction register lengths down to 2 bits >>> (which is the minimum allowed by the standard). My cursory >>> examination of the Atmel data sheets indicates that the part has 2 >>> pins that control the test modes - a TST (which seems to enable some >>> manufacturing modes so it must always be low) and the JTAGSEL (which >>> seems to be temperamental in that a reset is required between >>> toggles). I'm wondering if the FPGA pins are connected to either of >>> these pins and perhaps interfering with the boundary-scan chain >>> during configuration? I'm suspicious of some interaction of that >>> sort, if not between the FPGA and those pins, perhaps some other ones >>> - or perhaps an interaction between the processor pins and PROG or >>> the FPGA mode pins during configuration. >>> >>> Idle thoughts... >>> >>> Glad you have a work-around. >>> >> yes I have a workaround that is ok so far, but for production test I need >> correct solution too. >> >> JTAGSEL is connected to PLD, everything was fine until I changed the >> JTAGSEL >> value by reprogramming the PLD, afer that impact just frozed while >> trying to reporgram the PLD. >> >> so no matter the the reason for the fail, there is some sort of bug >> with impact as any kind of >> wrong behaviour of the JTAG chain during programming should not cause >> impact to freeze. >> >> my guess about the 3 IR bits not supported was based on fact that as >> soon as reverted >> the ARM into ICE mode with longer IR register everything started to >> work again. the >> ARM has been unprogrammed all the time, only change to revert the >> chain useable >> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the >> connection >> to PLD can not change the scan chain config once powered. >> >> well FPGA PROG_B is also connected to the PLD, but it should not >> matter as the >> signal that made the difference was JTAGSEL on ARM, no matter the FPGA >> connections it should not prevent the PLD from being programmed - as long >> as ARM IR chain doesnt chain its length during runtime. I will >> investigate it >> a little more when the board is otherwise fully tested. >> >> Antti >> > > Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not > actually frozen but just taking a really long time to fail. If it is a > 9500/XL/XV then these devices use polling to indicate when programming > (or erasure) is complete. The device responds with a status to iMPACT > to indicate success or failure. Some failure statuses mean keep trying > - just wait longer. The wait time increase can quickly increase to > minutes in certain failure situations. I am speculating that the PLD > mucks with JTAGSEL doing something horrible to the boundary-scan chain, > making the output look like the status that says "keep trying - just > wait longer" and then you end up with this apparent "freeze". Bad > behavior. Should fail more elegantly if that's what happening. That's > my theory, anyway. > >> >> >> >> >> >> >> >>
