• 0
Boris_S

Defective JTAG on Digilent Cmod A7-35T board

Question

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.

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

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.

 

Share this post


Link to post
Share on other sites
  • 0

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?

Share this post


Link to post
Share on other sites
  • 0
  • 0

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!

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

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

Edited by xc6lx45

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

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

 

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0

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. 

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

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

Edited by zygot

Share this post


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

Share this post


Link to post
Share on other sites
  • 0

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.   

Share this post


Link to post
Share on other sites
  • 0

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

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