Jump to content
  • 0

Vivado Hardware Manager disconnects CMOD-A7 target in Win7


zygot

Question

This issue had been a pain ever since I started using the CMDO-A7 devices. In Windows 7, using Vivado 2016.2, if I open the hardware manager in Vivado to configure the device, after a few minutes Vivado decides that the target is no longer available and disconnects it. This is a particular problem when I am also using the USB UART... though the problem doesn't happen immediately. This issue makes using the ILA extremely difficult to impossible with this board.

When I use the Adept Utility for Windows to configure the board I can use the UART all day without a problem. I suspect a JTAG/UART driver related issue is to blame.

Link to comment
Share on other sites

24 answers to this question

Recommended Posts

Well, since this keeps getting batted around, after years of customers reporting problems,  I'll just repeat what my situation is.

I have 2 of the earlier CMOD-A35T modules. I have a drawer full of micro USB 2.0 cables that I got with many FPGA development boards. Whenever I use one of the CMOD modules for a project I just randomly select on of the unused USB cables. I've never had an issue programming either of the modules using either Vivado Hardware Manager or the Adept Utility for Windows. I consistently have an issue with the USB endpoint getting detached when the board is configured and Vivado Hardware Manager is running such as when trying to use the ILA functionality. I also have a similar problem with Vivado Hardware Manager running while trying to use the COM endpoint with another application such as Putty. I've stopped using the USB cable UART functionality and now use a TTL USB UART cable or breakout board and spare IO pins. I now just create my own debugging functionality to replace the ILA. The CMOD is the only FPGA board that I need to make such accommodations for.

Are there bad USB cables out there? Sure. Could Digilent have resolved this issues years ago by just providing a cable with their boards? Maybe.

Note that the smaller cheaper FT2232 devices have fewer ground and power pins than the older devices in larger packages. I doubt that issue is resonance  (EMI) related. I haven't seen any indication that there is a general issue with any of my designs requiring too much power ( or more importantly too much instantaneous power ) than the USB 2.0 specifications delivers; but I also don't pretend that these modules are just like normal sized boards except smaller so my designs are appropriate to expectations. There's no doubt that using an FPGA board that can only be powered through a USB 2.0 cable is problematic; for a number of reasons. Personally, I suspect that the board stackup design is more of an issue. There just isn't a lot of mass to these things. From my perspective there likely is a driver issue involving Vivado hardware Manager and VCP. I can say that things on the Intel side with it's JTAG/COM enumeration are a lot worse. I don't think that FTDI planned on the success that it would have when it created it's first multi-endpoint devices.

Adding a capacitor for bulk storage will certainly help if the issue is an inability of the USB upstream port to deliver instantaneous current requirements. This would be, in general a design specific phenomena.  Can users create a design for the 35T that requires more than the 500 mA USB current provided? Almost certainly. The CMODs just aren't tiny ARTY boards. By the way the most recent thing I did using the CMOD-A735T board was last month for my post on SOC Strategies. This involved hooking up an FT232H in Synchronous 245 FIFO mode with average data rates > 40 MB/s so my designs haven't all be simple low speed ones.

I can't for the life of me figure out why I need to be repeating myself once again. This issue has always been simple to resolve ( assuming that cables are an issue ) and that is for Digilent to take responsibility for it's own products and supply cables that work. So the imaginary cost is a bit higher. The real cost to the consumer would be lower as I'm sure that Digilent can buy cables in the 1K lot cheaper that users can buy individual cables. Now this isn't just a Digilent problem as everyone seems to be supplying products without required components in order to create a false impression of the actual cost of the product. You can buy a Raspberry Pi 4 cheap, but by the time you get the non-standard power supply and HDMI cable, and Micro-SD card in order to actually use the thing your costs are twice what you paid for the board. Vendors.. stop it already!

Making problems created by vendors bad decisions a customer problem might seem to be the easy path but it's really a bad idea on very many levels.

 

Link to comment
Share on other sites

We have found that a 100nF capacitor attached across VBUS and ground near the connector makes the Cmod A7 more tolerant of out of spec cables and we will consider adding it to a future revision.

There aren’t any pads for the capacitor, which makes it a bit challenging to solder in a 10V, 100nF ceramic capacitor. We managed to stack it on top of half of D1 and half of C65, which are both on the bottom of the board.

image.png

When testing with USB.org certified cables, we haven't been able to reproduce any connectivity issues.

We also recommend plugging in the cable into a port directly on the motherboard or into a USB hub instead of a front panel USB port.

Link to comment
Share on other sites

11 hours ago, xc6lx45 said:

Maybe it's even more a question of ESR than capacitance.

That's the main reason I was so surprised the questionably old 47uF electrolytic loosely dangling off the power pins made such a difference. The spikes I was seeing with the scope were relatively high frequency (High frequency for me anyways, 500MHz >> x >> 100MHz) and I would have thought an electrolytic would not have made much in the way of a difference. The sketchy electrolytic is a low bar to set, and I feel good about calling my work better than that, so I'm willing to hope for good behavior with my project.

And the board I'm putting together for the CMOD-A7 is an "RF" front end so I'm distributing that ~60uF across the board in appropriate locations, though I'm only doing 10uF and 100nF caps, but the project is also not required to pick up anything above about 5MHz so I mean really is it RF? Either way, I've spent a healthy amount of time looking up best practices to treat this as a dry run for actual high frequency PCB design. I'm a bit on a tangent here, but I'll post up in the projects section at some point soon.

Link to comment
Share on other sites

>> having about 60uF of ceramic decoupling goodness

Maybe it's even more a question of ESR than capacitance. Ceramic if money doesn't matter (e.g. Mouser: 22 µF: €4..6).
The typical solution are staggered capacitors, with a quick look at the datasheet for the self resonance frequency in the impedance curve. I do this for RF (try to get a quality short at n GHz...) but if I had to make a blind guess, I'd use two orders of magnitude, e.g. 10 µ, 100n, 1n and with a nervous glance at my Voodoo doll, 10p.

The CMOD A7 is reported quite frequently (possibly because it's one of the most attractive boards) but I can tell that I've run into the same issues with FTDI's reference module for the 2232H. The chip just shuts down if it doesn't like what it sees on VCC.
It took a long Friday night in the lab to prove without doubt that our system is sensitive to USB cables. We changed the design and shipped with non-detachable cable. Zero issues so far.

Link to comment
Share on other sites

I'll drop my two cents in here, though it looks like a pretty well hashed, but I think there's a pretty simple explanation that either got missed, or I missed in reading the thread.

I show very similar issues with the CMOD-A7 disconnecting from my laptop. I took a scope to the USB power pins and found 2.5 volt transients across what I'd guess is the main  USB power decoupling capacitor.

My connector is about one inch long. Just a USB A male to micro USB male adapter.

I didn't have any issues when using a ~3 foot long USB cable with a ferrite bead, and there were no issues when I was plugged into a USB splitter using the 1" connection. Odd.

So, being the undergrad student, I broke the USB rule of 10uF and just mechanically wrapped the legs of a 47uF crummy electrolytic cap between the ground and VU pins, and made sure the electrical connection was good and secure with a small piece of electrical tape (I'm being sarcastic, just to be clear) BUT! Much to my surprise with such a janky setup, the problem just about vanished.

Lucky enough for me, I'm going to be plugging the FPGA into a PCB that will wind up having about 60uF of ceramic decoupling goodness, so I'll already be adding the soft start protection to meet the USB spec, and I can keep using the teeny tiny 1" connector, I think.... Time will tell.

In my eyes, USB power is really surprisingly noisy or something on the FPGA is pulling very ugly power spikes. I'm inclined to blame USB, but either way the parasitic inductance of a long cable and or ferrite bead seems pretty important for this little device. Oh, and I'd assume the USB hub fixed the problem by adding its own power management circuitry, after all, you wouldn't want all of the other devices attached to disconnect because of a power dip from plugging in something new.

I also made a lot of assumptions here, so please, I'd love to hear your thoughts.

Link to comment
Share on other sites

2 hours ago, jpeyron said:

I am glad to hear that you are now able to consistently use the Cmod A7

I didn't interpret the post by @dftmax  as stating that all of the CMOD-A7 USB problems have been vanquished using a particular cable. I appreciate his testing approach and methodology, though not necessarily his conclusions; and he doesn't conclude that there are no more problems after 10's or 100's of uses with the cable of his choice.

If you look at my original post, it isn't about not being able to configure the board. In fact I've never had a problem configuring the board. I've had consistent  problems using the USB UART functionality with Vivado Hardware Manager running. Obviously, the scope of the issue is larger than the one that I reported.

The CMOD-A7 is unique in that it is designed to be powered through the USB cable, which also happens to provide the USB UART and JTAG functionality. Issues with that interface obviously reduce it's usefulness.

Let me make a few assertions that I believe deserve a reply from Digilent:

  • A USB connected device that is fussy about what cable is connected to it ( as long as the cable meets the specifications of the USB standard ) has a design flaw.
  • If Digilent wants to make the case that careful selection of a cable 'fixes' the design flaw of one of it's boards then Digilent should sell the board in question with a cable that provides a usable board without issues. The price of board plus cable should be a bit higher. Selling a product that's unusable as shipped is problematic, though providing an option to buy quantities without a cable might be OK as long as there's a warning about cable selection. (Still refusing to provide a list of approved cables?)
  • The CMOD-A7 has USB connectivity issues that are unique compared to any other FPGA board made by Digilent. I can read posts as well as anyone else. I own an use the ATLYS, GENESYS, GENESYS2, and NEXYS_VIDEO on an on-going basis ( plus the 'we'd rather not be reminded that we made this product' FMC-Carrier-S6.. rest in peace which both self immolated due to design flaws ) , as well as a  myriad of Spartan3 era boards made by Digilent. That's just the Digilent FPGA boards...

Issues like configuring an FPGA board with a design that causes power supply or thermal issues are separate matters that can affect all FPGA boards. When a manufacturer sells products to technically astute customers there is an expectation that the products will be properly specified and tested to meet those specifications. Of course, this comes with a much higher price tag. (clearly, when the user design can over tax power supply and thermal dissipation capabilities of a board this aspect is difficult to specify ). Vivado does provide help some help in anticipating current usage for any design. Hopefully, the technically astute customer will be thinking about these things when trying to use a product. The less technically astute customer is more likely to find deficiencies in these areas unintentionally though  experimentation. It seems to me that trying to ignore issues is just a bad plan.

I am not complaining about the CMOD-A7 as a product. I've adjusted to it's flaws and I don't try to expect too much from it. I now use a separate USB UART cable to do UART interfaces. Yeah, I could think of the board as being more expensive than the list price suggest, but I just care about getting projects completed. I've managed to do just that with the 2 CMOD-A735T boards that I own for quite a few projects now. I realize, and so should Digilent, that not all customers will have as favourable outlook as I do.

Link to comment
Share on other sites

I realise that my posting was quite long, so perhaps my main point went unnoticed.

I am more and more sure that the issues seen by zygot, myself and others are related to the voltage drop resulting from poor quality USB cables. 

Just to re-iterate. My PC is under a desk. I have a USB lead plugged into the back of the PC (i.e. the motherboard itself) which goes to a Dell monitor. I suspect that the Dell monitor behaves like a powered hub. I then have a USB lead from the Dell to a small 4-port (unpowered) USB 2.0 hub. The CMOD-A7 connects to this hub by means of a USB lead.

I use a USB voltage monitor to measure the off-load voltage seen at the output of the 4-port USB hub. It is 4.9V. The 0.1V drop almost certainly dropped by the USB cable connecting the hub to the Dell. I connected the CMOD-A7 to the hub with the 4 (random) micro-USB leads which I had. I measure the reduced voltage at the output of the hub and the voltage between the gnd and Vu pins of the CMOD-A7 (i.e. both ends of the USB cable).

Lead type  / voltage measured at hub / voltage measured at CMOD-A7 / notes

Very short white lead / 4.75V / 4.22V / is not recognised by Win10

Black "velcro" lead / 4.75V / 4.33V

Long black lead / 4.76V / 4.36V

Very long white lead / 4.74V / 4.38V

So the shortest lead (6 inches) has the worst voltage drop, and the longest lead has the lowest voltage drop. If I plug the long white lead into the USB of the Dell monitor I measure 4.60V at the CMOD-A7, and it finally programs correctly in Viviado with no disconnects/re-connects.

My suspicion is that some leads will drop enough voltage to "upset" the FDTI chip, which in turn really screws up Win10.

Also if the application currently running on the CMOD-A7 is power hungry, it will just exasperate the voltage drop.

I hope this clarifies my point and might help other users of this excellent FPGA board. It also ties in with the suggestion from Digilent to use a powered hub. I would also suggest that the voltage drop across a selection of USB leads be measured in order to pick the best "quality" lead. Finally it might be worth using a pin on the board as a "low power" pin, which can be tied low (for example) during programming to minimise the current. In the RTL this input would disable PLLs and clocks. I use one of the button as a reset and noted that when pressed the current taken by the CMOD-A7 reduces and so the voltage measured at the CMOD-A7 increases. For user suffering marginal problems this will minimise any voltage drop (which we now know screws up the FDTI chip), and might be sufficient to allow the FPGA to be programmed.

--Gary

hub + CMOD voltages (1024x768).jpg

Link to comment
Share on other sites

4 hours ago, dftmax said:

The current circuit has 150MHz operation and OSERDES at 750Mbps (1080p HDMI - which amazingly does work).

Since I've pretty much said everything on the CMOD-A7 USB interface topic that I have to say and that doesn't appear to match what others are reporting I was going to sit your post out. I've since concluded that perhaps I might have some thoughts worth pondering.

  • The Artix device is a very small package on a very small PCB. If Digilent were selling commercial grade products it would have to characterize and specify the boards thermal characteristics. Personally, I see these modules as perfect for small control and sensing projects, not for complex designs with high speed IO. It's easy to add a DRP component to keep tabs on the Artix internal substrate temperature. I do this for all Series7 designs even with boards that have a heat sink and fan like the Genesys2. It's just a gut feeling on my part from years of electronics design but I'd be very queasy about trying to push the boundaries of these boards given small surface area, crowded component footprints,  and likely minimal number of pcb layers. There's no doubt in my mind that a user can stuff a design into these boards that will cause thermal issues. The same goes for other FPGA boards.
  • On USB cables. Again,  I've not been able to replicate the experiences related by Digilent or others by swapping cables. Note that Digilent does not supply or recommend a particular cable as guaranteed to resolve whatever design issues these boards have. Like you, the CMOD-A7 is the only one of dozens of FPGA boards, mostly from Digilent, that I've ever experienced this difficulty with. I want to note that USB 2.0 is backward compatible with every verison of the USB standard down to the days when 1.5 mega-bits/s was good enough. There are some very old cables out there. Fortunately none of the really old ones have mini-B type connectors. There are a lot of crappy cable manufacturers out there these days but if all your cables work without issues on all of your devices except for one board then it's hard to blame cables... Digilent can and should fix this, even if it's as simple as publishing a list of cable that are guaranteed to work with this problematic product.
2 hours ago, xc6lx45 said:

Test with a different PC.

I can't see the logic in this statement. I've never had a PC be an issue. You might try connecting your module directly into your PC instead of a HUB. You didn't mention if your HUB is independently powered or not.

2 hours ago, xc6lx45 said:

USB is a mess, and creating a reliable high performance USB bus-powered design may be much harder than most people would expect

USB is a mess if you don't understand the standard and haven't taken the time to design and characterize real-world USB applications. As to the second half of that sentence, yeah, I'll jump on that bandwagon. Here's what I can say without qualification. I've done a lot of FPGA designs using USB 3.0 or earlier. Almost every design requires a slightly different FPGA implementation to fit the project requirements. There's no one HDL interface that addresses the needs of every project. Selecting the right parts and vendor also helps. Don't blame the standard; it's been remarkably scalable through the years.

Link to comment
Share on other sites

Hi,

4 V does not seem right. I think you should supply the board externally (not through USB but use the external power input).

Test with a different PC. Yes it's inconvenient but it may save you many hours. Or if not possible, put in at least a different USB card.

USB is a mess, and creating a reliable high performance USB bus-powered design may be much harder than most people would expect ("high performance" because an FPGA is by far the most sophisticated electronics component ordinary mortals get to play with).

For curiosity, read up on polyfuse memory, one root cause why those things can be near-impossible to debug. And the minimum number of cycles on USB connectors. And the recent crisis regarding low quality USB cables (and no one would have cared if they hadn't caused things to actually break).

 

Link to comment
Share on other sites

I would appreciate any help. I have having a nightmare trying to program the CMOD-A7 in the Vivado programmer manager screen.

Background. I use a PC and WIN10. I bought the board some time ago and followed the tutorial and burnt the switches and LEDs demo into the board. I am now working on a real project, based on Hamsters HDMI on Artix 7 web page. Whenever I open the programmer manager in Vivado it is highly unstable and get disconnects and error windows. There is another thread where someone posted a snip of the error box. It gets so bad that my USB hub locks up and the CMOD-A7 is no longer recognised (in any USB port). 

I have searched the forums and found relevant threads. It appears that I am not alone with this problem. Digilent suggest using a high-quality USB cable (I have no idea how you determine what is high quality). They also suggest using a powered hub. Others have reported success using shortened USB cable.

This lead me to think that the issue might be caused by the voltage drop over the USB cable run from the PC motherboard to CMOD-A7. Also these micro USB cables tend to be very thin, and therefore the gnd and +5V wires are likely to be very thin. From painful past experience there can be a substantial voltage drop over a short distance. For example I plug an extender cable into a front port on the PC, which in turn has a cable running from the front port to the motherboard. I then use what appears to be a high quality cable from the extender to the CMOD-A7. That's quite a few feet of cable! My (unpowered) hub to which I normally connect the CMOD-A7 (due to convenient placement) connects from a monitor which is turn connects to the PC (PC <-> Dell <-> 4-way hub<->CMOD-A7).

Also I would like to point out that I have several other FPGA boards, Altera, Xlinix (3E and Spartan6), some of which use the FDTI FT2232 chip, and they all have had no problems when connected to my hub (even with multiple other devices connected). This also suggested to me that perhaps the issue could be made worse due to the higher power of the Artix chip. This in turn could be made worse depending upon the frequency of your circuit. When I played with the simple switches and LED example, I don't recall having problems (but it was 4/5 months ago). The current circuit has 150MHz operation and OSERDES at 750Mbps (1080p HDMI - which amazingly does work). So if the flash is programmed with a heavy current load application the instability when programming could be made worse?

The past few days I have been unable to program the flash. I just get the disconnect error box from Vivado. Searching for the programmer just loops finding nothing.

I did some measurements. The end of the extender plugged into the front panel, shows 4.4V using a USB voltmeter ($10 from Ebay). I use a simple digital voltmeter across the Vu and GND pins of the CMOD-A7 and this reads less than 4V. The LEDs still light, but perhaps the FDTI chip might struggle and crash/lock-up? This isn't the normal way I connect.power the CMOD, but the voltages given to show that +5V at the end of the USB cable is not to be taken from granted.

So I used my Rigol power supply to actively power the hub (for the first time). Ironically the power lead was thin. I set the Rigol to +5.40V. The USB voltmeter plugged into the hub read 5.3V, and the voltmeter across the VU/gnd pins now read 5.0V. I now though that I wouldn't have any problems. Wrong!!!

Hoever for the first time I was finally able to program the flash, overwriting the old switches and LED code with the HDMI code.Now I only had problems with the Dell recognising the 1080p signal!

It's all a bit hazy but Vivado started to display the usual connection lost error box. I found that my hub was locked up (could have been  due to the overvolt - but I doubt it as this lock-up is what happened the day before). The UART was displaying as COM12 in the Windows device manager. When I unplugged the CMOD-A7 the COM12 entry stayed. When the system  is working it goes away. I tried plugging the CMOD-A7 into another USB port, but there was no bing-bong-bing recognition. There was when I plugged in a USB drive. Clearly the PC was all confused (perhaps it was still confused thinking that the CMOD-A7 was plugged in, so refused to recognise it in another port???). Even asking for a USB re-scan the COM12 did not go away. Plugging the USB into the hub did not work. The PC was clearly not happy with the hub. The only way out was a complete re-boot. I tried modifying the code to 720p HDMI, but the same set of problems occured again, and once again the PC stopped responding to anything plugged into the hub. In this condition I ran Adept-2 and it just hung.

At this point I gave up.

I thought that fixing the voltage drop would fix the FDTI communcation problem. It didn't. The hub lock up also happened the day before, so it's nothing to do with powering the hub. I am at a loss of what to do, and I am getting pretty frustrated.

HELP!!!!!!!!

regards..

--Gary

 

 

Link to comment
Share on other sites

I have 3 CMOD A7's, and I had no trouble on my old Lenovo box, no matter what cable I used.  I moved to a new high-end HP Zbook, and my CMOD A7's were unstable--kept connecting and disconnecting from the hardware manager, in and endless loop.  I was using a garden-grade USB cable.  After reading this blog, I switched to a short (18 inch), very high end USB cable, and the problem went away.  So, it would appear that the cable is a factor, but the USB PHY on the PC may also play into this problem (which is why some people might experience a different result with the same cables, etc.)

Link to comment
Share on other sites

I also seem to be having this issue. Board will stay connected indefinitely but as soon as I program any new design, it will drop out in a matter of seconds. I have been trying all the USB cables I own. Do you have a specific cable that you know to work reliably?

Link to comment
Share on other sites

@JColvin

You are still focusing too much on the cables.

The only statement that really needs to be addressed, and is probably an understatement is:

>Also, it is my understanding that the Cmod A7 (for reasons unknown to me) appears to also be more susceptible to this

I agree, you do have a USB design issue, I suggest you give all existing users of this product a discount voucher for your new improved USB re-designed Cmod-A7 ;) and like I have said before, if you did not hide that part of the circuit, which is crazy, us engineers/customers could help you out with that design .... for free.

Cheers,

B.

Link to comment
Share on other sites

Hello,

Here is my understanding of the situation based on the email that I received from our senior engineer who did the analysis:

Over the past day I spent a fair amount of time looking into the Cmod A7 USB instability and made some interesting discoveries:
1.       If I use the Chinglung USB A to Micro B cable and run a JTAG ID code loop then there will be a random USB error after 9K – 300K iterations. This is consistent and easily repeatable with 5 different Chinglung cables and 2 different CMOD A7 15T’s that I tried.
a.       I used a USB packet analyzer to log the USB transactions and found that when the USB error occurs the FTDI device has stopped responding to IN tokens. Normally if the device is busy or doesn’t have any data it will issue a NAK response or a STALL response. But at the point of failure no response was being received, which is why the driver prorogated an error upward to the host side software.
b.      I hacked one of these cables open and much to my surprise I found that all four conductors were twisted together in a manner such that noise or GROUND or VBUS could couple into D+ or D-, but not necessarily both. This is bad because that noise won’t be rejected and can result in data errors.
2.       If I use the Digilent branded retractable USB A to Micro B cables, which we no longer sell, then I can run the ID code loop indefinitely without error.
a.       We stopped selling these cables because they don’t have a shield, and therefore do not meet the USB specification.
b.      These are the same cables that I validated the design with years ago because they were what I had on my desk at the time, so that explains why I didn’t notice this problem.
c.       These cables twist D+ and D- together and then run GROUND on one side and VBUS on the other. Noise from either of those should couple equally into D+ and D-, which is good for rejecting any power supply noise that flows through the cable.
3.       If I use the Evernew USB A to Micro B cables that we have downstairs I can run the ID code loop indefinitely without error.
a.       These cables have a shield and it’s connected on both ends.
b.      I hacked one of these cables open and D+ and D- are properly twisted together with Ground and VBUS running parallel alongside. Once again, this is good for rejecting any power supply noise that flows through the cable.
 
Given this information I suggest that we recommend customers who run into problems try using USB .org certified high speed USB cables, as those as those are pretty much guaranteed to be properly constructed and should work. I do NOT recommend using any Chinglung cables. By the way, the Chinglung cable is the cable that we’ve been kitting with our products for the past 8 or 9 years, and up until recently, it was also the cable that we shipped to customers when they ordered cables separately. Therefore it’s very likely that anyone who bought a USB cable from Digilent likely has one of these Chinglung cables.

Also, it is my understanding that the Cmod A7 (for reasons unknown to me) appears to also be more susceptible to this, so we are working on a different design for a future revision that will help address this. 

That is all the information I am aware of though.

Thank you,
JColvin

Link to comment
Share on other sites

@bmentink

Thanks for adding your observation to the thread.

@Bianca

I think that we can agree that "it's the cables" is a bit unsatisfying from an engineering perspective. Use "high speed" cables, whatever that means to you,  isn't any better. Perhaps you could supply some specific USB cables from specific vendors that appears to obviate the unfortunate disconnection issue when both JTAG and UART functions are needed. I can't argue with your premiss without concrete and specific information. I certainly could be wrong about this but is sure smells like a driver issue... unless you can provide a mechanism for how using the UART causes the FT2232HQ to initiate a driver disconnect. As the issue from my experience involves using the UART functionality while Vivado hardware manager is running and occurs at unpredictable intervals your argument certainly has the appearance of being implausible.  Of course your customers are at a disadvantage in helping as Digilent has chosen to replace that circuitry with a blank page in its published schematics.

 

Link to comment
Share on other sites

@zygot

This USB issue is also discussed at the end of this thread:

https://forum.digilentinc.com/topic/5034-artix-a7-non-gui-development/

Digilent have been very quick to blame the cables ... but like you, I have used my "faulty"  cables on a number of other vendor boards without issue.

Looks like Digilent have some re-design to do regarding the high speed USB area of the board. Let's hope version II is better .. ;)

There is even a similar issue on the Xilinx forum that could be this fault:

https://forums.xilinx.com/t5/Welcome-Join/Problem-with-Cmod-A7-JTAG/td-p/792624

@Bianca

Your signature is very apt for this issue: :) Love it ..

Link to comment
Share on other sites

Hi @zygot

We also tested the same cable with other boards. It seems that the Cmod  is more affected. It happens even with our cables, so if you have cables from Digilent, don't use those. We are working to solve this out but for now, high speed USB cables are working. 

Best regards,

Bianca

Link to comment
Share on other sites

@Bianca

Thanks, I will try to verify. I have to say that I use the same USB cables without incident on other boards from Digilent and other vendors without incident so I'm a bit skeptical about your conclusions ( I usually keep USB cables supplied with boards attached to that board....)

Link to comment
Share on other sites

Hi @zygot,

Sorry for the delayed answer. The problem was looked into and it seems that the issue is caused by the USB cable. Please try to use a high speed USB cable as those are pretty much guaranteed to be properly constructed and should work without having data errors

Best regards,

Bianca

Link to comment
Share on other sites

Hello @zygot,

Sorry for the late reply. I wanted to try and replicate this behavior and tried to connect the board to the HW Manager without the UART to see if it crashed and it did but it took it more than 5 hours. After that I opened a terminal to see what is happening. I checked Vivado after about half an hour and the target was already disconnected. 

We started to look into the issue to see exactly what is happening.

Best regards,

Bianca

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...