Digilent JTAG-HS3 not discovered

Arvid · September 12, 2018

Hello,

My computer is a Ubuntu 18.01 machine. I have a Digilent JTAG-HS3 and 3rd-part board with a FTDI FT2232 chip connected to my computer. The FT2232 chip is just a simple FTDI device, it doesn't have any EEPROM connected to it.

If the devices are are connected to my PC in the wrong order, the Digilent JTAG-HS3 will not be discovered by the Adepts utilities. If I then swap the physical USB ports for the cables, the Digilent JTAG-HS3 can be found.

Is this a bug in the Adept Runtime for Linux?

$ djtgcfg enum
No devices found

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 066: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
Bus 001 Device 067: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 007: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 005: ID 0bc2:2300 Seagate RSS LLC Expansion Portable
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)
Bus 001 Device 002: ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 5: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 6: Dev 7, If 0, Class=Hub, Driver=hub/2p, 480M
    |__ Port 8: Dev 67, If 0, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 9: Dev 66, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
    |__ Port 9: Dev 66, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M

$ djtgcfg enum
Found 1 device(s)

Device: JtagHs3
    Product Name:   Digilent JTAG-HS3
    User Name:      JtagHs3
    Serial Number:  210299A06B5F

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 065: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 064: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
Bus 001 Device 007: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 005: ID 0bc2:2300 Seagate RSS LLC Expansion Portable
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)
Bus 001 Device 002: ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 5: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 6: Dev 7, If 0, Class=Hub, Driver=hub/2p, 480M
    |__ Port 8: Dev 64, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
    |__ Port 8: Dev 64, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
    |__ Port 9: Dev 65, If 0, Class=Vendor Specific Class, Driver=, 480M

Arvid · September 28, 2018

Hello,

Yes, I do use FT_Open(), because most FTDI devices I work with lack the EEPROM and therefore doesn't have any serial or meaningful description.

I have installed the updated runtime.

$ dpkg -s digilent.adept.runtime | grep Version
Version: 2.19.1

Here is the log with the non-working setup:

$ ADEPT_RT_LOGDETAIL=5 djtgcfg enum && cat DebugErc.log
No devices found
System Time     Process     Thread        ERC     ERC String                  Message
517481022       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - cftdevPrev = 0, cfdevCur = 3
517481029       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - CreateDeviceInfoList found 3 devices
517481029       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 0
517481029       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 1
517481029       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - interface list contains 0 devices
517481034       11136       248846144     0       ercNoErc                    FEnumAndUpdateCache - OpenEx failed on serial 210299A06B5F, erc = 2

And if I swap USB ports:

$ ADEPT_RT_LOGDETAIL=5 djtgcfg enum && cat DebugErc.log
Found 1 device(s)

Device: JtagHs3
    Product Name:   Digilent JTAG-HS3
    User Name:      JtagHs3
    Serial Number:  210299A06B5F
System Time     Process     Thread        ERC     ERC String                  Message
517319541       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - cftdevPrev = 0, cfdevCur = 3
517319548       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - CreateDeviceInfoList found 3 devices
517319548       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 1
517319548       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 2
517319548       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - interface list contains 0 devices
517319608       11024       3140945728    0       ercNoErc                    FEnumAndUpdateCache - added interface 210299A06B5F to the list

Arvid · January 31, 2019

Good to hear! Please let me know if you want me to test anything!

Thank you!
Arvid

malexander · January 19, 2019

@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

Arvid · December 21, 2018

Thank you!

malexander · December 17, 2018

@Arvid

I heard back from FTDI over the weekend. They were able to reproduce the issue on their end and are investigating a solution. We will post a new Adept Runtime Installer for Linux once FTDI provides a new driver. After this week I'm out of the office until January 7th so it's not likely that we will publish a new installer until next year even if FTDI provides the driver before then.

Thanks,
Michael

jpeyron · December 13, 2018

Hi @Arvid,

I reached out to Michael for an update. Michael said that he had not heard from FTDI but that he will ping them again and see if there are any updates.

thank you,

Jon

Arvid · December 13, 2018

Hi Michael

Any news?

Thanks,
Arvid

malexander · November 2, 2018

Hi @Arvid

Their US support, which is who I have to deal with, said they would forward the information I sent them to their developers (UK based) and get back to me. I will ping them again and see if there are any updates.

Thanks,
Michael

Arvid · November 1, 2018

Hello,

Have you got any updates from the FTDI support?

malexander · September 28, 2018

Hi @Arvid

Thanks for running that test. The behavior appears to be the same on your system and clearly your non-Digilent FTDI device is one that your user has R/W permissions for because ListDevices and CreateDeviceInfoList are returning the same count. I'm not sure why the behavior is different when they are plugged into different ports, but that is useful information that I can pass along to FTDI. I sent them a detailed description of the problem and am now awaiting a response. They've been pretty slow to respond in the past so it may be a while before we here anything.

Thanks,
Michael

malexander · September 27, 2018

Hi @Arvid

I'm curious, did you call the standard FT_Open function or was it FT_OpenEx? The reason I ask is because we use the FT_OpenEx function and we open by serial number, which is required for several reasons that I won't go into detail about.

This afternoon I modified the Adept Runtime such that it will log a bunch of information during the device discovery process when the "ADEPT_RT_LOGDETAIL" environment variable is set to "5" and the "ADEPT_RT_LOGFILE" environment variable specifies a valid filename. During the process of testing the newly added logging capabilities I discovered a couple of oddities. With an FT_4232H Adept Device and a blank FT_2232H I found that our internal ListDevices function, which I wrote using libusb, returns a device count of 6 while our internal CreateDeviceInfoList function returns a device count of 4. I found that the discrepancy is the result of something I forgot about: certain libusb functions cannot be used on a device for which the current user does not have read/write permission. This makes sense because my default user does not have read write access for the FT_2232H (I didn't add myself to the dialout group) and it only has access to the FT_4232H, which our UDEV rules caught and set the permissions to 666 following usb enumeration. In this scenario "dadutil enum" correctly found and listed the single Digilent device.

I wanted to see what gets logged when I run "dadutil enum" with read/write permissions for the blank FT_2232H so I used chmod to manually set the permissions of the blank FT_2232H to "666". I then re-ran "dadutil enum" and much to my surprise 0 Digilent devices were found. A quick peak at the log file allowed me to immediately identify the problem:

System Time     Process     Thread        ERC     ERC String                  Message
490087700       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - cftdevPrev = 0, cfdevCur = 6
490087707       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - CreateDeviceInfoList found 6 devices
490087707       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 0
490087707       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - skipped non-Digilent device 1
490087707       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - interface list contains 0 devices
490087711       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - OpenEx failed on serial 210383142250A, erc = 2
490087716       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - OpenEx failed on serial 210383142250B, erc = 2
490087720       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - skipped unsupported interface 210383142250C
490087724       28983       1629599488    0       ercNoErc                    FEnumAndUpdateCache - skipped unsupported interface 210383142250D

Above you will see that our ListDevices and CreateDeviceInfo list calls both found 6 interfaces (2 for FT_2232H and 4 for FT4232H). We skipped the first 2 interfaces (shown as devices here) because information received from GetDeviceInfoDetail did not match the minimum set of requirements for them to be considered potential Digilent devices. Things get more interesting once we get past the initial screening.

Entries 6 and 7 of the log file show that the call to FT_OpenEx fails with error code 2 (FT_DEVICE_NOT_OPENED). Since we can't open a handle to the device we can't read the additional information that we require from the EEPROM. Unfortunately this is a bug in FTDI's libftd2xx library, and not a bug in our code. We did not write our own implementation of the entire libftd2xx library... only certain enumeration functions (ListDevices, CreateDeviceInfoList, GetDeviceInfoDetail) and we only did that to work around bugs in FTDI's linux driver. While I could re-write the entire library it would require a lot of work, possibly even more work then it would require to re-write the rest of our code to use D2XX on windows and libftdi on Linux/OSX. In any case, that's more work then I will receive approval to do. So for now the best I can do is report my findings to FTDI and try to pressure them into fixing libftd2xx.

I'm curious to see what the enumeration log shows on your system. Can you please download this package that includes the logging and give it a go:

https://www.dropbox.com/s/z7qy2herknvp1c4/digilent.adept.runtime_2.19.1-amd64-debug.deb?dl=0

In order to enable logging you will have to execute "export ADEPT_RT_LOGFILE=adept_log.txt" and "export ADEPT_RT_LOGDETAIL=5" prior to executing "djtgcfg enum".

Thanks,
Michael

Arvid · September 26, 2018

Hi malexander,

FT_GetDeviceInfoDetail(0)
  Flags:  0x00000002
  Type:   0x00000008 (FT_DEVICE_232H)
  Id:     0x04036014
  LocId:  0x0000010e
  Serial: 210299A06B5F
  Desc:   Digilent USB Device
FT_OPEN(0) returns FT_OK

FT_GetDeviceInfoDetail(1)
  Flags:  0x00000002
  Type:   0x00000006 (FT_DEVICE_2232H)
  Id:     0x04036010
  LocId:  0x000010f1
  Serial: 
  Desc:   Dual RS232-HS A
FT_OPEN(1) returns FT_OK

FT_GetDeviceInfoDetail(2)
  Flags:  0x00000002
  Type:   0x00000006 (FT_DEVICE_2232H)
  Id:     0x04036010
  LocId:  0x000010f2
  Serial: 
  Desc:   Dual RS232-HS B
FT_OPEN(2) returns FT_OK

malexander · September 24, 2018

Hi @Arvid,

Is there any possibility that you can call from your libftd2xx based application and tell me what it reports for the device type, serial number string, and description string of the JTAG-HS3 when it's not visible via djtgcfg?

Thanks,
Michael

Arvid · September 21, 2018

Hello Malexander,

No, root permissions does not make any difference.

And when I have the setup where the JTAG-HS3 is not found, if I pull out the power on the board with the FTDI chip (USB cable still connected to PC), then the JTAG-HS3 starts to work. And if I plug in the power to the FTDI device once more, the JTAG -HS3 is not found any more.

$ sudo djtgcfg enum
[sudo] password for arvid:
No devices found

$ sudo djtgcfg enum
Found 1 device(s)

Device: JtagHs3
Product Name: Digilent JTAG-HS3
User Name: JtagHs3
Serial Number: 210299A06B5F

$ sudo djtgcfg enum
No devices found

I have tried doing the same experiments with JTAG-HS1 and JTAG-HS2, and I get the same behaviour. I have tried with a FTDI FT2232H and a FT4232H device and I get the same behaviour.

To add more confusion, I have my own application that enumerates FTDI devices (this application can either use the the official libftd2xx or the open source libftdi to enumerate FTDI based devices). An it finds the the JTAG-HS3 dongle (and the FTDI device).

/* Using the libftd2xx */
DWORD cnt = 0;
FT_DEVICE_LIST_INFO_NODE node = {0};
if (FT_CreateDeviceInfoList(&cnt) == FT_OK) {
	for (int i=0; i<cnt; i++) {
		if (FT_GetDeviceInfoDetail(i, &node.Flags, ... , &node.Description, &node.ftHandle) == FT_OK) {
          	/* Print devices */
			...
		}
	}
}

/* Using libftdi */
struct ftdi_context *ftdi = ftdi_new();
int vid[] = {0x0403, 0x0403, 0x0403};
int pid[] = {0x6010, 0x6011, 0x6014};
struct ftdi_device_list *devs;
struct ftdi_device_list *dev;
char name[64] = {0};
int cnt;
for (int j=0; j<3; j++) {
	cnt = ftdi_usb_find_all(ftdi, &devs, vid[j], pid[j]);
	dev = devs;
	for (int i=0; i<cnt; i++, dev = dev->next) {
		ftdi_usb_get_strings(ftdi, dev->dev, NULL, 0, name, sizeof(name)-1, NULL, 0);
		/* Print devices */
		...
	}
}

However, if I try to list all Digilent JTAG dongles, using the Digilent Adept SDK, it's not found (similar to djtagcfg). So the device seems to get lost somewhere in the Digilent Adept software.

/* Using Digilent Adept SDK*/
int ndvc;
DCAP dcap = dcapJtg;
DmgrEnumDevicesEx(&ndvc, dtpUSB, dtpUSB, dinfoDCAP, &dcap);
DVC dvc;
char name[cchProdNameMax+1] = {0};
for (int i=0; i<ndvc; i++) {
    if (DmgrGetDvc(i, &dvc) == fTrue) {
		/* Print devices */
		if (DmgrGetInfo(&dvc, dinfoProdName, name) == fTrue) {
			...
		}
	}
}

My application never use the JTAG-HS3 via the ftdi libraries directly. It only use the ftdi libraries to communicate with stand-alone FTDI devices. The application only uses the Digilent Adept SDK to communicate with the JTAG-HS3, even if it can be found via the ftdi libraries.

Is there any other information that I can provide?

malexander · September 19, 2018

Hi @Arvid

I can't seem to replicate this behavior in my Ubuntu 18.04 VM using an a blank FT2232H and a JTAG-HS3. I'm just curious, have you tried executing "sudo djtgcfg enum" after "djtgcfg enum" fails to find the JTAG-HS3? Perhaps there is an issue with the permissions being set correctly upon attachment.

Another possibility is that an FT2232H with no EEPROM functions differently than an FT2232H with a blank EEPROM (what I tested with). I don't have a board that doesn't have an EEPROM. However, I can probably desolder the EEPROM from a board and see what happens.

Ok - even with the EEPROM completely removed I still can't replicate this.

Thanks,
Michael

Arvid · September 13, 2018

Hello JColvin,

The FTDI device always works, it doesn't matter which port its connected to. I have also seen the same behaviour on another computer.

JColvin · September 13, 2018

Hi @Arvid,

As an additional follow-up question since I missed asking it the first time (I apologize for the confusion), it looks like when you were able to get the JTAG HS3 to work you just swapped USB ports with the other FTDI device? Does the other FTDI device work on this first USB port that the JTAG HS3 was not working on? Just so we can more readily confirm that there is not a non-functional USB port.

Thank you,
JColvin

Arvid · September 12, 2018

Hi

I have tried both directly in the PC and using a USB hub. I get the same result.

No processes is using the FTDI device, it is only connected to the computer. Removing the ftdi_sio kernel driver does not make any difference.

JColvin · September 12, 2018

Hi @Arvid,

I have asked another engineer about this; I'll let you know when I hear a response back. As a clarification question though, are you connecting the JTAG HS3 and this other 3rd party board to their own individual USB ports on the PC or are you connecting them to a USB Hub?

Thanks,
JColvin

Digilent JTAG-HS3 not discovered

Question

Link to comment

Share on other sites

19 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Archived