malexander

@zygot The Linux application was modified to be usable outside of Linux and it was renamed to dpmutil. An example was published under the "dpmutil" branch: https://github.com/Digilent/Eclypse-Z7-SW/tree/dpmutil Sorry I somehow forgot to send this to you but it looks like it has been there for a while. Please let us know if you run into any problems. Thanks, Michael

@MarceloNotThePLCguy I was expecting the output to show libftd2xx under an "adept" sub directory. Since it's showing it under "/lib64" that means the version that's being loaded isn't the version that we distribute with the Adept Runtime and could be an older version than the one we include (1.4.8). You could try downloading 1.4.8 from FTDI's website and replacing the library in "/lib64" with it to see if that makes any difference. https://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx-x86_64-1.4.8.gz If this is an intermittent issue that only occurs after several hours or days of usage then it may be similar to Raspberry Pi 4 driver. If that's the case then we don't have a solution at this point in time. We are still trying to figure out a good way to replicate it and capture the behavior in a log.

@attila I'm unaware of any issues of this sort on i386/x86_64 desktop Linux. @MarceloNotThePLCguy We should check and see if there's more than one version of libftd2xx installed on your system. Can you please execute the following command and see how many items are listed? /sbin/ldconfig -p | grep libftd2xx.so Can you tell me exactly which version of Redhat it is and the architecture? Thanks, Michael

@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 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: digilent.adept.runtime_2.20.1-amd64.deb digilent.adept.utilities_2.3.2-amd64.deb 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 In a terminal switch to root using "su" In the same terminal execute "rmmod ftdi_sio" In the same terminal execute Enumerate.py and post the results Thanks, Michael

@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: Detach AD2 from PC Attach AD2 to PC Execute "sudo rmmod ftdi_sio" 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.

@zygotWe are going to provide a bare metal project for configuring the PMCU. The task has been assigned to a specific person and is the next thing in their queue. Unfortunately I do not have a good estimate for when that work item will be completed but am hopeful that it will be sometime in early May.

@zygot Presently there is no bare metal equivalent of decutil, any existing libraries, or example code for communicating with the Platform MCU from bare metal. When I was involved in the development process the primary use cases that people were describing always involved a Linux OS so I didn't take the time to develop any software for communicating with the Platform MCU from bare metal. Clearly this is an over site on my part. We will discuss this internally and decide if this is something that will be developed by the software team or by my team and come up with a plan to produce a usable bare metal solution. Thanks, Michael

The Platform MCU (IC23) controls the FPGA fan. Fan speed can be set to one of four different speeds using the decutil Linux application: minimum, medium, maximum, and auto. The decutil application is included with the Linux image. My colleagues did not agree with using udev to set the default permissions to "rw" for all users of the I2C controller so you will need to use "sudo" to run the decutil applicatin, otherwise you will get an error. The commands for setting the various fan speeds are as follows: decutil setfancfg -fanid 1 -speed minimum decutil setfancfg -fanid 1 -speed medium decutil setfancfg -fanid 1 -speed maximum decutil setfancfg -fanid 1 -speed auto If you configure the fan speed to "auto" (factory default) then the fan will only turn on when the Zynq die temperature exceeds 40C and will automatically switch between minimum, medium, and maximum speed based on the temperature. Once the temperature falls below 35C the fan will turn off again. The configuration is stored in the MCU flash and will be preserved across power cycles. The documentation for decutil can be found here: https://reference.digilentinc.com/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf Thanks, Michael

@zaxxon It looks like the Analog Dscovery 2 that you have connected to your machine now can at be enumerated by everything in the chain, which is an improvement from the results you posted in January. Are you using the same MAC to run the script or is this on a different MAC? Did you try running Waveforms again to see if it can access your discovery 2? I assume you did and the answer is no. The error message means that something called DmgrGetInfo and requested a device attribute field that's not supported by the device. I looked at the python script and all of the calls that it makes to DmgrGetInfo specify attributes that are supported. Plus the output that you posted doesn't show any error messages specific to the Dmgr calls made directly from within the script. Perhaps the offending call is in the Waveforms framework. @attila can you give me a list of the DmgrGetInfo calls that Waveforms makes so I can try to figure out what the unsupported attribute is that's being requested? Thanks, Michael

@zaxxon I'm not sure what's preventing libftd2xx from accessing the device, but if we can't resolve that issue then Waveforms will never be able to see the AD2. I read back through your posts and noticed that you were running Parallels desktop. Can you confirm that the AD2 USB device is not being taken over by parallels and passed to a VM? Thanks, Michael

@attila No I haven't observed any issues a powered USB hub, and that is in fact, the only way that I've been using the Discovery with my Macbook pro because it doesn't have enough physical ports for me to plug it in directly. @zaxxon The output from the script should look similar to this: Digilent FTDI Enumeration library loaded Devices: 1 1. SN:210321A2A6D8 'Digilent USB Device' flags: 0x0 type: 0x8 id: 0x4036014 locid: 0x141d0 FTDI Version: 0x10202 Devices: 1 1. SN:210321A2A6D8 'Digilent USB Device' flags: 0x2 type: 0x8 id: 0x4036014 locid: 0x141d DMGR Version: 2.8.4 Devices: 1 1. SN:210321A2A6D8 'Analog Discovery 2' PDID: 0x40300360 DWF Version: 3.9.1 Devices: 1 1. SN:210321A2A6D8 'Analog Discovery 2' It's odd that libdftd2xx can see and access the device but libftd2xx cannot. Our library, libdftd2xx only implements some of the enumeration functions, and does not support any of the data transfer functions. We rely entirely on libftd2xx for those. Since libftd2xx cannot see the device neither DMGR or Waveforms will be able to open it. I wonder if this is the same bug that we found in the Linux version of FTDI's libftd2xx library. Do you have any other FTDI devices attached to your system, and if so, can you detach them and try running the script with only the Discovery attached? I realize that this isn't the solution you are looking for but having that information would give me an idea of what to look for, and likely lead to me being able to work with FTDI to address the issue in their library. Thanks, Michael

@hartfort @zaxxon I have Mojave 10.14.2 and Waveforms 3.9.1 is able to open my Analog Discovery 2 when it's attached to the USB port on my MacBook Pro. Mojave appears to list any and all attached serial devices under the Network Manager, and that would include any FTDI chip that uses the standard VID/PID combination, even if you don't utilize at as a COM port. Nevertheless this does not seem to impact the ability to access it using the libftd2xx library, which is utilized by our lower level software to communicate with the Analog Discovery 2. Can you confirm that you installed both the WaveForms application and dwf.framework and did NOT install DigilentFtdiDriver.pkg? Can you confirm that you haven't opened the device as a serial port through any terminal applications? If you open the device with a terminal application then Waveforms will not be able to access it. Can you run the attached python script with the Analog Discovery 2 attached and post the output? Thanks, Michael digi_enum.py

@kpax It sounds like the Arty is working correctly on your desktop so we can rule out any EEPROM image issues, as well as any issues with the actual hardware. SInce this appears to be an issue with the FTDI driver not attaching correctly to the device re-installing Vivado over and over isn't going to help resolve the issue. I see you already tried updating the driver and that doesn't appear to have worked because Windows thinks it's the same driver that's already installed. Have you tried doing the following: 1. In the device manager under USB devices right click on “USB Serial Converter A” and click “Uninstall”. Do the same for “USB Serial Converter B”. 2. Disconnect the Arty from the PC 3. Reboot, reattach the board, and see if the driver gets properly installed/loaded If that doesn't work then another option is to disconnect the ARty board from your PC and then use FTDI's CDM Removable tool to uninstall the driver. They don't appear to have updated the tool in quite some time but it's still available for download from their website: http://www.ftdichip.com/Support/Utilities/CDMUninstaller_v1.4.zip If you want to try this disconnect the Arty board, run the application as an Administrator and put in “0403” for Vendor ID, “6010” for product ID and then click “Add”. After that click “Remove Devices”. Reboot and re-attach Arty board to PC with USB cable. This does a more thorough removable than just uninstalling the driver from the Device Manager, so I suspect you may get better results when reinstalling the driver. If none of the above works then perhaps try a different USB cable and/or different USB port. Thanks, Michael

There appears to be a different issue on your system. Our internal library that enumerates FTDI devices directly using libusb appears to see the AD2 but for some reason FTDI's D2XX library does not. I don't recall ever encountering this situation before. Normally both don't work. Can you please execute "ioreg -c IOUSBInterface -l -w 0 > usbdevices.txt" and then send me the txt file? Thanks, Michael

Hi Naoshi, I'm glad to hear that it's finally working. I understand why the python script wasn't previously working but I'm still not sure why the WaveForms application bundle didn't work prior to you installing the dwf.framework. The Runtime should have been able to find those data files in the application bundle without the dwf.frame being installed. It works correctly on my system. I will continue to research this problem and see why it doesn't work for some people. Thanks, Michael

Hi Naoshi, It sounds like you don't have the dwf framework installed, which may explain why it can't find the Digilent data directory or the firmware images directory. Presently we perform the following search when attempt to locate the data directory: 1. Check to see if the path to the data directory was specified by the "DIGILENT_DATA_DIR" environment variable. If this path exists then it is returned as the path to the data directory. 2. Check to see if the "@executable_path/../Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files. 3. Check to see if the "@executable_path/../Frameworks/dwf.framework/Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files. 4. Check to see if the "/Library/Frameworks/dwf.framework/Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files. 5. Check to see if the "/usr/local/share/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files. Since this python script is not executing the WaveForms application bundle paths 2 and 3 that I listed above won't be found and the expectation is that we are going to fall back to path 4. However, if the dwf framework isn't installed then that path won't be found either. We don't expect any external users to have the software installed in their /usr/local directory and that path is a fallback used for internal testing. Can you please mount the waveforms dmg and then drag dwf.framework into both the "Frameworks" and "SDK" folders to the right of it? After that try re-running the python script. Be sure that the environment variables for generating the log files are still set. Thanks, Michael

Hi Naoshi, Can you please check to see if this directory exists: "/Library/Frameworks/dwf.framework/Resources/digilent/adept/data/firmware" ? It should exist and contain the following files: FTDIFW_50_00000011_00000000_010A.dylib FX2FW_01_00000001_00000000_030A.HEX FX2FW_09_0000000D_00000000_030A.HEX FTDIFW_51_00000001_00000000_010A.dylib FX2FW_01_00000010_00000000_030A.HEX FX2FW_0A_0000001D_00000000_030A.HEX FTDIFW_52_00000011_00000000_010B.dylib FX2FW_02_00000001_00000000_030A.HEX FX2FW_0B_00000000_0000000D_030A.HEX FTDIFW_53_00000001_00000000_010A.dylib FX2FW_02_00000004_00000000_030A.HEX FX2FW_0C_0000000D_00000000_030A.HEX FTDIFW_54_00000013_00000000_010B.dylib FX2FW_03_00000011_00000000_030A.HEX FX2FW_0D_0000000D_00000000_030A.HEX FTDIFW_55_00000811_00000000_010A.dylib FX2FW_04_00000005_00000000_030A.HEX FX2FW_0E_0000000D_00000000_030A.HEX FTDIFW_56_00000811_00000000_010A.dylib FX2FW_05_0000000D_00000000_030A.HEX FX2FW_0F_00000000_0000000D_030A.HEX FTDIFW_57_00000001_00000000_010A.dylib FX2FW_06_0000001D_00000000_030A.HEX FTDIFW_60_00000000_00000801_010A.dylib FX2FW_08_0000000D_00000000_030A.HEX Assuming that directory does exist one additional thing to try doing is executing "export DIGILENT_DATA_DIR=/Library/Frameworks/dwf.framework/Resources/digilent/adept/data" and then re-running the python script. It would be odd if that worked, and if it does then it would suggest that there's a bug in code that searches for the location of the data directory and for some reason or another it doesn't manifest on the Mac's that we have here. Thanks, Michael

@Naoshi I was checking this thread regularly for a few days and then got distracted and forgot about it. Anyway, ERC 3090 means that there was an error while initializing DPCOMM. There are a number of reasons why this could happen. Thankfully there is a way to enable an error log. Can you please do the following: 1. Execute "export ADEPT_RT_LOGDETAIL=1" 2. Execute "export ADEPT_RT_LOGFILE=~/adept_erc.log" 3. Re-run your modified version of digi_enum.py and post the output of the log file here. Thanks, Michael

@ChristopherN If the script reports that no devices are connected please disconnect your AD2, reconnect it, and then execute the "syslog" command. If the Digilent kernel module is working correctly then you should see something similar to the following: Jan 16 16:45:57 michaels-mbp kernel[0] <Notice>: Digilent Stopping Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe8: initial probe score = 100000 Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe: Manufacturer Name = Digilent Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe8: final probe score = 100001 Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent Starting If you can't find anything with "syslog | grep Digilent" or you see "Digilent Stopping" while the device is still connected then something isn't working correclty with the kernel extension. Thanks, Michael

@ChristopherN I modified Attila's python script so that it will call the FTDI enumeration functions inside of libdftd2xx.dylib prior to attempting to call the ones in libftd2xx.dylib. Can you please try running the below script on your MBP with the AD2 attached and post the output? Thanks, Michael digi_enum.py