Technical Forum Moderator
  • Content count

  • Joined

  • Last visited

  • Days Won


malexander last won the day on February 11 2016

malexander had the most liked content!

About malexander

  • Rank
    Frequent Visitor

Profile Information

  • Gender

Recent Profile Visitors

1314 profile views
  1. malexander

    2 wire JTAG

    Hi @Jim H The TMSC pin is only bi-directional when using the MScan, OScan0, OScan1, OScan2, OScan4, OScan5, or OScan6 scan formats. Data is only read from the TMSC pin during the bit times denoted "TDO" in those scan formats. The DjtgSetScanFormat function must be called to set the scan format. Further, if you are using a scan format (OScan2 - OScan 7) that requires a different packet format during shift-XR vs non-shift-XR states then you must call DjtgSetScanFormat and tell it each time you've navigated into or out of the shift-xr state of the TAP controller so that it uses the correct packet formatting. Based on your description of the ARM SWD protocol it doesn't sound like it's going to be possible to implement it using a JTAG-HS2... at least not with any of our existing software API's, and certainly not with the DJTG API. I think the hardware itself may be capable of implementing the protocol, but without digging deeper into ARM SWD protocol I'm not sure. Thanks, Michael
  2. @OuYang@attila We don't have a package for ARM64 and as far as I can tell Raspbian doesn't have an official 64-bit build. I don't think we will support this until there is mainstream support for it on the Raspberry Pi. Thanks, Michael
  3. @davorin @attila I managed to track this down. It's a bug in version 1.4.4 of the FTDI driver (D2XX library). If I attach a blank FT2232H device (equivalent of what's on the HiFive-1 board) and that device shows up in the device list before the Digital Discovery then the FT_OpenEx function of the D2XX library fails with a device not found error returned when we attempt to open the Digital Discovery. If I take the blank FT2232H device and use FT_Prog to set the serial number field to "1" (e.g. EEPROM no longer blank and serial number string no longer randomly generated by the device) then FT_OpenEx will successfully open a handle to the Digital Discovery, regardless of the order of the device's in the device list. If I erase the FT2232H and put it back in the blank state I can get FT_OpenEx to fail again. After doing so, I removed version 1.4.4 of the FTDI driver and installed version 1.2.2 (the previous known working version). With version 1.2.2 this issue doesn't exist. Therefore this is a new bug that was introduced by FTDI when they released driver version 1.4.4. Unfortunately, there is no way for me to work around the bug. All I can do is reach out to FTDI and ask them to fix it. In the meantime my recommendation is that customers who experience this problem rollback to driver 1.2.2. Thanks, Michael
  4. @attila Sorry I got busy with other projects and somehow forgot about this. I was able to replicate this behavior on my MAC by attaching the Digital Discovery and then a board with a blank FT2232H. If I attach the the board with the blank FT2232H first and then attach the Digital Discovery it works fine. I spent some time stepping through the debugger and during the enumeration process it gets to the point where it wants to open a handle to the device by serial number and that call fails with a device not found error code. I'm going to have to dig into this more tomorrow, but I suspect that it's due to a bug in the FTDI driver.
  5. malexander

    Digital Discovery and Platform Cable

    @attila I couldn't get the Platform USB Cable II that I found in our office to work at all (not in impact or Vivado on Windows 7 or Windows 10) regardless of what devices I have plugged into my PC. I think it's physically damaged in some way because iMPACT keeps saying it can't detect VREF on pin 2 but the XUP USB Cable I have works fine plugged into the same target. The XUP USB cable is pretty much equivalent though so it should work for testing scenarios like these. I was able to replicate the behavior described by @wlevans one time, and only one time, by connecting the XUP USB cable and Digital discovery to my PC and then running Auto connect in Hardware Manager 2016.4. Hardware manager incorrectly tried to open the Digital Discovery, and for whatever reason, made no attempts to open the Xilinx cable. After I opened the Digital Discovery in Waveforms, which locks the USB interface, Vivado stopped trying to open it and would then correctly open the XUP cable. I tried closing all software, disconnecting everything, and reconnecting it to see if I could repeat this behavior but now Vivado does not see the Digital Discovery even when it's not open in Waveforms and it manages to open the XUP cable. The initial behavior I observed leads me to believe that Xilinx is giving preference to Digilent JTAG cables over their own cables, that they are incorrectly opening the Digital Discovery (they shouldn't because the firmware ID and PDID are wrong), and that they give up after the first failure to initialize a scan chain. This is definitely a bug in Vivado and at the moment there are two workarounds I can recommend: 1. Connect only the platform USB cable initially, start hardware server, and connected to the MicroZed. Then connect the Digital discovery to the PC. 2. Connect both devices but open WaveForms and have it connect to the Digital Discovery prior to launching hardware server. This will lock the USB interface and cause Vivado to skip over it. If I can figure out how to reproduce this behavior more consistently then it should be possible to have it fixed in future versions of Vivado... probably 2018.3 or later.
  6. malexander

    Nexys Video with Xilinx XM105 FMC Debug board?

    Hi Ken, The FMC specification requires an installed card to be included in the JTAG scan chain. The Nexys Video has onboard circuitry that detects the presence of the card. When no card is present the FPGA_TDO net is connected to the FMC_TDO net, which is connected to the on-board JTAG programmer. When a card is present FPGA_TDO is disconnected from FMC_TDO and connected to FMC_TDI. This places any JTAG TAP controller that's present on the mezzanine card in the scan chain with the FPGA. I looked at the XM105 schematic and I don't see any active JTAG devices. I also don't see any connections between FMC_TDI and FMC_TDO on the XM105. I believe that if you install a shorting block (jumper) between FMC_TDI and FMC_TDO on header J5 of the XM105 then your problem will be resolved. I strongly discourage hotplugging the XM105. Thanks, Michael
  7. @attila I haven't seen any issues when having multiple FTDI devices attached, but all of the testing I've done involved having multiple Digilent products connected. It would be good to know which devices there appears to be a conflict with so that we can try and replicate it locally.
  8. malexander

    Artix-A7 non-GUI development

    Off the top of my head I'm not sure why it's failing. Hopefully one of the guys from the applications team or support team will chime in.
  9. malexander

    Artix-A7 non-GUI development

    No you don't need to launch hardware server - the first line of the TCL script does that. You can use djtgcfg from the Adept Utilities package to program the FPGA. If I remember correctly the syntax is something like "djtgcfg prog -d <device_username> -i 0 -f config.bit". You can use "djtgconfig enum" to figure out the username string. I think the default for that board is CmodA7 so executing "djtgcfg prog -d <device_username> -i 0 -f config.bit" may do the trick, provided that config.bit is the name of the bitfile you want to load and that your current working directory contains that file.
  10. malexander

    Artix-A7 non-GUI development

    Vivado has integrated support for the programming circuit on the CmodA7 so you can program both the FPGA and the flash using Hardware Manager. If you want to do this from the command line then the easiest way is with TCL scripts. I've attached the TCL scripts that we use to program the user demo into the flash during the manufacturing test. On a Windows machine you would use these by opening a command prompt, changing to the directory that contains both prof_flash_15t.tcl (or the other one in the case of the 35T) and CmodA7_User_Demo-15T.bin, and then executing "vivado -mode batch -source prog_flash_15t.tcl". The process should be very similar in Linux. If you want to program a bin file with a different name into the flash then you will need to modify the TCL script. prog_flash_15t.tcl prog_flash_35t.tcl
  11. malexander

    Can't install windrvr6

    Hi Ryan, You can try running the Adept System inatller from the command line and passing in an argument that tells it the path to a log file. In order for this to work you must first create the file, as it will not create the file if it doesn't exist. For example, if you have an e: drive you could create an empty text document named "adept_install_log.txt" and then run the following command, which assumes the installer executable is also located at the root of the e: drive: "digilent.adept.system_v2.16.4.exe /LogFile="E:\adept_install_log.txt"" Be sure to use quotes around the filename that is specified for the log file. Hopefully the log will tell us something more than we already know. Thanks, Michael
  12. malexander

    Can't install windrvr6

    Hi Ryan, Unfortunately that error code doesn't tell us anything other than that there were 3 driver packages present that couldn't be installed. It seems odd that neither our driver package nor Xilinx's WINDRV6 will install on your system. What operating system are you running? Is your user account a remember of the Administrators group? I feel like there was one person that had an issue like this before but I don't recall whether or not we found a solution. Maybe @attila remembers. Thanks, Michael
  13. malexander

    Can't install windrvr6

    Hi Ryan, Try downloading and installing the latest version of the Adept System for Windows and installing it: That should give you the files that are missing. Once installed try using the auto connect option in Vivado's Hardware server and see if it will connect. You shouldn't need WINDRVR6 unless you have a Xilinx Platform USB cable or the equivalent on-board circuit. If for some reason you do need to use the Platform USB cable you will need to reach out to Xilinx's technical support team to see if they can help you install WINDRVR6. Thanks, Michael
  14. malexander

    Can't install windrvr6

    Hi Ryan, WINDRV6 isn't part of our drivers package, it's actually the driver for Xilinx's Platform USB cables. As I recall the ZC706 uses a Digilent JTAG-SMT1 or JTAG-SMT2 module, and not Xilinx's Platform USB. However, I think the Vivado installer groups all driver installs together and runs the sub installers sequentially and that it attempts to install WINDRV6 before installing the remaining drivers and support files. I'm not sure if failure to install the first set of drivers results in the installer aborting or if it continues on to the next set. If you navigate to your Vivado folder do you see ".\lib\win64.o\FTD2XX.dll" and\or ".\lib\win32.o\FTD2XX.dll"? Also, if you go to control pannel, Programs and Features, do you see "Digilent Software" as an entry? Thanks, Michael
  15. @kpax It sounds like the Arty is working correctly on your desktop so we can rule out any EEPROM image issues, as well as any issues with the actual hardware. SInce this appears to be an issue with the FTDI driver not attaching correctly to the device re-installing Vivado over and over isn't going to help resolve the issue. I see you already tried updating the driver and that doesn't appear to have worked because Windows thinks it's the same driver that's already installed. Have you tried doing the following: 1. In the device manager under USB devices right click on “USB Serial Converter A” and click “Uninstall”. Do the same for “USB Serial Converter B”. 2. Disconnect the Arty from the PC 3. Reboot, reattach the board, and see if the driver gets properly installed/loaded If that doesn't work then another option is to disconnect the ARty board from your PC and then use FTDI's CDM Removable tool to uninstall the driver. They don't appear to have updated the tool in quite some time but it's still available for download from their website: If you want to try this disconnect the Arty board, run the application as an Administrator and put in “0403” for Vendor ID, “6010” for product ID and then click “Add”. After that click “Remove Devices”. Reboot and re-attach Arty board to PC with USB cable. This does a more thorough removable than just uninstalling the driver from the Device Manager, so I suspect you may get better results when reinstalling the driver. If none of the above works then perhaps try a different USB cable and/or different USB port. Thanks, Michael