Analog Discovery troubleshooting

[attila]

During device opening internal chips are enabled and configured. This results in consumption increases, specially when the 100 MHz clock (PLL) is started. The needed current increases from 100mA to 500mA. In case the USB can't provide enough current the voltage drops below the minimal required for the device to operate and communication fails.

 

In case you get “Device configuration failed (PLL 1)" or "Communication with the device failed.” error message:

The device needs at least 2W/400mA from USB cable. To satisfy this:

- Try to use different USB cable and computer plug.

- Use the USB plug on the back of the PC, not the one on the front panel.

- Use short cable, do not use long cable or cable extender.

- Use powered USB-hub, avoid un-powered hub.

- Use USB-Y cable to load power from two plugs.

 

Device not detected by WaveForms:

Open Windows Device Manager then connect the device and wait up to one minute for a device to appear:

 - USB Serial Converter, with warning

- Connect the device directly to the computer's USB plug without using external hub.

- Restart the computer.

- Reinstall WaveForms, including the Adept Runtime section.

 - USB Serial Converter, without warning

- Restart the computer.

- Reinstall WaveForms, including the Adept Runtime section.

- Other application might have erased the USB controller EEPROM (FT_Prog, programming cable drivers...)

 Use the "My device is not listed" button in WaveForms application Device Manager to reprogram the EEPROM.

 - Unknown Device

    Check the Hardware IDs under device Properties, Details tab

- USBVID_0403&PID_6014

  The USB driver is not installed.

- Restart the computer.

- Reinstall WaveForms, including the Adept Runtime section.

- USBVID_0000&PID_0000

  Device not identified or malfunction. See "Nothing shows up".

 - Nothing shows up:

- Connect the device directly to the computer's USB plug without using external hub.

- Try to use different USB cable and computer plug.

   The device or its plug might be damaged.

Edited February 26, 2018 by attila

[slalps]

Reinstalling the FTDI drivers seems to have fixed the issue for me and I can now use my AD2. Thanks for your help!

[attila]

Hi @slalps

Good to hear it is working.
Than you for the feedback.

[Toladar]

Hello,

I have the AD2 since one year and i m very happy to have it. Yesterday i plugged it to my computer and the device was not reacheable.

I tried to change the usb cable / reinstall driver / change the port / use an other system ( i m working on linux ) / follow your instructions but i can't communicate with it. The ftdi driver seem to be ok. With dmesg i can see the USB Serial Converter and it's correctly attach.

When i tried to reprogram the eeprom on linux i have the message FT_Open Failed and on window the waveform software crash

I have no idea how to solve this issue. Could you help me ?

[attila]

Hi @Toladar

Try reinstalling Adept Runtime:
https://reference.digilentinc.com/reference/software/adept/start

Try running the Enumerate.py 

You only have to reprogram the EEPROM in case it was accidentally erased with some USB development application, like FT_PROG

 

[Toladar]

Thank you for your answer @attila

I reinstall Adept Runtime and i have the same issue :(

Please find below the output console from your python script (After reboot and with AD2 attached)

Quote

FTDI Version: 0x10408
Devices: 1
 1. SN:  flags: 0x1 type: 0x3 id: 0x0 locid: 0x0

DMGR Version: 2.8.8
Devices: 0

DWF Version: 3.12.2
Devices: 0

Seems to be good for driver side ? and also for software version but the device is always not detected :(

[attila]

@malexander

Could you help in this issue?

@Toladar

When I run the Enumerate.py the first time the FTDI lib returns no data. The following runs however are correct.
Could you try running the script twice?

What Linux distribution/version are you using?

Could you try the device with Windows or MacOS?

 

$ python Enumerate.py 

FTDI Version: 0x10408
Devices: 1
 1. SN:  flags: 0x1 type: 0x3 id: 0x0 locid: 0x0

DMGR Version: 2.8.8
Devices: 1
 1. SN:210321A419AA Analog Discovery 2 PDID: 0x40300360

DWF Version: 3.13.15
Devices: 1
 1. SN:210321A419AA Analog Discovery 2

$ python Enumerate.py 

FTDI Version: 0x10408
Devices: 1
 1. SN:210321A419AA Digilent USB Device flags: 0x2 type: 0x8 id: 0x4036014 locid: 0x103

DMGR Version: 2.8.8
Devices: 1
 1. SN:210321A419AA Analog Discovery 2 PDID: 0x40300360

DWF Version: 3.13.15
Devices: 1
 1. SN:210321A419AA Analog Discovery 2
 

[Toladar]

After launched the script multiple times, i have exactly the same content. I installed on MacOs and the device is also not detected.

I m working on a updated Debian 10 linux system and before this issue i never has any issue with the device.

[malexander]

@attila

It looks like on Linux your python script first tries enumerating using libftd2xx.so. I suspect that the ftdi_sio driver is still attached the first time you run the script after device plug-in. Our library (libdft2xx.so) used by DMGR to enumerate devices will first read the EEPROM and determine which interface(s) should be Adept interfaces, and then manually detach the ftdi_sio driver from those interfaces prior to using libftd2xx.so to open the device handle. Once the ftdi_sio driver has been detached from the adept interface it should remain detached until the next time the device is reconnected to the USB port. To test this theory you could perform the following steps:

1. Detach AD2 from PC
2. Attach AD2 to PC
3. Execute "sudo rmmod ftdi_sio"
4. Attach AD2 to PC and run the script and see if it enumerates the first time.

I will have to spin up a Debian 10 VM to perform additional testing for Toladar.

 

[malexander]

@Toladar

I just spun up a fresh Debian 10.3 64-bit installation inside of Virtual Box. After installing the required software packages waveforms was able to find the Analog Discovery 2 and access it. I installed the following packages:

1. digilent.adept.runtime_2.20.1-amd64.deb
2. digilent.adept.utilities_2.3.2-amd64.deb
3. digilent.waveforms_3.12.2_amd64.deb

Based on the output you posted for Enumerate.py I think it's likely that something is wrong with the EEPROM on your AD2. Can you please do the following:

Connect AD2 to Debian 10 PC

1. In a terminal switch to root using "su"
2. In the same terminal execute "rmmod ftdi_sio"
3. In the same terminal execute Enumerate.py and post the results

Thanks,
Michael

[Toladar]

@malexander

I missing to install the digilent adept utilities from your website. So now it's installed :

Quote

Command return from the dpkg :

ii  digilent.adept.runtime                        2.20.1                              amd64        Digilent Adept Runtime
ii  digilent.adept.utilities                      2.3.2                               amd64        Digilent Adept Utilities
ii  digilent.waveforms                            3.12.2                              amd64        Digilent WaveForms

I also disabled the autosuspend mode for the usb device and following your instructions.

The python script is currently

Quote

FTDI Version: 0x10408
Devices: 1
 1. SN: Single RS232-HS flags: 0x2 type: 0x8 id: 0x4036014 locid: 0x109

DMGR Version: 2.8.8
Devices: 0

DWF Version: 3.12.2
Devices: 0

I hope that the AD2 is not brick

Thanks you again !

[malexander]

@ToladarThat looks like an EEPROM issue to me. I believe we do have a way to reprogram the EEPROM from Windows, but I don't think there's any option for programming it from Linux. @JColvin can you help Toladar with EEPROM reprogramming?

[Toladar]

I can access to a windows laptop so if you have the tutorial to reprogram the EEPROM i can try

 

[JColvin]

Hi @Toladar,

I don't know for certain if this is built into the Linux version of the WaveForms app, though it is in the Windows version where you can reprogram the EEPROM directly from WaveForms. Essentially, when you open up WaveForms and go to select your device in the Device Manager, there would be a "My device is not listed button" that will walk you through the reprogramming process. This is shown more directly in this specific post here in step 3: https://forum.digilentinc.com/topic/35-analog-discovery-troubleshooting/?do=findComment&comment=53880.

Are you able to successfully reprogram in the EEPROM through that method?

Thanks,
JColvin

 

[Toladar]

Hello @JColvin

I already tried to reprogram on all os system.

On windows, the application crash when i click on Program button

On linux and macos the console return OpenFX failed when i click on Program button.

Do you have an other way to reprogram the EEPROM ?

Have a nice day !

[attila]

Hi @Toladar

The programming probably fails because the device is busy, opened as COM port.

On Windows open Device Manager:
- make sure the "Load VCP" is unchecked. If it is, uncheck and reconnect device.
- make sure the driver version 2.12.28.0 update from Windows update or https://www.ftdichip.com/Drivers/CDM/CDM v2.12.28 WHQL Certified.zip

[Cappernicus]

Hey there!

I've got a Discovery (version 1, rev.C) that does absolutely nothing when plugged into the computer. The computer makes no sign that it was pllugged in at all. After some debugging and tracing out power supplies with help from the schematics in the reference guide and other solutions posted on this forum, I've been able to narrow the problem down. Current consumption for the whole device is under about 5mA (measured with a USB power meter). The ferrite beads on the USB power lines are both good, as is the protection diode.

Probing all the power supplies reveals that all contollable enable lines for power supplies are off (including the one for IC20). This means the AVCC5V0 line is off with all the subsequent analog power supplies, as well as the 1.8v digital supply. I assume this is because they are only enabled after the FPGA has been configured. The 1v and 3.3v digital supplies are operational.

Probing the FTDI chip reveals that it is properly powered and all looks normal except for two things. VCORE on pin 38 is 1.8v as it should be, but VCCA on pin 37 is grounded. In addition, PWRSAV# on pin 31 is grounded, forcing the chip into suspend mode (which could be why VCCA is low?).

I could not find anything besides the FPGA that might be able to suspend the FTDI, so I am left with the conclusion that one of these two chips is damaged.

Since I don't know much about FPGAs and I don't have a board layout to consult, this is as far as I can easily get without replacing chips. What are your thoughts or suggestions? What is the FTDI power save line connected to?

Thanks!

[attila]

Hi @Cappernicus

The VCCA is an internal rail of the controller. 
It should be measured on the marked capacitor, above the 'IS' of the 'discovery' label.

 

According the AD2 EEPROM setting the PWRSAV# option should not be used. This signal is used with a 10k pull-down for other purpose.

If you suspect this to be the problem you can try to solder a temporal ~2k pull-up to OE_JTAG and DVCC3V3. See the bottom layout:
Connect USB, use the WaveForms application/ Device Manager / "My device is not listed" to reprogram the EEPROM.
Disconnect and remove the pull-up.

To test this, I have configured the AD2 to 'Suspend on ACBus7 Low' and 'Self Powered'
The VCCA was indeed low and device not detected.
With the above method I was able to recover it.

Edited May 18, 2020 by attila

[Cappernicus]

It's an AD1, not AD2. Is PWRSAV# used in the AD1?

 

[attila]

Hi @Cappernicus

Here you have for AD1.
The PWRSAV is used the same way as on AD2.

[Cappernicus]

I attached the pull-up to the OE_JTAG line and clicked "My device is not listed". When I click "Find Device" it says "No device found". Clicking "program" just says that there is no device to program.

As I said earlier, there is no change in the windows device manager when I plug it in, even after waiting several minutes. It does not show up at all, even as an unknown device. Should I assume that the FTDI chip is dead? Or is there something else to check?

*edit: I did also check continuity of both data pins from the "A" end of my USB cable to the associated pins on the FTDI chip. Both are connected so I assume there is no problem with my cable or the USB connector. I also tried all the USB ports on my laptop, and I tried another computer, all with the same result.

Edited May 20, 2020 by Cappernicus
additional information

[attila]

Hi @Cappernicus

If the USB data lines are good and the 3.3V rail is good but the device is not detected most probably the USB controller is damaged.
On AD1 the USB is supplied with DVCC3V3 and on AD2 from USB 5V.

The pull-up should have helped if the EEPROM was accidentally reprogrammed to use the Suspend option.
In Suspend the device is not detected and VCCA is down. In this case the other internal rail VCCCORE is still on.

At this point I don't have any other idea than replacing the USB controller...

[Cappernicus]

That's what I needed to know. I'll order a new chip. Thanks!

[Sairy]

Hi
Could you tell me about available voltage range settings on MATLAB?
I want to set it under 100 mV scale.

ch_in.Name = "AD1_1_in"
rate = 300e3;
dq.Rate = rate;
ch_in.Range = [-2.5 2.5];

https://jp.mathworks.com/help/daq/getting-started-acquiring-data-with-digilent-analog-discovery.html

[attila]

Hi @Sairy

The AD1/2 have two scope input ranges 5 and 50Vpk2pk
https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual#scope_input_divider_and_gain_selection

[MiaPka]

Hello, I encountered this problem when using the software. 

I've tried to restart programs and computers, use other USB interfaces and cables, and use other PC interfaces and the interfaces on the back, but they don't work. Other people don't have this problem when using it. Is there any good solution to solve this problem?