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?

 

 

 

 

[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.  

[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

[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.

[dfergenson]

Thank you. Will instructions for how to make an exchange be posted to this thread? -David

[vicentiu]

Yes, we'll post details once the boards are available.

[vicentiu]

We have boards now.

If you mentioned at some point on the forum that you're having USB issues, I passed on the email you have on the forum account to customer service so they can contact you for a replacement.

If you're reading this post and you haven't made any mention on the forum, send me a private message.

[wfpga]

I had the same problem with USB disconnects.

My solution does not belong to the kind of USB cables or if USB Hubs are in use, but rather looking at the schematics of the board
and - as those pages in schematics are not public - also looking how the USB connector was made on the board..

 

At first, i noticed that the USB connectors shield onboard is not connected to ground.
Thats honestly said *unusual* or *bad style*, therefore i connected it to ground with a short wire.
Did not solve problem.

The second problem is the power supply on cmod a7. Who ever designed it, did it not properly. If the board is powered from USB,
it's powered from +5V (+0.25V, -0.6V). Actually that means, that every USB port at spec is

->  4.4V..5.25V @550mA max.

4.4 Volts is not that much, and after the diode D1(PMEG2020EJ) on page 7 of the schematics, there will be no more than 3.8..4.0 volts; depending on the current..
And this is the input voltage for the buck regulator LTC3569. This regulator has three outputs; which are also not equal. Output 1 has lower Rdson as
output 2 and output 3. And output 3 with highest Rdson serves the 3.3volts for USB (more losses on the rail with lowest voltage reserve..).

I use the cmod on a breakout board i designed for it. Every io (except pmod) is fed through a 74lvx4245 to outside world to protect the fpga.
Also it's powered - via jumper - from MP1584EN external DCDC. VU pin is kept on 5..5.25V@2A max in any case, if external DCDC is jumpered.

What i can confirm is, that powering the CMOD A7 from external voltage immediately solves any USB disconnect problem,
while powering from USB gives disconnects every few minutes. No matter which power supply i choose,
no current flows from FPGA outputs in my case (except the tiny input current of the 74lvx4245's).

Any USB cable works in my case - if i power the board externally.

[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.

[vicentiu]

[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... 

[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...

[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.
 

[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.

[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.

[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.

[dfergenson]

I'm writing to report that the design problem was completely solved for me by the updated design but I want to mention an experience that I had because I didn't understand what was happening myself until a few months later.

I was one of the people who requested and received a replacement Cmod. That one suffered from the same disconnecting issues so I had just assumed that the issue remained.

But I ordered two more Cmods a few weeks ago and neither had the issue. I mentioned this to my customer service rep and she sent a replacement for the replacement. That one worked well, too.

I think that the channel may not have been flushed out initially but it is now.

If you've replaced your Cmod and are still experiencing the problem, check with Digilent. The new boards work reliably.

[dfergenson]

Vicentiu,

Thanks for doing this. I'm having a bit of trouble identifying the pads since some of the features are covered by components.

Can you possibly post a photograph so that I can attempt to perform this modification?

Thanks again for looking into this problem.

-David

P.S. I also found that using a USB 3.0 hub made my connection much more stable.

[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.

[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.

[fentonc]

For the record, I only have a single CMOD-A7 board. The working cable came with a pair of "Beats" bluetooth headphones, and is otherwise unlabeled. One of the non-working cables is a short, flexible cable (silicone, maybe?) that came with an "Arduboy" Arduino-based gameboy device (and was successfully used to program that), and the other non-working cable was a random micro-USB cable from amazon (unlabeled, and no longer remember the exact purchase model).

[JColvin]

Hi @fentonc,

Out of curiosity, what were the brands of the two non-working USB cables and the one working USB cable -- curious to see if there is any consistency to what we have seen or not.

Thanks,
JColvin

[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

[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]

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.