Digilent CMOD A7 Disconnects and/or does not Program

[Christian Klein]

I've seen similar issues in the forum, but no real solution.

I have 5 CMOD A7 boards and only 2 of  them behave properly.

The other 3 do not accept a program and sometimes disconnect.

I get the following errors;
ERROR: [Labtools 27-3165] End of startup status: LOW
ERROR: [Common 17-39] 'program_hw_devices' failed due to earlier errors.

I have tried:

- many different USB cables

- Different ports on the PC

- Powered USB hubs

- Vivado Lab 2017.2 and 2018.1

- 2 different bitstream files

 

The boards that work, always works. No matter the cable or USB ports.

Anything else I should try?

 

 

 

 

[vicentiu]

[malexander]

@wfpga

The USB shield is AC coupled to ground through a 1nF capacitor with a 1M ohm bleed off resistor, which is the same way we’ve connected USB shield on 95% of our boards.

I just reviewed the datasheet for the LTC3589 regulator and I don’t see any issue with the existing power supply design. Sure the diode adds an additional voltage drop (approximately 350mV at 500mA) that would result in VU being below 4.5V when VBUS as seen by the device is 4.5V, but its still over 4V, which is well above the undervoltage lockout threshold (2.5V) and well above the area where the output would be unregulated because the LTC3589 is capable of 100% duty cycle and at 4.15V the duty cycle is ~80%. If the input voltage were to drop low enough that 100% duty cycle were required to output 3.3V then the minimum voltage for VU would be (0.265*0.6)+(0.170*0.6)+3.3 = 3.561V so I don’t see this being an issue. Using an external power supply may give you a better ground reference then the one provided by the USB cable and provide better noise immunity, especially in the case of a poorly constructed USB cable.

[dfergenson]

Thanks. Got it. I'm going to attempt to implement the fix and will report back when I've been able to reproduce it.

Do you know if this will be addressed in future revisions to the Cmod A7 product line?

-David

[zygot]

4 hours ago, malexander said:

Using an external power supply may give you a better ground reference then the one provided by the USB cable and provide better noise immunity, especially in the case of a poorly constructed USB cable.

Hopefully. when Digilent spins the next CMOD they will provide a better arrangement for using the configuration circuitry with an external power supply. Even as a standalone module configured from flash 1 Vcc pin and one GND pin is less than ideal, and likely problematic if the FPGA is driving or receiving a number of single-ended signals.  

[hamster]

57 minutes ago, zygot said:

Hopefully. when Digilent spins the next CMOD they will provide a better arrangement for using the configuration circuitry with an external power supply. Even as a standalone module configured from flash 1 Vcc pin and one GND pin is less than ideal, and likely problematic if the FPGA is driving or receiving a number of single-ended signals.  

Anything that uses 0.1" headers is more of a "use on a breadboard for learning/experiments" than a serious module for integration... 

[vicentiu]

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.

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.

[fentonc]

I've been experiencing this same issue with my Cmod A7-35T board, and I would love a solution to it. I've seen flaky behavior across multiple USB cables and 3 different computers (a windows and linux laptop, and a linux workstation). Typically I will plug in the device and it will disconnect after 15-20 seconds. On windows, the USB device rarely shows up again, whereas on the Linux workstation it seems to re-connect most of the time. If I'm quick, I was occasionally able to program the FPGA with a new bitfile before it disconnects on linux. I tried programming the flash, but it always dies a couple seconds into the 'erase' step.

My suspicion is some kind of hardware fault, but I'm not sure how to diagnose it further. Any suggestions would be welcome!

[zygot]

Yes this is an issue with the CMOD-A7. It is not an issue with cables ( even if Digilent would wish it to be so). It is an issue with the interface on the CMOD-A7 and a particular issue when Vivado hardware manager is opened ( for instance in trying to use the ILA feature ).

Some problems, even those that shouldn't be hard, take Digilent years to resolve. I've stopped trying to use Vivado ILA or the USB UART with the CMOD-A7 . I do use something other than Vivado to configure the CMOD-A7. I do connect a separate USB UART cable to 2 spare IO pins to have nice uninterrupted productive UART sessions with my FPGA application. 

This issue has been known for a few years now. It took me almost 3 years to get the Genesys2 documentation free from silly errors but I kept after them until someone actually looked into the problem. I suspect that this problem cannot be resolved retroactively for current customers.... but no one is paying me to figure out the exact nature of the problem.

[zygot]

15 hours ago, hamster said:

Anything that uses 0.1" headers is more of a "use on a breadboard for learning/experiments" than a serious module for integration... 

I want to pass over this comment... but I just can't control myself. Sure there are applications that require 12 Gbps rated connectors but I have plenty of FPGA modules attached to PCBs doing thing that I'd consider "serious" functionality. Those .1" headers were all there was back before the HSMC standard was introduced and more than a few were integrated into commercially viable hardware. The FPGA devices of that era, except for large amounts of BRAM, are still competitive with , and in a few areas of IO capability, superior to today's devices for some applications.

Some companies just aren't interested in being involved in this area in a serious way...

[fentonc]

Ugh, this feels like a flakey hardware issue. What do you use besides vivado to configure it?

[dfergenson]

My company uses a CMOD A7 to drive a set of SPI-based peripherals, a few interlocks and some slow-moving analog controls.

The 0.1" headers are plenty fast for SPI interfacing and make field repairs and upgrades simple.

Speaking only for our application, I would not chose a higher pin density if one were available. I will, however, probably need an upgrade path at some point either to an Artix7 105T or a Zynq Z7-20.

-David

[wfpga]

@hamster:    well, that's not always the case.

I want to use it to replace an oldstyle trigger unit for a high power device (few megawatts pulsed power output), which doesnt fit anymore for several reasons and was a bunch of digital chips. If an fpga together with an pcb designed for it, would reliable trigger with not too much jitter, it's well suited for this purpose. If i would design the fpga directly on board, the MAX10 would be better choice btw.

 

Anyway, malexander's answer doesn't sound too much interested in really solving this problem.

If 95% of digilents boards USB port shields are AC-coupled only, digilent should be happy to not having  more problems with other boards.
But it looks that this is not the problem to be solved.

 

Also, a board which runs stable only a certain USB cable doesnt have a problem with a bad cable, it's rather the problem itself.

Quote

Using an external power supply may give you a better ground reference then the one provided by the USB cable and provide better noise immunity

USB has a symmetric connection (D+/D-) , exactly to exclude this kind of problems. If that changes anything, it changes only the input voltage VU of the board.

 

btw: i'm wondering what a 'poorly constructed USB cable' could be. In my case, i use a short and low resistance one. Shielding is not the problem, if external power solves USB disconnects.
 

[dfergenson]

I've stumbled upon what seems to be a complete solution to this problem.

First, I switched cables, which did help but I still couldn't run the ILA through the new cable.

In order to get ILA working, I lowered the connection speed. To do this:

1. In the lower left corner of Vivado, right click on "Open Hardware Manager" and press the menu that pops up to close it. This is poorly labeled but what it actually does is disconnects the Cmod.

2. Regular click on "Open Target" and select "Open Hardware Target..." A window will pop up in the middle of the screen.

3. Click "next". Make sure that Local Server is selected in the popup before clicking "next" again.

4. In the next window, you'll have the option to select the connection speed. Select a slower speed and click to connect.

In my case, I'm routing my USB circuitry through a PCB because I need to be able to select between bus power and PCB power. That made my connection unstable so to get things up and running I just directly connected (at the default 15000000 Hz) with a new cable. But I couldn't run ILA successfully. So I had to connect at slower speeds to use ILA (6000000) but when I did that it made the JTAG connection more stable as well, even through the PCB. I went to an extreme and the system was stable at 125000 Hz but at this speed it begins to hurt my personal productivity. I'm going to do a binary search to see what I can get away with.

Can anyone else confirm that this works for them? Would anyone else care to post their successful connection speeds?

If this is a complete solution, then it would seem to obviate the need for a redesign of the Cmod USB/JTAG circuitry.

[zygot]

23 hours ago, wfpga said:

btw: i'm wondering what a 'poorly constructed USB cable' could be.

I'm quite confident in saying that Digilent doesn't have an answer to that mystery either; they certainly haven't provided any measurements supporting the idea. They haven't provided any recommendations as to what a good USB cable would be either. But blaming a part that they choose not to provide is certainly a convenient way to handle complaints; make it the user's fault. The fact is that the module suffers from a number of poor design decisions.

As to your argument that their USB shield implementation is wrong I suggest that USB shield is not supposed to be digital ground. An AC coupled bleed off resistor is not an uncommon or incorrect way to reference cable shield to system ground.

BTW just today I've experienced the same CMOD and cable working with VIvado 2016.2 on WIN7 while using the ILA flawlessly over the course of 6-7 hours. Actually, Ive been working off and on doing the same project for over a month now without issues. But using the same module and cable on Vivado 2019.1 on WIN10 I get disconnects after a number of minutes. Same FPGA source. Same module. Same cable. Different experiences.

[jpeyron]

Hi @fentonc,

Do you see the same issues without using the usb hub? Please download Adept 2 here? Do you experience the same issues using Adept 2?

thank you,

Jon

[fentonc]

Yes, I do see the same behavior with and without the USB hub. I only tried adept 2 on the windows 10 laptop, and I see similar behavior (sometimes the board appears briefly, but then it goes away)

[jpeyron]

Hi @fentonc,

Here is the forum thread that discussed the USB cable issue that is with the Cmod A7.  Are the usb cable connections loose on the cmod a7 devices that are not working. Also please attach a screen shot of the text in adept when it connects and then disappears.

thank you,

Jon

[zygot]

On 7/21/2018 at 3:36 PM, fentonc said:

Ugh, this feels like a flakey hardware issue. What do you use besides vivado to configure it?

When working in Windows 7 I use the Digilent Adept Utility which is a very nice and robust program. This is mostly what I do when using the CMOD-A7.

When working in Linux I do use Vivado but make sure to terminate the Hardware Manager as soon as it has finished configuration.

I never have an issue with the CMOD-A7 USB connection detaching now that I've moved all USB UART operations to an external device and Vivado Hardware Manger is not running. I have tried without success to replicate any sort of association with this issue and a particular cable ( I've got a lot of USB cables on hand.... ). This is the only FPGA product that I have experienced this issue with. I almost always us a USB HUB ( USB 2 or USB 3 ) when working with FPGA boards.

[wfpga]

1nF | 1MOhm works only in a certain frequency range, lets say 1MHz .. 200MHz (high pass filter <-> self resonance). What about switching noise (60kHz..1MHz)?
Anyway, from my tests, it doesnt matter here.

[fentonc]

Update - Success! I found a 3rd USB cable (aside from the other two I had tested with), and it magically started working with Vivado (and Adept, for that matter, although I don't think I can use Adept to program the boot flash). This cable came from a pair of 'Beats' bluetooth headphones (of the other two failures, 1 came with an Arduboy and the other was a random amazon purchase). I was able to both program the FPGA and re-write the flash without incident.

I think my conclusion is just that most micro USB cables are garbage, and the CMOD-A7 is super sensitive to USB noise.

[zygot]

3 hours ago, wfpga said:

What about switching noise (60kHz..1MHz)?

It depends on what you are trying to accomplish with the shield. In this case we're talking about a shield "ground" reference point with respect to a digital ground reference point. What's important from a power supply perspective is mitigating any radiated noise impressed on the voltage supply with respect to the digital ground reference.

The analysis of ground schemes is far from trivial and easy to get wrong. There are a number of textbooks dedicated to this singular topic. I'd think that a PC with various connected external devices would fall under the "complex system" range; not medical application category but complex enough for many of us to get wrong, especially from a cursory analysis.

I'm inclined, at this point, to believe that being a victim of radiated noise isn't what's wrong with the CMOD design.

[xc6lx45]

Hi,

if you want a 2nd opinion, you can try my labToy executable. It runs completely independent JTAG code.

Most likely, it'll fail the same. But if it happens to work reliably, the next question would be "why".

I suspect it's USB power related - you might give it a shot to supply the boards externally.

[xc6lx45]

Remembered one thing: You were using only a single PC, is that so? Try another one.

It may be that there are broken drivers somewhere in the Windows directory. Maybe the USB hardware is unreliable. A powered hub won't automatically fix it.

If a full install is too much work, use the LabToy.exe file and put the FTDI drivers into the same folder (or install them system-wide via FTDI's installer). Speaking of which, updating them to the latest version (8/2017!) might be worth a shot in any case.

 

 

[vicentiu]

On 9/25/2019 at 4:01 AM, dfergenson said:

Do you know if this will be addressed in future revisions to the Cmod A7 product line?

We are working on resolving this on our side and we’ll provide an exchange for anyone encountering this problem. I don’t have an exact time frame but it will be in a matter of weeks.

[jpeyron]

Hi @fentonc,

I am glad that the third USB cable is working with all of your Cmod A7's. Thank you for sharing what fixed your issue.

cheers,

Jon