I bricked my CMOD-A7

[hamster]

I seem to have bricked my CMOD-A7 while programming the flash. 

The 'DONE' LED never lights, and the USB JTAG seems to appear for a few seconds then go away again:

[ 1382.675956] usb 2-1.3: New USB device found, idVendor=0403, idProduct=6010
[ 1382.675962] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1382.675966] usb 2-1.3: Product: Digilent Adept USB Device
[ 1382.675969] usb 2-1.3: Manufacturer: Digilent
[ 1382.675972] usb 2-1.3: SerialNumber: 210328A41214
[ 1382.679134] ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected
[ 1382.679207] usb 2-1.3: Detected FT2232H
[ 1382.679559] usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1382.682361] ftdi_sio 2-1.3:1.1: FTDI USB Serial Device converter detected
[ 1382.682427] usb 2-1.3: Detected FT2232H
[ 1382.682846] usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB2
[ 1382.697639] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 1382.697675] ftdi_sio 2-1.3:1.0: device disconnected

Not sure what I did wrong, but I suspect I failed to set "Under Configuration Modes, select Master SPI x4"

Putting a scope on the QSPI flash, I can see the FPGA  attempt to read the image.

Any hints on how to unbrick?

Thanks

Mike

[hamster]

Wahoo! Success!

Thanks for your help @zygot, @D@n & @xc6lx45, and faith that the CMOD wasn't a completely bricked.

Last night while I was on the way to bed walked past my bench and had one last try.

Plugged the CMOD A7 into a powered USB, and then booted up my Linux PC. Once booted and signed in I cleared the kernel message buffer with a "sudo dmesg -c".

I then plugged the hub into the PC, and both FTDI channels channels came up and stayed up.

As a test, I then removed and replugged the CMOD to the hub, and had the usual fault happen - both came up, but the JTAG interface disappears.

I repeated the process from cold, and got the same results.

Conclusion:

With at least my invalid image in the flash, the FTDI JTAG interface or driver does not initialize correctly if plugged into a PC directly.

By using a powered hub,. and giving the CMOD enough time, BEFORE you connect the hub to your PC, you can restore JTAG functionality.

... phew, I am glad I wasn't in a hurry to break out the soldering iron and hot air..

@JColvin Are any of the back-room team aware of this sort of thing happening and how to work around it? Maybe they could investigate what is going on, publish a process on how to recover and it might save a few warranty claims / product failures. I am sure that there will be people other than me who have experienced this issue.

[xc6lx45]

Thinking aloud: Is it even possible to "brick" an Artix from Flash? On Zynq it is if the FSBL breaks JTAG, and the solution to the problem without boot mode jumpers is to short one of the flash pins to GND via a paper-clip at power-up. But on Artix? Can't remember having seen such a thing. Through EFUSE, yes, but that's a different story.

If you like, you can try this if it's a 35T (use ADC capture at 700 k, it stresses the JTAG port to capacity). For example, it might give an FTDI error. Or if it works, you know that JTAG is OK.

 

[D@n]

@hamster,

I think I'm going to agree with @xc6lx45, I don't think you've  bricked this.

You may have the flash in an unusual mode.

Can you load and run a design on the S7 that doesn't use the flash, to see if that works?

Dan

[zygot]

The CMOD mode pins default to SPI programming so if the contents in the FLASH are bad you have a problem. Unfortunately, there's no room for a JTAG header on these modules so I'm guessing that you need a way to clear the FLASH. I can't think of a way for the FLASH to brick your FTDI device. It does look as if your USB driver is disconnecting the JTAG endpoint which is a problem. I'd certainly try the code that @xc6lx45has provided as it uses a different driver.

This would be a lot less mysterious if the schematics were complete. As an alternative Digilent probably should provide a utility to erase the FLASH on products with limited configuration options and a preference for FLASH configuration.

[D@n]

No, the USB driver disconnecting from the JTAG endpoint could be part of a normal connection.

I know when I connect one of my Digilent devices, it connects, recognizes the device, and then disconnects and reconnects with a different driver.

This is normal.

Hence, I don't (yet) have enough information from the dmesg dump above to know if there's a problem with the JTAG chain.

One of the things you can use FTDI read-memory command to get a dump and see if it looks like what it should.  (You should, for example, be able to read "CMOD S7" or something similar from the FTDI's flash to confirm it "looks" okay.)

Dan

[hamster]

 

The devices identifies correctly so it looks as if the FTDI is OK.

The serial port stays up and active, but the JTAG port only hangs around for a few seconds.

It looks to me as though the lack of the FPGA to configure correctly is crashing/blocking the USB JTAG interface.

Looking at the schematics the JTAG is only connected to the FPGA, and doesn't connect to the QSPI Flash at all, so I can't see why it won't work, unless the JTAG is blocked while the FPGA is configuring, and this is causing the driver to barf and fail. I wonder if I can remove and reprobe the USB device?

I've checked at least the 3V3 rail, and it seems OK. 

I am half thinking of breaking out the microscope and jumpering the FPGA into JTAG boot mode rather than SPI....

Maybe if all else fails I lift the Flash from the board, program it with a good image and then put it back???

 

Looks very similar to 

https://forums.xilinx.com/t5/Other-FPGA-Architecture/device-disconnected-when-programming-FPGA/td-p/768702

and 

https://forums.xilinx.com/t5/Xilinx-Evaluation-Boards/Digilent-Adept-USB-device-disconnects-immediately/m-p/310301#M12179

[zygot]

2 hours ago, hamster said:

Maybe if all else fails I lift the Flash from the board, program it with a good image and then put it back???

Before you start cutting you might consider trying to force JTAG configuration mode. It looks like the mode pins have 1K pulldowns for access.

[xc6lx45]

You might try to take an old USB cable and put an amperemeter into the 5V wire. I suspect you'll observe that current consumption starts around 80 mA (the FTDI chip waking up) then dropping much lower when the FTDI chip shuts down. I've seen this pattern on other designs when there are issues with USB / power supply. Most likely it has nothing to do with Flash.

Hypothetically, I could flash a design that draws more current than USB can provide, and would cause the FTDI chip to run out of juice and shut down. Maybe the PROG_DONE LED goes on for such a short time that the eye does not notice. In this case, the paper clip trick should be sufficient to bypass Flash boot once.

And as mentioned above, you can access the boot mode pins, e.g. solder a wire to the FPGA end of the resistor.

 

[hamster]

Tried multiple cables and power supplies, but no different behavior.

I've been investigating playing with the boot mode strapping resistors, as suggested by @zygot & @xc6lx45 but they are 0402 or maybe even 0201, and on the bottom-side of the board. I'ld really need to borrow a friend's microscope, and even then I think I lack the skills for anything but carefully shorting the FPGA signal (not the power side!) to the opposite power rail.  Compared to lifting the strapping resistors popping the flash off would be easy....

I might sit on it, and maybe try looking at the Linux layer for the USB equivalent of a SCSI hot-plug/rescan, based on the assumption that the attempt to configure from flash must timeout after a while. Ether that or try connecting the power lines before I connect the data lines, or putting powered a hub toop.

Will play again in the weekend if time allows.

[hamster]

Success! Now works again plugged directly into the laptop.

[zygot]

@hamster

Thanks for sharing your issue and more importantly your solution.

[Decanter]

hamster, what did you do???  You said "Success!", but didn't list your solution. I'm having the same problem.

BTW, I tried what you suggested at https://www.eevblog.com/forum/fpga/unbricking-a-digilent-cmod-a7-fpga-devboard/ and it did not work.

[Decanter]

Is no-one from Digilent going to address this problem? I have a dead Cmod that's consumed a couple of hours already, with no solution in sight. Others clearly have the same issue. If there is a reliable solution, could you please point us to the answer?

[JColvin]

Hi @Decanter,

Hamster listed their solution in their own self-marked best answer in this same thread; here's a direct link to the comment: https://forum.digilentinc.com/topic/19036-i-bricked-my-cmod-a7/?do=findComment&comment=51076.

For your particular case, what do you mean by a "dead Cmod"? Do the lights turn on when you plug it in? Can you see it in the Digilent Adept software?

Thanks,
JColvin

 

[Decanter]

Thanks for your reply JColvin. I was finally able to get my CMod A7 working again, after a list of other things had failed. After searching quite a bit more, I found a post that mentioned the Adept drivers as a solution. I installed them (I got the impression that the tool had not been updated in years, but it seemed to install drivers for the Artix A7 based Cmod), had to reboot my PC (no effect without rebooting), and after that, I was able to reprogram the CMod.

So, what worked for me was simply installing the Adept drivers, rebooting, and voila! Solved.