If you're having issues with the parallel cable in Linux, the USB JTAG
cable DLC9G "Platform Cable USB" works fine in Linux.
Impact should not return success unless the transfer really was
successful. Apparently there's a CRC that is performed to confirm this.
Jason
On 28 Jan 2009, at 21:12, 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>
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
