Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

Everything posted by malexander

  1. @varunnagpaal Unfortunately I don't have an answer for you. If I were debugging this I'd be probing the JTAG signals with an oscilloscope but I don't have the hardware here and I doubt I'm going to get authorization to purchase a Snickerdoodle for this purpose.
  2. Hi @Grant Edwards I see a kernel version posted but not the name of the distribution that you are running. Can you please tell me which Linux distribution you are using? I assume it's also the 64-bit version? I'll be on vacation for the next 10 days after today so it may be a while before I have a chance to debug this on my end if I don't get to it today. Thanks, Michael
  3. @anshumantech If you look at the top left corner of sheet 6 you will find header J8 attached to the TMS, TDI_FPGA, TCK, and TDO_FPGA nets through resistors R163, R164, R165, and R166. Those resistors are present to help prevent damage from any drive conflicts that may occur when both an external and onboard programmer are active. However, JTAG programming can't function correctly when both an onboard and external programmer are active. There are tri-state buffers between the onboard USB controller and the TMS, TDI_FPGA, and TCK nets. These buffers are held in tri-state when the programmer
  4. @varunnagpaal I still think your issue is the STM32F078VBH6. If Krtkl doesn't want you to remove RN9 then you should ask them the circumstances under which the STM32F078VBH6 drives the JTAG lines and how to get it into tri-state mode. If you have an oscilloscope you could try probing pins 2 and 7 simultaneously when the JTAG-HS3 is trying to drive TCK and if you don't see a clock signal of the same amplitude on both sides of the resistor then there is likely a drive conflict. If you post oscilloscope captures and tag me then I'd be willing to review them. Thanks, Michael
  5. @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
  6. @perdue Based on the output it doesn't look like you have installed, which is the full FTDI driver. The 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: (libc6,x86-64) => /usr/lib64/digilent/adept/ (libc6,x86-64) => /usr/lib64/digilent/adept/ (libc6,x86-64) => /usr/lib64/digilent/adept/ Did you run the install script for t
  7. @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/" 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
  8. @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
  9. @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
  10. @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
  11. 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 w
  12. 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.
  13. 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: 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
  14. @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. If this is an intermittent issue that only occurs after several hours or days of usa
  15. 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
  16. @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 Can you tell me exactly which version of Redhat it is and the architecture? Thanks, Michael
  17. @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
  18. @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?
  19. @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 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 roo
  20. @attila It looks like on Linux your python script first tries enumerating using I suspect that the ftdi_sio driver is still attached the first time you run the script after device plug-in. Our library ( 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 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 dev
  21. @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.
  22. @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 curren
  23. @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."
  24. 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.
  25. 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