Hi. We just finished getting an ibob up and running from the prom, and we saw a few strange things that might be related:
1) We had to cycle the power to get the design to load into the FPGA, even when we checked the right boxes. This is unusual, but not unheard of. 2) We couldn't even get it to do this without loading a different design in first, and then erasing the prom. This sounds like BS, but it's true! But we don't load our ibobs very often, having set the proms to a standard design, and left them alone. I second the idea of putting a scope on the daisy chain signals and looking for poor signal integrity. John > 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 >> >> >
