malexander

Technical Forum Moderator
  • Content Count

    137
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Like
    malexander got a reaction from ahmetnc in FPGA and ARM MCU Programming With JTAG-SMT3-NC Module   
    @ahmetnc
    It's not possible to connect the UART channel of the JTAG-SMT3 to the ARM STM32F439 because the JTAG-SMT3 has fixed direction buffers whose direction respect UART signaling and will prevent TMS, TDI, and TDO from being driven correctly.
    If you want to use a single JTAG-SMT3 to communicate with both an Artix 7 FPGA and ARM STM32F439 then you will need to place the devices in series and connect them both to channel A of the JTAG-SMT3. The JTAG protocol was designed to work with multiple devices in series and I'm fairly certain that Vivado can place the ARM device in bypass so that it can communicate with the Artix 7. However, I don't know anything about the ARM programming/debugging tools and cannot comment on whether they properly detect and place unknown/unsupported devices in bypass mode. You'll have to research that on your end.
    Thanks,
    Michael
  2. Like
    malexander got a reaction from Clyde in XUP USB-JTAG Programmer   
    @kursatgol
    What I did to get this working the last time someone asked about using the XUP JTAG Cable in Linux was the following:

    1. Execute "cd /opt/Xilinx/Vivado/2018.1/data/xicom/cable_drivers/lin64/install_script/install_drivers/"
    2. Execute "sudo ./install_drivers"
    3. Execute “source /opt/Xilinx/Vivado/2018.1/settings64.sh”
    4. Execute “vivado” to launch the application.
    5. Open hardware manager and click auto connect.
    Today I tried to replicate the setup in my CentOS 7 Virtual Machine running on my Windows 10 host and Vivado 2018.1 didn't initially find XUP JTAG Cable. In my attempts to debug this I disconnected the cable from the virtual machine and opened Vivado 2018.1 in Windows 10 and proceeded to see if it could be found. Much to my surprise, Vivado could not find it. I then opened the device manager and discovered that in Windows the XUP USB JTAG Cable was showing up as "Xilinx Embedded Platform USB Firmware Loader", which is effectively a bootloader firmware that's used to download the real firmware image. When the driver is properly installed in Windows 10 the OS should initially detect that the device does not have the application firmware programmed, programm it, and then re-enumerate it on the bus. To get Windows to do this I had to do the following:
    1. Right click on “Xilinx Embedded Platform USB Firmware Loader” in the device manager and click “Uninstall”.
    2. When the uninstall dialog popped up I checked the box the box that says “Delete the driver software for this device.” And then click ok.
    3. Once driver uninstall completed I disconnected the programming cable.
    4. Launched a command prompt in administrator mode and navigate to "c:\Xilinx\Vivado\2018.1\data\xicom\cable_drivers\nt64\dlc10_win7"
    5. execute "wdreg -compat -inf %cd%\windrvr6.inf uninstall"
    6. execute "wdreg -compat -inf %cd%\xusbdrvr.inf uninstall"
    7. execute "wdreg -compat -inf %cd%\windrvr6.inf install"
    8. execute "wdreg -compat -inf %cd%\xusbdrvr.inf install"
    9. Reattach the XUP JTAG cable to the USB port.
    After doing this I connected the cable and Windows loaded two drivers for it: a Jungo driver and a “Xilinx USB Cable” driver under the “Programming cables” section. My Windows 10 installation of Vivado 2018.1 is now able to recognize the XUP JTAG cable and find the Zynq 7020 that’s on the Zed board.

    Now when I connect the XUP JTAG CABLE to my Centos7 VM and run Vivado Hardware manager is able to find it (see attached screenshots). Having observed this jogs my memory a bit. I remember that in the old days when you wanted to use the XUP JTAG CABLE, or any Xilinx Platform USB Cable in Linux, it was necessary to manually install the drivers via a script. This script not only installed a set of udev rules, but it also modified those rules so that they would call an fxload application and pass it the pathname for the correct firmware image to download to the cable. I also remember having to manually install fxload.
    A quick look at the udev rules file installed with the 2018.1 drivers:
    cat /etc/udev/rules.d/52-xilinx-pcusb.rules
    # version 0002
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="0007", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="000f", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", MODE="666"
    ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015", MODE="666"
    Here we can see that there is no call to fxload and there are no pathnames specified for the firmware images. I suspect that if you want to get this to work seamlessly then you will need to install impact and the cable drivers that impact includes. However, I cannot gaurantee that will work either. Since you are running a Windows host you could just do the same thing that works for me, which is installing the Windows drivers and letting Windows download the firmware to the XUP JTAG cable before you connect it to your Linux VM.

    Thanks,
    Michael


  3. Like
    malexander got a reaction from Cristian.Fatu in JTAG-HS3 warm, locks up system   
    @Don Koch
    Excessive heat suggests that there may be a damaged component on the board.
    The reset line is active low and is driven by an open drain buffer that has a 100 ohm series resistor between it and pin 14 of the JTAG connector. There is no onboard pull-up on the reset line and it is assumed that the host board will pull the line to the inactive state (high). When you say reset is not being asserted, do you mean it's always high or always low? Does your board have any push-pull buffers that drive the reset line?
    When you say remove power do you mean remove the USB cable or remove VREF from pin 2 of the JTAG header? The onboard buffers will tri-state when they aren't powered. However, the output buffers are powered from the VREF pin of the JTAG header, while the USB controller, which drives the inputs of the output buffers is powered from USB VBUS. If VREF is present but USB power isn't then the buffers will be powered but they should still be held in tri-state because the output enable pin is pulled to ground through a resistor. I don't think you will need to insert extra buffers between TMS, TCK, and TDI.
    Thanks,
    Michael
  4. Like
    malexander got a reaction from Devendra Pundir in JTAG-SMT2-NC "USB Device not Recognized"   
    Hi @Devendra Pundir
    Can you try removing U82 from your PCB and see if that solves the problem? 30pF is a lot of added capacitance for the USB data lines and is likely what's causing the issue.
    Thanks,
    Michael
  5. Like
    malexander got a reaction from jpeyron in Pin mapping for JTAG-SMT2-NC?   
    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.
  6. Like
    malexander got a reaction from manuelreyes60 in JTAG SMT2 coolrunner programming   
    Hi @manuelreyes60 and @ELG_MPT,
    I managed to answer my own question by using the Adept Windows application to program the CPLD and then using iMPACT 14.7 to verify the contents of the CPLD against the JED configuration file. My suspicions proved to be correct and even though the Adept Windows application can program the XC2C32A without crashing, it does so incorrectly and does no pass verification in iMPACT. I'm happy to report that was able to modify the low level programming code and am now able to successfully program the XC2C32A from a Raspberry Pi 3b and have iMPACT pass image verification. I created a new installer for Adept Runtime 2.19.2, which will eventually be posted on the Digilent website. For now you can download it here:
    https://www.dropbox.com/s/n8823fyamak9dgv/digilent.adept.runtime_2.19.2-armhf.deb?dl=0
    At some point we will also publish new installers for Windows and x86/64-bit Linux that resolve this problem on those platforms.
    Thanks,
    Michael
  7. Like
    malexander got a reaction from jsmithsrc in JTAG-SMT2-NC Power sequence   
    Hi jsmithsrc,
     
    The USB controller has an option that can be enabled to prevent it from forcing current down the USB lines when VBUS isn't present. However, that option is not enabled on the SMT2 or SMT2-NC because it requires a resistor divider to connect VBUS to one of the IO pins. We are unable to enable this option because the IO pin required was utilized for the purposes of implementing 1149.7 (2-wire) support, due to the lack of any other suitable pins being available.
    Originally the SMT2 and SMT2-NC were designed with the idea that VDD would power on prior to VREF or that they would ramp simultaneously. However, this sequence is not strictly required, as powering VREF prior to VDD does not backpower any of the components powered by VDD, nor does it violate any specifications of the components used to implement the design. I have confirmed that powering VREF prior to VDD does not cause any problems and that the SMT2/SMT2-NC is able to successfully program the JTAG device once VDD is powered.
    Thanks,
    Michael
  8. Like
    malexander reacted to albert in Cannot detect Analog Discovery in OSX   
    I think you are right and that the changes are a good idea. I guess you thought of this already but alternatively, perhaps you can detect what version of the library you found and keep looking if it is too old?
    I did not try any of my other software that might be using the other driver (I guess it could be Arduino/Energia) but I guess something will probably break if I keep it renamed
    My /usr/local/lib/ has both 0.1.7 and 1.2.2 and uses a symlink that points to 0.1.7. Since you say 1.2.2 should work I will do some experimenting with changing the symlink to point to that version instead in case I find issues with some other software. (Before saw your latest message I was going to ask for a strategy for running Waveforms along with other software that uses that driver..)
     
    Finally, thanks a lot for guiding me Michael! You made it really difficult for me to be mad at Digilent for having to spend two weeks just to get this up and running
  9. Like
    malexander got a reaction from albert in Cannot detect Analog Discovery in OSX   
    HI Albert,
    Sorry it didn't occur to me earlier that you might have another copy of the library already installed. The log file won't be generated as long as the library can be loaded. As it stands now, we make multiple attempts to open the library. The first call to dlopen doesn't specify a path, so if libftd2xx.dylib exists in /usr/lib or /usr/local/lib then it will get loaded from that directory. If it doesn't exist, then the first call to dlopen will fail, after which, we make additional attempts to open the library from locations that are relative to the running executable.
    I suspect that your problem may have been related to version 0.1.7 of the d2xx library being opened. We've only performed testing with version 1.2.2, so I don't know whether or not it will work with 0.1.7, but I do know that early versions of the Linux library had lots of bugs and I would be surprised if earlier versions of the OSX library also suffered from similar bugs.
    Based on your feedback I think we will change the way that we perform the dlopen calls on MAC OSX so that we can guarantee we get the version of the library that we want, and not some other version that may be installed in a system wide directory.
    Thanks,
    Michael