Impact 8.1 problems with non xilinx device in chain

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

formatting link
)

--
Antti Lukats
Reply to
Antti Lukats
Loading thread data ...

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.

Reply to
John_H

"John_H" schrieb im Newsbeitrag news:88sCf.1959$ snipped-for-privacy@news02.roc.ny...

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 to
Antti Lukats

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.

Reply to
John_H

"John_H" schrieb im Newsbeitrag news:%GsCf.1962$ snipped-for-privacy@news02.roc.ny...

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 to
Antti Lukats

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:

Reply to
Neil Glenn Jacobson

"Neil Glenn Jacobson" schrieb im Newsbeitrag news:dre15b$ snipped-for-privacy@cliff.xsj.xilinx.com...

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 to
Antti Lukats

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 to
Neil Glenn Jacobson

.. perhaps the Atmel device itself has Bypass problems in the other mode ?

-jg

Reply to
Jim Granville

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:

formatting link

Neil Glenn Jacobs>> "Neil Glenn Jacobson"

Reply to
Neil Glenn Jacobson

"Neil Glenn Jacobson" schrieb im Newsbeitrag news:drehdt$ snipped-for-privacy@cliff.xsj.xilinx.com...

Hi Neil,

hmmm - the JTAGSEL is only captured at powerup later level changes (PLD pins floating) should not cause any change or trouble.

also I would have expected JTAG problems in the case where ARM-ICE JTAG is in chain but it is the other way around, when ICE is in chain all works, when ARM boundary scan is in chain then the chain is scanneable, but impact fails really strange.

I would be happy to leave the JTAGSEL=0 and ARM in ICE mode, but the manufacturer of the board wants to access boundary scan on all devices that support it, this includes the ARM

and yes the PLD is XC9572XL, but complete freeze (or what seems as complete freeze) could still be prevented, ie the 'abort' button should be responsive also during the wait periods

Antti

Reply to
Antti Lukats

the mode that has problems is the boundary scan mode not ICE mode so I do not want to belive that the bypass instruction in boundary scan mode is not implemented properly. Atmel is sure know to have weird silicon bugs, but this time I am relatilvly sure there is no issue with bypass instruction.

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

You know Antti, in a very strange way you can take some credit for that fact. Your statement in a comp.arch.fpga posting 18 months ago

formatting link

"NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux thanks to the full integration of the config and integration into Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible todo the same for MicroBlaze uClinux config and build. "

p***ed me off so much I went and created the auto-config mechanisms that now make mb-uclinux by far the easiest (and probably most popular) soft-CPU Linux solution around.

So, thanks - I think :)

John

Reply to
John Williams

formatting link

Oh John,

sorry when I got you pissed off.

you know I am happen to so poor guy that I can not afford to have second workstation only for MicroBlaze development and as you know the MicroBlaze uClinux build until today can not be done on the Windows machine.

So what I stated 18months ago stands so far that it is (or was at least) possible to configure and and build uClinux on single Windows PC a nice to have thing for poor souls like me not having separate linux PC box around.

OTOH - I did only check the uClinux config from SOPC builder, it worked, but I have never ever seen it working as I do not happend to have NIOS uClinux ready hardware ready and hasnt cared enough to obtain such hardware so far either.

And I have build uClinux systems way before the auto-config, and it has been always been easy for me (after the first try).

I have spent a lot of time in desperate attempts to get coLinux environment setup with preconfigured microblaze uClinux toolchain after some pain it works but the way todo file transfer to windows host PC is real complicated, so only ysterday (or today if in US timezone) I did install Bochs source code and compiled Bocs x86 emulator on Windows for one simple reason:

to have windows based virtual linux with pre installed images containing MicroBlaze toolchain and uClinux deve tools - so other poor guys (those with no Linux!) can also work on single PC and still develop for uClinux Microblaze

and again just today I got finally working a MicroBlaze uClinux FPGA tested driver for SD Cards so I was able to mount in MicroBlaze uClinux a SD card formatted with FAT16 and after mount I did see files on the card.

its FAST bit.banged software driver that works with SD (later I may add MMC card support too) cards in NON-SPI mode. It can work with any software controllabe PIO port, currently with GPIO CMD-DAT-CLK-card sense onto port, all other is software.

a small bootloader exists that loads the full uClinux image from SD card using the same bitbang mode, load time approc 7seconds. This could be even better as I have not done assembly level optimization to the code yet.

I am replying in such details as I was just about to contact you to ask what is the procedure to submit the driver to be included in the uClinux distribution (it is GPL licensed)

John, dont judge me so hard, for those who primare work on linux its really hard to understand how much trouble it is setting up and maintaining 2 work stations for the linux cross compile. I just want to type

make menuconfig make dep make

from my primary workstation (winPC)

as long as that is not possible, well it means additioal burden - at work I did today the following procedure 18 times

1 edit mmc.c 2 TFTP PUT mmc.c 3 stand up from my chair going to linux PC here working standing 4 copy from tftpboot to \drivers\block 5 make 6 back to my workplace, sitting down 7 TFTP GET image bin

8 copy image.bin to SD card, insert to FPGA board, reset 10 seconds linux prompt is ready :)

I have a mouse-keyboard-switch, but linux doesnt work with it :( I really have killed pretty much of my time because of no easy solution exist for those whose primary system is windows - and that has to be so as FPGA tools are generically better supported on WinXP then linux so switching to linux completly is not an option for me.

anyway I am hoping to have the BOCHS emulator setup to provide a solution that doesnt require the purchase of second PC for microblaze uclinux development

cheers Antti

Reply to
Antti Lukats

What about SSH ?

Mostly when I work on the kernel, my test platforms are no just right beside me but connected to a "server" where it download (tftp & nfs) from and it's serial port is also connected to that machine. I can even hard-reset the platform from that machine.

All I have to do is ssh to that machine with 2 terminals, and on one, lauche a terminal emultator to see the RS232 console output and on the other I can do the "common" tasks. Well, since my main pc is also Linux I don't do the compile on the server but nothing prevents me from ... And all that without sitting up ;)

Sylvain

Reply to
Sylvain Munaut

Antti Lukats wrote: ...

Doesn't CoLinux work?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

it does.

nothing wrong running mincroblaze toolchain on it, the problem was copying the resulting file out from colinux the virtual network adapters and bridginh things did not want to work properly

Antti

Reply to
Antti Lukats

"Sylvain Munaut " schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

:) I was possible yesterday lazy in non creative way, sure remote access would also work if linux accessible computer is on accessible, what is unfortunatly is not the case at home. I just need to setup some scripts that launch make and shuffle files.

Antti

Reply to
Antti Lukats

Hi Antti,

On the Linux vs windows workstation issue, we are almost evenly split here in our group. I do everything (ISE, EDK, uClinux, ...) on a Linux box, running CentOS3 (perfectly compatible with Xilinx tools). I do have an old Windows laptop for running MS Office and web/email but that's about it.

Others in the group are running CoLinux, some on laptops, and they run all of the tools in that environment. CentOS 3 installs just fine in CoLinux, so the entire Xilinx tool flow can occur in a virtual Linux PC.

One of our brainy guys hacked colinux to tunnel the parallel port, so we run impact inside CoLinux with vanilla Xilinx drivers - it couldn't be much easier.

The decision to not support Windows (Cygwin) for MicroBlaze uClinux development is a difficult one, but justified I believe by experience in the misery of Cygwin. Cygwin is just enough like Linux to make you think "it should work", but just different enough to make life miserable.

Some of these restrictions come from underlying Windows crud, like case insensitive filesystems, poor handling of file permissions, that sort of thing. Linux sees a difference between 'makefile' and 'Makefile' - windows can't. While nobody would recommend overloading filenames in this way, there's not a lot that can be done about it retrospectively without (IMO) inordinate effort.

It's also dreadfully slow - compile times can be on the order of 2-3 times longer.

Anyway, perhaps we should package up our CoLinux environment a bit better and distribute it, it might make life a bit easier for people in your position (and those stuck in MS Windows corporate environments).

Regards,

John

Antti Lukats wrote:

Reply to
John Williams

Hi John,

It would be *very* nice to have pass-through parallel port access from CoLinux. Personally, I'd be looking at it for debugging a ColdFire running ucLinux rather than any Xilinx work, but I suspect it would be of interest to a range of embedded developers. I know the CoLinux developers have been looking at the possibilities of tunnelling serial ports, parallel ports, and USB, but have had problems with locking issues. If your "brainy guy" has working code, perhaps it could be donated to the official CoLinux project?

mvh.,

David

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.