malexander

Technical Forum Moderator
  • Content count

    31
  • Joined

  • Last visited

  • Days Won

    1

malexander last won the day on February 11 2016

malexander had the most liked content!

About malexander

  • Rank
    Advanced User

Profile Information

  • Gender
    Female

Recent Profile Visitors

562 profile views
  1. Hi Albert, This shouldn't happen unless your serial device is reporting information that causes the driver to think it's a Digilent device. When our driver is loaded and you plug-in a device our probe function gets called. There we read the manufacturing string from the string descriptor and check to see if it's "Digilent". If it's not, then we return a probe score of 0, which should cause OSX to continue looking for a matching driver. If the manufacturing string is "Digilent' then we perform a Control Transfer to read a field of the EEPROM, which contains bits that specify which interface(s) should be used as a virtual com port. Depending on the value of the bitfield we either return a high probe score so that our driver remians loaded, or we return 0. If the bitfield indicates that the interface is to be used as a VCP we return 0, which again, should cause OSX to continue looking for a suitable driver. Keeping the above in mind, I have no idea why our driver would remain loaded for your device if it doesn't specify "Digilent" as the manufacturer and contain the appropriate bitfield setting in the EEPROM. Thanks, Michael
  2. Response sent via email.
  3. Hi Dave, You can specify the serial number instead of the username string, which will allow you to open a specific device. This is done by placing a "SN:" in front of the serial number shown by "djtgcfg enum". See below for an example. C:\>djtgcfg enum Found 1 device(s) Device: ArtyS7 Product Name: Digilent Arty S7 - 50 User Name: ArtyS7 Serial Number: 210352A58ACD C:\>djtgcfg init -d SN:210352A58ACD Initializing scan chain... Found Device ID: 0362f093 Found 1 device(s): Device 0: XC7S50 Thanks, Michael
  4. Is this a two wire or 4-wire JTAG interface? My memory for the the 2-wire JTAG interface is a bit fuzzy as I haven't really worked with that since 2012. For now I will assume it's a 4-wire JTAG interface. If I recall correctly the Synopsys ARC cores properly implement the JTAG protocol and will automatically load the IDCODE instruction into the INSTRUCTION register whenever you pass through Test Logic Reset (TLR). Assuming that's the case, you can do the following to load the IDCODE instruction, get into Shift-DR, and read the first 32-bit IDCODE form the chain: HIF hif; BYTE rgbSetup[] = {0xaa, 0x22, 0x00}; BYTE rgbTdo[4]; DWORD jid; DmgrOpen(&hif, szDevName); // szDevName likely = "JtagHs2" DjtgEnable(hif); DjtgPutTmsTdiBits(hif, rgbSetup, NULL, 9, fFalse); // pass through test logic reset and go to SHIFT-DR DjtgGetTdoBits(hif, fFalse, fFalse, rgbTdo, 32, fFalse); // shift out the first 32-bit IDcode from the scan chain jid = (rgbTdo[3]<<24) + (rgbTdo[2]<<16) + (rgbTdo[1]<<8) + rgbTdo[0]; // note: you may want to enter a loop where you continue to shift 32-bits of data while (( 0 != jid ) && ( 0xFFFFFFFF != jid )) I don't remember all of the details but I know there are several extra steps for performing the same operation in 2-wire JTAG mode. Thanks, Michael
  5. Hi Carson, In IMPACT you can specify a different clock frequency through the cable setup dialog. Open the cable setup dialog and do the following: 1. Choose "Select Speed" for the "TCK Speed/Baud Rate:" option. 2. Click "OK". The Dialog should now refresh. 3. Under "TCK Speed/Baud Rate:" choose the clock frequency that you desire. I recommend trying 10 MHz, as it should work for my chips and board designs. 4. Click "OK". Now the cable should be open and ready to use. Thanks, Michael
  6. Hi Quique, Remote device configuration is not related to indirect programming of SPI flash. The Xilinx tools should be able to program the SPI flash that's attached to the FPGA. Thanks, Michael
  7. Hi Mike, Can you describe the topology of the scan chain and tell me all the devices that are supposed to be in the scan chain? Thanks, Michael
  8. The fact that it doesn't work makes me think there is something wrong with Darkkey's Vivdao installation. I suggested installing the Digilent software for troubleshooting purposes.
  9. Hi Darkkey, Have you downloaded and installed the Adept Runtime and Adept Utilities packages? If not please download and install the appropriate (32-bit or 64-bit) RPM packages from the following website: https://reference.digilentinc.com/reference/software/adept/start?redirect=1#software_downloads Once you've installed both packages you should be able to execute "dadutil enum" in the terminal and see the Arty listed as one of the connected devices. Assuming that works, the next thing to try is "djtgcfg init -d Arty" which will enable the JTAG interface, read the ID code from the devices in the scan chain, and then display a list of devices that are in the chain. Assuming all of this works, try running hardware server again, as it should now be working. Thanks, Michael
  10. Can you run the Adept GUI application, which came with the Adept System, and then see if it reports 4 devices with the correct ID codes when you click initial scan chain? It should show 4 devices but it may not be able to identify them, as it is only able to recognize devices that are on Digilent system boards. However, the ID codes listed in the status Window should in theory be correct. It would be great to compare the ID codes shown against the ID codes provided by iMPACT. Thanks, Michael
  11. Hi there,

    Here's the list of USB devices on my Mac Pro, as requested :) I had to compress it to get it down to a size the forum would accept, so you'll have to 'bzip2 -d' it to read it.

     

    Cheers

     Simon

    usbdevices.txt.bz2

    1. malexander

      malexander

      After examining the file you sent me it appears that you have 3 FTDI based devices attached to your MAC. Two of them are Digilent devices and the third is using FT230X for the name in it's string descriptor. Both of the Digilent devices show that the Digilent KEXT is attached, while the other shows Apple USB serial. I thought that perhaps the Digilent driver wasn't attaching on your system but the log shows otherwise.

      FTDI has their own kext that's supposed to prevent Apple's driver from attaching. It's called D2XXHelper. The downside to their kext is that it will prevent the Apple USB serial driver from attaching to all FTDI devices, not just the Digilent ones. So using D2XXHelper isn't a long term solution even if it solves the problem on your system. However, if you could try it out and let me know whether or not it addresses your issue I would really appreciate it.

      http://www.ftdichip.com/Drivers/D2XX/MacOSX/D2xxHelper_v2.0.0.pkg

      I would detach all FTDI devices, run the pkg file, reboot, and then try attaching the Digilent devices again and run the digi_enum.py to see if all 4 methods of enumeration show the Digilent devices.

      Do you know which piece of hardware the FT230X is associated with? The FTDI D2XX library will only allow a single application to open a device interface at any given time. If you are running any other software that opens FTDI devices with D2XX make sure that it's not opening the Digilent ones automatically otherwise that could lead to our software failing to open the device.

      Also, to remove D2XX helper after you've tried this test you have to delete the associated kext from your /Library/Extensions directory and reboot.

      Thanks,
      Michael

       

    2. SpacedCowboy

      SpacedCowboy

      Thanks - I'll try this on Monday. I hadn't actually logged into the site, so I didn't see your reply until just now :(

       

      Cheers

       Simon

  12. 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. 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. 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. 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