Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


malexander last won the day on October 25 2018

malexander had the most liked content!

About malexander

  • Rank
    Frequent Visitor

Profile Information

  • Gender

Recent Profile Visitors

1769 profile views
  1. @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
  2. @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
  3. @Arvid I received a new build of the 64-bit libfd2xx Linux driver from FTDI and am happy to report that they fixed the bug. They haven't yet released the updated driver to the public, but once they do we will publish new runtime installers that include the new driver. Thanks, Michael
  4. @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
  5. @kursatgol What I did to get this working the last time someone asked about using the XUP JTAG Cable in Linux was the following: 1. Execute "cd /opt/Xilinx/Vivado/2018.1/data/xicom/cable_drivers/lin64/install_script/install_drivers/" 2. Execute "sudo ./install_drivers" 3. Execute “source /opt/Xilinx/Vivado/2018.1/” 4. Execute “vivado” to launch the application. 5. Open hardware manager and click auto connect. Today I tried to replicate the setup in my CentOS 7 Virtual Machine running on my Windows 10 host and Vivado 2018.1 didn't initially find XUP JTAG Cable. In my attempts to debug this I disconnected the cable from the virtual machine and opened Vivado 2018.1 in Windows 10 and proceeded to see if it could be found. Much to my surprise, Vivado could not find it. I then opened the device manager and discovered that in Windows the XUP USB JTAG Cable was showing up as "Xilinx Embedded Platform USB Firmware Loader", which is effectively a bootloader firmware that's used to download the real firmware image. When the driver is properly installed in Windows 10 the OS should initially detect that the device does not have the application firmware programmed, programm it, and then re-enumerate it on the bus. To get Windows to do this I had to do the following: 1. Right click on “Xilinx Embedded Platform USB Firmware Loader” in the device manager and click “Uninstall”. 2. When the uninstall dialog popped up I checked the box the box that says “Delete the driver software for this device.” And then click ok. 3. Once driver uninstall completed I disconnected the programming cable. 4. Launched a command prompt in administrator mode and navigate to "c:\Xilinx\Vivado\2018.1\data\xicom\cable_drivers\nt64\dlc10_win7" 5. execute "wdreg -compat -inf %cd%\windrvr6.inf uninstall" 6. execute "wdreg -compat -inf %cd%\xusbdrvr.inf uninstall" 7. execute "wdreg -compat -inf %cd%\windrvr6.inf install" 8. execute "wdreg -compat -inf %cd%\xusbdrvr.inf install" 9. Reattach the XUP JTAG cable to the USB port. After doing this I connected the cable and Windows loaded two drivers for it: a Jungo driver and a “Xilinx USB Cable” driver under the “Programming cables” section. My Windows 10 installation of Vivado 2018.1 is now able to recognize the XUP JTAG cable and find the Zynq 7020 that’s on the Zed board. Now when I connect the XUP JTAG CABLE to my Centos7 VM and run Vivado Hardware manager is able to find it (see attached screenshots). Having observed this jogs my memory a bit. I remember that in the old days when you wanted to use the XUP JTAG CABLE, or any Xilinx Platform USB Cable in Linux, it was necessary to manually install the drivers via a script. This script not only installed a set of udev rules, but it also modified those rules so that they would call an fxload application and pass it the pathname for the correct firmware image to download to the cable. I also remember having to manually install fxload. A quick look at the udev rules file installed with the 2018.1 drivers: cat /etc/udev/rules.d/52-xilinx-pcusb.rules # version 0002 ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="0007", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="000f", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", MODE="666" ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015", MODE="666" Here we can see that there is no call to fxload and there are no pathnames specified for the firmware images. I suspect that if you want to get this to work seamlessly then you will need to install impact and the cable drivers that impact includes. However, I cannot gaurantee that will work either. Since you are running a Windows host you could just do the same thing that works for me, which is installing the Windows drivers and letting Windows download the firmware to the XUP JTAG cable before you connect it to your Linux VM. Thanks, Michael
  6. @Arvid I heard back from FTDI over the weekend. They were able to reproduce the issue on their end and are investigating a solution. We will post a new Adept Runtime Installer for Linux once FTDI provides a new driver. After this week I'm out of the office until January 7th so it's not likely that we will publish a new installer until next year even if FTDI provides the driver before then. Thanks, Michael
  7. Hi @pelle I upgraded to Mojave. It appears that Apple did modify the way AppleUSBFTDI works and I am able to use D2XX without installing a custom KEXT to block AppleUSBFTDI from claiming the interface. You should be able to upgrade to Mojave (if you haven't already) and use Waveforms without installing our custom KEXT. To remove the kext you have to open up a terminal and then use sudo rm -rf to remove our kext from the /Library/Extensions folder. After doing so reboot your machine and then re-run Waveforms with the Discovery attached. @attila Have you upgraded to Mojave, and if so, can you confirm that the Discovery products are working without the Digilent KEXT? That appears to be the case on mine. If you can confirm this on your end then please remove the KEXT from our Waveforms installer. We can then have support push all customers that are having problems to upgrade to Mojave and remove the custom KEXT. Thanks, Michael
  8. Hi @Arvid Their US support, which is who I have to deal with, said they would forward the information I sent them to their developers (UK based) and get back to me. I will ping them again and see if there are any updates. Thanks, Michael
  9. @attila @pelle This seems to be related to the issue that another customer reported. I wasn't able to reproduce it on my end and I think it may be an issue that only shows up with newer MAC hardware than I have access to. The driver was originally written using the IOUSBDevice and IOUSInterface classes from IOKIT. At some point Apple deprecated these and drastically overhauled the API, pushing new driver development to use the poorly documented IOUSBHostDevice and IOUSBHostInterface. OSX still includes the dependencies for IOUSBDevice and IOUSInterface which has allowed us to continue using our driver. However I don't think Apple tested all of their newer hardware with those libraries and that's probably why we are seeing crashes that don't occur when running older MAC hardware. I re-wrote the driver to use IOUSBHostDevice and IOUSBHostInterface, with the hope that doing so may alleviate the crashes. Unfortunately I'm having issues to get it to laod consistently. I asked several questions of Apple Developer Technical support and haven't received any response. I also filed a bug report against the AppleUSBFTDI with the hope that they will modify their driver so that it will read the EEPROM (if present) and only attach to interfaces that have been configured as virtual COM port interfaces. This is essentially the equivalent behavior of the Windows FTDI driver. Our KEXT does exactly this in the probe function and if the interface is supposed to be VCP then it returns a really high probe score (higher than AppleUSBFTDI) to prevent AppleUSBFTDI from loading so that we can use D2XX. If the interface is supposed to be VCP then we return a probe score of 0 and allow AppleUSBFTDI to attach to the interface. Apple DTS recently sent me an email and asked me to check the functionality of AppleUSBFTDI under OSX Mojave. I haven't yet done this because I needed to use my MAC BOOK pro for testing some FRC stuff. Now that i'm done with that I will upgrade to Mojave and see if they made the changes that I requested. If they modified AppleUSBFTDI in the manner that I requested then it will no longer be necessary to distribute a custom KEXT with Waveforms. I will work on upgrading and get back to you. Thanks, Michael
  10. Hi @manuelreyes60 and @ELG_MPT, I managed to answer my own question by using the Adept Windows application to program the CPLD and then using iMPACT 14.7 to verify the contents of the CPLD against the JED configuration file. My suspicions proved to be correct and even though the Adept Windows application can program the XC2C32A without crashing, it does so incorrectly and does no pass verification in iMPACT. I'm happy to report that was able to modify the low level programming code and am now able to successfully program the XC2C32A from a Raspberry Pi 3b and have iMPACT pass image verification. I created a new installer for Adept Runtime 2.19.2, which will eventually be posted on the Digilent website. For now you can download it here: At some point we will also publish new installers for Windows and x86/64-bit Linux that resolve this problem on those platforms. Thanks, Michael
  11. Hi @manuelreyes60, I finally received a Cmod C2 that has the XC2C32A and was able to replicate the segfault that you reported on a Raspberry Pi 3b. I was also able to program the device successfully in Windows (according to Adept). I fired up the debugger on the Rasbberry Pi and was able to identify where there's a segfault. Based on what I've seen I'm surprised that the XC2C32A can be successfully programmed from any platform. It's pretty clear to me that this device was never tested, and that's probably the result of it not being utilized on any Digilent system board. My findings leave me wondering if the CPLD is even being properly programmed in Windows. The design that I implemented in ISE was so simple that it doesn't provide a good indication of proper functionality. Can you tell me if your design functions correctly when programmed into the CPLD from the Windows Adept application? Thanks, Michael
  12. Hi @Arvid Thanks for running that test. The behavior appears to be the same on your system and clearly your non-Digilent FTDI device is one that your user has R/W permissions for because ListDevices and CreateDeviceInfoList are returning the same count. I'm not sure why the behavior is different when they are plugged into different ports, but that is useful information that I can pass along to FTDI. I sent them a detailed description of the problem and am now awaiting a response. They've been pretty slow to respond in the past so it may be a while before we here anything. Thanks, Michael
  13. Hi @Arvid I'm curious, did you call the standard FT_Open function or was it FT_OpenEx? The reason I ask is because we use the FT_OpenEx function and we open by serial number, which is required for several reasons that I won't go into detail about. This afternoon I modified the Adept Runtime such that it will log a bunch of information during the device discovery process when the "ADEPT_RT_LOGDETAIL" environment variable is set to "5" and the "ADEPT_RT_LOGFILE" environment variable specifies a valid filename. During the process of testing the newly added logging capabilities I discovered a couple of oddities. With an FT_4232H Adept Device and a blank FT_2232H I found that our internal ListDevices function, which I wrote using libusb, returns a device count of 6 while our internal CreateDeviceInfoList function returns a device count of 4. I found that the discrepancy is the result of something I forgot about: certain libusb functions cannot be used on a device for which the current user does not have read/write permission. This makes sense because my default user does not have read write access for the FT_2232H (I didn't add myself to the dialout group) and it only has access to the FT_4232H, which our UDEV rules caught and set the permissions to 666 following usb enumeration. In this scenario "dadutil enum" correctly found and listed the single Digilent device. I wanted to see what gets logged when I run "dadutil enum" with read/write permissions for the blank FT_2232H so I used chmod to manually set the permissions of the blank FT_2232H to "666". I then re-ran "dadutil enum" and much to my surprise 0 Digilent devices were found. A quick peak at the log file allowed me to immediately identify the problem: System Time Process Thread ERC ERC String Message 490087700 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - cftdevPrev = 0, cfdevCur = 6 490087707 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - CreateDeviceInfoList found 6 devices 490087707 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - skipped non-Digilent device 0 490087707 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - skipped non-Digilent device 1 490087707 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - interface list contains 0 devices 490087711 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - OpenEx failed on serial 210383142250A, erc = 2 490087716 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - OpenEx failed on serial 210383142250B, erc = 2 490087720 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - skipped unsupported interface 210383142250C 490087724 28983 1629599488 0 ercNoErc FEnumAndUpdateCache - skipped unsupported interface 210383142250D Above you will see that our ListDevices and CreateDeviceInfo list calls both found 6 interfaces (2 for FT_2232H and 4 for FT4232H). We skipped the first 2 interfaces (shown as devices here) because information received from GetDeviceInfoDetail did not match the minimum set of requirements for them to be considered potential Digilent devices. Things get more interesting once we get past the initial screening. Entries 6 and 7 of the log file show that the call to FT_OpenEx fails with error code 2 (FT_DEVICE_NOT_OPENED). Since we can't open a handle to the device we can't read the additional information that we require from the EEPROM. Unfortunately this is a bug in FTDI's libftd2xx library, and not a bug in our code. We did not write our own implementation of the entire libftd2xx library... only certain enumeration functions (ListDevices, CreateDeviceInfoList, GetDeviceInfoDetail) and we only did that to work around bugs in FTDI's linux driver. While I could re-write the entire library it would require a lot of work, possibly even more work then it would require to re-write the rest of our code to use D2XX on windows and libftdi on Linux/OSX. In any case, that's more work then I will receive approval to do. So for now the best I can do is report my findings to FTDI and try to pressure them into fixing libftd2xx. I'm curious to see what the enumeration log shows on your system. Can you please download this package that includes the logging and give it a go: In order to enable logging you will have to execute "export ADEPT_RT_LOGFILE=adept_log.txt" and "export ADEPT_RT_LOGDETAIL=5" prior to executing "djtgcfg enum". Thanks, Michael
  14. Hi @Arvid, Is there any possibility that you can call from your libftd2xx based application and tell me what it reports for the device type, serial number string, and description string of the JTAG-HS3 when it's not visible via djtgcfg? Thanks, Michael
  15. Hi @Arvid I can't seem to replicate this behavior in my Ubuntu 18.04 VM using an a blank FT2232H and a JTAG-HS3. I'm just curious, have you tried executing "sudo djtgcfg enum" after "djtgcfg enum" fails to find the JTAG-HS3? Perhaps there is an issue with the permissions being set correctly upon attachment. Another possibility is that an FT2232H with no EEPROM functions differently than an FT2232H with a blank EEPROM (what I tested with). I don't have a board that doesn't have an EEPROM. However, I can probably desolder the EEPROM from a board and see what happens. Ok - even with the EEPROM completely removed I still can't replicate this. Thanks, Michael