malexander

Technical Forum Moderator
  • Content Count

    132
  • Joined

  • Last visited

  • Days Won

    5

malexander last won the day on January 22

malexander had the most liked content!

About malexander

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Female

Recent Profile Visitors

2681 profile views
  1. @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
  2. 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.
  3. 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.
  4. 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
  5. @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.
  6. 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.
  7. @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
  8. @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
  9. @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?
  10. @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
  11. @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.
  12. @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.
  13. @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.
  14. @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."
  15. 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.