Jump to content

malexander

Technical Forum Moderator
  • Posts

    224
  • Joined

  • Last visited

Posts posted by malexander

  1. @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.

  2. @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.

  3. @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:

    1. digilent.adept.runtime_2.20.1-amd64.deb
    2. digilent.adept.utilities_2.3.2-amd64.deb
    3. 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

    1. In a terminal switch to root using "su"
    2. In the same terminal execute "rmmod ftdi_sio"
    3. In the same terminal execute Enumerate.py and post the results

    Thanks,
    Michael

  4. @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:

    1. Detach AD2 from PC
    2. Attach AD2 to PC
    3. Execute "sudo rmmod ftdi_sio"
    4. 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.

     

  5. @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.

  6. @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

  7. The Platform MCU (IC23) controls the FPGA fan. Fan speed can be set to one of four different speeds using the decutil Linux application: minimum, medium, maximum, and auto. The decutil application is included with the Linux image. My colleagues did not agree with using udev to set the default permissions to "rw" for all users of the I2C controller so you will need to use "sudo" to run the decutil applicatin, otherwise you will get an error. The commands for setting the various fan speeds are as follows:

    decutil setfancfg -fanid 1 -speed minimum
    decutil setfancfg -fanid 1 -speed medium
    decutil setfancfg -fanid 1 -speed maximum
    decutil setfancfg -fanid 1 -speed auto

    If you configure the fan speed to "auto" (factory default) then the fan will only turn on when the Zynq die temperature exceeds 40C and will automatically switch between minimum, medium, and maximum speed based on the temperature. Once the temperature falls below 35C the fan will turn off again.

    The configuration is stored in the MCU flash and will be preserved across power cycles.

    The documentation for decutil can be found here: https://reference.digilentinc.com/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf

    Thanks,
    Michael

  8.  

    @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

  9. @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

  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. @kpax

    It sounds like the Arty is working correctly on your desktop so we can rule out any EEPROM image issues, as well as any issues with the actual hardware. SInce this appears to be an issue with the FTDI driver not attaching correctly to the device re-installing Vivado over and over isn't going to help resolve the issue. I see you already tried updating the driver and that doesn't appear to have worked because Windows thinks it's the same driver that's already installed. Have you tried doing the following:

    1. In the device manager under USB devices right click on “USB Serial Converter A” and click “Uninstall”. Do the same for “USB Serial Converter B”.
    2. Disconnect the Arty from the PC
    3. Reboot, reattach the board, and see if the driver gets properly installed/loaded

    If that doesn't work then another option is to disconnect the ARty board from your PC and then use FTDI's CDM Removable tool to uninstall the driver. They don't appear to have updated the tool in quite some time but it's still available for download from their website:

    http://www.ftdichip.com/Support/Utilities/CDMUninstaller_v1.4.zip

    If you want to try this disconnect the Arty board, run the application as an Administrator and put in “0403” for Vendor ID, “6010” for product ID and then click “Add”. After that click “Remove Devices”. Reboot and re-attach Arty board to PC with USB cable. This does a more thorough removable than just uninstalling the driver from the Device Manager, so I suspect you may get better results when reinstalling the driver.

    If none of the above works then perhaps try a different USB cable and/or different USB port.

    Thanks,
    Michael
  12. 1 hour ago, SpacedCowboy said:

    @malexander Still not working over here, though :(

    I am still seeing:

    
    sh-3.2$ python ~simon/Downloads/digi_enum.py 
    
    Digilent FTDI Enumeration library loaded
    Devices: 1
     1. SN:210321A195D5 'Digilent USB Device' flags: 0x0 type: 0x8 id: 0x4036014 locid: 0x110
     2. SN:210299A1818C 'Digilent USB Device' flags: 0x0 type: 0x8 id: 0x4036014 locid: 0x1b0
    
    FTDI Version: 0x10202
    Devices: 0
    
    DMGR Version: 2.8.2
    Devices: 0
    
    DWF Version: 3.4.7
    Devices: 0

    (one of these is the Analog discovery, the other is an HS3) ... and I have:

    
    sh-3.2$ ls /Library/Frameworks/dwf.framework/Resources/digilent/adept/data/firmware
    FTDIFW_50_00000011_00000000_010A.dylib	FX2FW_03_00000011_00000000_030A.HEX
    FTDIFW_51_00000001_00000000_010A.dylib	FX2FW_04_00000005_00000000_030A.HEX
    FTDIFW_52_00000011_00000000_010B.dylib	FX2FW_05_0000000D_00000000_030A.HEX
    FTDIFW_53_00000001_00000000_010A.dylib	FX2FW_06_0000001D_00000000_030A.HEX
    FTDIFW_54_00000013_00000000_010B.dylib	FX2FW_08_0000000D_00000000_030A.HEX
    FTDIFW_55_00000811_00000000_010A.dylib	FX2FW_09_0000000D_00000000_030A.HEX
    FTDIFW_56_00000811_00000000_010A.dylib	FX2FW_0A_0000001D_00000000_030A.HEX
    FTDIFW_57_00000001_00000000_010A.dylib	FX2FW_0B_00000000_0000000D_030A.HEX
    FTDIFW_60_00000000_00000801_010A.dylib	FX2FW_0C_0000000D_00000000_030A.HEX
    FX2FW_01_00000001_00000000_030A.HEX	FX2FW_0D_0000000D_00000000_030A.HEX
    FX2FW_01_00000010_00000000_030A.HEX	FX2FW_0E_0000000D_00000000_030A.HEX
    FX2FW_02_00000001_00000000_030A.HEX	FX2FW_0F_00000000_0000000D_030A.HEX
    FX2FW_02_00000004_00000000_030A.HEX

     


    There appears to be a different issue on your system. Our internal library that enumerates FTDI devices directly using libusb appears to see the AD2 but for some reason FTDI's D2XX library does not. I don't recall ever encountering this situation before. Normally both don't work. Can you please execute "ioreg -c IOUSBInterface -l -w 0 > usbdevices.txt" and then send me the txt file?

    Thanks,
    Michael

     

     

     

  13. 12 minutes ago, Naoshi said:

    Hi, Michael,

    I executed the following steps:

    1. I downloaded "digilent.waveforms_v.3.4.7.dmg"

    2. I had my mac mount the file.

    3. Then, the installer of waveforms2015 was popped up.

    4. "To install,..." message is written in the upper side of the finder window, and "Runtime and SDK..." message is also written in the lower side.

    5. I don't know where the SDK directory is. But I followed the message in the lower side. That is, I only dragged the "dwf.framework" icon into /Library/Framework folder.

    6. I started the Terminal app.

    7. I executed the digital_enum.py in the Terminal, then, I have the following messages:

    dyld: warning, LC_RPATH @executable_path/../Frameworks in /Library/Frameworks/dwf.framework/dwf being ignored in restricted program because of @executable_path

     

    Digilent FTDI Enumeration library loaded

    Devices: 1

     1. SN:(serial number) 'Digilent USB Device' flags: 0x0 type: 0x8 id: 0x4036014 locid: 0x140e0

     

    FTDI Version: 0x10202

    Devices: 1

     1. SN:(serial number) 'Digilent USB Device' flags: 0x2 type: 0x8 id: 0x4036014 locid: 0x140e

     

    DMGR Version: 2.8.2

    Devices: 1

     1. SN:(serial number) 'Analog Discovery 2' PDID: 0x40300360

     

    DWF Version: 3.4.7

    Devices: 1

     1. SN:(serial number) 'Analog Discovery 2'

    8. Hmm, It goes well??

    9. I executed Waveforms2015. Then, finally it could recognize my Analog Discovery 2.

    10. First of all, Scope, Wavegen, and Supplies work normally!!!!

    Thank you, Michael. 

    The message of the installer should still be improved.

    Hi Naoshi,

    I'm glad to hear that it's finally working. I understand why the python script wasn't previously working but I'm still not sure why the WaveForms application bundle didn't work prior to you installing the dwf.framework. The Runtime should have been able to find those data files in the application bundle without the dwf.frame being installed. It works correctly on my system. I will continue to research this problem and see why it doesn't work for some people.

    Thanks,
    Michael

  14. 14 hours ago, Naoshi said:

    Hi, Michael,

     

    My Mac has only the directory "/Applications/Waveforms.app/Contents/Frameworks/dwf.framework/Resources/digilent/adept/data/firmware"

    in stead of "/Library/Frameworks/dwf.framework/Resources/digilent/adept/data/firmware" .

    It does not have the directory "/Library/Framewors/dwf.framework.

    All of the listed files are contained in the directory.

    Hi Naoshi,

    It sounds like you don't have the dwf framework installed, which may explain why it can't find the Digilent data directory or the firmware images directory. Presently we perform the following search when attempt to locate the data directory:

    1. Check to see if the path to the data directory was specified by the "DIGILENT_DATA_DIR" environment variable. If this path exists then it is returned as the path to the data directory.
    2. Check to see if the "@executable_path/../Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files.
    3. Check to see if the "@executable_path/../Frameworks/dwf.framework/Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files.
    4. Check to see if the "/Library/Frameworks/dwf.framework/Resources/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files.
    5. Check to see if the "/usr/local/share/digilent/adept/data/" directory exists. If this directory exists then assume it contains the appropriate data files.

    Since this python script is not executing the WaveForms application bundle paths 2 and 3 that I listed above won't be found and the expectation is that we are going to fall back to path 4. However, if the dwf framework isn't installed then that path won't be found either. We don't expect any external users to have the software installed in their /usr/local directory and that path is a fallback used for internal testing.

    Can you please mount the waveforms dmg and then drag dwf.framework into both the "Frameworks" and "SDK" folders to the right of it? After that try re-running the python script. Be sure that the environment variables for generating the log files are still set.

    Thanks,
    Michael

  15. 27 minutes ago, Naoshi said:

    Hi Michael,

    I have the following message in the generated log file:

     

     

    System Time     Process     Thread        ERC     ERC String                  Message

    1751613013      9038        1407363402352003080    ercInternalError            USBC::FInit() failed to get firmware image path

    1751613013      9038        1407363402352003080    ercInternalError            DPCOMM DllInit failed to init USBC

    1751613026      9038        1407363402352003090    ercDpcommInitFailed         DPCOMM library initialization failed

    Hi Naoshi,

    Can you please check to see if  this directory exists: "/Library/Frameworks/dwf.framework/Resources/digilent/adept/data/firmware" ? It should exist and contain the following files:

    FTDIFW_50_00000011_00000000_010A.dylib FX2FW_01_00000001_00000000_030A.HEX    FX2FW_09_0000000D_00000000_030A.HEX
    FTDIFW_51_00000001_00000000_010A.dylib FX2FW_01_00000010_00000000_030A.HEX    FX2FW_0A_0000001D_00000000_030A.HEX
    FTDIFW_52_00000011_00000000_010B.dylib FX2FW_02_00000001_00000000_030A.HEX    FX2FW_0B_00000000_0000000D_030A.HEX
    FTDIFW_53_00000001_00000000_010A.dylib FX2FW_02_00000004_00000000_030A.HEX    FX2FW_0C_0000000D_00000000_030A.HEX
    FTDIFW_54_00000013_00000000_010B.dylib FX2FW_03_00000011_00000000_030A.HEX    FX2FW_0D_0000000D_00000000_030A.HEX
    FTDIFW_55_00000811_00000000_010A.dylib FX2FW_04_00000005_00000000_030A.HEX    FX2FW_0E_0000000D_00000000_030A.HEX
    FTDIFW_56_00000811_00000000_010A.dylib FX2FW_05_0000000D_00000000_030A.HEX    FX2FW_0F_00000000_0000000D_030A.HEX
    FTDIFW_57_00000001_00000000_010A.dylib FX2FW_06_0000001D_00000000_030A.HEX
    FTDIFW_60_00000000_00000801_010A.dylib FX2FW_08_0000000D_00000000_030A.HEX

    Assuming that directory does exist one additional thing to try doing is executing "export DIGILENT_DATA_DIR=/Library/Frameworks/dwf.framework/Resources/digilent/adept/data" and then re-running the python script. It would be odd if that worked, and if it does then it would suggest that there's a bug in code that searches for the location of the data directory and for some reason or another it doesn't manifest on the Mac's that we have here.

    Thanks,
    Michael

     

  16. @Naoshi

    I was checking this thread regularly for a few days and then got distracted and forgot about it. Anyway, ERC 3090 means that there was an error while initializing DPCOMM. There are a number of reasons why this could happen. Thankfully there is a way to enable an error log. Can you please do the following:

    1. Execute "export ADEPT_RT_LOGDETAIL=1"

    2. Execute "export ADEPT_RT_LOGFILE=~/adept_erc.log"

    3. Re-run your modified version of digi_enum.py and post the output of the log file here.

    Thanks,

    Michael

     

  17. @ChristopherN

    If the script reports that no devices are connected please disconnect your AD2, reconnect it, and then execute the "syslog" command. If the Digilent kernel module is working correctly then you should see something similar to the following:

    Jan 16 16:45:57 michaels-mbp kernel[0] <Notice>: Digilent Stopping
    Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe8: initial probe score = 100000
    Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe: Manufacturer Name = Digilent
    Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent probe8: final probe score = 100001
    Jan 16 16:46:04 michaels-mbp kernel[0] <Notice>: Digilent Starting

    If you can't find anything with "syslog | grep Digilent" or you see "Digilent Stopping" while the device is still connected then something isn't working correclty with the kernel extension.

    Thanks,

    Michael

×
×
  • Create New...