Defective JTAG on Digilent Cmod A7-35T board

[Boris_S]

Hi,

I have a brand new Digilent A7-35T board I tried to program via the USB built in JTAG using Vivado 2018.2. The part intermittently shows up in Hardware Manager, but a seconds later disconnects. Sometimes it disconnects just being connected (opened) in Hardware Manager and sometimes during programming. It is even worse if I try to erase and program the QSPI flash. I also downloaded and installed the latest Digilent Adept 2 with updated drivers and observed the same behavior. I tried different USB cables, different USB ports directly on my PC, via a powered hub, but the behavior is always the same -- it intermittently disconnects and fails. The amber LED does however stay lit. In Device Manager I am able to see the FTDI UART. I did also see it enumerate as a Microsoft BallPoint Mouse -- whatever that is.

With this exact same setup, PC, Vivado, USB cables, etc, I have been programming the Zybo Z7-20 and the Arty boards with several designs without any such issues.

Please let me know if I missed anything and what are the next steps in getting the board replaced or fixed. Thanks.

[xc6lx45]

2 hours ago, grf said:

It seems to me that the A7 is booting, my machine briefly recognises it as a JTAG device, then (*sadly) the A7 starts it's demo app, which appears to tear down the JTAG port -

...

I think that when I am  lucky (the 2% of the time!) I am hitting the hw_server just as the device is being seen for the first time, or in one of these 'cycles'.

I really think that it it was not for the demo app trying to use the UART my connection would be stable. 

if you can bring it up once in Vivado HW manager (maybe with the help of an external +5 V supply), you might be able to erase the flash.

If not, you may be able to prevent loading the bitstream from flash e.g. by pulling INIT_B low (R32 is on the bottom of the board, its label slightly below the CE mark). See https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf "INIT_B can externally be held Low during power-up to stall the power-on configuration sequence at the end of the initialization process. When a High is detected at the INIT_B input after the initialization process, the FPGA proceeds with the remainder of the configuration sequence dictated by the M[2:0] pin settings.""

[zygot]

On 9/12/2019 at 12:59 PM, xc6lx45 said:

Also, the specified number of cycles for USB connectors is ridiculously low.

Most connectors have very short insertion cycle specifications; unless they are expensive and specifically made to endure a high number of insertions.

Having made that statement I will say that I have to maintain at least 4 tower and 2 laptops to support all of the obsolete tools and drivers that I've accumulated and still need; and I have yet to identify 1 USB port that has gone bad. My main Win7 delvelopment PC is as old as, well.. Windows 7 is.

It's not a bad idea to invest in a few USB hubs. They are a lot cheaper than PCs. There are reasons for doing this even if you aren't worried about connectors going bad. I recently destroyed ( well I haven't bothered to take the time to figure out what the problem is ) a USB HUB while developing a FT232H project ( this is a lot easier to do than you might think) ; glad that it wasn't one of my motherboard USB Host Controllers...

I generally keep USB cables plugged into development boards when not being used. I've had a number of USB connectors rip off of such boards. In particular, if you have any development board with a USB connector lacking thru-hole shield ground tabs I guarantee that sooner or later it will come off with the end of your cable. One way to mitigate this is to apply some epoxy around the connector before using such a connector. I do this as a habit. I've found that most USB micro or mini cable connectors require a high insertion force, and that's if you are trying to plug it in correctly; some are worse than others.

Zygot rule for the day: "Break cheap stuff, not expensive stuff". Corollary: "You are going to break something sooner or later".

[edit] I should have specified that by USB HUB I mean self-powered USB HUB.

[xc6lx45]

>> Don't know why my tower doesn't work but my laptop does

might be a bad USB card or interface. For example, the polyfuses in the voltage supply line are notorious for their even infinite memory effects. Also, the specified number of cycles for USB connectors is ridiculously low.

USB from the PC shop is consumer technology - a USB card can be had for $5, an industrial GPIB card is $500 even though the former is even technologically more advanced ?

[gentlemanJack]

Hi vincentiu and zygot,

OK, this just in:  Up and running now.  I moved to my laptop and used a fairly nice looking 3 foot USB A to microB cable.  It works both with a powered USB hub and with just the cable itself.  Tried it about ten times to "open the hardware manager", and downloaded the blinky program from the Digilent "Getting Started with Vivado".  Laptop has Vivado webpak 2019.1 loaded.

On my laptop, the connected cable shows up in two ways on my Device Manager:  (1) as a serial port at 9600, 8N1 with FTDI device driver 2.12.28.0, 8/16/2017 and (2) as Universal Serial Bus controllers with two entries, USB serial converter A and USB serial converter B.

I also, per vincentiu, added a 100nF capacitor, 0603 size, unknown manufacturer before I started.  As I get more Cmod A7 I will try with and without.  I did design the Cmod A7 into my board, but before I go into production, I will look at the boards that have JTAG.  I really, really like the Cmod A7 form-factor and that users don't have to buy a Xilinx cable.  We'll see how the next few work.  I just can't have this same problem affecting my customers.

Don't know why my tower doesn't work but my laptop does.  My guess would be something's wrong with the software on my tower, but it was kinda homemade with a Megatrends motherboard, my laptop is a very new Lenova.

FYI, I found a fairly nice USB A to micro B cable, that I have not yet received from a certain retail mega-monolith whose name begins with "A", supposed to be good for  480Mbps, 24AWG, search for "iKits micro USB cable".  I am getting both the half foot and 4 foot versions.  I will report on results in a day or so.

I have been an occasional user of FGPA for many years, and I remember the troubles that Xilinx had with Serial Parallel Cable 2, first a version with a black housing, then an improved version with a red housing so people could instantly know they had the good new one.  So the cables have historically been difficult.

Finally, zygot, I would like to email with you about my frequency counter project.  As it has to deal with asynchronous input - nature of the beast - it will be a little tricky.  Don't know if the moderator can set us up, or whatever.  If not possible, that's OK.

Let you know about these iKits cables in a few days.  - gentlemanJack

[zygot]

5 hours ago, vicentiu said:

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.

Again, making the customer resolve you design issues is not nice. Especially since many of your customers aren't experienced electronics design engineers. So you have a particular 100 nf capacitor in mind? Did you use a low ESR cap? What was the part number? When your all-thumbs customers destroy their board trying to implement your "fix" are you willing to replace those boards?

I have a lot of FPGA development boards from Digilent that use the same USB cable(s) as the CMOD modules do. All of these have a separate power supply connector and JTAG header so the boards are usable without a USB cable. Curiously, the only product with an issue, happens to be lacking either a power supply connector or a JTAG header and is therefore unusable without a USB cable and that's the one that you don't sell with a cable. You've even refused to recommend a cable for customers. Since the issue was first raised Digilent has only provided fuzzy, non-specific solutions which doesn't engender confidence.

Really, please stop marking these "answers" as a solution to the problem. If the problem is the cable start selling the modules with a cable and then declare the problem solved. The solution is either incredibly easy ( you supply the cable ) or needs a re-design. Either way your customers can't be expected to do your engineering for you or even find "good" parts such as a cable on their own. Digilent, can on the other hand resolve the issues completely; they just have to want to.

By the way I've never come across a "bad" cable though I have no doubt that there are vendors selling such things.

[vicentiu]

8 hours ago, gentlemanJack said:

is there a more robust Digilent board that has traditionaly Xilinx parallel cable 2.

All our boards (except Cmods) have JTAG pins or staggered holes to which you can connect any JTAG programmer, including the Xilinx platform cable 2, but it's not needed because all our boards have JTAG over usb which you can control through Vivado or other tools.

For alternative boards, the Cmod S7 has the same form factor but a smaller FPGA.

Next up is the Arty A7 with same FPGA as the Cmod A7.

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.

[gentlemanJack]

I tried to find the lastest forums on this often discussed CMOD A7 cable problem.  I hope I choose the right one.  I knew nothing of this problem, but designed-in a CMOD A7 on a project to do precision frequency counting.  I started this morning, and hit this problem immediately.  I only have one board.  At the bottom of my story, I list 5 actions that I could take.  Can people experienced with this problem comment?  Particularly on Item 5, if there is a more robust Digilent board that has traditionaly Xilinx parallel cable 2.

My Vivado is 2017.4, Windows 10 64-bit.  I went thru the "Getting Started with Vivado" tutorial, got the needed files, no problems with anything, generated a bitstream and …. when I tried to auto-connect with the Hardware Manager (by hitting "Open Target") It shows localhost(0) is Connected, but it also says:  'No hardware target is open' and "Program Device" in the Flow Navigator is still grayed-out.

And yes, I tried 4 different microUSB cables, including a 1 foot long.  My CmodA7 out of the box has the "DONE" light on, and the pushbuttons change the LED[2:0} indicating that the CmodA7 has a program already in it.

I read that some people install Adept 2.  I ran install_digilent.exe which I found under C:\XilinxFull\Vivado\2017.4\data\xicom\cable_drivers\nt64\digilent and it says I am up-to-date in a window that says "Digilent Adept Runtime Setup".

I also read about windrvr6.inf and xusbdrv.inf being a problem for Vivado Versions 2017.4 and 2018.2.  I see them under dlc10_win7 (which contains 18 files) but not under dlc10_win10 (which only has 3 files)

I did run install_drivers_wrapper.bat as described in the forum: https://www.xilinx.com/support/answers/59128.html, running the cmd window as admin, moving the prompt to C:\Xilinx\Vivado\2017.4\data\xicom\cable_drivers\nt64
install_drivers_wrapper.bat C:\Xilinx\Vivado\2017.4\data\xicom\cable_drivers\nt64 c:\Xilinx\Vivado\2017.4\install.log c:\Xilinx\Vivado\2017.4\

... this is the log file results ......
NFO: InstallPath="C:\XilinxFull\Vivado\2017.4\data\xicom\cable_drivers\nt64\"
windrvr6 is not installed.
INFO: Installing Windows 10 pcusb driver...
Microsoft PnP Utility

Processing inf :            xpcwinusb.inf
Driver package added successfully.
Published name :            oem67.inf

Total attempted:              1
Number successfully imported: 1

INFO: INF file C:\XilinxFull\Vivado\2017.4\data\xicom\cable_drivers\nt64\dlc10_win10\xpcwinusb.inf was successfully installed for driver.
INFO: Running digilent installer...

<<<<< Digilent Adept Runtime Setup >>>>>
Installer version: 1.4.6 release: 2015/12/08
Digilent Software Path: C:\Program Files (x86)\Digilent

Your system is up-to-date with the components of this installer.
INFO: Running SmartLynq installer...
INFO: SmartLynq installed successfully

.... So... going forward, should I:
(1) install latest Vivado (maintenance fee?)
(2) see why dlc10_win10 only has 3 files
(3) get a download of Adept 2 and use it to download the .bit file from Vivado
(4) put a large capacitor on the USB 5V Rail as described in https://forum.digilentinc.com/topic/4769-vivado-hardware-manager-disconnects-cmod-a7-target-in-win7/, Jan 10.
(5) call today a bad investment and find another FPGA board

 

[zygot]

@grf

It's good for the community that you've taken the time to post your experiences. Now the only question is whether or not Digilent cares enough to commit resources to resolving this for good. I'd suggest that since they are in the habit of replicating hardware to save development costs, whether the hardware should be replicated or not, such an effort will be in their best interests. Ultimately, this is not a customer problem to solve; but more useful information form customers should help guide the product developer's.

[grf]

Just to follow up on this.  

I did manage to remove the default demo app (after many attempts). 

Since then, I do find that my cmod A7 is now more accessible (probably 30-40% of the time - still not perfect - but better than the < 5% I saw previously) 

So I am able to write bitstreams to the device pretty consitently.

Another observation (now I have removed the demo app) is that the first time I try to use the device (after it has been disconnected from USB power for a while) it is detected almost 100% of the time. Just cycling the power (once it has been up for a while) does not do it.  I now am wondering whether this is because the device has had a chance to cool?  Maybe my success after removing the demo app, is not because the default demo is using the uart, because my replacement app (which does nothing except illuminate a led when button is pressed) is using less power, and thus not thermally loading the device. Hmmm.  

Anyway I am far more productive now. So am reasonably pleased with this strategy.   

[zygot]

@Boris_S

Since you are using Windows it might be worth your time to try an experiment. xc6lx45 has posted his awesome busbridge3 demo in the Project Vault. I have created an executable that runs on my WIn7 computer using the source code and SharpDevelop compiler. If, as I suspect, the issue is completely a hardware one then you shouldn't be able to run the code and configure your board. I made slight modifications to the source so that I could confirm the configuration step. Read the project postings. Once I resolved some basic C# issues I had no problem running the executable with either of my two boards ( again, I've not had issues programming them ). This project does not require a separate JTAG FPGA configuration application to be running. Download the project and read through the source code just because it's a great tutorial for anyone who hasn't tried creating a PC application that configures and interacts with an FPGA board before.

When I first ran into the problem it certainly 'smelled' like a software or driver issue; Vivado Hardware Manager doesn't play nice with other applications, including the Adept tool for Windows which I generally favor for configuring Xilinx FPGA boards. Since I've been able to use my boards with a simple work-around I haven't allocated the time to doing what Digilent should have done and resolved long ago; that is fix this once and for all.

The FTDI JTAG and UART should be enumerated as separate endpoints and not interfere with each other. I don't have a USB bus analyzer ( Digilent most certainly has no excuse for not investing in one ) so ferreting out the source of OS disconnects is more work than I want to do. FTDI doesn't provide the level of debugging support that Cypress does for their USB devices so tracking down issues involving a lot of software and hardware elements is non-trivial. Even so, there's simply no excuse for these reoccurring customer complaints not being aggressively addressed and resolved by the vendor.

[grf]

I have just started hitting this in the past week  (Ubuntu 18.10) with my Cmod A7 35T. It was hit and miss before then, now I can only connect perhaps 2% of the  time.  

I have two other boards (Basys3 and Nexus Video) and I am using the same usb cables that work 100% of the time with them.  But have tried multiple cables. 

Here are my observations (for what they are worth) and even a guess at what the problem is.

Using a combination of 'sudo lsusb' and looking at the logging from 'hw_server' I can see that the A7 appears as a JTAG Digilent devices, then drop out before being seen as a FTDI driver on the same physical device. 

It seems to me that the A7 is booting, my machine briefly recognises it as a JTAG device, then (*sadly) the A7 starts it's demo app, which appears to tear down the JTAG port so it can communicate with the host via the UART.  At this point the hw_server thinks it has lost the JTAG/USB and so no longer sees the device, so drops it.  I see the UART drop then reappear in cycles from this point out.

If I have the Vivado UI up (usuallly I avoid).  I will see multiple dialogs stacked, as it see's, then loses connection with the device.   

I think that when I am  lucky (the 2% of the time!) I am hitting the hw_server just as the device is being seen for the first time, or in one of these 'cycles'.

I really think that it it was not for the demo app trying to use the UART my connection would be stable.  

So I would love to know how to disable/delete the demo app.   I think after that, I would be in  good shape. 

Maybe these observations might help someone with more experience to determine a plan of action. 

[zygot]

@Boris_S

I've written about this so much that I've been avoiding responding to posts such as yours any more. I decided to add my 2 cents to your thread because your experience is very similar to mine. For my older 2 CMOD-A35T boards I've never had an issue configuring the CMOD-A35T but do have USB disconnect issues with Vivado Hardware Manager if I try to use the ILA for some time. I have a drawer full of cables and none of them make a difference. I find the board useful if I use an external TTL USB UART attached to 2 IO pins. You obviously can't do that if you can't even configure the FPGA device. Digilent is set on blaming the problem on cables... yet they don't sell the board with any or guarantee operation with any known vendors cable even after a few years of complaints.

You are correct that this is the only FPGA board that Digilent ( or anyone else that I know of ) makes with this problem; and Digilent has made a lot of boards with roughly the same programming interface over the past 5 years or so. My personal suspicion is that the particular FTDI device used on this board ( the newer cheaper ones have fewer power and ground pins), pcb layout decisions, and possibly the way that whatever makes their interface proprietary is different for this board is causing the issue but I can't prove that and frankly it's not worth my time to try. Neither you nor I can make Digilent take any particular action with regard to these boards but it is clearly not doing anything positive for their reputation ( I sometimes wonder if they even care about reputation ). Since they are cheap, if I were the vendor, I'd re-spin the board, test the JTAG interface exhaustively, and sell the modules with a mated cable. I suspect that the board needs a different stackup and less component density and a JTAG re-design. Making customers eat the cost of a poor design just isn't good business if you want to engender good will. There have been customers that support Digilent's claim that a different USB cable makes the problems disappear but, as you and I know, not all of us customers can verify this. I happen to think that if a customer can't use a new board with known design problems a more liberal replacement policy should be in order... the vendor can figure out what's going on working with the returns. It's problematic that the same board and cut & paste copies of newer versions are being sold without a fix. Perhaps Digilent doesn't think that the cost merits testing product but for their customers the cost is signifiant, especially when the board is unusable.

I know what I do when a vendor has a habit of not treating me well... I use a different vendor.

The Terasic DE0 Nano is about the same cost but comes with a USB cable and has more IO pins in a slightly larger form factor but is still quite usable for attaching to a custom board that I design. It doesn't use an Artix device but for what these embeddable modules are good at has served me quite well. I've designed a few dozen boards that have integrated either the 2 CMOD-A735T or the DE0-Nano as a component over the past couple of years.

If Digilent were willing to replace your board, given the known issues, then I'd try that for the modest cost of shipping but if not I certainly wouldn't throw more money at a different one hoping for a different outcome. There are a few vendors offering similar modules but I only have experience with the two that I've mentioned. Trenz makes a few similar FPGA boards but I've never used any so I can't offer any opinions about them.

 

[xc6lx45]

@Boris_S

Hi,

I didn't even mean you should rig up a test cable. It would, most likely, show when the FTDI chip goes into shutdown, but that's it (it would be more useful if you could compare with a known-good board, but I think that's not the case)

Of course, there is always the possibility of broken hardware.

If I had to make the board work, I'd try to supply 5 V externally, with e.g. 47µ tantalum cap in parallel. There is one corner pin for external supply.
I suspect it will not reach the FTDI chip directly (D1 in the schematic), but may help to suppress current spikes from the FPGA.

[Boris_S]

Hi All,

The first thing that I suspected is a bad cable, so I did try it with several different brand micro USB cables. I tested it with different USB ports, a powered USB hub, then I tested it with another PC. Same behavior in all cases.

Second I suspected that maybe since the board was more recent than the other boards I had been using, I updated the Digilent drivers from the Digilent web site. I even installed the Digilent Adapt 2 app which permits you to program the part without Vivado. But the same flaky behavior was observed.

I took a look at the board under a magnifying glass to see if anything is amiss -- it is tiny with 0201 parts, but it looks fine.

I rebuilt the design (with different pinouts) for the Arty board, following the same programming sequence, and that worked fine on the first try. I regularly work with different FPGA boards, including the Zedboard, the original Zybo, the Zybo Z7-20 and the Arty with no such issues on the same setup so I think the likelihood that something with my installation of Vivado, drivers, or knowledge of FPGAs being the issue is low.

I will test the current draw, but I cannot imagine that exceeding 500 mA would be considered normal for an idle board, especially if it is not driving anything external. The Arty works fine just powered off the USB bus (it has the same Xilinx XC7A35T-1C part).

I'll look into how others resolved this problem, but it seems to look like an issue with the FTDI chip. Unfortunately the Cmod does not have an alternate JTAG pins to bypass the FTDI.

Thanks!

[vicentiu]

There have been other cases like this. The best solution is to use a high speed (good quality) USB cable. 

https://forum.digilentinc.com/topic/4769-vivado-hardware-manager-disconnects-cmod-a7-target-in-win7/

https://forum.digilentinc.com/topic/17435-unstable-usb-connection-with-cmod-a7-35t/

https://forum.digilentinc.com/topic/9766-digilent-cmod-a7-disconnects-andor-does-not-program/

 

[vicentiu]

As @xc6lx45 recommends, can you try the board on another system with a different cable and see if you reproduce the issue?

Do you have any other fpga board you can try on that system and see if Hardware Manager recognizes it?

[xc6lx45]

Hi,

the difference may be that this board is bus powered.

Most likely the USB cable and / or the PC side USB hardware are at fault, even if they work with other boards.There can be supply issues that border on Voodoo, e.g. caused by permanent changes in polyfuses on the host after tripping them once. You cannot "prove" that a cable etc works by testing it with another device (not stating this as a philosophical concept but as a lesson learned the hard way with a unit that went to customers...)

If you would rig up a debug cable with an amperemeter in +5V, you would probably observe that the FT2232H USB chip draws ~80 mA once it's initialized by the driver, and this drops to zero when the chip decides USB is bad and it shuts down. There is AFAIK nothing that can be done about this in software or configuration.