if it works with one ibob board (no chaining),
i suggest buying (or asking xilinx to donate)
four USB download cables.
dan
Rurik Primiani wrote:
Hi everyone,
Thanks for the replies! To clarify a little more, our system is now on
the summit of Mauna Kea so physically checking jumpers and changing JTAG
configurations may be difficult due to the time difference (we're
working remotely from Cambridge at the moment). Jason, I did however
make sure to leave the mode jumpers on 3-4. And thanks for the tip on
Impact, I'll see if that helps.
We were experiencing JTAG chain initialization problems in Impact with
more than four boards attached but this was attributed to TCK being
overloaded. We're working on a buffered JTAG chain but for now will
leave the summit installation at four. Our end goal is to freeze our
designs and use the EEPROM for programming on startup but we'd like to
have a JTAG chain installed and ready in case our designs change.
Perhaps we're still seeing TCK integrity problems but on a much more
subtle scale? If so, and the bitstream weren't loaded correctly, would
Impact still return a success?
Andrew: a power-cycle typically fixes the problem. Only very
occasionally is another power cycle needed. I'll get someone on the
summit to switch a board over to a different serial port and/or switch
to a machine with a different OS altogether and see if that works. It
does not appear to be an issue with the multiport switch as the same
behavior occurs on another linux machine with a built in serial port.
David, Dan and Oren: I have not tried it with one iBob on the chain or
other methods of programming as the four-node case has worked perfectly
in all other respects. The DONE lights are something I always noticed to
be funny. On some iBobs the DONE lights never go on but serial
communication still works fine. On one of them the DONE light always
comes on after reprogramming and stays on whether or not the serial port
is hung or not. When we attempted to increase the chain length we
considered probing the JTAG lines but were in a hurry to ship to the
summit and so left the system with only a four-node chain in place. We
are using Parallel Cable IV but in compatibility mode (with Parallel
III) as the linux driver does not support it otherwise.
When using our system in Cambridge I just assumed that a reprogramming
event could occasionally stall the PowerPC running TinySH and thus hang
the serial port as well. This made sense to me at the time since serial
communication was always successful on a cold start. If this were a JTAG
programming issue would Impact consistently return successfully? Am I
correct in thinking that TinySH handles serial communication?
Thanks again for your responses and sorry for the length of the email.
We're working on getting IP power switches so we can do remote
power-cycling but it would also be nice to shed some light on and maybe
even fix this issue.
Best,
Rurik
On Wed, Jan 28, 2009 at 1:31 AM, Oren Milgrome <o...@berkeley.edu
<mailto:o...@berkeley.edu>> wrote:
Hi Rurik, maybe you already know this, but there is some useful jtag
debugging info from Xilinx at:
http://www.xilinx.com/itp/3_1i/pdf/docs/jtg/jtg.pdf
In particular, this note explains the difference between hi-z and bypass
modes for noise immunity in multi-device jtag chains. Next time it
fails,
check the state of the TDO pins with a voltmeter to verify they are not
stuck low.
Best Regards, Oren
> Hi everyone,
>
> We've been experiencing issues with hanging serial ports when
> reprogramming
> our iBob's over JTAG. Our setup at the moment is a linux control
computer
> with an 8-port serial-PCI card with two iBob's attached and four
iBob's
> total on a JTAG chain (the first two being the serial-linked ones).
> Programming works just fine and from a cold start so does serial
> communication usually.
>
> The problem occurs when we reprogram a board with a *different*
bitstream,
> the serial port hangs permanently until the iBob's are power
cycled and
> reprogrammed. Programming the same bitstream typically does not
break the
> port. Occasionally however even the power-cycling and
reprogramming does
> not
> bring back the serial ports. It does not seem to be the specific
designs
> because they usually work after this procedure, instead it seems
to be
> linked to the reprogramming.
>
> Has anyone seen this behavior before, or something similar to it? It
> appears
> to me that during an iBob reprogramming some pin that controls
the serial
> port fails to go low but perhaps it's a linux multi-serial port
problem?
>
> Thanks for your help!
> Rurik
>
--
Oren Milgrome
University of California - Berkeley
Radio Astronomy Lab 601 Campbell Hall
Berkeley, CA 94720-3411
mobile: 510 368 6857 office: 510 642 5509
lab: 510 642 0381 fax: 510 642 3411
email: o...@berkeley.edu <mailto:o...@berkeley.edu>
