malexander

Technical Forum Moderator
  • Content count

    35
  • 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

660 profile views
  1. Hi Tony, That information should be in https://reference.digilentinc.com/_media/cmod_s6:cmods6_rm.pdf. However, it's not there. I pulled it from the Spartan 6 datasheet. I will ask the appropriate people to update the documentation to include voltage specifications. Thanks, Michael
  2. Hi Tony, According to the datasheet the forward drop for the input diode (B240A-13-F) is 0.5V at 2 amps and figure 1 suggests that the drop will be 0.35V or less at 500mA or less. If you are applying 5V to the VU pin and seeing 4.5V at the input of the regulator (IC1) then that suggests that the regulator is either fried or that there is a short at the output of the regulator. The regulator claims to have short-circuit protection but does not specify which method it uses. I assume that when it detects a short it will blank the output for some amount of time. Since there is an LC filter at the output of the regulator a multi meter will measure a non-zero average voltage that's significantly lower than the target output voltage. Do you have an oscilloscope that you could use to probe the VCC3V3 rail (regulator output)? If so, I suspect you will see the voltage spikes up and then quickly drops off to something close to zero and that this process repeats at some periodic rate. The Spartan 6 FPGA pins are rated for a maximum input voltage of 4.1 volts and the recommended operating range is -0.5V to 4.0V. Are you students applying voltages above this to the PIO pins? If so, then it's likely that repeated application of higher voltages has caused the pins to short internally, and that's why the power LED doesn't come on. The board wasn't designed to be 5 volt tolerant and applying voltages above 3.3V to the pins will result in random failures. Once this happens there is no way to repair the board without replacing the FPGA, which is not cost effective. Thanks, Michael
  3. Hmm which version of OSX are you running?
  4. Hi Albert, I think they should both show up in the system profiler regardless of which driver is attached. What I do see from your post is that the second device doesn't have "Digilent" as the Manufacturer string so our driver should return a probe score of 0, which would give another driver the opportunity to match. The following is from Apple's Developer website: Driver Matching When a nub detects a device, the I/O Kit finds and loads a driver for the nub in three distinct phases, using a subtractive process. In each phase, drivers that are not considered to be likely candidates for a match are subtracted from the total pool of possible candidates until a successful candidate is found. The matching process proceeds as follows: In the class matching step, the I/O Kit narrows the list of potential drivers by eliminating any drivers of the wrong class for the provider service (that is, the nub). For example, all driver objects that descend from a SCSI class can be ruled out when the search is for a USB driver. In the passive matching step, the driver’s personality (specified in a driver’s XML information property list) is examined for properties specific to the provider’s family. For example, the personality might specify a particular vendor name. In the active matching step, the driver’s probe function is called with reference to the nub it is being matched against. This function allows the driver to communicate with the device and verify that it can in fact drive it. The driver returns a probe score that reflects its ability to drive the device. See Device Probing for more information. During active matching, the I/O Kit loads and probes all candidate drivers, then sorts them in order of highest to lowest probe score. The I/O Kit then chooses the remaining driver with the highest probe score and starts it. If the driver successfully starts, it is added to the I/O Registry and any remaining driver candidates are discarded. If it does not start successfully, the driver with the next highest probe score is started, and so on. If more than one driver is in the pool of possible candidates, the more generic driver typically loses out to the more specific driver if both claim to be able to drive the device. The probe function takes as arguments the driver’s provider and a pointer to a probe score. The probe score is a signed 32-bit integer initialized to a value specified in the driver’s personality (or to zero if not explicitly initialized). The driver with the highest initial probe score is given the first chance to start operating the device. The purpose of the probe function is to offer drivers an opportunity to check the hardware and to modify their default probe scores as assigned in their personalities. A driver can check device-specific registers or attempt certain operations, adjusting its probe score up or down based on how well suited it is for the device it is examining. Whatever it finds, each driver must leave the hardware in the same state it was in when probe was invoked so the next driver can probe the hardware in its original state. A driver, in its probe function, returns a driver object (IOService *) if the probe was successful and returns zero otherwise. The returned object is usually the driver itself, but the driver can return another driver that is more suited to the provider. The probe score is an in-out parameter, which probe can modify based on what it discovers about the device. The probe function takes as arguments the driver’s provider and a pointer to a probe score. The probe score is a signed 32-bit integer initialized to a value specified in the driver’s personality (or to zero if not explicitly initialized). The driver with the highest initial probe score is given the first chance to start operating the device. The purpose of the probe function is to offer drivers an opportunity to check the hardware and to modify their default probe scores as assigned in their personalities. A driver can check device-specific registers or attempt certain operations, adjusting its probe score up or down based on how well suited it is for the device it is examining. Whatever it finds, each driver must leave the hardware in the same state it was in when probe was invoked so the next driver can probe the hardware in its original state. Driver Loading A driver, in its probe function, returns a driver object (IOService *) if the probe was successful and returns zero otherwise. The returned object is usually the driver itself, but the driver can return another driver that is more suited to the provider. The probe score is an in-out parameter, which probe can modify based on what it discovers about the device. Based on the above description and a review of the source code for our driver I believe we are doing the correct thing. Can you please try disconnecting all FTDI devices, then connecting your USB serial device and executing "syslog | grep Digilent" in the terminal and then paste the results here? Thanks, Michael
  5. 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
  6. Response sent via email.
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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.
  13. 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
  14. 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
  15. 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