Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


malexander last won the day on May 23

malexander had the most liked content!

About malexander

  • Rank
    Frequent Visitor

Profile Information

  • Gender

Recent Profile Visitors

2100 profile views
  1. One thing I forgot: if you install ISE 14.7 and have it install the cable drivers then there shouldn't be any need to manually install the Digilent plugin.
  2. @anshumantech The Adept GUI application was developed to provide a lightweight application for programming the FPGA and flash memories on Digilent system boards. It was not meant to be a general purpose programmer for all CPLD/FPGA/Flash combinations, and as a result we only tested the device combinations that were on Digilent system boards. We recommend using iMPACT 14.x with out plug-in for general purpose programming of older CPLD and Flash devices. For newer devices we recommending using Vivado. I don't think Vivado supports the XCF02S but I know it's supported in iMPACT. Have you tried using the HS1 and iMPACT with the Digilent Plugin to program the XCF02S on your board? You don't need a license to use iMPACT (part of ISE) for programming and you can download 14.7 here: Thanks, Michael
  3. @adambro What value are you passing for the fOverlap parameter of DspiPut? Are you running the same Linux distribution on both Linux PC's and is the architecture the same? What is the architecture: x86, x64, or arm? Thanks, Michael
  4. @DJOConnor XC3S400 is an old device and my guess is that we most likely designed one or more part from the same family onto a Digilent board, tested it, and assumed it would work for all parts in the family and didn't explicitly test programming an XC3S400. We never really intended for djtgcfg to be used as a general purpose FPGA configuration tool... we only intended for it to be used to configure the devices that were on Digilent System boards. Now that ISE and Vivado both include integrated support for our programmers there is no need to add support for new devices, nor is there any motivation to go back and test any of the legacy devices that aren't utilized on active Digilent system boards. If we do another release of djtgcfg then we will likely remove all legacy devices from jtscdvclist.txt so that those devices end up being unrecognized by djtgcfg and then have jtsc spit out a message that says to use iMPACT or Vivado. In the end the solution is to use iMPACT or Vivado, both of which have the programming algorithms built in and tested by Xilinx. Thanks, Michael
  5. If you want to probe the OEx signals as they appear coming out of the USB controller then R25, R24, and R5 are the easiest locations to access. If you want to probe the GPIO signals as they appear coming out of the chip then R29, R28, and R34 are the easiest locations. Those are in order of 0, 1, 2. Just to confirm, you are asking about the the JTAG-SMT2 or JTAG-SMT2-NC and are trying to use the GPIO's in OpenOCD?
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. @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
  11. 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.
  12. @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
  13. @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
  14. @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
  15. @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