• 0
Christian Klein

Digilent CMOD A7 Disconnects and/or does not Program

Question

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?

 

 

 

 

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0
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... 

Share this post


Link to post
Share on other sites
  • 0
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...

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0
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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0
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.

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now