malexander

Technical Forum Moderator
  • Content Count

    137
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by malexander

  1. @Don Koch If I understand what you are asking is if you plug in a USB cable that only provides GND, D+, and D-, but not VBUS, then would the module still work? The answer is no because the USB controller is powered by VBUS, not VREF. The tri-state buffers between the USB controller and the actual I/O pins prevents any current from flowing into the USB controller when it's not powered. The TDO pin has an open drain buffer between it and the USB controllers input pin so no current should flow in that way either. If you find that the module works without powering VBUS then there must be a leakage path that I'm not seeing and that will warrant further investigation on our end. Thanks, Michael
  2. @perdue Based on the output it doesn't look like you have libftd2xx.so installed, which is the full FTDI driver. The libdftd2xx.so library is only a partial implementation that we use for enumeration purposes to work around a bug in FTDI's driver. It should look something like this if properly installed: libftd2xx.so (libc6,x86-64) => /usr/lib64/digilent/adept/libftd2xx.so libdftd2xx.so.1 (libc6,x86-64) => /usr/lib64/digilent/adept/libdftd2xx.so.1 libdftd2xx.so (libc6,x86-64) => /usr/lib64/digilent/adept/libdftd2xx.so Did you run the install script for the FTDI driver? Btw we normally recommend using one the rpm or debian package for installation and not the tar.gz. We only provide the tar.gz for platforms that use package managers that aren't compatible with rpm or debian package files. Thanks, Michael
  3. @perdue Can you please do the following: 1. execute "/sbin/ldconfig -p | grep ftd2xx" and paste the output 2. execute "cat /etc/udev/rules.d/52-digilent-usb.rules" and paste the output 3. execute "cat /etc/ld.so.conf.d/digilent-adept-libraries.conf" and paste the output Do you have any other system that you can attach the VCU118 USB interface to see if the issue is limited to your Centos 7.5 installation? Thanks, Michael
  4. @attila There's a lock associated with each interface that gets acquired when the enable command is executed and released when disable is executed. The lock has to be shared across processes so it doesn't go away until all applications referencing the runtime libraries are closed. The type of lock I'm using should be recoverable from a dead thread/process but perhaps that's not working correctly. I'll look into this while I'm working on the next release. Thanks, Michael
  5. @perdue How did you install the software? Was it through the rpm packages or did you perform a manual installation using the tar.gz archives? Can you try running "sudo dadutil enum" to see if the results are any different? Thanks, Michael
  6. @MikeA I just connected a JTAG-HS3 to J15 of the Zed board and Vivado 2019.2 was able to detect both the ARM and PL on my Windows 10 PC. It's rather odd that Adept can see the 7015 on your board but Vivado cannot. I looked at the PicoZed schematic and the JTAG lines are referenced at 3.3V with 4.7K pull-ups to 3.3V. Do you have any additional pull-up or pull-down resistors on your board? What about series resistors or buffers between the 14-pin header and the JTAG lines? One other thing: are you supplying power (probably should be 3.3V) to pin 2 of your 14-pin JTAG header? Thanks, Michael
  7. PGVCC5V0 is created using a resistor divider off the VCC5V0 supply output. The divider creates a voltage of ~1.598 (assumes ideal resistors and infinite input impedance on all loads), which is plenty high to exceed the enable threshold of the ADP7118 (1.3V max). If you are measuring anything between 1.5V and 1.6V then there's nothing wrong with the PGVCC5V0 net. If USR_VCC12V0 is measuring 0V then IC10 must be damaged or there must be a short circuit downstream of that device. The VCC12V0 output is tested as part of the manufacturing test so the unit should have failed testing if that supply wasn't functioning prior to the unit being shipped.
  8. malexander

    Eclypse-Z7 FPGA Fan

    @zygot Specifying the fanid via a letter is not something that was supported in the original Linux application so I'm not surprised that the command line parser doesn't allow it. I forwarded the information you provided and have been told that the ability to set the fanid using a letter has been added and that the other issues have been fixed and pushed to git. Sorry for the inconvenience.
  9. malexander

    Eclypse-Z7 FPGA Fan

    @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
  10. @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.
  11. Error code 0x2 means the transfer was cancelled due to timeout. It would be helpful to understand how large the DptIO calls by Waveforms are, the frequency at which they are made, and how to easily reproduce this on my end. I have an old PC that I could load desktop Ubuntu on and try this. Being able to use the USB packet Anlayzer to log what's happening on the bus when this error occurs would be really useful. However, if it requires hours or days for the error to occur then it's going to be very difficult to correlate the failure with a specific point in the log. I remember we had some sort of problem on Raspberry Pi before with an older version of the FTDI driver where the driver stopped issuing IN tokens on the bus. If that's what's happening here then that's a bug in the FTDI driver and I can't fix it and unless we can come up with an easy way to reproduce the symptoms then FTDI won't fix it either.
  12. @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
  13. @ahmetnc It's not possible to connect the UART channel of the JTAG-SMT3 to the ARM STM32F439 because the JTAG-SMT3 has fixed direction buffers whose direction respect UART signaling and will prevent TMS, TDI, and TDO from being driven correctly. If you want to use a single JTAG-SMT3 to communicate with both an Artix 7 FPGA and ARM STM32F439 then you will need to place the devices in series and connect them both to channel A of the JTAG-SMT3. The JTAG protocol was designed to work with multiple devices in series and I'm fairly certain that Vivado can place the ARM device in bypass so that it can communicate with the Artix 7. However, I don't know anything about the ARM programming/debugging tools and cannot comment on whether they properly detect and place unknown/unsupported devices in bypass mode. You'll have to research that on your end. Thanks, Michael
  14. @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?
  15. @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
  16. @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.
  17. @jesmith All of the fixed supplies (+3.3V, +5.0V, +12.0V, -12.0V) have short circuit protection and current limits. Additionally, they are protected to undervoltage/overvoltage of +/- 16V.
  18. @jesmith I'm not sure where you browsing the documentation because I don't see page numbers but if you are talking about the statement that says "Important Note: To prevent damage to the device, care must be taken not to drive input signals to the digital input/output channels over 5V." then yes, it's overly cautious. I think the reason we list "Inputs are 5V tolerant" for the AD2 vs "Overvoltage up to ±20V is supported" is because at 5V the PTCs won't trip. If you apply a 20V input at a high enough duty cycle then the PTCs will trip and not allow any current to flow. In both cases current is going to flow through the clamp diodes to the digital 3.3V supply, resulting in a much lower input impedance than what would be seen by a 3.3V signal. Off the top of my head the only other differences are: 1. The programmable power supply rails on the Analog Discovery Studio are limited to be between +1V and +5V on the positive supply and -1V and -5V on the negative supply. 2. Analog Disovery 2 with BNC adapter supports AC or DC coupled inputs by using a jumper to bypass the coupling capacitor when DC coupling is desired. All inputs of the Analog Discovery 2 are DC coupled.
  19. @jesmith The Digital I/O protection of the Analog Discovery Studio is identical to the Analog Discovery 2. The statement is section 5 of the Analog Discovery 2 reference manual is correct and applies to Analog Discovery Studio: "Input and output pins are LVCMOS3V3. Inputs are 5V tolerant. Overvoltage up to ±20V is supported."
  20. malexander

    Eclypse-Z7 FPGA Fan

    @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.
  21. You can try installing the KEXT that's included in the Waveforms dmg and see if it'll work on 10.14. It was designed for older versions of OSX but I do recall it loading and functioning correctly when I had 10.14 installed on the MBP that I have here. The probe function of the kext uses a control transfer to read the EEPROM attached to the FTDI and determine if it's not a Digilent device or if the VCP drivers are supposed to be loaded, and if so, then returns a probe score of 0, allowing any other serial driver to take control of the device interfaces. If it's a Digilent device and the VCP bit isn't set for the interface then a very high probe score will be returned, preventing other serial drivers from claiming the interface. I don't think you actually need "FTDIUSBSerialDriver.kext" with 10.14 or newer to communicate with FTDI chips.
  22. You can try using "sudo kextunload /System/Library/Extensions/AppleUSBFTDI.kext" and see if that will work. That won't delete the kext but it should temporarily unload it, and then hopefully you will be able to connect to the AD2.
  23. @Wayne Contello I see AppleUSBFTDI.kext listed. That's almost certainly what's preventing the FTDI driver from accessing your Analog Discovery. WHat's odd about that is I remember AppleUSBFTDI.kext being removed in 10.14 so I'm surprised that it's still on your system. As a test can you please try the following: Disconnect AD2 from your MAC. Execute "sudo mv /System/Library/Extensions/AppleUSBFTDI.kext AppleUSBFTDI.kext.disabled" Reboot Connect AD2 Run enumerate.py script Run Waveforms and see if AD2 is found Thanks, Michael
  24. @Wayne Contello When everything is working correctly the output of the script should appear similar to the following: Digilent FTDI Enumeration library loaded Devices: 1 1. SN:210321A805BB 'Digilent USB Device' flags: 0x0 type: 0x8 id: 0x4036014 locid: 0x141a0 FTDI Version: 0x10416 Devices: 1 1. SN:210321A805BB Digilent USB Device flags: 0x2 type: 0x8 id: 0x4036014 locid: 0x141a DMGR Version: 2.8.4 Devices: 1 1. SN:210321A805BB Analog Discovery 2 PDID: 0x40300360 DWF Version: 3.12.2 Devices: 1 1. SN:210321A805BB Analog Discovery 2 In your case it looks like our internal library, which is only used for low level enumeration and not for data transfer, is able to access the device. At that level all we are doing is performing simple control transfers on the control endpoint and not actually claiming an interface or transferring any data with the bulk endpoints. The FTDI driver gets used for everything else and something on your system seems to be preventing it from accessing the USB interfaces of the Analog Discovery 2. The serial port driver (AppleUSBFTDI.kext) that Apple included in older versions of OSX used to claim the USB interfaces and prevent the FTDI driver (libd2xx) from accessing the interfaces. In order to use the AD2 when AppleUSBFTDI.kext was prevent it was necessary to unload the kext, delete the kext, or use a custom kext that we wrote to prevent AppleUSBFTDI.kext from claiming the interfaces of the AD2. All of these issues should have gone away with Mojave (10.14) and newer, as Apple overhauled their serial drivers, and there should not longer be a need for a custom kext to prevent an Apple driver from claiming the interfaces. Can you execute "ls /System/Library/Extensions/ | grep USB" and paste the results so that I can see if there's anything different on your system that I have on mine. Thanks, Michael
  25. malexander

    Eclypse-Z7 FPGA Fan

    @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