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 <[email protected]> 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: [email protected] > >
