malexander

Technical Forum Moderator
  • Content count

    41
  • Joined

  • Last visited

  • Days Won

    1

malexander last won the day on February 11 2016

malexander had the most liked content!

About malexander

  • Rank
    Frequent Visitor

Profile Information

  • Gender
    Female

Recent Profile Visitors

757 profile views
  1. @D@n So far I've been unable to reproduce the crash on my end. I opened hardware manager in Vivado and connected to the system monitor and even left it running. When I launch WaveForms without the DD plugged in it reports that no devices were detected but it doesn't crash. If I connect a Digital Discovery and launch WaveForms then it finds and properly configures it (see image). Please keep in mind that I installed the latest version of the adept Runtime and WaveForms using dpkg, and did not do any manual installation from the tar files. Can you execute "ldconfig -p | grep libftd2xx" at the terminal and paste the output here? Thanks, Michael
  2. @D@n Can you tell me which version of Vivado you had the Nexys Video open in when Waveforms crashed? Also, does Waveforms crash if the NexysVideo is conencted and powered on but not open in Vivado? I setup a virtual machine running the same version of Ubuntu and am not experiencing any crashes with the Nexys Video attached. However, I have not tried it with Vivado running but will after you tell me which version you were using. Thanks, Michael
  3. Hi Vihang, I attached the schematic for the 14-pin adapter as well as a screenshot of the typical system board mating pin-out. I think the screenshot will answer most, if not all of your questions. Please note that the PS_SRST_B signal will only be present on Zynq boards. Also note that the JTAG-HS2 with 14-PA cannot drive PS_SRST_B and that if you need to drive that signal you will need a JTAG-HS3. Thanks, Michael JTAG 14PA.pdf
  4. Hi Zygot, Having looked at the BSD files in ISE I do think it's possible that it's a typo. However, since I didn't add these devices to the list and since they've been there for many years I'm reluctant to modify jtscdvclist.txt that we publish in the installer. If you want to try changing it in your local copy there are two linesof the file that you will need to modify: 1. change "XC3SD$A 06800000h 0FE00000h" to "XC3SD$A 03800000h 0FE00000h" 2. change "1800 06840093h 0FFFFFFFh" to "1800 03840093h 0FFFFFFFh" Hopefully this will at least make it recognize the part. Thanks, Michael
  5. HI zygot, Each FPGA series may have a different JTAG configuration algorithm and a different set of instruction codes. The Adept Utility (djtgcfg) and Adept Application were designed to configure CPLDs and FPGAs that are on Digilent system boards. It may or may not support parts that aren't on Digilent boards. That being said I do see the XC3SD1800A in the configuration file with an ID code of 0x06840093. Does the IDCODE reported by Adept match that one? On Windows the config file is located in "C:\Program Files (x86)\Common Files\Digilent\Data\jtscdvclist.txt". You may be able to add the IDCODE to the list if it's different from the one that's already there. Thanks, Michael
  6. Hi Stefan, That's correct you can't use the on-board JTAG programmer/debugger while using the synchronous DPTI interface. However, it should be possible to connect an external JTAG cable, such as the JTAG-HS2, to header J17 and use that to access the scan chain while simultaneously using DPTI. I haven't tried this myself but the on-board JTAG interface has tri-state buffers and is held in tri-state when not enabled so it should work. Thanks, Michael
  7. 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
  8. 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
  9. Hmm which version of OSX are you running?
  10. 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
  11. 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
  12. Response sent via email.
  13. 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
  14. 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
  15. 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