malexander

Technical Forum Moderator
  • Content Count

    88
  • Joined

  • Last visited

  • Days Won

    3

malexander last won the day on May 23

malexander had the most liked content!

About malexander

  • Rank
    Frequent Visitor

Profile Information

  • Gender
    Female

Recent Profile Visitors

1831 profile views
  1. There are directional buffers between the FT232 and the actual GPIO pads on the module. The direction of these buffers is controlled by the logic level that's applied on the OE0, OE1, and OE2 nets. Placing a '0' on the OEn net will configure the applicable buffer as an output and allow the signal to be driven out of the applicable GPIO pad. Placing a '1' on the OEn net will configure the associated buffer as an input and allow the FT232H to read the state of the applicable GPIO pad.
  2. malexander

    DDR3 input clock source

    There is only a single 100MHz oscillator that's loaded (IC3). The other one (IC2) is not loaded. In order to meet timing the DDR reference clock and DDR system clock have to be in the same column as the bank that contains the DDR3 interface. I don't recall what the thinking was when we included the 12 MHZ USB clock (UCLK) that goes into Bank 15, but you should be able to clock the entire device from pin R2.
  3. Hi @Carlos Posse, Based on the output from dmesg I can tell you that this is not an issue with drivers or software configurations. It's a hardware issue of some sort. I don't see any issues with your schematic. Have you tried using a different USB cable or connecting the cable to a different port on your PC? What are you loading for L8 and L9? Perhaps try loading shunts (0 ohm resistors) instead of ferrites or inductors and see if that makes any difference. Thanks, Michael
  4. malexander

    DMC60c CAN Bus

    Hi @opethmc, The message identifier for sending control messages, which are the types of messages that are sent for driving the output, is 0x02060000 (API field = 0 decimal). You need to append the device number of the target DMC60c to the lower 6-bits. This should be documented in the Output Control Protocol section of the DMC60C CAN Protocol Guide. Thanks, Michael
  5. @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
  6. To be honest I don't think that I've ever used the Adept SDK to compile an application on an embedded Linux target, and have only ever built the Runtime and the utilities on that platform. Since it's been quite a while since the last time I built anything I will have to see if I can get my old Raspbian build setup working again or setup a build environment under Petalinux, which is the easiest thing for me to boot on one of our Zynq based boards. I'm not sure that any of this is going to be worthwhile in the end because the JTAG-SMT2 is one of our FTDI based programmers and there are a lot of bugs in FTDI's arm driver. Unless FTDI released a new driver we are likely going to find that the same driver bugs that plague the AD2 on Raspberry Pi will also prevent the SMT2 from reliably performing JTAG transactions.
  7. @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
  8. @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
  9. @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
  10. @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
  11. @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/settings64.sh” 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
  12. @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
  13. 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
  14. 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
  15. @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