Re: Impact 8.1 problems with non xilinx device in chain

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@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag news:dre15b$ngj6@xxxxxxxxxxxxxxxxxxxxxxx
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.









.

Loading