Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
in [FPGA]
|
From: Bob on 6 May 2008 12:38 On May 6, 11:33 am, "MM" <mb...(a)yahoo.com> wrote: > > Okay, but I don't know how to do this. Where do I "pick the code" > > that you refer to? > > Martin is talking about the source code for the microcontroller... Oh!!! Do you mean this user-supplied function? void waitTime(long microsec); Now we're talking! The version I got suggested three approaches, one that pulses TCK, one that doesn't, and one that does for short durations, and doesn't for long ones! Well, I chose the one that simply delays, as the comments suggested that's okay for Spartan-3; on the other hand, the default does pulse the TCK! Since this is in agreement with Martin, I'll try that tonight, and report back... Thanks, guys! Bob
From: Bob on 4 May 2008 10:50 On May 2, 11:34 pm, "MM" <mb...(a)yahoo.com> wrote: > I guess Antti is right... Anyway, which version of the tools are you using? 9.2i > What is you microcontroller? Freescale MCF5234 Coldfire > Do you have any external pullups? No. > Do you disconnect the cable when running your player? Yes > There is a number of Answer Records on Xilinx site, which might be relevant to your problem. > e.g.http://www.xilinx.com/support/answers/22255.htm I've looked, but I can't seem to find one that helps... I need to get this working by Friday, so I hope someone has some ideas? Thanks, -Bob
From: Andreas Hölscher on 5 May 2008 10:30 Bob, (04.05.2008 16:50): >> Do you have any external pullups? > No. Did you check "Drive Done Pin High" in the startup options? Andreas
From: Bob on 5 May 2008 10:47 On May 5, 10:30 am, Andreas Hölscher <andreas.hoelsc...(a)dsa-ac.de> wrote: > Did you check "Drive Done Pin High" in the startup options? Maybe, but I don't think so. I thought of trying this, but I'm not convinced it has anything to do with it. DONE not going high is just a convenient way to tell if the configuration was successful, as I have it controlling an LED. Furthermore, the configuration is not "taking effect", and the FPGA remains unconfigured. On the other hand, if this "option" is automatically applied by iMPACT when it is doing an actual FPGA configuration, but it is not added to the recorded .svf or .xsvf files, then you may be right. So, I will try it tonight (~8:30 PM EDT), and let you all know. In the meantime, in seems there are a number of potential "gotchas" with various options that may be applied to the bit file generation process. Or to put it another way, I've become quite concerned that I'm missing some critical options that may well be documented somewhere and I messed it, or perhaps something everyone assumes I know when in reality I don't. Can someone who has done this give me a concise list of options they used, or what options are critical, or can point me to documentation on this (other then XAPP058)? Whatever is easy - I'm not asking for anything fancy. Thanks! -Bob
From: MM on 5 May 2008 12:06
"Bob" <rsg.uClinux(a)gmail.com> wrote in message news:286aab22-ec7d-4c46-b232-049bd306e451(a)a23g2000hsc.googlegroups.com... > On May 2, 11:34 pm, "MM" <mb...(a)yahoo.com> wrote: > >> Do you have any external pullups? > No. I am not sure if this could be your problem, but... normally JTAG signals require pullups. Bitgen can (and probably does) enable them internally, but personally I've never relied upon them and always designed in external resistors... The behaviour with iMPACT might be different because there might be some pullups inside of the programming cable and/or simply the drivers/receivers are different. /Mikhail |